Full Tax Summary rounding issue in pdf invoice

Question

For some reason our Magento rounds the individual tax rate's amount wrong in PDF invoice. In shopping cart and in order email the amount is right.

Here is the wrong version:

VAT 24%: 1.93
ALL TAXES: 1.94

The "all taxes" in that example is the right amount of tax.

We have these settings:

Tax calculation method based on: Total
Tax Calculation based on: shipping origin
Catalog prices: including tax
Shipping prices: including tax
Apply customer tax: after discount
Apply discount on prices: including tax
Apply tax on: original price only
Enable cross border trade: no

Invoice display settings:

Display prices: including tax
Display subtotal: including tax
Display shipping amount: including tax
Include tax in grand total: yes
Display Full Tax Summary: yes
Display Zero Tax Subtotal: no

Answer 1

• Sales Invoice PDF file is generated through /app/code/core/Mage/Sales/Model/Order/Pdf/Items/Invoice/Default.php @ line 107: 'text' => $order->formatPriceTxt($item->getTaxAmount()),

• The problem you're facing possibly because of formatPriceTxt(), which is located @ /app/code/core/Mage/Directory/Model/Currency.php

• So, you can create a new formatTxt() function and override the existing one from your local code base! That will do your job!

Answer 2

The infamous one cent issue. The likely scenario is that there is some issues with the number of significant figures after the decimal place during various calculations.

The best way I can illustrate this is using some math in an example:

A product that has a cost of 1.15 and has a tax rate applied at the single item level, for each of two items will be a penny different than the tax rate applied to the total of the product cost for two items.

While it seems like this is something that is rather obvious, what it has to do with is when and how rounding is handled. If I were to leave the decimals significance to 4 digits throughout the entire calculation, the solution will be the same at the very end for both scenarios. If I round to two digits before adding the cost of each item in the line total, then it may have a different result than if the two items were rounded to two digits after the summation of the line total.

PS> [math]::round((1.1500*0.24*2),2)
0.55

PS> [math]::round((1.1500*0.24),2)*2
0.56

Now, this can also occur when a single item is being taxed. It simply depends on what the cost of the item is at four decimal significance when tax is calculated.

If a product has a price of 2.8750, and were to be rounded to 2.88 before tax, we get two different answers.

PS> [math]::round(2.8750*(1+.24),2)
3.56

PS> [math]::round(2.88*(1+.24),2)
3.57

If you are going to dispute the price inserted similar to the example above to 4 digits after the decimal, then here is where I suggest that this is common among 'catalog' discounts where a percentage is applied to matching products, and the price update results in a difference that would yield such a price to four digits.

I think (and welcome detailed corrections) that there have been some methods implemented to work with such issues in a more flexible way: getPrice() and getFinalPrice(), if I am not mistaken produce a four-decimal and two-decimal result, respectively. The getFinalPrice() method handle the calculations to two decimal places and depending on your settings is the price that would be used for tax calculations.

---

The reason I explain the scenarios is simply because it is possible that this is so unique to your situation that a fix cannot be found but the scenario can be debugged and resolved.

Combining both scenarios above, you are now even more hard-pressed to find the problem within the code.

---

Perhaps the solution would be best resolved to rewrite the output of the totals in the pdf methods, to obtain the calculated and stored values within the sales_flat_order table.