a.net charged tax before discount

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?

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?

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.

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

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.

You can round all your product prices with Techicant's MySQL from this thread #58:
https://www.zen-cart.com/showthread.php?79927-Increase-price-on-all-products-universally/page6&highlight=price+change

mc12345678:

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.

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?

jeking:

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

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?

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.

jeking:

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.

jeking:

... 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 throw the gateway into test mode for a minute and re-run the transaction? (Just add same items to your own cart and check out.)

VDecalS:

You can round all your product prices with Techicant's MySQL from this thread #58:
https://www.zen-cart.com/showthread.php?79927-Increase-price-on-all-products-universally/page6&highlight=price+change

Wanted to be sure at least someone spoke to this. That method of SQL rounding would be helpful for those that:

1. entered prices using the local currency and as such a decimal number that needed the additional rounding.
2. for cases where the database price needed to be changed.

That said, the issue being observed here is not related to what was originally entered in the database, but how the database information is used to make a purchase. Pretty standard things but the output/result seen is not even close to what is expected.
I.e.:
add product to cart
begin shipping process
begin payment process and apply coupon code
taxes applied
see results/confirmation
make purchase
data stored in database about purchase
review of data indicates a "problem" as the total for the purchase does not match the amount charged to the customer.

It just happens that the coupon applies a 15% discount and local taxes are 8% which might lead one to think that there is a "larger" change being applied like described in that post/thread.

RixStix:

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.

What a simple question (That I should have done initially!)

When I recreate the order, I get $52.47 as my total. For those not wanting to look back, this was the total a.net charged. Conclusion: something was wrong with the cart but somewhere along the line, I'd guess the upgrade to 1.5.5e, fixed it. The original install was 1.2.5 back in 2005, oldest cart I've seen. It's a new client for us, so they'll be happy to hear this news.

What a great community of helpers. :D

jeking:

What a simple question (That I should have done initially!)

When I recreate the order, I get $52.47 as my total. For those not wanting to look back, this was the total a.net charged. Conclusion: something was wrong with the cart but somewhere along the line, I'd guess the upgrade to 1.5.5e, fixed it. The original install was 1.2.5 back in 2005, oldest cart I've seen. It's a new client for us, so they'll be happy to hear this news.

What a great community of helpers. :D

Perhaps then some additional context could be provided about how these things fit together? Me here still confused about the "history" of the transaction... Seemed like there was a concern with how ZC 1.5.5 was processing payment, the quoted message implies that ZC 1.5.5 had nothing to do with the transaction in question and that possibly was looking over some sort of historical records and came across the discrepancy?

And in your test(ing) did you take it to completion or just to the point of submission, etc? Was the issue first seen in an earlier version of ZC 1.5.5 (current being ZC 1.5.5e)? It would be good to know and maybe come to understand especially if someone else were to come across the same issue.

Absolutely, let me try to do that.

At the time of the transaction it was 1.5.5a. Since then, we upgraded to 1.5.5e and changed the template (unrelated, but full disclosure). It was brought to my attention by the new business owner while doing reconciling.

My test order was processed through a.net and was for $52.47.