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. >
