openerp-expert-accounting team mailing list archive

["Olivier Dony \(OpenERP\)" <odo@xxxxxxxxxxx>]

Hi everyone,

To finish the discussion on this issue, and specifically the remaining
question of whether to have the invoice automatically handle additional
"rounding moves" somehow, here is an explanation of the strategy that
will be used in OpenERP.

We have considered all possible options, and came to the following
conclusions:

 - OpenERP accounting is specific and does not need 'rounding moves' to be able 
   to validate a multi-currency invoices with everything balanced (as opposed to other 
   accounting systems that perhaps need it). 
 - Accounting is a very sensitive and complex topic, but our goal is to try keeping the main
   process as simple as possible, and avoid bloating it with all kinds of exceptions and specific
   behaviors.
 - Specifically, we know that in many countries the law lets you handle these situations as you
   see fit. For example some "legally defined" charts of accounts do not even include dedicated
   accounts for "rounding adjustments" or "penny difference" as they were named here. 
   This is why OpenERP will only implement the basic logic that is common to everyone in 
   multi-currency.
 - I repeat: we want to be very clear for community and customers, OpenERP does not make errors in 
   computing multi-currency invoices, and all moves are balanced.
 - Now for countries or companies that absolutely insist that the "penny difference" 
   or "rounding adjustment" must be processed by the invoice itself and not to be handled by the
   normal reconciliation process (as for exchange rates write-offs), we will offer the same sort of
   solution as usual: this must be done in a separate module.

But in order to be able to cleanly implement a separate module as suggested in last item above, a refactoring of the current code is needed, to split the process in smaller chunks that will be easier to extend. 
This refactoring cannot be considered for stable (5.0) of course, so it will be done in trunk (for 6.0). 

However, we already want to provide an extension hook dedicated for this situation. Please see the definition of the hook that we propose in the patch in the next post. By default this hook is basically a "no-op", but you can use it to provide you own logic.
With this solution, you can directly write a module that implements everything you still wish to add. In fact you can even do this for 5.0! Your module could even add a property per company and currency to choose the account where you directly want to post the "penny difference" moves that you don't want to see on the payable account.

I think this concludes the discussion on this bug, and we can safely
consider it fixed.

-- 
Cannot validate invoices with foreign currency
https://bugs.launchpad.net/bugs/452854
You received this bug notification because you are a member of OpenERP
Accounting Experts, which is a direct subscriber.

Status in OpenObject Addons Modules: Fix Released

Bug description:
Hello,
have stumbled upon interesting problem. Latvian Lats (LVL) is the base currency for Accounting. Try to issue (or encode received from supplier) invoice in Euros(EUR). The same would happen between any other currencies too.

Invoice totals:
Total w/o VAT (Untaxed): 1158,00 EUR
Tax VAT 21% : 243,18 EUR
Total: 1401,18 EUR

Try to Confirm invoice and you will get "You can not validate a non balanced entry !"

Made some investigation what is wrong, and have found that the problem is.

Obviously the totals are calculated perfectly right, but as the base currency for accounting is different from the currency we are issuing invoice the accounting moves are done in the base currency, in this case LVL.

So goes the currency exchange

Total w/o VAT (Untaxed): 1158,00 EUR ->(813,8470320 ~813,85 LVL)
Tax VAT 21% : 243,18 EUR ->(170,9078767 ~170,91 LVL)
Total: 1401,18 EUR ->(984,7549087 ~984,75 LVL)

Which again are technically right, with one difference, that the totals for posting are now not dependent on each other anymore. They are being rounded before posting.

If you would issue invoice in a base currency the difference is in 0.01LVL, which is lost during rounding process. Notice the Total sum.
Example:
Total w/o VAT (Untaxed): 813,85 LVL
Tax VAT 21% : 170,91 LVL (VO_VAT * 21% = 170,9085000)
Total: 984,76 LVL (VO_VAT + VAT_21)

To deal around floating point storage in Python (as well as other programming languages), allowed difference between sums are allowed 0.0001. This is the place where postings do not pass validate(...) function in "account.py".

This is right as balance between credit and debit should be equal. What should be done - accountant would probably create write-off entry for the missing sum to make the balance right. This functionality is missing in OpenERP, and is fundamental for foreign trade.

Any ideas?

P.S. version 5.0.6.

Kaspars