fix multicurrency on supplier invoices

[thomas-Ngr]

FIX multicurrency total is wrong on invoices

If a currency (ex. USD) invoice contains many lines, the main (ex. EUR) price may be wrong.
This is due to EUR total being sum of EUR price for each line. This bug exists at least from 14.0 to develop.

This PR makes the EUR total be computed from the USD price.

example wrong (140/1.1 = 127.272727 => 127.27)

example right

[eldy]

Even if 140/1.1 = 127.272727, the total on 2 digits is not necessary 127.27.
Because total is not the round of the final result but the sum of several rounded values. So it depends on how we make the rounding on each detailed line. Because we must make a rounding on each line, the total is the sum of each rounding. And, if a lot of lines are rounded higher and few are rounded lower, the total may be rounded higher instead of lower at the end.
So can you identify on each line among all detailed lines, there is an error and paste the screenshot of it.

i recommand to first try to reproduce on develop branch, because on develop, I added a feature so you can see the detail in detabase whe you put your mouse on the amount. Exemple on this screenshot:

If there is a bug, we must first found on which line there is the bug and check that total is correctly sum of each line (it must ALWAYS be the sum of each detailed line, so if there is error, it will be in the way we store the line).

[thomas-Ngr]

Because total is not the round of the final result but the sum of several rounded values.

It is. But in the case of a document labeled in foreign currency (USD in the example), the total that must be used is the USD total, not the EUR total. Otherwise rouding made on each line will sum up to always greater errors. If the document is labeled in foreign currency, then the numbers to compute on are the numbers labeled in foreign currency. Total in EUR has to be accurate with total in USD.

So can you identify on each line among all detailed lines, there is an error and paste the screenshot of it.

There is no error on any line. The error is to get the EUR total as the sum of each EUR line instead of converting the USD total to EUR value. since the invoice is labeled in USD.

---

Take the example of 10 times the same product. One line with qty 10 should give the same total than 10 lines with quantity 1, for consistency, right (tests done on a fresh develop install) ?

One line with qty 10 : total USD 624,00 ; total EUR 567,27 (right computation)

10 lines with qty 1 : total USD 624,00 ; total EUR 567,30 (wrong computation)

With qty 100 you would get 27cts of difference :

• on one line : ROUND(52×1,2×100 /1.1) = 5672,73 EUR (which is equal to 6240/1.1; so it is accurate with currency price)
• on 100 lines : ROUND(52×1.2/1.1) × 100 = 5673.00 EUR (which is not equal to 6240/1.1, so it is not accurate with currency price

[eldy]

No, the total of round is not the same than the round of total.

So having 10 times the same product is NOT always the same than 1 time the product in qty 10. The reason is that you setup your app to get a rounding on 2 digits on each lines.
You can see on your screenshot that when you have 1 line, that total is 472.73 and when you have 10 lines, each line has a total of 47.27.
In both cases, the total in foreign currency, the the total in main currency * 1.1, then rounding on the 2 digits, as expected for euro and dollars

So everything is correct.

And the final amount on invoice must be the sum of each line. And your screenshot show that result is correct: 472.73 for first cas and 472.70 in the second case. This is the expected value.

So yes the rate on final amount is not exactly 1.1. This is because the rate of 1.1 must be good on each lines, not on final total. You can't have both the rate that is exactly 1.1 on both the detail of line and on the final total. This is mathematically not possible.
So both of your screenshot give the expected result.

You will get the same effect with VAT calculation.
The total of rounding is NOT the rounding of total !
So we have to make a choice where is the accurate side: On lines or on final total.
Because the accountancy rules are to have the best accuracy on lines and not on total, the choice done by Dolibarr, like most accounting software, is to have the accuracy (the exact ratio) on line level.

[thomas-Ngr]

ok, thanks.