New field to specify the internal uom of products

[David E Jones-2]

On Sep 20, 2006, at 5:35 AM, Jacopo Cappellato wrote:

> 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).

I can see this as potentially rather inconvenient. It would mean that  
most companies won't be able to use whatever measures they currently  
use for materials, and it will force them to use very small units or  
to approximate quantities and not worry about the differences, though  
that may be bad for more expensive materials, or lead to inaccurate  
or inconsistent measures of waste materials and such.

I guess I'm not seeing the reasons why we need to avoid decimal  
numbers for inventory quantities and stick to integers... could you  
describe your thoughts on this?

>> 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

I'm interested in what #2 might entail, but I still don't see how  
with better UOM support (which we certainly need) we could avoid the  
need for the amount and amountUomId fields... For products that are  
custom measured and not unitary by nature, how else would you treat  
them?

-David

[Jacques Le Roux]

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" <[hidden email]>

>
> 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
>