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

[frank18]

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!

Thanks G/T - I will revert to the standard code and then apply your suggestion (code looks sort of familiar from older releases).

[frank18]

Thanks G/T - I will revert to the standard code and then apply your suggestion (code looks sort of familiar from older releases).

Didn't work for me.

[GoverT]

Hello frank18,
You did adjust the Tax decimal places in Admim-store to 2?

[frank18]

Hello frank18,
You did adjust the Tax decimal places in Admim-store to 2?

No, changing the tax decimals only changes the padding in the display of the tax amount. Eg, you set the tax decimals to '0' then the customer is presented with say 10%, now set the tax decimals to '2' then the customer sees 10.00% on the invoice. You can test this by loading an existing invoice in admin, don't close the tab in your browser, then change the tax decimals from '2' to '0' or whatever. Next you reload the invoice in the browser and you see the padding change. But, it has no influence on the underlying code calculations.

I reverted back to my own suggestions as per post #14 but made one additional change in includes/classes/order.php (code starts around line 449):

      $taxRates = zen_get_multiple_tax_rates($products[$i]['tax_class_id'], $taxCountryId, $taxZoneId);
      $this->products[$index] = array('qty' => $products[$i]['quantity'],
                                      'name' => $products[$i]['name'],
                                      'model' => $products[$i]['model'],
                                      'tax_groups'=>$taxRates,
                                      'tax_description' => zen_get_tax_description($products[$i]['tax_class_id'], $taxCountryId, $taxZoneId),
                                      'price' => $products[$i]['price'],
                                      //'final_price' => zen_round($products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']), $decimals),
                                      'final_price' => zen_round($products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']), 4), // changed to 4 decimals for rounding calcs -- frank18
                                      'onetime_charges' => $_SESSION['cart']->attributes_price_onetime_charges($products[$i]['id'], $products[$i]['quantity']),
                                      'weight' => $products[$i]['weight'],
                                      'products_priced_by_attribute' => $products[$i]['products_priced_by_attribute'],
                                      'product_is_free' => $products[$i]['product_is_free'],
                                      'products_discount_type' => $products[$i]['products_discount_type'],
                                      'products_discount_type_from' => $products[$i]['products_discount_type_from'],
                                      'id' => $products[$i]['id'],
                                      'rowClass' => $rowClass); 

Next I did tests with

1. a tax free product
2. a product on sale (special price)
3. a product with quantity discounts (attributes)

all with varying quantities in the cart

Every single scenario showed up correct in the cart, the checkout pages, the final order and in the invoice, there were no rounding errors at all no matter which scenario I chose.

I will leave it at that until someone can come up with a more elegant (and thoroughly tested) solution.

[GoverT]

Okay what works for you is good enough. Again, I'm no programmer but I think the tax decimal places affect the tax amount. Tax decimal places also pad the tax AMOUNT this amount of decimal places. For example, if the amount of tax was $3.05 and tax decimal places was set to 0, I think it would display and calculate as $3. You could at least try. ;) My solution is thoroughly tested and you can see it at work in our webshop. It also makes sense that the not rounded amount excluding tax and the not rounded tax is exactly the right amount including tax, if you show prices including tax in your webshop. I will leave it at this too but it would be great to get the elegant credit for it

[webchills]

First of all I want to thank frank18 for the suggested fixes in includes/classes/shopping_cart.php, includes/classes/order.php, includes/classes/currencies.php and includes/functions/functions_prices.php.
I have implemented these changes in a 1.5.5a store and the sub-total calculations are now fine.

To demonstrate that this is a big issue especially for European store owners that persists now for years and is still alive in the latest 1.5.5a look at this Vanilla 1.5.5a store:
https://www.webchills.at/155-en-vanilla/

The store is setup to display prices with tax both in frontend and admin.
The tax rate is 20%
Look at the product Subtotal Wrong
The price is set to 4.9167 net which is 5.90 gross
Add 10 units to the cart and go to checkout (login credentials provided in the product description) and you get a Sub-Total of 59.04
No customer will understand such a calculation, this is a nightmare for shop owners.

Now look at the same store with the frank18 fixes here:
https://www.webchills.at/155-en-roundingfix/
The product Subtotal Wrong is now as it should be
I would really appreciate if these fixes would make their way to the current 1.5.5

Unfortunately there is a further issue which the frank18 fixes do not cure:
Look at the Priced by Attributes product in the vanilla store.
Product is priced by attributes
Product Price: 0
Attribute 1 Price: 0.5833 (net)
Attribute 2 Price: 0.6250 (net)

Attribute 2 Price is shown correctly as 0.75 (gross)
Select Attribute 2 (Size Large) and add it to cart
Price in cart and checkout grows up to 0.76 which is wrong

[frank18]

First of all I want to thank frank18 for the suggested fixes in includes/classes/shopping_cart.php, includes/classes/order.php, includes/classes/currencies.php and includes/functions/functions_prices.php.

Thanks for that! Glad that I get this confirmed ....

Unfortunately there is a further issue which the frank18 fixes do not cure:
Look at the Priced by Attributes product in the vanilla store.
Product is priced by attributes
Product Price: 0
Attribute 1 Price: 0.5833 (net)
Attribute 2 Price: 0.6250 (net)

Attribute 2 Price is shown correctly as 0.75 (gross)
Select Attribute 2 (Size Large) and add it to cart
Price in cart and checkout grows up to 0.76 which is wrong

Zum Teufel!!! What I don't get is that Attr. 1 is showing correctly and Attr. 2 does not...... why??

Could you do 2 things please:

1. compare the 2 attribute configurations in admin and check that they have been set up identically.

and if they are identical then

2. change the value of 0.5833 to say 0.5875 net and see what happens - should show 0.71 gross with 20% tax applied (it is 0.705 in real terms which mathematically rounds up to 0.71)


FWIW Many other applications which are using tax / roundings etc, the end result shows up as out by a few cents. I am seeing this sometimes on invoices received from my suppliers.... so ZC is not alone.

[webchills]

Zum Teufel!!! What I don't get is that Attr. 1 is showing correctly and Attr. 2 does not...... why??

I don' t get this as well :-)

1. compare the 2 attribute configurations in admin and check that they have been set up identically.

They are identical, see attached screens

2. change the value of 0.5833 to say 0.5875 net and see what happens - should show 0.71 gross with 20% tax applied (it is 0.705 in real terms which mathematically rounds up to 0.71)

Did that for you, see the new product Priced by Attributes 2

FWIW Many other applications which are using tax / roundings etc, the end result shows up as out by a few cents. I am seeing this sometimes on invoices received from my suppliers.... so ZC is not alone.

I know that Zen Cart is not alone with that. We did come a long way and have a long history of rounding issues and fixes. The attribute example is coming from a clients store which depends on attribute pricing. To avoid such issues I normally do not use attribute pricing at all. But sometimes it's inevitable and we should be able to calculate it correctly.

[SarahL]

Thank you again - upgraded to 1.5.5a - still have decimal issue - your changes agian seem to have resolved it - tad frustrating still a problem but THANK YOU for keeping this up to date with newer versions

[Reneetje]

I never had any issues with this untill I recently had my shop upgraded tot 1.5.5b. Suddenly prices show incorrectly at checkout-page and are a cent off...in 1.5.4 all worked fine.

I tried the solution as mentioned by FRANK18 (post 14 and 44 )and see some differences but at the end when checking out the final confirmation does still not match.

How to fix...anyone has an idea?