Price precision not respected


#1

As we had the need to increase the price precision for our customer, I’ve stumbled upon the DecimalToIntegerConverter::PRICE_PRECISION respective IntegerToDecimalConverter::PRICE_PRECISION constants.
But they are not used in most of the Spryker code.

So far I’ve found the following parts which cannot handle a higher price precision by the core:

  1. Currency formatting has no conversion from a potential higher price precision before the price is formatted (affects Zed, Yves & Glue)
  2. Absolute discounts are not converted into a potential higher price precision, neither they are stored in higher precision. Therefore applying an absolute discount will apply a lower discount, depending on the price precision. (e.g.: Price Precision 1000 instead of default 100 will apply a 10€ discount as 0,1€ instead)
  3. Absolute expenses are not converted into a potential higher precision, neither they are stored in higher precision. Therefore applying an absolute expense, like shipping costs, will add a lower expense than expected. (e.g.: Shipping costs of 4,95€ will be applied as 0,49€ with a price precision of 1000 instead of 100)
  4. Price data importer does not respect price precision either, but this could be discussed if it is expected behaviour as the project may already import from a dataset which contains the higher price precision.

As adapting the price precision constants was the official solution to increase the price precision, according to Price as decimal I would expect that those constants are used in the code as they provide only a partial solution for now and therefore are mostly useless without adapting a few other parts of the code.


#2

I’ve found a small related bug in https://github.com/spryker/tax/blob/master/src/Spryker/Zed/Tax/Business/Model/PriceCalculationHelper.php#L107 where the price is cast to integer but the netPrice is used in the following code, so casting does not have any effect.
As this is one of the parts which needs to be adapted to fix the tax calculation in the case of a higher price precision, we had the need to overwrite this anyway, so it’s not a big issue, just a little strange behavior.


#3

Hi Alberto,

Thank you for the feedback. The ticket is created. I will notify when it’s investigated/fixed.

Best regards,
Valerii