Wrong tax calculation

[gandalf]

In a B2B store, we are using round each item, 2 decimal, and we set all products with price excluded taxes. Some customers has a group discount (ie, 5%)

Tax calculation is wrong, probably it doesn't round the product price before calculating the tax amount. In example, 22% of 12.1753 is = 14.8538 but when using 2 decimal, 22% of 12.18 is 14.8596 that is 14.86. This is 1 cent more. If you have multiple items in the cart, in example, a product with 48 or 56 bottles, you have some euros less.

This is the same in PS 1.6 to 1.7.2, there are some long-date opened bugs with no fix (they are focused to some "higher priority" tasks than fixing the tax calculation O_o )

Probably , PS/TB internally are using the number without rounding (so, with 4 decimal precision) because in psorderdetail I can the product stored with 4 decimals, in example, we have a product (real "correct" price is 4.85) stored as "4.845000" in psorderdetails.

Customer bought 6 of this, thus real total price should be 4.85*6 = 29.10 but PS/TB is calculating it as 29.07 In backoffice I can see the correct price (29.10) but the total tax calculation for the whole cart is wrong, as it is calculated based on 29.07

[Traumflug]

My current higher priority is getting the 1.0.8 release out of the door :-)

Because each time I tackle such a fundamental bug I run into many minor issues, which are solved fairly quickly, but nevertheless another week is gone. And merchants see nothing of all this work, which is bad.

That said, a wrong price calculation is a high priority issue, of course. thirty bees also provides multiple ways of rounding prices, some merchants might consider the calculation you see as correct. Setting is in back office -> Preferences -> General, there's Round mode and Round type Please try these to find out whether one of these settings matches your expectation.

[gandalf]

No, is not correct for all, because is not respecting the rounding. If you choose a rounding schema, you have to use the same schema everywhere.

Currently, the admin interface is rounding in a way (regardless the rounding schema set in the back office), product prices are using the rounding schema configured but tax calculation not.

If I set to use a certain rounding schema, the same schema must be used for vat calculation or the ending result is to calculate vat on a wrong price.

As wrote above: product price is 12.18 (rounded properly), thus you have to calculate vat on 12.18 and not on the "original" not rounded price (12.1753). If you do so, at least in the whole europe, you are calculating taxes on a wrong amount and the is a mismatch even in what customers see: total price 12.18, vat (22%) 14.85 but should be 12.18+22%=14.86

[Traumflug]

If I set to use a certain rounding schema

There is always a rounding scheme in use. One can't switch this off. These schemas distinguish by exactly what you complain about. And "in whole Europe" isn't an argument, because thirty bees has to work for every merchant on this planet.

If thirty bees doesn't round the way it's set in back office, it's a bug. If it doesn't round the way you like it, change this setting. There is no one-size-fits-all rounding scheme.

[gandalf]

It Is a bug, that Is why i have opened this post in the bug section

Tax calculation doesn't respect the choosen rounding schema. Additionally, the back Office seems to not respect the rounding schema because if I set to round only the total (and not each item) prices in the order detail, are still rounded one by one (it can't be differently, PS/TB stores prices as 4 or 6 digits on database but only show 2 digits in backoffice, thus there Is a rounding somewhere even if i set to round only the total)

In other words, rounding only the totals (this Is not what i want but it's easier to explain) will make inconsistecies on what administrator see (each price for each ordered item) to what PS/TB calculate as Total If you manually put each order line (rounded one by one regardless the rounding schema) to Excel and make a sum, the order total doesn't match

To fix this i have set to round each item. This will fix the inconsistecies issue between the back office and the order total , but tax calculation Is still made by using the original, not rounded, 4/6 digits price so now there is an inconsistency between the order total and order vat

On PS there are at least 10 or 15 bugs regarding the rounding issue, vat calculation and so on. I've thought that in TB , forked to be more focused on bug fixing than adding new buggy-features like PS, these where fixed but I've seen the same bug even here

[gandalf]

This happens in B2B stores, where vat must be added (in a B2C vat is included in the product price and as so you don't have vat calculation to do) AND by using a customers group discount like 5%

If product price ex-vat is 9.55 and customer has a 5% discount on it's group, sold price is 9.0725

From now on, each calc Is wrong, on on tax, or on what Is shown in the backoffice or on order total, based on what Is used for rounding (that Is not consistent)

[gandalf]

Simple example, i've attached a screenshot. Current rounding schema is: "Round up away from zero", "Round on each item", 2 decimals

backoffice:

cart on the frontend:

€ 9.07 * 24 is NOT € 217,74 but is € 217,68

The error is coming form the rounding. This product has an original price (ex vat) of € 9,55 The customer group has a 5% discount, thus: € 9,55 - 5% = € 9.0725 not rounded.

If you do € 9.0725 * 24 you'll get € 217,74 but I've set round on each item, so PS/TB should round each product (€ 9.0725 to € 9.07) then multiply it for 24.

There are two issues in this: 1) the frontoffice and backoffice are still showing the proper product price (€ 9.07) but any following calculation are wrong, so in the same page (frontoffice or backoffce) there is a product price that multiplied to the ordered quantities doesn't return the shown price. This is wrong and misleading for customers and administrators)

2) VAT is calculated on the wrong price (the non-rounded one) thus there is also a fiscal issue.

EDIT: changing the rounding schema doesn't help, because on frontend and on backoffice you must round each product item to show it as 2 decimal. Thus even by setting the rounding procedure to each line or to total, you'll still get the same rounding issue. Internelly PS/TB is using the non-rounded price but is showing the rounded price to 2 decimals, so a rounding on each item is mandatory (at least for viewing the cart).

[gandalf]

rounding each item makes another issue: PS/TB is rounding each product, even when calculating taxes, so:

9.07*24 = 217,68 then, when calculating price with tax, it does: round(9,07+22%) = 11,07. 11,07 * 24 = 265,68 Total VAT is 265,68 - 217,68 = 48 euros.

This is wrong, real vat is: ((9.07 * 24) + 22%)) - 9.0724 = 265,57 - 217,68 = 47,89 That is equal to: 9.0724*22% = 47,89

Setting rounding to the total expose to the original issue: frontoffice and backoffice are still rounded to 2 decimals for viewing, so is misleading to customers, it would be shown a price that is different from the price used for calculating taxes and sums.

Another question: why there is a TBPRICEDATABASEPRECISION_ constant hardcoded to 6 ? I've tried to set it to "2", the same as backoffice and this fixed all rounding issues except for the tax calculation (as wrote above)

[gandalf]

There is also a paid module to fix this bug: https://www.presta-addons.net/en/content/7-incorrect-tax-rounding-and-application-in-prestashop-161

[Traumflug]

https://github.com/thirtybees/thirtybees/issues/795