http://ofbiz.116.s1.nabble.com/Re-Dev-OFBiz-JIRA-Commented-OFBIZ-826-Order-Unit-of-Measure-tp167770p167773.html
I don't know if any back-end support was ever added when amount field was added. In fact, I don't think even the stuff I recommended when it was discussed was ever finished.
What should probably happen with inventory is to keep a total "quantity" that is the ordered quantity multiplied by the ordered amount (iff an amount is specified). For sales orders the same thing should happen when deducting from inventory for reservation (ATP) and for issue (QOH), ie use quantity * amount, and again iff an amount is specified. Also in both cases the amount UOM should match the inventory UOM or be converted...
So yeah, I imagine some work is needed in this area as given the progression of some of these things chances are the state of things is not all that great...
> David,
>
> yes I know that the amount field can store decimal values. However I
> think that there could be problems when inventory operations are
> considered because I'm not sure that the amount field is currently
> treated correctly there:
>
> 1) are reservations and issuances handled correctly? I think that
> reservations/issuances are done considering the quantity field, instead
> of the amount field
>
> 2) what happens when a purchase order is received? I'm rather sure that
> the amount field is ignored
>
> Jacopo
>
> David E Jones wrote:
>> Jacopo Cappellato wrote:
>>
>>> Ok, so if the prices will be expressed for the units in the sku uom id
>>> then everything will be a little easier (no conversion needed when you
>>> calculate the order item amount); as a consequence, the new field that
>>> will store the sku uom id could be named Product.internalQtyUomId
>>> instead of Product.inventoryQtyUomId.
>>>
>>> The biggest issue I see is that OrderItem.quantity field should be an
>>> integer value (even if the db field allows for decimal values, the
>>> system expects it to contain integer values): so you'll have to manage
>>> this... I'm not sure about the best approach here; comments from others?
>> As I've mentioned before in order to push the quantity to a whole number we introduced the amount field which is meant to be a decimal. For many packaged goods no amount is needed as it is always 1.0, but for something like rope or boards that are custom cut or other things like that, the amount would be used along with a UOM to specify exactly what is being ordered.
>>
>> -David
>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev>>
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev