It looks like there is already a unitsIncluded field on the entity
that is a floating-point, just as the quantityIncluded should be.
So, what we should probably do is add a piecesIncluded field that is
a numeric.
I guess it would be something like:
> piecesIncluded = 1 (new field)
> quantityUomId = LEN_cm (centimeters)
> lastPrice = 1$
> unitsIncluded = 10000
-David
On Sep 5, 2006, at 10:56 PM, Jacopo Cappellato wrote:
> Ok, something like this (continuing with my example)?
>
> quantityIncluded = 10000 (new field)
> quantityUomId = LEN_cm (centimeters)
> lastPrice = 1$
> unitsIncluded = 1
>
> Is it correct?
>
> Jacopo
>
> David E Jones wrote:
>> It might be nice to use a pattern here that is similar to the one
>> used on the Product entity, ie the combination of the
>> quantityIncluded, quantityUomId, and piecesIncluded fields. These
>> are pretty flexible, and it would be consistent with existing things.
>> -David
>> On Sep 5, 2006, at 3:41 AM, Jacopo Cappellato wrote:
>>> Let's say I have to purchase a raw material (rope) from a
>>> supplier; the ordered quantity is expressed in centimeters and
>>> the minimum order quantity (and order quantity increments) is
>>> 10000; the price for 10000 is 1$ and so the unit purchase price
>>> is 0.0001$.
>>> This is the summary:
>>> minimumOrderQuantity=10000
>>> orderQtyIncrements=10000
>>> quantityUomId=LEN_cm (centimeters)
>>> lastPrice=0.0001$
>>>
>>> I could not enter this price in the SupplierProduct.lastPrice
>>> field because the decimals allowed there are 2.
>>>
>>> One solution I think is the following one:
>>> minimumOrderQuantity=1
>>> orderQtyIncrements=1
>>> unitsIncluded=10000 (is it ok to use this field or should I add a
>>> new one for this purpose?)
>>> quantityUomId=LEN_cm (centimeters)
>>> lastPrice=1$
>>>
>>> Does this make sense?
>>>
>>> Jacopo
>>>
>>> PS: I've noticed that the SupplierProduct.lastPrice is of type
>>> currency-amount; shouldn't it be of type currency-precise like
>>> the ProductPrice.price field?
>
Locked
