Some price rounding issue #795
Lots of description, still unclear which rounding types (back office -> Preferences -> General) get used:
Over the last two days I reviewed this rounding business. There were lots of hardcoded values rather than usage of constants. Problem with the rounded line was that it rounded to the wrong precision. PS used the same value for
The tax thing is more tricky. Products store their prices always with high precision. Which means, taxes have to get re-calculated after rounding, depending on what gets displayed. Currently taxes get fetched from the product and rounded after that.
Next task will be a review of orders. They apparently have their own calculations, which isn't ideal. Turning a cart into an order should take prices from the cart as-is, to avoid any potential for deviations from the cart.
This should fix remaining parts of issue #795. The option to kind of re-engineer the tax rate by comparing a price with and without tax was choosen, because applying taxes is a pretty complex business and the last thing we need is another place implementing it. Computation precision should be sufficient.