[
http://issues.apache.org/jira/browse/OFBIZ-224?page=comments#action_12434176 ]
Leon Torres commented on OFBIZ-224:
-----------------------------------
This raises an interesting issue in my head: We are assuming that these prices (currency and currency-precise) are two decimal digits precision or three or whatever, and our tests are based on that. If an implementer has requirements that these be be 4 or 5 decimal digits, they'll probably run into many more bugs like this, simply because we haven't tested for them.
So why are we assuming that the currency fields must have 2 or 3 decimal digits? Wouldn't it be better to have arbitrary precision in the database? Wouldn't it be more normalized that way? We can handle the precision requirements in the services and business logic, where they belong. The validation of data input into the fields can be handled transparently, perhaps using GenericValue.setBigDecimal(value, precisionRequirement, roundingModeRequirement). I would prefer to use an OfbizCurrency object and a requirements-based OfbizCurrencyFactory where all this can be handled in a standard way, without people having to mess with immutables, rounding issues, and scattered configuration.
Sorry for the digression, but I worry that we're overlooking a big issue just as we did when using primitive doubles to handle the currency computations.
> Problem with approximations if the ShoppingCart.basePrice has more than three decimal digits.
> ---------------------------------------------------------------------------------------------
>
> Key: OFBIZ-224
> URL:
http://issues.apache.org/jira/browse/OFBIZ-224> Project: OFBiz (The Open for Business Project)
> Issue Type: Bug
> Components: order
> Reporter: Jacopo Cappellato
>
> There is a problem with approximations if, in the ShoppingCartItem.basePrice field, a value with more than three decimal digits is set.
> This can happen mainly for two reasons:
> 1) the price in the ProductPrice entity has three decimal digits (it is now possible because that field is now of type currency-precise)
> 2) the base price is calculated from a price rule
> The problem is that, when the order is stored in the system, the unit price is approximated to two decimal digits (in OrderItem); unfortunately all the calculations (adjustments etc.) are performed with the original value with more than three decimal digits.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Locked
