[
https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855430#action_12855430
]
Bob Morley commented on OFBIZ-3666:
-----------------------------------
I agree specifying any precision seemed incorrect; but the reality is these
services were specifying a precision of 2 and I simply wanted to correct this
with the maximum precision of the data type so that rounding would not occur.
So in this case I am just making it work without a "higher risk" change that
may break the implementation.
As for the set field; we are a little out of step but has the type conversion
changed? I would have thought that value would be picked up by the
FlexibleStringExpander so you would get a properly typed result which would
then be converted to a String and assigned to the field. We ran into problems
with this when we corrected localization which would cause the value to be
formatted with a comma which would later cause problems parsing back to the
numeric field. Keep in mind we are working with a trunk that we last merged
about six months ago, so I understand some of this may have changed.
> 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.
