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

[frank18]

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....

[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!

[frank18]

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.

[frank18]

Sorry, can't delete image for tax settings:

Tax settings in Admin > My Store are

0
true
true
Shipping
Shipping
0
false

[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

[GoverT]

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

[frank18]

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....

[GoverT]

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.

[GoverT]

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!

Hope this works for you too frank18!

[GoverT]

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