Trouble rounding residual amount into invoice : may be a client trouble

Hello,

You need to set --price-accuracy=4 in the configuration.

If you are using Ubuntu then start the server from terminal with following way :

./openerp-server --addons-path=../../addons-5.0.6 --price_accuracy=4

Hope this will help you.

Thanks.

Hi !

I try with this option on my test server, but it doesn't change my test results :( The accuracy trouble is still here .

I also create a new database with this option, and in this case it return : 0.0096 instead of 0.01 which is better. But I still have a difference...

I don't really know how to handle this the right way. _amount_residual function should may be return 0,0 in that case, but it's not a good solution neither cause this difference could mean the invoice still has an open amount...

Thanks to give your opinion,

This problem with handling multi-currency (e.g. comp = EUR and invoice = CHF) is common for all financial packages due to rounding from one to another currency.
From technical point of view best way to handle this for OpenERP would be storing the financial values in database without rounding. Then round the value when displaying/print the value and only round in the database at the end of a workflow. Currently OpenERP doesn't do this.
Resulting you can expect this kind of rounding issues. Even when above methode would be used, you still can get rounding issues, but the diffs are smaller, thus more accurate.

The only way you can handle this for now is to accept the diff due to the multi-currency rounding and use of a write-off account to reconcile the invoice. As far I know this is allowed in every European country and common practice.
On the end of year this write-off account is more or less zero, because all rounding write-offs booked will equalize this account.

On the long term we could think of a redesign for all financial fields to store without rounding, change the forms to round the display fields, same for reports and add a new function to round the database value only at the end of a workflow.

In addition to my above #3 comment.

OpenERP is rounding every stored value, resulting in several roundings during the total workflow. This will lead ad the end (reconcile part) to more inaccuracy as needed. Thus this is not only a multi-currency problem, but a general rounding problem, where it is more visible with multi-currency. Above mentioned technical outline could solve most of the rounding issues in OpenERP, but needs a big rework.

can we do something about it in 5.0? I'm planning it on 5.2 because it's seems very important to have this fixed in 5.2. Nonetheless would also be nice to have it fixed in 5.0, but given the amount of change and work required I'm not sure Tiny can do it and accept it, while it would absorb a lot of resource if they attempt doing it in a backward compatible way that would better be assigned to fixing other important bugs. Thoughts?

Hi,

So I reference it in my BP about rounding trouble into OpenERP here:

https://blueprints.launchpad.net/openobject-server/+spec/generic-accuracy-improvement

Regards,

Joël

We have two issues: better rounding accuracy and what to do with rounding differences. IMO, writing-off the difference is the right thing to do we should just automate the process (like configuring a default write-off account, change methods that do the rounding to create a write-off move, etc.)

Hello Subscribers,

Would you please recheck with the lastest codes?

Here are the steps I followed:
1. Change the system date back to 1st jan.Restart the server.
2. New supplier Invoice of 1000 CHF on date 1st of Jan 2009.(Provided, the CHF rates are as per the discussion above).
3. I validate the invoice.
4. Create a new bank statement ,import the mentioned move lines.(wasn't this step useless ,guys?)
5. Change the system date to today's date.
6. Pay the invoice via wizard from invoice.
7. Observe the Residual amount. I get 0.00 in my case.

Thank you.

Hi !

According to the same scenario (made with OERPScenario), this bug is no longer here !

It's probably because you change the rounding into res_currency : well done !

Regards,

Joël