> 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)
I agree : we must set an unit and this can't be sub atomic. Jacques > Jacopo >
