openerp-expert-accounting team mailing list archive

[Joël Grand-Guillaume @ CampToCamp <joel.grandguillaume@xxxxxxxxxxxxxx>]

Hi,

This seems to work in some cases, but OERPScenario still fail with
price_accuracy = 2 with this test:

      Given the company currency is set to EUR 
      And the following currency rate settings are:
      |code|rate|name|
      |EUR|1.000|01-01-2009|
      |CHF|1.644|01-01-2009|
      |CHF|1.500|09-09-2009|
      |CHF|0.6547|10-10-2009|
      |USD|1.3785|01-01-2009|

@rounding @bug452854
  Scenario: Validate the rouding computation on an invoice with 3 lines
    Given I have recorded on the 11 oct 2009 a supplier invoice (in_invoice) of 1144.0 CHF without tax called MySupplierInvoiceRounding
    And I add a line called MyFirstLine on the last created invoice of 91.73
    And I add a line called MySecondLine on the last created invoice of 63.00
    And I correct the total amount of the invoice according to changes
    When I press the validate button
    Then I should see the invoice MySupplierInvoiceRounding open
    And the total credit amount must be equal to the total debit amount
    And the total amount convert into company currency must be same amount than the credit line on the payable/receivable 
account

      expected: 1983.71,
           got: 1983.7 (using ==)
      
       Diff:
      @@ -1,2 +1,2 @@
      -1983.71
      +1983.7

This fix the incoherence in price_accurace define in the server and the
computation, but doesn't handle the trouble with 2 digit I think.

On two digit, you still have a difference between debit and credit
moves...


I think it's ok to correct that, it's better than nothing, but don't close the bug as it did fix everything.


Regards,

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

Status in OpenObject Addons Modules: In Progress

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