Different Total Displayed

On Zen Cart 1.5.7d and 1.5.8.
I recently set up taxes for all products. Before I did not do this and this problem did not exist.

I have a product with a net price of 945.4545.
There is 10% tax, so the gross price is 1040.
There is no decimal for the currency I use.

When I put one of this item in the cart, the price displayed during checkout, email and invoice is 1040.
When I put two of those products in the cart, the price in the shopping cart is 2080, at the checkout_payment, checkout_confirmation, mail and invoice it is 2079. Obviously this is wrong and it should be 2080.

Anybody has any idea how to fix this?

Thanks for the report. While I don't know how to fix this yet, I will soon.

Hi,
I see this problem in my shop from time to time. Although I started investigating, I never got the end of it. Here is where I was:
Successful orders are saved in database and particularly prices for each products are saved in table 'orders_products'. There are saved without tax in field 'products_price' with 4 decimal digits and in field 'final_price' where rounded to 0 decimal as per shop setting.
Problem seems to be that this rounded value is used when creating invoice (from database) before applying tax.
A possible solutions would be to save prices tax included... Another one could be to not do any rounding when saving final price. The second one seems easier as there is just to change line 659 in class file 'order.php' but I am not sure of what would be displayed.
I need to do some testing...

Yes, I believe that calculation (and, obviously, rounding) differences on product pricing need to be different when products-are-displayed-with-tax.

Hi pilou2,

pilou2:

Successful orders are saved in database and particularly prices for each products are saved in table 'orders_products'. There are saved without tax in field 'products_price' with 4 decimal digits and in field 'final_price' where rounded to 0 decimal as per shop setting.
Problem seems to be that this rounded value is used when creating invoice (from database) before applying tax.
You are right; that seems to be the origin of the error.
pilou2:

A possible solutions would be to save prices tax included... Another one could be to not do any rounding when saving final price. The second one seems easier as there is just to change line 659 in class file 'order.php' but I am not sure of what would be displayed.
I need to do some testing...
I am not sure why in table orders_products products_price is saved with four decimals while final_price is saved as a rounded value.

The data for total and subtotal for the invoice is pulled from the table orders_total. In this table the value for subtotal is saved rounded and the total value is saved not-rounded.
It seems there is some inconsistency if values are saved rounded or not-rounded.

todoonada:

...I am not sure why in table orders_products products_price is saved with four decimals while final_price is saved as a rounded value...
Many currencies use two decimals. Using four prevents loosing precision.

todoonada:

..
The data for total and subtotal for the invoice is pulled from the table orders_total. In this table the value for subtotal is saved rounded and the total value is saved not-rounded.
It seems there is some inconsistency if values are saved rounded or not-rounded.

It is not what I have here. In my orders_total table, all numbers (product price, shipping fees, tax, sub-total and total) are saved as displayed in 'text' field and as number not rounded and with four decimals in field 'value' .

I tried saving final-price not rounded in database and it fixed it. I tried both with option to display with tax or not and checked for other possible consequences using developper tool in admin and so far all is good.

here is what I did:
Replacing line 659 in ..\includes\classes\order.php

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

by this:

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

Now, invoices and emails are as they should be.

pilou2:

Many currencies use two decimals. Using four prevents loosing precision.

With "table orders_products products_price is saved with four decimals" I meant that the value is not rounded.

pilou2:

here is what I did:
Replacing line 659 in ..\includes\classes\order.php

I can confirm that it works. Yet I am not sure if the code change will have any other complications. There should be a reason why the author of the code rounded the value.

todoonada:

...
I can confirm that it works. Yet I am not sure if the code change will have any other complications. There should be a reason why the author of the code rounded the value.

There was probably a good reason long time ago... I checked other files code where final_price is used and it is always rounded before displaying at least one time, but most of the time after calculation as it should be done.

Repeatable in a vanilla version of 1.5.8 and 1.5.8a

A good example of the error in the original calculation is to create an item including tax with a value of $5. Add 10 items items to the cart and progress to the "Step 2 of 3 - Payment information" screen. The subtotal is $50.05 instead of $50.00
Repeat for an item priced at $1.60 inc tax. When 10 items are added to the cart the sub-total is $15.95

Add the two items together to the cart and the sub-total is $16.00 + $50.00 = $66.00 which is correct.

The change above gives the correct answer for three scenarios.

Congratulations on posting this fix as I have been hunting for an answer for along time.

Has anyone tested this fix with both options for Display Prices with Tax?

dbltoe:

Has anyone tested this fix with both options for Display Prices with Tax?

It seems I did:

pilou2:

I tried saving final-price not rounded in database and it fixed it. I tried both with option to display with tax or not and checked for other possible consequences using developper tool in admin and so far all is good.

If anyone has the time to see if the current master branch in the Zen Cart GitHub (https://github.com/zencart/zencart) has corrected this issue, I'd appreciate it. There were a slew of changes in the pricing calculations (most of them hovering around the addition of Wholesale Pricing) that I believe have corrected these issues.

dbltoe:

Has anyone tested this fix with both options for Display Prices with Tax?

From my simple testing , it has.
Display Prices with Tax = false; Display Prices with Tax in Admin = false ; Tax rate (GST) = 10%

Item $1.60 each; add ten to cart; price displayed is $14.55;
Step 2 of 3 display payment information: Sub-Total = $14.55; Tax = $1.45; Total = $16.00

OldNGrey:

From my simple testing , it has.
Display Prices with Tax = false; Display Prices with Tax in Admin = false ; Tax rate (GST) = 10%

Item $1.60 each; add ten to cart; price displayed is $14.55;
Step 2 of 3 display payment information: Sub-Total = $14.55; Tax = $1.45; Total = $16.00
Most excellent! Thanks for the confirmation.

lat9:

If anyone has the time to see if the current master branch in the Zen Cart GitHub (https://github.com/zencart/zencart) has corrected this issue, I'd appreciate it. There were a slew of changes in the pricing calculations (most of them hovering around the addition of Wholesale Pricing) that I believe have corrected these issues.
The latest changes (#6017) show the correct Sub-Total but the Tax is incorrect.

Settings: Display Prices with Tax = true; Display Prices with Tax in Admin = true; Tax (GST) = 10%; Basis of Product Tax = Shipping

Item is $1.60; add 10 to cart; Sub-total = $16.00
Screen 2 of 3 - Payment information: Sub-Total = $16.00; Tax = $1.50; Total = $16.00.
Tax should be $1.45. [ $16.00 / 11 * 10 = 14.55 (14.5454 round to 2 places)]

OldNGrey:

The latest changes (#6017) show the correct Sub-Total but the Tax is incorrect.

Settings: Display Prices with Tax = true; Display Prices with Tax in Admin = true; Tax (GST) = 10%; Basis of Product Tax = Shipping

Item is $1.60; add 10 to cart; Sub-total = $16.00
Screen 2 of 3 - Payment information: Sub-Total = $16.00; Tax = $1.50; Total = $16.00.
Tax should be $1.45. [ $16.00 / 11 * 10 = 14.55 (14.5454 round to 2 places)]
Thanks for that; I'll get that modeled locally and see what I can do to correct.

GitHub issue opened: https://github.com/zencart/zencart/issues/6094

lat9:

Thanks for that; I'll get that modeled locally and see what I can do to correct.

GitHub issue opened: https://github.com/zencart/zencart/issues/6094

GitHub PR submitted: https://github.com/zencart/zencart/pull/6141

lat9:

Thanks for that; I'll get that modeled locally and see what I can do to correct.

GitHub issue opened: https://github.com/zencart/zencart/issues/6094
Thanks lat9. That works with all my testing.
Is far more accurate than it has been in the past.

There can be some minor variances which I think come from the original calculation of the product price. When the gross price is entered, ZC manipulates the Net price to its own calculation. The displayed price may not be the same as the stored price eg
Product Price
Entered stored(Gross) (Net) displayed as
5.00 5.0001 4.5455 5.00
4.999 4.999 4.5445 5.00
4.998 4.998 4.5436 5.00
5.001 5.001 4.5464 5.00

This is a different issue.

todoonada:

On Zen Cart 1.5.7d and 1.5.8.
I recently set up taxes for all products. Before I did not do this and this problem did not exist.

I have a product with a net price of 945.4545.
There is 10% tax, so the gross price is 1040.
There is no decimal for the currency I use.

When I put one of this item in the cart, the price displayed during checkout, email and invoice is 1040.
When I put two of those products in the cart, the price in the shopping cart is 2080, at the checkout_payment, checkout_confirmation, mail and invoice it is 2079. Obviously this is wrong and it should be 2080.

Anybody has any idea how to fix this?
@todonada, have you tested to see if the code in the current GitHub master branch (https://github.com/zencart/zencart) corrects this issue? I'm pretty sure that this was one of the test cases I used when making those pricing-calculation updates.