Different Total Displayed

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.

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?

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.

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.

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.

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.

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.

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)

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.

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?

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?