Prestashop: Computing tax amount issue with rounding

[matks]

With we have identified a possibly complex topic with @atomiix . I will try to explain it but it's quite complex 😅 however it's important.

The problem

In PrestaShop, we store prices with 6 digits in order to have computations as accurate as possible, especially when applying discounts or tax rates where it is necessary to have more digits than what is stored (= for EUR, 2 digits are used so for accurate computations, more than 2 digits are needed)

The topic is about about tax amounts.

Tax incl. price = (tax excl. price ) x (tax rate)
Or
Tax incl. price = (tax excl. price ) + (tax amount)

When we need to display this tax amount, usually in PrestaShop we compute it by doing a substraction of tax incl. price minus tax excl. price .

The issue could arise when rounding is involved.

See the following situation:

| usecase | tax incl. price | tax excl. | tax amount |
| -------- | --- | --- | --- |
| stored in database, with 6 digits | A1 | A2 | A3 |
| rounded for use | B1 | B2 | B3 |
| displayed | C1 | C2 | C3 |

"Stored in database" is self-explanatory
In this line, A3 = A1 - A2

"Rounded for use": let's say we want to send a payment gateway the data it needs, we are going to send at least B1 and B2, maybe B3 too. If the customer pays in EUR, we are going to use the numbers stored in database and round them to 2 digits.

"Displayed": in PrestaShop we display these numbers to customers and merchants after rounding them for the currency used to display (for example in the invoice)

The issues could arise if, in the source code, we compute
C3 = C1 - C2
but
B3 = ps_round(A3)

@atomiix found at least 1 location in the code where this problem arises

The idea behind is that the rounded tax amount can be computed by 2 different ways:

• by substracting tax incl. by tax excl.
• or by rounding the stored tax amount

If the 2 numbers obtained by these 2 methods differ, then it's possible that the customer pays a tax amount different from what he was displayed (although very close, and probably accurate).

What should we do ?

We should

1. check whether the 2 computation methods are valid, from a legal point of view
2. check whether they happen in PrestaShop
3. decide what to do when the 2 numbers differ*

*I think that B3 is more accurate than C3 however C3 is more logical for the customer. If we display B3 instead of C3, customer might wonder "how can the tax amount I am shown is different from 'tax incl.' minus 'tax excl.' ?"

[khouloudbelguith]

Related to https://github.com/PrestaShop/PrestaShop/issues/9779#issuecomment-415125166

[Hlavtox]

@matks Also take into account that every country can have different ways of computing VAT.

For example, in Czech republic, we have 21% VAT.

Until now, a correct way to compute tax FROM THE TOP was by using a coeficient:
VAT 21 % = 0,1736 × 229,9 = 39,91 Kč

But half year ago, the law changed:
VAT 21 % = 229,90 − (229,9 ÷ 1,21) = 39,90 Kč

[eternoendless]

We should never perform operations on amounts which have already been rounded up, except in very specific conditions: that there's a setting that controls when rounding is performed (either when calculating subtotal for each cart row, or for the grand total).

Logically, tax calculation should be calculated and stored separately, and not inferred from rounded up results. By this I mean that we should calculate and store everything, then display results rounded up to the appropriate number of decimal places according to the currency.

Also, I think that prices should always be rounded up (otherwise you could end up with a product with price 0), while taxes should be rounded half-up.

Here's a little comparison table.

Regardless of what I say, price calculation should be subject to a formal specification.

[Hlavtox]

Also, I think that prices should always be rounded up

I think you guys should get a lawyer for this topic, this is nonsense... 👍

The rounding must be absolutely correct, our accounting lady always wants to kill me when there is a 0.01 CZK floating around somewhere. 😃

[eternoendless]

I think you guys should get a lawyer for this topic

I agree, this is why I'm calling for a formal specification.

The subject of the missing or extra 1 cent is unclear to me. I said about rounding prices up to avoid very small prices to be rounded down to 0:

[Hlavtox]

@eternoendless In prices approaching zero, thats questionable, but you cannot just say “lets round tax up”, because you like it that way.

[MatShir]

17045 is it linked ? @colinegin @atomiix

[atomiix]

17045 is it linked ?

@MatShir Yep

[Betafer]

Please fix this !

[Gipielle]

Problem also present in Prestashop 1.7.6.3

[joachimdoerr]

One of the most important features of a online shop is to calculate prices correctly. Strange that prestashop is not abel to do that and strange that the issue is open since months. When can we expect this major bug to be fixed?

[Gipielle]

One of the most important features of a online shop is to calculate prices correctly. Strange that prestashop is not abel to do that and strange that the issue is open since months. When can we expect this major bug to be fixed?

Kudos !

[skerbis]

Please! You really should fix it. It could be a reason to switch to an other Shopsystem.

[joachimdoerr]

@matks One question: What are you waiting for? To fix that issue is from my opinion priority one!

[Betafer]

Problem also here: #18513

[ttoine]

Hello, if you look at the Epic https://github.com/PrestaShop/PrestaShop/issues/19445, you will see that the problem is defined and some work has been done already for the 1.7.7.

That said, this is an open source project, and the PrestaShop company is just the most important contributor to the PrestaShop open source project. If this is very important for your business, please consider to help with a contribution to fix it, or hire a freelance that can do it for you if you are not a developer. The maintainers will certainly enjoy to review pull requests on this very topic and help contributors to do it well regarding the architecture, if needed.

[joachimdoerr]

@ttoine in case of that is really your and your company's view on a shop-software and opensource projects than pleas stop directly that project. Due to the problem they have incorporated, all prestashop owners in germany commit tax fraud due to the rounding errors in terms of tax law.

[eternoendless]

@joachimdoerr Please read the project's licence, in particular article number 7 and 8.

It's up to integrators to verify tax compliance in their own territories, and in the spirit of open source, submit the required changes to the project so that everyone can benefit from them. You're completely missing the point.

[joachimdoerr]

@eternoendless what i don't overlook is that this major problem has been open since january. it is not the task of users of their software to fix such precarious core specific bugs. relying on the license at this point is just not a good style. this suggests that the company lacks the competence or personnel to fix a core specific major bug within 9 months. And i think it will continue. Finally I will have to change all my shops from prestashop to something functional. And the operators' investment in modules will probably have to be recorded as a loss! After all customers have been advised against prestashop and it may be necessary to publish this in the press in order to warn at least German and other European operators of this dubious problem under tax law, module sales will certainly decline noticeably, as will the relevance of prestashop. Sad!

[ttoine]

The PrestaShop software is a project anyone can download to use as a base. It is not at all a ready to use product with support and SLA, not at all a SaaS, not at all a freeware. So, you are actually using the project to build a solution to buy/sell online. And by the license, you are responsible for the use you have of the software.

Well, again, if this is a serious problem for your business, you can fix it (the code is open and the license allows you to modify it) and, eventually be fair with the project and share the fix in a contribution to the project (the license is made to manage collaborative writing of the software)

There are currently around 300000 online shops running PrestaShop globally. Small, medium, but also very big companies. So it means that accountants and merchants have found a way to work with it unless it's fixed. That's why using open source software is interesting.

Unfortunately, it seems that fixing this kind of issue represent a lot of value for people with this knowledge, and they seem to prefer to sell it to merchants. That's why, I guess, there is not a lot of contribution right now to fix this issue. BTW, it means that maybe, there is a module for that, specific to your country's law and accounting rules?

That said, you are right, this is an important issue. That's why it has been document in an EPIC, and why it takes time to fix it. Because, rounding and taxes, in accounting, is very different from country to country, and making it to work in all cases is very complicated. The current work is to replace float with integer: look at the decimal repository, and write automatic tests. Also, don't forget that a looooot of third party modules have an impact on price & taxes computing, and any improvement made to the core must not break the retro-compatibility.

But now, let's speak a bit about you: what is your contributor (or your company) status to the project? did you test the Beta 1 & 2 of 1.7.7 to check if the issue is still present? in what way(s) do you contribute?

[ttoine]

BTW: if you need to learn the difference between a project and a product, there are some resources here:
http://blog.ttoine.net/about-open-source/

Particularly:
https://opensource.com/business/15/8/open-source-products-four-rules

[joachimdoerr]

@ttoine from my side it sounds like you are creating major problems in your shop software to get the opportunity to sell some modules there to fix these problems. We can talk about me. Maybe i could solve that issue. If it is important enough for you or your company, you can provide a sufficient budget for it.

[joachimdoerr]

BTW: if you need to learn the difference between a project and a product, there are some resources here:
http://blog.ttoine.net/about-open-source/

Particularly:
https://opensource.com/business/15/8/open-source-products-four-rules

are you kidding me? Pleas fix your issues and stop that vendetta.

[ttoine]

If it is important enough for you or your company, you can provide a sufficient budget for it.

That's the point. And, it also apply to you and your company. Actually, it also apply to anyone or any company.

Let's stop this discussion for now. And let the place to people who will fix this issue.