Shopping cart Subtotal not equal Checkout Subtotal (rounding error) with GST/VAT

frank18:

I can confirm that it also works on 1.5.4

Found this thread after beating my head against that various rounding errors I'm getting. Thanks for all the work on it!

I'm still stuck with a product price error in the cart. Our key target currency is Japanese Yen. There are no decimal places used in specifying JPY. 1 Yen is like 1 cent.

The JPY price displays correctly (rounded) on the product page, but inexplicably rounded to the ten's place in the cart (so a calculated price of 9984.45 shows as 9984 on the product page, but as 9980 in the cart.)

When you get the payment page, the values have reverted to product page values. So it's just the values in the cart that are exhibiting this.

It looks as if the prices being displayed in the cart are generated in header_php.php in the modules/pages/shopping_cart folder, but I haven't figured out how it's working.

So if anyone has an insight into that, specifically, it would be much appreciated.

Just as a general comment, for us it's really important that what the customer sees makes sense.
So having the price be one value on the product page, another value in the cart, yet another value when totaled with other products, and have "Total" values on different pages are not actually showing the simple total of the displayed values above them.... those things are problems. :-)

Thanks!

Here is the fix to the problem we were having:

In modules/pages/shopping_cart/header_php.php

The line that calculates the product value displayed is this:
$ppe = zen_round(zen_add_tax($ppe, zen_get_tax_rate($products[$i]['tax_class_id'])), $currencies->get_decimal_places($_SESSION['currency']));

The problem is caused by the fact that this line rounds the base price (final_price) based on the number of decimals in the target currency instead of rounding the resulting display. So a final_price of $89.95 gets rounded to $90.00 before it is multiplied by the conversion currency (which happens, in the case of JPY to have 0 decimal places.)

We had our conversion set at 109, so we were getting a single item value of ¥9810 from $89.95, instead of the correct ¥9805.

Removing the rounding from that line fixed this for us (now we get ¥9805 in this example).
$ppe = zen_add_tax($ppe, zen_get_tax_rate($products[$i]['tax_class_id']));

YMMV

Here's a companion issue with its own set of solutions: https://www.zen-cart.com/showthread.php?218530-PayPal-Express-Checkout-Rounding-issue-causes-quot-Line-item-subtotals-do-not-add-up-quot

I'm pretty sure that the solution provided there will also apply to the scenarios posed in the current thread.

I hope this is the right place to respond / reply. It's a question also concerning rounding.

Tried all of the suggestions above, but that doesn't help. Updated Zen-cart from 1.5.1 to 1.5.5a and now have a rounding problem. It starts in checkout_payment (wrong subtotal). In checkout_confirmation also most products get rounded wrong (cent extra / cent less). Our website shows prices including 21% tax. The strange thing is that it didn't happen in previous releases (we started with 1.3.8). We use the responsive_classic template, but it's also in the normal template.
Upgraded by official procedure. PHP 7.0.6 but also tested with 5.6 the same problem. MySQL 5.5.5. What has been changed since 1.5.1 that causes this problem? Hope someone can help!

GoverT

Did you try applying the patches that are in the link I posted above?

Hello lag9,

Yes, tried them yesterday but that doesn't fix the problem. See picture what happens. webshop at https://www.fi-donc.nl/webshop. In 1.5.1 everything was okay!

B.t.w. the two products are 16,10 and 39,90 each including VAT/tax. In the checkout confimation at each a cent is added... The subtotal should be 56,00 but according to the confirmation (see picture) it should be 56,02 but 56,01 is shown.

lat9:

Did you try applying the patches that are in the link I posted above?

Applied the patches but sadly still getting the rounding error on the checkout pages.

So I can confirm the findings of GloverT

Example:

Normal products price is $21.95
Special price $19.97

I add 2 to the cart so I am expecting $39.94 which shows correct in main_page=shopping_cart

I am moving on to checkout and I am at main_page=checkout_payment

Now the subtotal shows $39.95 - 1 cent out!

and the same on the checkout_confirmation page:

Sub-Total: $39.95
Australia Post Parcel Service (Destination: AU (0.48 kg)): $8.00
GST: $4.36 (included in final price)
Total: $47.95

Thought this was finally fixed in 1.5.5a but to no avail.

Up to 1.5.4 my fixes (posted earlier in this thread) worked a treat but I am back to square one. :(

Ok, I removed lat9's patches and reverted back to my patches posted above (post #14) and I am getting the desired result: no rounding errors anywhere, not in the cart and not on the checkout pages.

Background:

This cart (1.5.5a) was upgraded using a complete rebuild, eg start with a vanilla installation, imported and upgraded the old DB and then added back some of my modules - just to make sure that I did not carry over any old code which MAY have been left since this shop was first built in 2007. IOW, I weeded out a lot of unused mods and some other stuff.

All files referred to in my post #14 were standard ZC 1.5.5a files - without modifications. And that's were the rounding error appeared again.

So, only when I noted that rounding error again on my invoices (and saw it confirmed by others) I applied lat9's patches - without success.

Next, I removed these patches (which are now a pull request for ZC 1.6.0) and re-applied my changes from post #14 - only the line numbers are not the same any more in 1.5.5a !

Carried out tests with normal products, products with special prices, a combination of special prices and group discounts, sale maker prices etc etc, free shipping, normal shipping, all sorts of combinations.

Result: every test came up good without rounding errors anywhere on any of the relevant pages nor in the admin or invoice. And best of all: no log entries!

I rest my case....

Hello frank18,

I already tried your solution, but that didn't work for me. Tried it again, thought I made a mistake, but the same result. I think it has to do with our (European endusers) prices shown INCLUDING tax. You have to calculate with the prices including tax, calculate the tax on that amount, round both then (rounded_total) less (rounded_tax)= price excl. tax. Then everything will go well. Hope you don't rest this case and inform me where I have to adjust this.

Thanks in advance GoverT (like G/T)

GoverT:

Hello frank18,

I already tried your solution, but that didn't work for me. Tried it again, thought I made a mistake, but the same result. I think it has to do with our (European endusers) prices shown INCLUDING tax. You have to calculate with the prices including tax, calculate the tax on that amount, round both then (rounded_total) less (rounded_tax)= price excl. tax. Then everything will go well. Hope you don't rest this case and inform me where I have to adjust this.

Thanks in advance GoverT (like G/T)

Interesting to see your findings. The Aussie tax rules are the same, the end user (customer) has to be presented with tax included in the price. So in that respect we are on level playing ground. Hmmmm....

The subtotal in the checkout_confirmation is now okay (was a total of not rounded product prices * quantity) so it's one step further, but the product prices are still wrong. You can try it in our website, see link. The same products are still available as seen in the screenprint. The strange thing is that my 1.5.1 didn't have this problem!! And you have had the problem in 1.5.1. too. That doesn't make sense!? Is it a setting?
Thanks for the help from Down Under!

GoverT:

The subtotal in the checkout_confirmation is now okay (was a total of not rounded product prices * quantity) so it's one step further, but the product prices are still wrong. You can try it in our website, see link. The same products are still available as seen in the screenprint. The strange thing is that my 1.5.1 didn't have this problem!! And you have had the problem in 1.5.1. too. That doesn't make sense!? Is it a setting?
Thanks for the help from Down Under!

I went through the history of my store and checked old invoices to establish when the rounding issue started

First installed ZC as version 1.3.7.1 on 2007-10-24. I updated directly from 1.3.7.1 to 1.3.9c on 2010-06-11 and it is the latter version where the rounding issue started here and persisted ever since with standard ZC code.

It could have started already in ZC 1.3.8 but I have no records with that version

v1.5.5 [2016-05-01 18:29:21] (Version Update 1.5.4->1.5.5)
v1.5.4 [2015-01-11 04:53:20] (Version Update 1.5.3->1.5.4)
v1.5.4 [2015-01-11 04:52:18] (Version Update 1.5.3->1.5.4)
v1.5.3 [2014-08-11 10:16:37] (Version Update 1.5.2->1.5.3)
v1.5.2 [2014-08-11 10:16:37] (Version Update 1.5.1->1.5.2)
v1.5.1 [2013-12-29 11:23:19] (Version Update 1.5.0->1.5.1)
v1.5.0 [2013-12-29 11:23:19] (Version Update 1.3.9->1.5.0)
v1.3.9c [2010-06-11 23:19:47] (Version Update 1.3.8->1.3.9c) <<<<----- rounding issue started here
v1.3.8 [2010-06-11 23:12:12] (Version Update 1.3.7->1.3.8)
v1.3.7.1 [2007-10-24 21:50:38] (Fresh Installation)

So, what has changed between 1.3.7.1 and (in my case) 1.3.9c?? The rounding issue never appeared with version 1.3.7.1 and I had plenty of orders with that store.

I guess it is from v 1.3.8 where we need to start looking.

None of my tax settings were ever changed and are still the same as they were in the first installation.

Sorry, can't delete image for tax settings:

Tax settings in Admin > My Store are

0
true
true
Shipping
Shipping
0
false

Hello frank18,

Your Tax Decimal Places should be 2 (which I have). I guess that's why you had to force the roundings to 2 in your adjustments? 1.3.8 and 1.5.1 are working fine. Today I will look at the difference between the files in Winmerge. Is it possible that it has something to do with pow and ** ?

G/T

By changing decimal places to 0 the calculation remains the same btw, as suspected. So it's back on 2 decimals again.

GoverT:

Hello frank18,

Your Tax Decimal Places should be 2 (which I have). I guess that's why you had to force the roundings to 2 in your adjustments? 1.3.8 and 1.5.1 are working fine. Today I will look at the difference between the files in Winmerge. Is it possible that it has something to do with pow and ** ?

G/T

Thanks G/T - never changed the tax decimal places since launching this store in 2007 - always the same, we only have a 10% tax rate in Aus (until our dear Govt decides to bump up the GST....). It also happened with tax free items so nothing to do with the tax.

The interesting part is my analysis of past invoices and compared that to the version I was running at the time.... :huh:

The mistake is in order.php. If you would use order.php from 1.5.1 everything is okay except for shipping charge which is then calculated without tax. So there's a programming mistake in order.php. I'm not a programmer, but I will try to figure it out.

Solved! (At least for us)

Line 456 of includes/classes reads:

'final_price' => zen_round($products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']), $decimals),

It should be without rounding:

'final_price' => $products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']),

Then everything is fine! :D

Hope this works for you too frank18!

Sorry, I didn't give the complete path:
/includes/classes/order.php