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

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
  • You've mentioned PDF invoice in your question. But, magento doesn't support PDF invoice download in default. You might be using an EXTENSION or, plug-in for that, try to find error on codes for that extension. Oct 30, 2014 at 12:50
  • @RahulKumarDas of course Magento does. The question is valid anyhow: Do you use any extension for the invoice PDF download? In any case, this extension solves many rounding problems - give it a try.
    – Simon
    Oct 30, 2014 at 12:54
  • @Simon Magento allows you to Print the invoice, but, not in a PDF downloadable form! That's what my point was. So, the Questioner must be using some extension to create an invoice PDF for it's customers. Oct 30, 2014 at 13:03
  • @RahulKumarDas you cannot download a PDF invoice as a customer, but as an admin you can of course download it with a standard Magento installation.
    – Simon
    Oct 30, 2014 at 13:06
  • @Simon that's very true! We both don't know, which side the invoice is generated here in case of our questioner. I thought, it might be from Customers end. So, the misunderstanding occurred. Let the questioner explain his issue in more detail. Oct 30, 2014 at 13:09

2 Answers 2

  • 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!

  • Thanks, but I could not find the formatPriceTxt() from that Currency.php. There was however formatTxt($price, $options = array()). Did you mean that? I'm not sure what to do there.
    – Webninja
    Oct 31, 2014 at 13:29
  • What's your Magento version? Oct 31, 2014 at 17:47
  • My Magento version is
    – Webninja
    Nov 1, 2014 at 5:43

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)

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

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)

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.