David, Jacopo, I wonder if this is related with the patch proposed by Géraud Buxerolles : modification of conversion services https://issues.apache.org/jira/browse/OFBIZ-302
Géraud made a 10 pages explanation of his work in french. I know that his patch is now a bit old and that if we commit it we will have to replace the licence headers. But it might be interesting to take a look at it. I have asked the same question to Neogia people. I don't know yet if they are really using the work of Géraud. What do you think ? Jacques ----- Original Message ----- From: "Jacopo Cappellato" <[EMAIL PROTECTED]> > > David E Jones wrote: > > > > I think that non-integer inventory quantities are okay, and for some > > products they are necessary. In fact, is there any way to avoid this > > quite a few manufacturing materials like rope, wire, glue, > > paint/lacquer, and so on? > > > > We are actually avoiding non-integer quantities by selecting for each > product the smallest unit of measure that is allowed in the system for > it; for example, if the consumption of rope in production runs is > expressed in millimeters then millimeters is the quantity of inventory > items, purchase prices are expressed in millimeters etc... > This solves a lot of issues but in the same time introduces new ones, > such as the problem I had recently to express unit purchase prices for > very small quantities... but I guess that when we will finally implement > the support for different uoms in sales/purchase/inventory this will be > solved (hopefully). > > > > > This is interesting, and a little scary... ;) > > > > I've never actually looked into this in detail as Andy is the one who > > implemented it. I don't think I like this implementation decision > > though, so unless someone sees a reason why it would be better this way > > I think we should change it. I _can_ think of a couple of reasons why it > > is worse: it is not very intuitive, and it could lead to inaccurate > > price calculations. > > > > Ok, I think that sooner or later we'll have to fix this part of the > system, and I'd suggest to follow one of the two paths here: > > 1) in the OrderItem, store the original unitPrice, quantity and amount > and then always get the order item subtotal as > unitPrice*quantity*amount; (we could do this for all the products if we > use the convention of storing 1.0 in the amount field for non-amount > products); however I think we should handle correctly the amount field > in the Invoice, Return etc.... I'm not sure it is correctly done now > > 2) replace the amount implementation with something new, such as a true > support for different uoms in sales/purchase orders and inventory > > Jacopo >
