Tax display off by a penny for some tax rates

Tax calculations are off by a penny when using a tax-rate with more significant digits than the currency displays.

Using a fresh zc156 base with the demo products loaded, I started by creating a Taxable Goods product with a price of $5.00.

I then modified the tax-rate for Florida to be a 5.5% tax and modified the Flat Rate shipping (still $5.00) to be also Taxable Goods.

Went to the storefront and added 2 x the $5.00 product to my cart, went to checkout choosing 'Flat Rate' as my shipping option.

On the checkout_payment page, the order's total is off by a penny:

Sub-Total: $10.00
Flat Rate (Best Way): $5.00
FL Tax 5.5%: $0.82
Total: $15.83

The issue lies with the ot_tax display, since the tax on $15.00 is $0.825 (rounded for display to $0.83).

Is this unique to v1.5.6?

Nope, I've verified back to zc154. I just used zc156 as the base to see if, perhaps, something had changed.

Here's another one (store is not displaying prices with tax). Using demo installation.

Create a product, priced at $74.75.
Modify one of the shipping methods (flat or item) to be (a) taxed and (b) to have a fixed cost of $5.00.
Create a fixed-price coupon for $1.01.
Modify the store's tax-rate to be 6%.

Add 1 x the product to the cart and go to checkout, choosing a shipping address that will have the 6% tax applied and choose the taxed $5.00 shipping method.

On entry to the checkout_payment page, the order's totals show:

Sub-Total: $74.75
Shipping: $5.00
Sales Tax: $4.79
Total: $84.54

Apply the fixed-price coupon. Totals now show

Sub-Total: $74.75
Shipping: $5.00
Coupon: -$1.01
Sales Tax: $4.73 ... should be $4.72 = 4.42 (rounded from 4.4244) + 0.30
Total: $83.47

FWIW, I believe that the second example's output is corrected by making the following modification to the zc155/zc156 versions' /includes/modules/order_total/ot_coupon.php:

          switch ($this->calculate_tax)
          {
            case 'None':
              break;
            case 'Standard':
              if ($od_amount['total'] >= $orderTotalDetails['orderTotal']) $ratio = 1;
              foreach ($orderTotalDetails['orderTaxGroups'] as $key=>$value)
              {
//-bof-20190217-lat9-Don't pre-round tax to be subtracted, can result in penny-off calculations
//                $od_amount['tax_groups'][$key] = zen_round($orderTotalDetails['orderTaxGroups'][$key] * $ratio, $currencyDecimalPlaces);
                $od_amount['tax_groups'][$key] = $orderTotalDetails['orderTaxGroups'][$key] * $ratio;
//-eof-20190217-lat9
                $od_amount['tax'] += $od_amount['tax_groups'][$key];
                if ($od_amount['tax_groups'][$key] == 0) unset($od_amount['tax_groups'][$key]);
              }
              if (DISPLAY_PRICE_WITH_TAX == 'true' && $coupon->fields['coupon_type'] == 'F') $od_amount['total'] = $od_amount['total'] + $od_amount['tax'];
              break;
            case 'Credit Note':
              $tax_rate = zen_get_tax_rate($this->tax_class);
              $od_amount['tax'] = zen_calculate_tax($od_amount['total'], $tax_rate);
              $tax_description = zen_get_tax_description($this->tax_class);
              $od_amount['tax_groups'][$tax_description] = $od_amount['tax'];
          }

Note that the "real" tax-rounding is happening in the order-total's ***process ***method.

Nope, that didn't work. Taking the configuration from post #4, with the following modification:

Create a product priced at $98.75
Modify store's tax rate to 7%
Create a 5%-off discount coupon

On entry to checkout_payment:

Sub-Total: $98.75
Shipping: $5.00
Tax (7%): $7.26 (actually 7.2625)
Total: $111.01

Apply the 5%-off coupon:

Sub-Total: $98.75
Coupon: -$4.94 (actually 4.9375)
Shipping: $5.00
Tax (7%): $6.91 (should be $6.92, rounded from 6.9167)
Total: $105.72

I'm all over the place with this one; the invalid output was due to a previous edit of the order-class operation. Using zc155f's order-class with the change proposed in post #5 of this thread produces the correct results.

lat9:

Tax calculations are off by a penny when using a tax-rate with more significant digits than the currency displays.

Using a fresh zc156 base with the demo products loaded, I started by creating a Taxable Goods product with a price of $5.00.

I then modified the tax-rate for Florida to be a 5.5% tax and modified the Flat Rate shipping (still $5.00) to be also Taxable Goods.

Went to the storefront and added 2 x the $5.00 product to my cart, went to checkout choosing 'Flat Rate' as my shipping option.

On the checkout_payment page, the order's total is off by a penny:

Sub-Total: $10.00
Flat Rate (Best Way): $5.00
FL Tax 5.5%: $0.82
Total: $15.83

The issue lies with the ot_tax display, since the tax on $15.00 is $0.825 (rounded for display to $0.83).

Just to update the calculation method, the individual taxes ($0.55 on $10.00 and $0.275 on $5.00) are each rounded to their currency-specified decimal digits (0.55 and 0.28, respectively) to produce the total of $0.83.

lat9:

I'm all over the place with this one; the invalid output was due to a previous edit of the order-class operation. Using zc155f's order-class with the change proposed in post #5 of this thread produces the correct results.
As indicated, I believe that the change posted corrects the tax-related rounding issue(s) with ot_coupon, but I'm still trying to find the root-cause of the base order penny-off calculations.

Here's another one, created a product priced at $98.75, still using that $5.00 flat-rate (and taxed) shipping.
Modified the tax-rate for Florida to be 6.5%.

On the checkout_payment page, the order's calculated tax is off by a penny:

Sub-Total: $98.75 ... tax is 6.41875, rounded to 6.42.
Flat Rate (Best Way) $5.00 ...tax is 0.325, rounded to .33
FL TAX 6.5%: $6.74 ... should be 6.42 + 0.33 = $6.75
Total: $110.49 ... should be $110.50

Why for the state of Florida is the shipping and item being taxed separately? Doesn't Florida Administrative Code (Rule 12A-1.045) identify that the tax should be applied against the entire purchase such that 98.75+5 = 103.75 and that 6.5% sales tax is to be applied such that the tax is 6.74375 and is then rounded down (amount after 6.74 is less than 5) such that the tax is 6.74 and the total is 110.49? Or is Florida a state that requires rounding up of final values to the nearest 0.01 such that the above would still be expected to be 110.50? Or even for that matter is the shipping taxable (if customer is given the option to pick up in store then presumably not)?

While I haven't worked out what combination of numbers would be necessary, it seems that if the proposed method of calculation (round tax at each item/method and then sum the taxes) were used that amounts in excess of the amount due would be collected instead of not enough...

And further than any of that being specific to FL (considering using the default database which tags FL for an example), which way is appropriate for general taxation? Sum of all items in a tax group and then tax on it, or tax on each item that is then summed to give a total? I pick this aspect of discussion as I am aware also of work on the VAT type module where the goal is to display the total including tax and total without the tax including such information on a page where each item is listed with both sets of numbers. As I have commented elsewhere in the forum, the associated values can vary depending on what the final expectations are. E.g. Tax on an item is calculated to the currencies number of decimal places and then multiplied by the quantity of items, total amount for the number of the product is determined then tax is calculated from that result, summation of all products cost and then tax from there, etc...

@mc12345678, that's called a test, simply using the Taxable Goods configuration provided by Zen Cart to model/test various tax situations that have nothing to do with Florida specifically.

The real question is: ***At what point should tax-related rounding occur?

***Zen Cart pricing/tax calculations get rounded by the order- and shopping-cart classes and various payment methods and order-totals, so that each taxed addition (or subtraction) from an order's pricing is rounded (or not) at the hands of the module that's making that change to the order's totals.

I guess the question is whether any tax additions/subtractions from the order should be performed with or without rounding, leaving the final rounding operation to the ot_tax module.

I now believe that at least part of the rounding-related issues might be due to various castings to (float).

Take a "simple" case:

A $1.00 product taxed at 0.055% with free shipping is added to the cart. On entry to the 'checkout_payment' page, the order's "Tax" improperly displays as $0.05 while the order's total properly shows $1.06.

The issue is that the value recorded in the order's tax_groups for that product is 0.05499999999999994 which, when rounded to 2 significant digits, is 0.05!

lat9:

The real question is: ***At what point should tax-related rounding occur?

***Zen Cart pricing/tax calculations get rounded by the order- and shopping-cart classes and various payment methods and order-totals, so that each taxed addition (or subtraction) from an order's pricing is rounded (or not) at the hands of the module that's making that change to the order's totals.

I guess the question is whether any tax additions/subtractions from the order should be performed with or without rounding, leaving the final rounding operation to the ot_tax module.
While in the US it is typically done one way, some other countries do treat it other ways. The answer would need to start with determining whether tax is initially charged at the per-item level vs the per-item-times-its-quantity level vs the all-items-of-that-tax-class level, as that affects the initial rounding strategy. Then an order-edit module would follow accordingly.

I have lost count of how many threads or posts there are about rounding errors. It seems way overdue that this issue is resolved.
So, if the issue is the tax basis

whether tax is initially charged at the per-item level vs the per-item-times-its-quantity level vs the all-items-of-that-tax-class level,
In my case (Spain), tax is added on the sub-total of all items within a tax group.

What is the roadmap for resolving this - can a discussion be initiated to determine all the possible tax basis?

torvista:

I have lost count of how many threads or posts there are about rounding errors. It seems way overdue that this issue is resolved.
So, if the issue is the tax basis

In my case (Spain), tax is added on the sub-total of all items within a tax group.

What is the roadmap for resolving this - can a discussion be initiated to determine all the possible tax basis?
Good idea! I've created this (https://www.zen-cart.com/showthread.php?225248-Discussion-of-various-tax-handling-methods) post as starting point to gather the taxation requirements (and underlying algorithms) required for the various localities.