http://www.martinfowler.com/ap2/quantity.html
http://timeandmoney.sourceforge.net/
Adam Heath wrote:
Adrian Crum (JIRA) wrote:
[ 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.
Not replying to jira just yet.
I'm interested in working on typed-Foo conversion, in a generic
fashion. Might need to add yet another library, maybe a Units
library, time to do a google search.
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.
