wrong currency rounding

[Lorenzo Battistini]

openobject-addons/6.0 revno 4863

Steps:

 - Configure 'account' module using EUR currency
 - Configure a bank journal for USD currency
 - Create a new rate for USD currency, with date 2011-10-01
 - Create a new invoice, with date 2011-09-01, selecting USD currency and inserting one line of 3638.97 amount
 - Pay the invoice selecting 'Reconcile with Write-Off' (with today's date)

The write.off entry is not created (it should be produced by the different currency rates).
This is because of line 88 of base/res/res_currency.py :

round(amount / currency.rounding) * currency.rounding
3638.9700000000003

and this makes false the line 719 of account_voucher.py (line.amount == line.amount_unreconciled)

I think the line

return round(amount / currency.rounding) * currency.rounding

should be replaced by something like

float(Decimal(str(amount)).quantize(Decimal(str(currency.rounding)), rounding=ROUND_HALF_UP))

[Amit Parik (amit-parik)]

Hello,

I have faced the same problem. The currency rate applied properly but "Amount Currency" doesn't proper.
For more reference I have attached a screen-shots so would you please check it.

Thanks.

[Lorenzo Battistini (elbati)]

Sorry Amit, I can't understand what's wrong with your screenshot.
What rate do you have for USD?

[Amit Parik (amit-parik)]

Hello Lorenzo,

Please see the "Amount Currency" for the "Counterpart Account" which is 0.0 USD but it should be 138.97 (104.23 EURO).

I have created a new currency rate for 1/10/2011 which is 1.33333 as per this currency rate calculation is correct.

Thanks.

[Olivier Dony (Odoo) (odo-openerp)]

Hi,

We don't use Decimal for OpenERP, our floating point calculations are all performed with floats, and we have appropriate solutions for all cases based on floats. So for consistency, please do not introduce the use of Decimal in patches.
For more info on the everlasting Float vs. Decimal discussion, see [1].

Here the problem is the equality comparison in account_voucher. For checking that 2 amounts are equal with regard to an appropriate precision, the 2 amounts should be subtracted and checked with res.currency.is_zero().
You can see other examples of how this is done in other places in the code, for example [2].

Thanks!

[1] https://lists.launchpad.net/openerp-expert-accounting/msg00067.html
[2] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/5493/account_voucher/account_voucher.py#L940

[Lorenzo Battistini (elbati)]

Thanks Olivier

[Lorenzo Battistini (elbati)]

So Amit, I think we should replace

line.amount == line.amount_unreconciled [1]

with something like

currency_pool.is_zero(cr, uid, currency, (line.amount - line.amount_unreconciled))

[1] http://bazaar.launchpad.net/~openerp/openobject-addons/6.0/view/4907/account_voucher/account_voucher.py#L718

[Ferdinand (office-chricar)]

Once again OpenERP must be set up to comply to fiscal standards

* countries have their individual rules or habits

we have to distinguish between
* outgoing / customer invoices
the method used (column/line) must be configurable in res_company to allow SAAS and multicompany whit different needs

* incoming / supplier invoices
>>> the company is obliged to post the same VAT amount that is printed on the invoice <<< hence
- the method must be set in res_country, because it is most likely that a suppiler will conform to his "home" rules
- if a supplier uses a different method it must be stored at partner level

for comfort - incoming invoices should be checked according to these rules and the appropirate rule should be applied
for this to happen it is necessary to enter the VAT amount for each invoice. otherwise it is up to the users to check visually and correct the VAT amount

give that total - vat may not be net caculcated by OpenERP an easy way must be established to correct VAT and NET

[Amit Dodiya (OpenERP) (ado-openerp)]

Hello,

Thanks Olivier Dony for the suggestion.

The issue is fixed in branch : lp:~openerp-dev/openobject-addons/6.0-opw-18123-ado with revision-id : <email address hidden> and revision-no : 4912

This will be merged into the stable version soon.

Thanks,
Amit

[Lorenzo Battistini (elbati)]

Hello Amit, see https://code.launchpad.net/~openerp-dev/openobject-addons/6.0-opw-18123-ado/+merge/81939/comments/177079

[Ferdinand (office-chricar)]

IMHO we should have a res_currency

def _compare(...,amount1,amount2)

which returns
-1 if amount1 < amount2
0 if amount1 = amount2
+1 if amount1 > amount2
taking into account currency and pythonic rounding issues

[Olivier Dony (Odoo) (odo-openerp)]

On 11/12/2011 01:26 PM, Ferdinand @ Camptocamp wrote:
> IMHO we should have a res_currency
>
> def _compare(...,amount1,amount2)

I think that's a good suggestion, I was on the process of extracting the
res.currency float methods into tools.misc to make them available for
other float computation (e.g. stock quantities), so I've added a
compare() like method too.

See the merge prop[1], reviews/comments are appreciated, as always.

[1]
https://code.launchpad.net/~openerp-dev/openobject-server/trunk-float-rounding-odo/+merge/82206

[Rifakat Husen (OpenERP) (rha-openerp)]

Landed on addons 6.0,
Revision ID: <email address hidden>
Revision 5092

[nicolas moreau (ytu-nipola8-hbw)]

6.1 seems affected by this bug too, it doesn't seem like the patch was

[nicolas moreau (ytu-nipola8-hbw)]

6.1 seems affected by this bug too,was this ever pushed to 6.1 ?

[Lorenzo Battistini (elbati)]

Just tested with
openobject-addons/6.1 revno 6996
and I'm not able to reproduce the bug

[Serpent Consulting Services (serpent-consulting-services)]

Nicolas,

Just made sure it is ported to 6.1.

See : http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/annotate/head:/account_voucher/account_voucher.py#L1321

Let me investigate more in detail.

Probable causes/solutions:
1. Good to set 4 as decimal precision/accuracy.
2. Some hectic numbers like x.666666 x.333333 might be causing a mess. In that case, what is proposed is an account that handles such a minor difference and thus it does not stop entries getting validated.
3. Old invoice if they were validated with accuracy 2 and we now use 4 accuracy for voucher! This could be the cause. In such a case, we should manually round the all calculations by 2. This is a workaround, works good, but not so professional approach for the fix.

Hope this helps.

Thanks.

[nicolas moreau (ytu-nipola8-hbw)]

In more detail the issue we found shows up in account_voucher.py/voucher_move_line_create
While calculating the amount on line 1082
amount_currency = currency_obj.compute(cr, uid, company_currency, line.move_line_id
this returned -2086.4000000000001 in our example, it should have been -2086.4000
This then fails later in reconciliation since -2086.4000000000001 != -2086.4000

So it seems currency_obj.compute doesn't take into account the rounding and decimal precision setup for the company.

[Lorenzo Battistini (elbati)]

On 09/20/2012 11:54 AM, nicolas moreau wrote:
> In more detail the issue we found shows up in account_voucher.py/voucher_move_line_create
> While calculating the amount on line 1082
> amount_currency = currency_obj.compute(cr, uid, company_currency, line.move_line_id
> this returned -2086.4000000000001 in our example, it should have been -2086.4000
> This then fails later in reconciliation since -2086.4000000000001 != -2086.4000
>

Hello Nicolas,
could you please provide the steps to reproduce your problem?

--
Lorenzo Battistini

[nicolas moreau (ytu-nipola8-hbw)]

like the original example:

 - Configure a bank journal for USD currency
 - Create a new rate for USD currency, company base is AUD
 - Create a new invoice, selecting USD currency and inserting one line of 2086.4
- Invoice created has name: SAJUSD0065(for example)
-Make sure invoice is posted in Journal Entries
- Pay the invoice using Customer Payments
-Throws exception saying SAJUSD0065

the exception is in account_move_line.py (803)

from what we found the exception is raised because the currency adjustment entry didn't get posted and stayed in draft state due to the fact that the amounts didn't match.
The amounts didn't match due to the above rounding errors

hope this makes sense

[Lorenzo Battistini (elbati)]

Sorry Nicolas, I'm not able to reproduce your problem.