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,

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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

PHP Code:

---

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


---

by this:

PHP Code:

---

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


---

Now, invoices and emails are as they should be.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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?

Quote:

---

Originally Posted by dbltoe

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

---

It seems I did:

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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)]

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by lat9

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

---

Sorry for the late reply!

I applied the changes described here
https://github.com/lat9/zencart/comm...44631fc0b06cba
and here
https://github.com/zencart/zencart/pull/6141/files

So far everything seems to work fine and the problem from the initial post is solved thanks to your code changes.

Quote:

---

Originally Posted by todoonada

Sorry for the late reply!

I applied the changes described here
https://github.com/lat9/zencart/comm...44631fc0b06cba
and here
https://github.com/zencart/zencart/pull/6141/files

So far everything seems to work fine and the problem from the initial post is solved thanks to your code changes.

---

Thanks to you, @todoonada! I appreciate the 3rd-party verification as well as your original posting of the issue.

Hello lat9,
I have one more question.
Currently a tax of 173.6363 is rounded to 173. (I have no decimals in the currency).
I would like to have it rounded to 174 (half round up method).
In the sense of "Total is 1910, a 10% tax of 174 is included".
Now it displays 173 instead of 174.

Where do I have to change your code?

I went to includes/modules/order_total/ot_tax.php
and changed line 98 from

Code:

---

'text' => $currencies->format($taxValue, true, $order->info['currency'], $order->info['currency_value']),

---

to

Code:

---

'text' => $taxValue,

---

Now on the front end the 10% tax is displayed as 173.3. Round this and it is 173 of course.
The value of 173.3 is not correctly. It should be 173.6.
So it seems it is not the wrong rounding method, but the calculation of $taxValue is off.

Sorry, some further information:

a) If I have a product price of 8280 and no shipping costs, the tax is displayed correctly as 753.
b) If I have a product price of 8280 and shipping costs of 910 (total of 9190), the tax is displayed as 836, it should be 835.
c) If I change the product price to 9190 (same like total in above) and free shipping, the tax is displayed correctly 835.

So it seems there is something wrong with the tax calculation of the shipping costs.

Versions affected: zc158a with patches and zc200
file /includes/classes/order.php

Issue: currency conversion applied on item price in shopping_cart and reapplied on the sub-total for checkout_payment.

I updated /includes/classes/order.php to include changes from #6094 and #6141 to correct tax calculations.
Prices are displayed including tax. Most orders are for domestic orders so they include tax. When the delivery address is overseas the items become tax exempt. This is determined by zones.


Now with the new code:

• user selects a currency eg Euro and creates an account with a delivery address outside Australia.
• The currency conversion is applied on the item:
• item cost in AUD ex tax = $118.77 converted to EUR = €73.58 [ conversion rate of 0.61948508] = result is OK
• in checkout shipping, postage is calculated and returned in Euro = result is OK
• in checkout payment, the sub-total before postage is now €45.93 = INCORRECT [ this is the items price in EURO reconverted to EURO by the same conversion factor ]

Thanks for the details, OldNGrey. Once I've coffeed-up, I'll take a look on zc200-rc1 and report back.

OldNGrey, what's the full (with 4 decimal digits) price recorded in the database for that 118.77 product?

Quote:

---

Originally Posted by todoonada

Sorry, some further information:

a) If I have a product price of 8280 and no shipping costs, the tax is displayed correctly as 753.
b) If I have a product price of 8280 and shipping costs of 910 (total of 9190), the tax is displayed as 836, it should be 835.
c) If I change the product price to 9190 (same like total in above) and free shipping, the tax is displayed correctly 835.

So it seems there is something wrong with the tax calculation of the shipping costs.

---

@todoonada, I'll be looking at this as well using the zc200-rc1 code.

Zen Cart issue created to track the correction(s) for the above two pricing issues: https://github.com/zencart/zencart/issues/6318

@todoonada and @OldNGrey, what's the value in use for Configuration :: My Store :: Currency Conversion Ratio?

Item #608 products_price = 118.7727
Configuration :: My Store :: Currency Conversion Ratio = 1.025

@OldNGrey and @todoonada, please see this PR: https://github.com/zencart/zencart/pull/6319

I've verified that the changes correct each of the issues identified in this thread and would appreciate some 3rd-party validation!

Using this PR, I did some testing changing all I can, price, tax display and value... As long as I use main currency, calculation was all good. But when using another currency, things get weird...
Second currency rate is 155 and tax is 10%, no decimal. I have two products in cart, one is priced at 48.34 (53.174 with tax) and the other is at 35 (38.5 w.tax).

When not displaying tax:
I got in cart product price 1 at 7440 (instead of 7493) and product 2 at 5425 as it should be.
In last checkout screen, product price 1 is still wrong, but all calculations are correct for these prices (7440 and 5425).

When displaying prices with tax:
I got in cart product price 1 at 8215 (instead of 8242) and product 2 at 6045 (instead of 5968).
In last checkout screen, product price 1 is 8242 and product 2 is 5968 as they should be but subtotal (14260 instead of 14210) and tax (1296 instead of 1292) are wrong. Total is 15035, which I have no idea how it ends to this value...

I am not sure if it is related to tax calculation, it might be more of a rounding problem when converting currencies.

Quote:

---

Originally Posted by pilou2

...Total is 15035, which I have no idea how it ends to this value...

---

I figure this out, 15035 = 14260 + 775 (shipping fee). It is time for me to sleep...

From my testing with the conversion from AUD to EUR, or any other currency I have set, the display for payment information is now correct.
Thank you Lat9

I think I figured out part of the problem. In my currency with rate 155 (JPY) I use 0 decimal. It seems that currency conversion in cart rounds to 0 decimals before conversion:
Product price 48.34 becomes 48 which multiply by 155 gives 7440 which is exactly the wrong price I got in cart without tax.
Second product price 35.00 has 0 as decimal. This is why price after conversion is still right. I don't know where it is in the code yet.

When displaying prices with tax:
Product 1: 48.34 x 1.1 = 53.174 ----> 53 x 155 = 8215 Which is what I got.
Product 2: 35.00 x 1.1 = 38.5 ----> 39 x 155 = 6045 Which is what I got too!

Rounding to new decimal setting should be done after conversion.

Calculation in last checkout screen is different and there might be something else to figure out...

Quote:

---

Originally Posted by lat9

@todoonada and @OldNGrey, what's the value in use for Configuration :: My Store :: Currency Conversion Ratio?

---

It is 1.05.
I only use one currency.

Quote:

---

Originally Posted by pilou2

I think I figured out part of the problem. In my currency with rate 155 (JPY) I use 0 decimal. It seems that currency conversion in cart rounds to 0 decimals before conversion:
Product price 48.34 becomes 48 which multiply by 155 gives 7440 which is exactly the wrong price I got in cart without tax.
Second product price 35.00 has 0 as decimal. This is why price after conversion is still right. I don't know where it is in the code yet.

When displaying prices with tax:
Product 1: 48.34 x 1.1 = 53.174 ----> 53 x 155 = 8215 Which is what I got.
Product 2: 35.00 x 1.1 = 38.5 ----> 39 x 155 = 6045 Which is what I got too!

Rounding to new decimal setting should be done after conversion.

Calculation in last checkout screen is different and there might be something else to figure out...

---

Thank you for taking the time to check this out. It would help me to reproduce and then correct the issue if I could verify:

Store currency, number of decimal digits (sounds like 2)
What is the 1.1 that multiplies the product pricing, for example 48.34 x 1.1 = 53.174
Store currency, converted to JPY with a 155 conversion rate.

Quote:

---

Originally Posted by lat9

Thank you for taking the time to check this out. It would help me to reproduce and then correct the issue if I could verify:

Store currency, number of decimal digits (sounds like 2)
What is the 1.1 that multiplies the product pricing, for example 48.34 x 1.1 = 53.174
Store currency, converted to JPY with a 155 conversion rate.

---

The main currency is default US$. I use a default cart with demo data to which I added Japanese yen as currency with rate (including factor 1.05) of 155 (155.00000000) and has 0 decimal. Then I modified Tax to apply worldwide and at a 10% rate which makes it easier for debugging. Then, I modified some products prices and one is 48.3400 without tax and the other is 35.0000 without tax too.
Now, I suppose you understand 48.34 (price w.o.t.) x 1.1 (10% tax).
1.1 is 1 + 10/100...

I looked at the code and find some rounding (line 118 in shopping cart header and some in shopping cart class) I can suppress to get correct prices, but then the 'one digit off' bug comes back. I think these rounding were added to correct this bug, but in fact hide it.
Probably, the right thing to do would be to do a rounding after currency conversion (if necessary) but before any other calculation like adding tax, then a last rounding before displaying.

I could not find where currency conversion is done for subtotals. It seems subtotal is calculated differently depending on page you are: cart, checkout payment and checkout confirmation... If you know where this currency conversion is done, please let me know.

Thanks for the quick response, @pilou2, it is much appreciated. I'm off to configure my testing site with that information and will hopefully have some idea of where the issue lies later today.

The sub-total calculations for the shopping-cart page's display are performed by the page's header_php.php, first via call to the shopping-cart class' show_total method, with the returned value then formatted into the currently-selected currency.

During the checkout, the subtotal calculation is performed within the order-class' cart method. The overall total and tax are further manipulated by the various order-total modules to produce the order's final tax and total.

Quote:

---

Originally Posted by lat9

Thanks for the quick response, @pilou2, it is much appreciated. I'm off to configure my testing site with that information and will hopefully have some idea of where the issue lies later today.

The sub-total calculations for the shopping-cart page's display are performed by the page's header_php.php, first via call to the shopping-cart class' show_total method, with the returned value then formatted into the currently-selected currency.

During the checkout, the subtotal calculation is performed within the order-class' cart method. The overall total and tax are further manipulated by the various order-total modules to produce the order's final tax and total.

---

Thanks, I come back here if I find something interesting.

@pilou2, is the site displaying prices with tax or not?

Quote:

---

Originally Posted by lat9

@pilou2, is the site displaying prices with tax or not?

---

Never mind, you have fully identified the cases in post #43 of this thread.

Cart page is now fixed but code still need lots of testing because of all possible discount, attributes and other free stuffs.
I made a branch for that on my ZC fork: https://github.com/piloujp/zencart/tree/Currency-prices

For checkout page, nothing is done yet.

Yep, I'm pretty close on an overall solution that appears to work properly for the issues identified here by @todoonada, @pilou2 and @OldNGrey; I'll post back here when that Zen Cart pull-request (PR) has been updated.

Quote:

---

Originally Posted by lat9

Yep, I'm pretty close on an overall solution that appears to work properly for the issues identified here by @todoonada, @pilou2 and @OldNGrey; I'll post back here when that Zen Cart pull-request (PR) has been updated.

---

PR updated. All cases reported in this thread (and a couple from clients) validated as corrected.

Quote:

---

Originally Posted by lat9

PR updated. All cases reported in this thread (and a couple from clients) validated as corrected.

---

Hello lat9,
thank you for the work you put into it.
I do not have the time to test at the moment.
I made a bit of a hack to solve the problem, so it works for me at the moment. However it is not a reasonable solution to go into main Zen Cart code.

Quote:

---

Originally Posted by lat9

PR updated. All cases reported in this thread (and a couple from clients) validated as corrected.

---

I tried the new PR.
For files header.php and shopping_cart.php I did exactly the same modifications at first, and it did correct issues discussed in this thread but re-introduced an old one...
Which is that the last digit has a one unit shift when using another currency. It appears only in total when displaying prices without tax, and it is also in subtotal when displaying prices with tax.

Problem comes from calculation logic.
For cart calculation, products price (in main currency) has tax added and then is being converted to new currency, all this one by one.
In this case, all prices are rounded one by one when conversion is done.
For subtotal or total calculation, all products prices in main currency are added then tax apply, then currency conversion.
In this case, all products prices are added then rounding is done at conversion time.

Unfortunately, due to rounding errors, total in both calculation can have a difference of one unit on the last digit.
With numbers I gave you and a conversion rate of 155 and tax at 10%, I got 1 yen difference at the end.

In cart (with tax displayed):
48.34 x 1.1 = 53.174 x 155 = 8241.97 rounded to 8242
35.00 x 1.1 = 38.5 x 155 = 5967.5 rounded to 5968
-------------------------------------------------
Total: 14210

subtotal calculation:
48.34 + 35.00 = 83.34 x 1.1 = 91.674 x 155 = 14209.47 rounded to 14209

My idea to fix it, that I applied in shopping_cart.php, is to do conversion and rounding on each price before adding them, when calculating subtotal or total:
((48.34 x 155 = 7492.7 rounded to 7493) + (35.00 x 155 = 5425)) = 12918 x 1.1 = 14209.8 rounded to 14210

With all possible prices modification by discounts, attributes and others it makes this modification pretty complicated...

I updated the GitHub branch with something that seems to do the job. https://github.com/piloujp/zencart/tree/Currency-prices
No more penny loss, numbers add perfectly except when using a secondary currency and a shipping module with tax class, then shipping tax is missing from the total. It is included in tax or shipping cost depending on tax display option, but always missing in total...

When using main currency, everything is perfect! If you have an idea of what is going on...

Attributes and discount stuffs have not been tested yet.

I saw, a little bit surprised that the PR was merged already. I tested it today and apart from the lost penny problem that is still here, when there is a tax applied on shipping, it is not displayed at all anymore, not in shipping cost (when displayed with tax), nor in tax total, nor in total cost.

When merging my modification with this new ZC version, problem is identical, which makes me think it is coming from the code change on $tax_add handling in file order.php after line 860.

Quote:

---

Originally Posted by pilou2

I saw, a little bit surprised that the PR was merged already. I tested it today and apart from the lost penny problem that is still here, when there is a tax applied on shipping, it is not displayed at all anymore, not in shipping cost (when displayed with tax), nor in tax total, nor in total cost.

When merging my modification with this new ZC version, problem is identical, which makes me think it is coming from the code change on $tax_add handling in file order.php after line 860.

---

@pilou2, the intent of merging that PR was to get a wider audience for testing, I agree that more changes are needed. I am traveling this weekend, so my response time will be slow, but my intent is to focus on the calculation issues that you and others identify as we get closer to a zc200 final release.

Quote:

---

Originally Posted by pilou2

I saw, a little bit surprised that the PR was merged already. I tested it today and apart from the lost penny problem that is still here, when there is a tax applied on shipping, it is not displayed at all anymore, not in shipping cost (when displayed with tax), nor in tax total, nor in total cost.

When merging my modification with this new ZC version, problem is identical, which makes me think it is coming from the code change on $tax_add handling in file order.php after line 860.

---

Would you supply the details of the associated "missing shipping tax" configuration? Please include
- Prices including tax (true/false)
- USD => JPY conversion factor (I'm pretty sure you're using 155 JPY/USD)
- The shipping cost
- Tax rate (I'm pretty sure you're using a 10% rate)

Quote:

---

Originally Posted by lat9

Would you supply the details of the associated "missing shipping tax" configuration? Please include
- Prices including tax (true/false)
- USD => JPY conversion factor (I'm pretty sure you're using 155 JPY/USD)
- The shipping cost
- Tax rate (I'm pretty sure you're using a 10% rate)

---

It won't be necessary, I found the problem and it has nothing to with new PR... For any reason, I set the flat rate module I use to a zone 'all countries' and 'all zones', which prevented it from displaying on shipping page. Next module (per item) has same description, same rate but was not set with tax and I was going through this page as quickly as possible...
Stupid thing that made me loose few hours...
Removing this zone setting fixed the shipping tax problem which was not really one. I used same data as before for prices, tax etc...
Good news is the new PR code works perfectly (except the small penny loss).
Bad news is that there is another bug with zones set to all countries or all zones.

Based on lat9 new PR, I did more testing and tried new code. I got a good 'penny loss' fix that works great on standard orders, no more differences between tax display or not, cart or final invoice. But this is not a final solution, lots need to be testing. Just for those who are interested in testing:
https://github.com/piloujp/zencart/tree/The-Lost-Penny

I am now working on discount coupon but have hard time understanding all options.
My image of coupon is that they are a discounts (fix or percentage) that apply to what customers pay at the end as a deduction. Although there are some that apply only to some items. Validation can be pretty complicated, but Zen cart seems to do it very well.
Where I start to get lost is when looking at 'Admin->Modules->Discount coupons', there are few options that I can't understand very well:

'Include Shipping' in calculation.

Probably used when checking if discount is higher than total, but I am not sure.

'Include Tax' in calculation.

Same as shipping?

'Re-Calculate Tax'
There are three options here:

'None' is easy to understand, nothing is change, tax is as it was before discount.

'Standard', I suppose tax is adjusted to new taxable total. It is pretty straight forward if there is only one tax class that apply to all item including shipping, then new tax should be tax rate x new total without tax. But it is not the case in ZC now, something is wrong in calculation. I did some test with 10% tax and a fix discount coupon, but tax displayed is never 10% of the new total without tax.

'Credit Note', I am not sure what it is, but it is the one that gives results identical to 'none'.

With 'standard' option set, tax calculation if off and final total too. Coupons seems to be treated as an item with price without tax and tax included, but when creating coupons there is only one price. It does not make sense to me to apply tax on coupons. How a shop owner can control what discount he does if tax is applied or not on a discount set in %? Plus a discount is money not paid, how can it be taxed?
There might be some rounding error too, but before trying to fix it, I need to understand what is expected here.
Please, if someone as some light to through on this I would really appreciate.

@pilou2, that ot_coupon.php code's tax handling (as you identified) is quite confusing and I fully expect that there will be follow-on penny-off errors with its use. If you find such issues, please open a new thread specifically for the coupon-handling so that this thread can keep track of only 'base' product/shipping tax issues.

Quote:

---

Originally Posted by lat9

During the checkout, the subtotal calculation is performed within the order-class' cart method. The overall total and tax are further manipulated by the various order-total modules to produce the order's final tax and total.

---

Hi,

Sorry for asking on this but. I'm just at a point in making a payment plugin, and have looked a a few other one's and am getting a mixed view on 'order's final total' that's sent to payment gateway as some are using : "$amount_total=round($order->info['total']*$order->info['currency_value'],$decimal_places)*$multiplied_by;" but to me the amount sent to the payment gateway should just be "$order->info['total']" untouched by any sort of "$order->info['currency_value']" as this in my view is dealt with for cart total, am i right on this please?
just to let you know what "$multiplied_by" is, the "presentment currencies - Zero-decimal currencies. Three-decimal currencies ..." which are needed before sending to the gateway.

So if currency conversion is done at cart to order point then, this
"$amount_total=round($order->info['total']*$order->info['currency_value'],$decimal_places)"
is just making the amount to pay bigger by currency rate of the order and not matching the displaid amount in checkout before and after payment has been taken and shown on success page?

Quote:

---

Originally Posted by OJ_SIMON

Hi,

Sorry for asking on this but. I'm just at a point in making a payment plugin, and have looked a a few other one's and am getting a mixed view on 'order's final total' that's sent to payment gateway as some are using : "$amount_total=round($order->info['total']*$order->info['currency_value'],$decimal_places)*$multiplied_by;" but to me the amount sent to the payment gateway should just be "$order->info['total']" untouched by any sort of "$order->info['currency_value']" as this in my view is dealt with for cart total, am i right on this please?
just to let you know what "$multiplied_by" is, the "presentment currencies - Zero-decimal currencies. Three-decimal currencies ..." which are needed before sending to the gateway.

So if currency conversion is done at cart to order point then, this
"$amount_total=round($order->info['total']*$order->info['currency_value'],$decimal_places)"
is just making the amount to pay bigger by currency rate of the order and not matching the displaid amount in checkout before and after payment has been taken and shown on success page?

---

Hi,


example of ""$amount_total=round($order->info['total']*$order->info['currency_value'],$decimal_places)*$multiplied_by;"" would be:


main product of £100.00 (GBP (1.0)) and secount of USD (currency rate of say 10 (1.10) at cart it would be $110.00 then displayed in checkout as $110.00 but amount sent to gateway of $121.00 X 100 (decimalisation to 12100) which is wrong?