Comment 18 for bug 707923

Hello,

I confirm both tax computation methods are usually allowed and we never found one country which does not allow both. After having checked a few softwares, we noticed both practices exists on the market. We think it's not a big constraint, because you can always change the amount if your supplier uses the other method.

The reasons we did per line and not globally:

1. Prices with Tax Included
-----------------------------------

It's the only way to make invoices having prices with tax included. If a product has prices with tax included the way you compute the tax is very different and a small delta must be applied to the tax itself, to reach the product's price. Suppose a product is 4€, having a VAT of 19.6% (like in France). If you compute, you have 3.34*1.196=3.99 and 3.35*1.196=4.01. The real amount must be: Without VAT: 3.34, VAT: 0.66€.

The only way to compute this is to work by line and not globally, if you mix several products having different taxes.

2. Complex taxes
-----------------------

OpenERP has the strongest tax engine I ever saw in any accounting software. It allows to do a lot of things: multiple taxes on a product, a tax that is applied over another tax (like in Quebec/Canada), a tax which is a mix of several taxes, not only pure percentage but fix price or python expression.

When several taxes are mixed in one invoice, you can not always recompute globally, easily.

Even worse, some taxes can never be computed globally. In Belgium, you have the SACEM tax (Sabam in France, a tax on the art work of artists). This tax computation looks like:
  - it applies only if the painting/music is less than 50 years old
  - the price is computed according to the base price. I don't remember the exaxt amount, but it looks like:
     - from 1 to 500€: 10€ of tax
     - from 501 to 5000€: 30€ of tax
     - ...

This is simply impossible to compute globally. It's not a "so special" use case, we have at least 6 customers in production that are using this tax in the auction module.

Workaround if you really need it
-----------------------------------------

Computing globally is very complex and not suitable if we want to keep this code clean. However, there is a quick workaround we already used for some customers, with only two lines of code to change:
  - keep a 'per line' computation
  - but don't do rounding at the end of the line, just apply the rounding at the end.
This will give you the same effect than a global tax computation, but will works in all scenario.

I prefer not to apply this on OpenERP has it's not very clean, but it seems to work. (I did not tested with tax included)