Order Total differs on checkout and checkout review

1) when it comes to the order (grand) total it should always be the sum of the single product prices. which is 19.95 € in above example. you don't want to make a customer angry for one cent...

2) even tough not yet discussed, but still relevant to this issue: I wouldn't try to round the amounts on product / order detail level. if you want each line to be correct and have the sub total matching up - then we would need to display fractions of cents. to see the effect: add 6 different products, each worth one cent to your basket - depending if you have the price incl. or excl. VAT you will see an error of 1 cent in one or the other place when comparing the sum of the single lines to the displayed sum.

3) which leaves us with the problem what should we do with the subtotal and VAT of the complete order? this shouldn't be a problem! when we calculate 19.95 € divided by 119% (bbunse is from Germany, 19% VAT applies) then the subtotal is 16.7647 € or rounded 16.76 € (!). the VAT on the other hand is 19.95 € / 119% * 19% = 3.1853 or rounded 3.19 €. which sums up perfectly. this way of calculating will work for any amount.

4) finally I haven't tried how the system handles two different VAT rates. but according to the EU directive we have to be able to handle up to two subtotals. but handling them separately like described in 3) should work.

source if you like to dig deeper:
EU VAT invoicing rules: http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rule...
containing the following link to the directives: http://eur-lex.europa.eu/JOHtml.do?uri=OJ:L:2006:347:SOM:en:HTML

If someone can take a look at my code and provide a patch for this, that would be very helpful - at the moment no rounding is done by uc_vat except when reloading prices while editing a product, so maybe this is something in Ubercart core that needs changing?

@longwave: Your code is good. We have enough decimals to display any price incl. VAT (<=> control over the last cent), but we still have rounding issues.

By this example:
Insert 19.95 (incl. VAT), VAT 19% => 16.7647... which gets rounded to 16.765

16.7647 displays as 16.76, while 16.765 as 16.77

In the payment preview the function uc_payment_get_totals() rounds for two decimals and sums the values, so this explains the additional cent on the total.

This week I learned that professional ERP systems calculate internal with 5 decimals and this would be also my suggestion. I wrote some function to scan thousands of values with various tax rates and up to now 5 decimals seem to be enough, but I even didn't try all the incomplete VAT rate list on wikipedia.

In general I see that we have no alternative and I believe that if core has no issues with the third decimal it also would not make a difference anymore if there are five...

Thoughts?

There is a patch regarding rounding at #479784: Order rounding which I currently do not have time to try out. Perhaps someone could apply this and see if uc_vat works any better or worse with this?

I've tested the Patch in #4 of #479784: Order rounding but it does not help with the issue as described by bbunse.

In my case a price of 39,00€ incl. VAT gets divided into 35,46€ + 3,55€ = 39,01€.
The shopping cart displays 39,00€, but the order total preview does not.

I have this same problem.

This maybe a little hacky buy I've fixed it.

my use case

I has a product for £12 inc VAT, without 15% VAT uc_vat was storing this in the database as 10.435. Ubercart was then outputting this in the cart as £12.01.

I found if I manually edited the database to 10.434 Ubercart would output the correct price as £12.

solution

I have added $value = (floor($value * 1000)) / 1000; to uc_vat to round down the price to 3dp, rather than up. This is working for, but I would like to see if it does for everyone else.

I have added a patch.

I convinced myself that the only explanation is that somewhere Ubercart (or uc_vat) is doing calculations with numbers that have been rounded (or worse truncated) to only having 2 significant digits after the dot. The solution is to always work with "exact" numbers in the background and only round them to two digits just before displaying them to the user.

Even when the price excl. VAT is stored with just 3 digits after the dot that's enough to avoid the problem as long as the VAT is calculated exactly.
(Note: storing the price excl. VAT with just 2 digits after the dot would unavoidably lead to rounding errors.)

after more thinking and checking examples...

Even tough when storing "prices excl. VAT" with 3 digits after the dot the "price incl. VAT" will (at least can) be calculated correctly a problem remains:
the sum of "prices excl. VAT" and VAT when rounded to two digits will not in all cases sum up to the "price incl. VAT". in other words "price incl. VAT" will be correct, but the components as displayed won't sum up to it.

I made a spreadsheet to try different cases:
- trying different VAT rates (16%, 18% and 19%)
- and all prices 0.01 - 100.00 in increments of 0.01

Result: we need to save "price excl. VAT" with at least 5 digits after the dot to cover all these cases.

Example: try Price: 2.85 with VAT: 19%.

and here the example in more detail for your convenience.

I asked myself if there are cases asking for saving prices with even more digits after the dot. I found only some rare cases for the reduced rate in France, should we cover them?

And I came across cases which cannot be solved by increasing the significant digits in the database: 4%, 12% and 20%.
Anyone from Austria, Bulgaria, Estonia, Italy, Portugal or Slovenia? How do shops deal with rounding problem in your country?

hello i also have this problem

any solutions found ? has the prepatched version of ubercart been updated with it ?

Is there a way to send only the final price to paypal, and not send the VAT amounts ?
Or is there a way to send the good rounded prices & vat to paypal ?

I also have another issue
when (in my paypal payment configuration), i check the line that says "send all articles one by one to paypal"
( Envoyer un commande détaillée montrant chaque produit avec sa description. )
it adds VAT. I have to check "validate the command just in one line" (Valider l'ensemble de la commande comme une seule ligne article.
see pictures G1 & G2 & G3

the website i'm working on is here

Thanks to all

http://fbwn.net/DEV/drupal

hello all

rounding.patch does not work for me
can anyone send me the patched uc_vat.module ?

thanks

Ubercart RC7 now has 5 decimal places - please test if it fixes your problem.

I just tested with the example figures from #1 but the same problem still occurs in rc7. However, applying timmillwood's rounding-down patch from #7 fixes it so the order total preview is correct. Can someone else review that patch with different prices on their site and see if it fixes it for all cases? I'm not sure if this would just be covering up other cases where rounding up instead is necessary.

timmillwood just let me know that it does indeed break in other cases with that patch applied, so reverting back to active for now :(

I have also tested now with the figures given in #1 and on my site the problem is fixed. 16.76, 3,19, 19,95 everywhere. For me this is fixed - at least for the numbers given in #1.

(
I know it's not fixed for what I mentioned in #11
for German speaking people: I have asked the Austrian Government here:
http://www.help.gv.at/fuapublic/appl/foren-flow?id=80&zielgruppe=unterne...
look for "21.08.2009: Rundungsdifferenz Umsatzsteuer"
and feel free to push them for an answer
)

My mistake, it was indeed fixed, I did not run all the necessary database updates. I've also committed a patch to round the VAT inclusive prices when editing to 5dp, otherwise you save a price such as 19.95 and it is reloaded on the edit page as 19.950005.

As for the 20% VAT issue the only way I can see of fixing that is to round down one of the 0.005 values and round up the other, otherwise that problem will always occur. From what I have seen VAT should never be rounded down so perhaps we need to check if the product price ends in 0.005 exactly and round that specific case down? Marking as fixed for now anyway, as the original issue and almost all cases should now be correct.

For the 20% VAT rate problem mentioned in #11 a new issue has been opened: #587654: Rounding problem for 20% VAT rate