a.net charged tax before discount

[jeking]

A client brought this to my attention. A customer order with both sales tax and a coupon:

Sub-Total: $43.06
Table Rate (Best Way): $12.95
Discount Coupon: FIRSTTW : $6.46
IL TAX 8%: $2.93
Total: $51.96

The a.net charge was $52.47. I saw it myself. The coupon is for 15%. a.net lists shipping as 12.95 and tax 2.92

Order totals are:
Discount Coupon ot_coupon 280
Group Discount ot_group_pricing 290
Gift Certificates ot_gv 840
Priority Handling ot_priority_handling 350
Shipping ot_shipping 200
Sub-Total ot_subtotal 100
Tax ot_tax 300
Total ot_total 999

How does a.net get a different order total?

[mc12345678]

A client brought this to my attention. A customer order with both sales tax and a coupon:

Sub-Total: $43.06
Table Rate (Best Way): $12.95
Discount Coupon: FIRSTTW : $6.46
IL TAX 8%: $2.93
Total: $51.96

The a.net charge was $52.47. I saw it myself. The coupon is for 15%. a.net lists shipping as 12.95 and tax 2.92

Order totals are:
Discount Coupon ot_coupon 280
Group Discount ot_group_pricing 290
Gift Certificates ot_gv 840
Priority Handling ot_priority_handling 350
Shipping ot_shipping 200
Sub-Total ot_subtotal 100
Tax ot_tax 300
Total ot_total 999

How does a.net get a different order total?

I'm actually questioning how ZC got the total displayed above:
Even if taking in order of the order_totals:
Sub-Total: 43.06
(current total: 43.06)
Shipping: 12.95
(current total: 56.01)
Discount Coupon (applied to product: 43.06*0.15 = 6.459 ~= 6.46 making product total: 36.60)
(current total: 49.55)
No group discount
Tax (applied to product: 36.60 * 0.08 = 2.928 ~= 2.93)
(current total: 52.48 or if not yet rounded: 52.479)
No priority handling
No gift certificates
Total the "sum" of the above: 52.48 not 51.96... and of course not 52.47...

Is there a currency conversion involved? Product price entered in "odd" units? Ie. "final" taxed price entered with reverse calculation of actual price? 43.06 seems like an unusual price for the sub-total.

[jeking]

The sub-total might look odd, but it's correct. Item totals are:
$6.40
$7.95
$6.40
$7.96
$7.95
$6.40

Only USD involved.
No odd qty units.
Tax Decimal Places is set to zero

It does come to 52.48. Wow, how *did* Zen Cart get 51.96

[mc12345678]

There is this thread where there is discussion of possible ways to address what may be a "penny" off/when talking about multiples of items there can be some rounding issues, though it seems a little odd for there to be a loss of some 50 cents: https://www.zen-cart.com/showthread.php?209786

In some respects it comes down to having multiple "methods" to obtain the values and pretty much so many so that the equations are overdetermined. You know whole degrees of freedom, unknown values, and equations to get the final result.

As far as how certain things can end up calculated? Well, sheesh, I just ran a "small" spreadsheet, though I'm getting myself confused with all of the possible variations of adding, rounding, truncating, and multiplying, I did find several cases where it was possible to have at least a penny off between two methods of calculation, also I found a case where it was possible to have 51 cents "removed" if say tax was calculated based off of the product's base cost and then the coupon applied against the tax the reduction in price/tax should have been 51 cents (based on one method of calculation).

In a similar thread to the above, I discuss "who" pays/gets the extra penny. I say that because at the bottom of any line there are things like the tax to be applied to a product and there is the tax to be applied to a purchase...

For example: Take the above sale but look at only the sales tax and disregard a discount.
the four decimal place taxes are:
$0.5120
$0.6360
$0.5120
$0.6368
$0.6360
$0.5120
which sum up to $3.4448 or in money speak: $3.44

But if you apply 8% to each product with the value truncated instead of rounded and then add those taxes (as if each tax is individually calculated but the remainder is just dropped):
$0.51
$0.63
$0.51
$0.63
$0.63
$0.51
Then the total is $3.42 for tax...

If each of those values is rounded instead of truncated:
$0.51
$0.64
$0.51
$0.64
$0.64
$0.51
Then the total tax is $3.45....

Which way is correct? At the end of the day when "filing" the paperwork, how is everything calculated/entered? Just fill in the blank: collected this much tax? Is it by total sale? number of sales made with each related amount calculated?

For most, it seems to come down to what is presented to the customer at the screen they are viewing and does it make sense to them... Like: hey I add the price of all these items together and then multiply by the tax rate and that's what the tax should be. Some say/would say that discounts do not alleviate the need to pay the tax associated with the original product (I have begun to think that this statement is just to cover situations like this where the "computer" doesn't figure it out right. :) )

I haven't gone through the a.net code to see how the calculations are pushed through to get to the final price, but there is likely something/more there.

[VDecalS]

You can round all your product prices with Techicant's MySQL from this thread #58:
https://www.zen-cart.com/showthread....t=price+change

[jeking]

I haven't gone through the a.net code to see how the calculations are pushed through to get to the final price, but there is likely something/more there.

I have come across rounding discrepancies before. It's been awhile, but your examples do point out how it can happen and that there is no 'right' answer. My concern here, and the clients question, is how did the charged amount differ from the Zen Cart total? I assumed whatever Zen Cart calculates is what get's passed to the processor. It would seem rounding is not the issue because we can't get to near $0.51 with rounding.

[RixStix]

Which numbers do the Auth.net AIMmydebug log files show being transmitted to auth.net?
Which numbers do the Auth.net AIMmydebug log files show being received from auth.net?

vs shown on zencart invoice?

[mc12345678]

I have come across rounding discrepancies before. It's been awhile, but your examples do point out how it can happen and that there is no 'right' answer. My concern here, and the clients question, is how did the charged amount differ from the Zen Cart total? I assumed whatever Zen Cart calculates is what get's passed to the processor. It would seem rounding is not the issue because we can't get to near $0.51 with rounding.

Don't miss RixStix questions as they should show how the calculations were performed to support a.net. I wonder if the sequence of the order total modules of the discount and taxes plays a factor in this. To where basically the taxes got discounted twice on the "screen" but only once through a.net. Total guess and ly because 15% by yhe tax on I think it was the discounted price came out to a 51 cent "reduction"...

I mean talk about trying to squeeze a problem into an observation, but the value that a.net charged/came up with looks more correct than the total shown in ZC, even if possibly off a penny... possibly...

[jeking]

Which numbers do the Auth.net AIMmydebug log files show being transmitted to auth.net?
Which numbers do the Auth.net AIMmydebug log files show being received from auth.net?

vs shown on zencart invoice?

Rick,

Good question. I only wish I knew. This transaction was a month ago. Debug logs were not enabled and neither was database storage. We did an upgrade since then as well. I know I stared this, but might need to wait for another occurrence to get enough details to really figure this out.

[RixStix]

Rick,

Good question. I only wish I knew. This transaction was a month ago. Debug logs were not enabled and neither was database storage. We did an upgrade since then as well. I know I stared this, but might need to wait for another occurrence to get enough details to really figure this out.

Can you recreate the same order, logged in as the Customer & get similar numbers?
I don't remember auth.net performing any calculations when we were using AIM but we switched from AIM to SIM.