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
