You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Bob Morley (JIRA)" <ji...@apache.org> on 2010/04/09 16:07:51 UTC

[jira] Updated: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision

     [ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bob Morley updated OFBIZ-3666:
------------------------------

    Attachment: OFBIZ-3666_DoNotRoundPreciseQuantity.patch

> Errors attempting to use quantities with more than 2 decimals of precision
> --------------------------------------------------------------------------
>
>                 Key: OFBIZ-3666
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-3666
>             Project: OFBiz
>          Issue Type: Bug
>          Components: order, product
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>            Priority: Minor
>             Fix For: SVN trunk
>
>         Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch
>
>
> We have a need to handle inventory items with quantities up to four decimal places.  The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision.  What I found was ...
> - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect.  This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2).  Since this is being used as a calculation it should not be rounded -- the total itself should be rounded.
> - In a number of spots in issuance and reservation services values were (sometimes) being rounded.  For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value.  All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd).  The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision.  Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.