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

[David R]

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!

[David R]

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

[lat9]

Here's a companion issue with its own set of solutions: https://www.zen-cart.com/showthread....ot-add-up-quot

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

[GoverT]

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

[lat9]

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

[GoverT]

Hello lag9,

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

[GoverT]

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.

[frank18]

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.

[frank18]

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

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