[
https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855479#action_12855479
]
Jacques Le Roux commented on OFBIZ-3666:
----------------------------------------
I completly agree about stronger data types. But I have often found that
increasing the currency decimals number to its maximum (6) is a workaround when
rouding issues occur. I do it directly in DB fieldtypes and add or change
(depending on the fastness the client wants). Certainly not the best way to do
it, but surely the fastest.
> 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.
