OFBiz
  1. OFBiz
  2. OFBIZ-224

Problem with approximations if the ShoppingCart.basePrice has more than three decimal digits.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: order
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Leon Torres added a comment -

          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.

          Show
          Leon Torres added a comment - 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.
          Hide
          Jacques Le Roux added a comment -

          This is still an important issue, isn'it ? Or do I miss someting and it should be closed ?

          Show
          Jacques Le Roux added a comment - This is still an important issue , isn'it ? Or do I miss someting and it should be closed ?

            People

            • Assignee:
              Unassigned
              Reporter:
              Jacopo Cappellato
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development