c2c-oerpscenario team mailing list archive

["Fabien \(Open ERP\)" <fp@xxxxxxxxxxx>]

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)

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/707923

Title:
  [6.0 and 5] invoice tax - rounding issue

Status in OpenERP Modules (addons):
  Won't Fix

Bug description:
  see attachment

  due to rounding of the calculated tax for each position we get totals
  which are wrong.

  In Austria we usually group the basis per tax rate and calculate the
  tax from this basis to avoid such errors.

  in account/invoice.py
  class account_invoice_tax  - 
  def compute must be modified 

  actually only some lines of code to group the invoice lines before
  calculating the tax

  probably this has been discussed (but not solved) already