taxes on invoice depend on the order of the line items

in the screenshots you can see that swapping the order lines changes the tax coding applied, it picks up the code of the first line item.

in account/account_invoice.py
line 1679 insert
                val['id'] = tax['id']
line 1701 change to
                key = (val['tax_code_id'], val['base_code_id'], val['account_id'], val['account_analytic_id'], val['id'])

so it groups by tax ID, not just the tax code IDs

alternatively just add val['name'] to the key, but I think it is probably best to go by ID

The problem was that ST0 and ST11 both contributed to the same tax code (total sales ex VAT) and the grouping is by code and not by tax

also need to change the key in check_tax_lines to match

Hello Alan,

I have tried your issue with zero rated tax with latest code but I didn't face any problem at my end.

Also I am not able to seen the line 1679 insert
                val['id'] = tax['id'] on account/account_invoice.py.

I have attached the screen-shot for your more details, So would you please check it which clearly show the zero rated tax entry.

Would you please try with latest code and notify us have you still face the problem or not.

Thank you and waiting for your reply!

what chart of accounts is that?
here is a diff that fixes the problem by the tax name rather than the id. The problem happens when you have two taxes with the same base code and same tax code but different amounts on them. We have this in the UK chart of accounts - your one is probably set up differently.

=== modified file 'account/account_invoice.py'
--- account/account_invoice.py 2013-01-05 23:29:19 +0000
+++ account/account_invoice.py 2013-01-31 09:27:02 +0000
@@ -786,7 +786,7 @@
             for tax in inv.tax_line:
                 if tax.manual:
                     continue
- key = (tax.tax_code_id.id, tax.base_code_id.id, tax.account_id.id, tax.account_analytic_id.id)
+ key = (tax.tax_code_id.id, tax.base_code_id.id, tax.account_id.id, tax.account_analytic_id.id,tax.name)
                 tax_key.append(key)
                 if not key in compute_taxes:
                     raise osv.except_osv(_('Warning!'), _('Global taxes defined, but they are not in invoice lines !'))
@@ -1692,7 +1692,7 @@
                     val['account_id'] = tax['account_paid_id'] or line.account_id.id
                     val['account_analytic_id'] = tax['account_analytic_paid_id']

- key = (val['tax_code_id'], val['base_code_id'], val['account_id'], val['account_analytic_id'])
+ key = (val['tax_code_id'], val['base_code_id'], val['account_id'], val['account_analytic_id'], val['name'])
                 if not key in tax_grouped:
                     tax_grouped[key] = val
                 else:

Hello Alan,

Ok, now I got why you get only one line on tax line. You have got one tax line for two different taxes because you have given a same base code and same tax code for both taxes.

Let me elaborate more here. base code and tax code are used for differentiate a tax category, you can see the chart of tax account based on base code and tax code. Base code will shows the base amount and tax code shows the tax amount.

If you select the same base code and tax code then it will shows the only one tax line invoice which is fine. If you want the separate tax line on invoice then you have to give a separate tax code and base code.

Currently we are shows the first invoice lines 's tax on tax description, that's why you get this type of result.

So this is not a bug rather than its behavior please share your answer.

Thank you!

the problem is that it is perfectly valid to have two different taxes at different rates contributing to the same base code and tax code for the tax report. If you group taxes from invoice lines based on them having the same base and tax codes then you get the wrong rate being applied.
Zero rated is probably not the best example as that doesn't need a tax code so could be different to the standard rate one, but consider an invoice with some lines at lower rate vat at 5% and some at standard rate vat at 10%. It doesn't make sense to collapse two differently named taxes onto one line just because they contribute to the same totals on the tax report.

Hello Alan,

I have checked your issue with latest trunk with "UK chart of accounts".

I have tried the following steps (you can see it on attached video).

I have created a two invoice line with two different taxes but both taxes have the same tax code and same base code.

i.e (As on video). I have select two different product line with two different tax( one is 10% and 2nd is 20%) and amount is same100.

Then see the only one line created for tax (tax line) and amount is see.. .. tax amount which is 30 and its absolutely correct.

Please see attached video and let me know your answer about this.

Thank you!

yes, that is the issue, it reports as one tax line with code PT11, the amounts are right, but it is confusing to see it reported as 30 against PT11 when the tax on the invoice is actually 20 of PT11 and 10 of PT1. If you swap the lines around then it will be 30 of PT1. The tax reporting shouldn't depend on the order of line items on the invoice!

Hello Alan,

As I told you on my comment#1, When there is a same tax code and base code on taxes of invoice line it will be grouped the tax line and shows the only one tax line with one tax's description.

Yes, It will be confusing sometimes cause its shows one taxes description. We have to found a better solution for that and decide which description should be better for grouped tax line.

Actually this is not a bug, but its improvement for removing the confusion that's why currently I am setting this as a "Wishlist".

Thank you!

this was discovered because I was doing some reporting on the account.invoice.tax objects to try and validate the tax reports (we had some invoice line items that were not coded correctly as zero rated) and I could see that the zero rated tax code had tax amounts booked to it. The best solution is not to group different tax names as per the patch above in #10. That works fine, it still groups multiple lines booked to the same tax, it still allows multiple taxes on one line, it still credits the same bits of the tax reports, it just doesn't mess up reporting on account.invoice.tax objects.

Hello Alan,

On official addons we have on report for tax report and on this report we have categorize the tax line by their account tax code.

So you never worry about the tax name and description , you can see the tax amount based on account tax code.

And its fine, Please try to use Generic Reports/Taxes/ Tax Reports.

Thank you!

This appears to still be an issue in version 8 trunk

Alan, I to am having this same issue and need this corrected. It is bad enough in the United states where one City has 3 different tax rates based on State, City and County, but if I have to add all 3 different taxes per transactions every time I cut an invoice I am looking at 3 different bases, 3 different tax codes, this will not work at all.

We need to separate the line items by separate taxes that can share the same tax code but show separate lines for each so the taxes are not merged to one line as the customers are very confused and by law I have to show a separate line item for specific tax charged.

I have been trying to get this to work in V8 (Trunk) for the last 4 days until I found this post. Is there a module they could make for United States tax lines?

Also, regarding the Taxes on the invoice, why for each separate tax that I add, it shows a Base amount original amount of the invoice added to that sum each time I apply another tax.

Example:
My total invoice is for $600.00 and I apply a state tax at .06875 or 6.875%, base says $600.00, then I apply another separate City Tax at .0050 or .05% and now the base says $1200.00 and then I add my 3rd Tax a County Tax of .00250 or .0250% and the base now says $1800.00. This gets printed on the invoice and I just don't understand why can someone please help me or explain this to me?

Thanks

I created a merge proposal to fix this bug
https://code.launchpad.net/~alanbell/openobject-addons/openobject-addons/+merge/212830

Edward Washburn, you should file a new bug for that as it doesn't seem to be related to this one.