Rounding issue while adding shipping cost tax and goods tax

[mamhoff]

We have the following case: We enter prices with VAT included (hello, this is Europe speaking 🎉)

When we have a price of a good of 8,50 EUR (VAT incl)
And we have associated shipping costs of 1,65 EUR (ALSO VAT incl)
We would expect the rounded total VAT to be 0.55607 + 0.10794 = 0.6640 ~ 0,66 €

However, Spree comes up with 0,67 EUR. We suspect this is due to that Spree adds the already rounded individual tax values:
(0.55607 ~ 0,56 EUR) + (0.10794 ~ 0,11 EUR) = 0,67 EUR

We expect rounding to occur after summing tax values for individual line items and eventual adjustments (like shipping and promotions).

Since calculating taxes in Spree is quite complex and has to cover lots of different use cases, we're hesitant to come up with a PR at this point; however, if you could guide us as to where and how this could be fixed, we'd give it a try.

Thanks!

[JDutil]

The line item taxes are calculated within the TaxRate model:
https://github.com/spree/spree/blob/master/core/app/models/spree/tax_rate.rb#L82-L100

The accumulation is calculated here:
https://github.com/spree/spree/blob/master/core/app/models/spree/adjustable/adjustments_updater.rb#L32-L46

I'm not sure what the best way to fix this would be, and think this may be duplicate of another issue. I'm not spotting any rounding taking place in the code because I believe that our database column is automatically handling the rounding as we've set our scale to 2:
https://github.com/spree/spree/blob/master/core/db/migrate/20130319082943_change_adjustments_amount_precision.rb#L4

So in order to fix this I believe we would have to allow greater scale at the database level, and then also ensure everywhere we output the value we round to 2 places... i.e. API responses, frontend views, backend views etc...

[mamhoff]

This is a surprisingly complex issue - and it comes down to the individual shop's needs: In case you would accept payments in a currency with very high value-per-unit, Spree's saving of price data with only two digits of precision can be disastrous (think Bitcoin, for example).

However, if on the website you display prices and taxes with two digits of precision, and because of different rounding behaviour after adding two different line items, that could be, disconcerting to users (especially very meticulate ones), too. Are there any book-keeping experts around to shed light on the matter?

For what it's worth: Magento uses decimal(12,4) for most prices, and decimal(20,6) and even decimal(24,6) for some tax rates and currency conversion fields.

[mamhoff]

After talking to our client's book-keeper, Magento is wrong in calculating so exactly, and Spree is doing it correctly. I'll close this issue now.

[JDutil]

Hurrah better than Magento again.