[
https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855435#action_12855435
]
Adrian Crum commented on OFBIZ-3666:
------------------------------------
No, the type conversion hasn't changed. The issue is there is no type to
convert to. Quantity should be a type, and Money should be a type. Strong data
typing would prevent applying quantity precision to a money, and money
precision to a quantity.
> 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.
