David,
David E Jones wrote:
>
> Will this require using sub-unit quantities? That's something we've
> started moving away from, and I'd prefer to continue that...
>
> -David
>
no, I agree with you that we should really avoid this (i.e. in inventory
items the qty, reservations, QOH and ATP will always be integers numbers).
I've thought a bit about this, and I think that the trick here is that
the unit in the uom set in Product.quantityUomId should be the minimum
indivisibile entity of a product.
For example, if quantityUomId = "centimeters", this means that we will
purchase, sell (or consume) and stock the product in centimeters (not
millimeters).
And the unit price (in ProductPrice) will be referred to one centimeter
of the product.
In this way, I think, the system will work fine as is now; the only
modification I will do is to store the Product.quantityUomId (in not
null, i.e. if not 'units' or 'each' uom) in the already existing
InventoryItem.uomId (every time newly inventory items are created for
the product).
Is this ok?
And, continuing with the example above, (sorry for the long post, but
this is very similar to the issue I'm facing with
SupplierProduct.lastPrice, discussed in another recent thread) if the
product is consumed/stocked in centimeters but we need to specify the
unit price for one meter (because we will sell it in 'units' of 100
centimeters long) we could represent it in the following way:
Product.quantityUomId: "centimeter"
Product.quantityIncluded: 100
ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
the product, i.e. one meter)
In order entry, if I enter a quantity of 2, in the cart the new item
will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).
Does this make sense? (I'm not sure it is 100% correct)
Jacopo
