[6.1] [account_voucher] exchange rate calculation is not working if company currency isn't rate 1

Bug #980967 reported by Carlos Vásquez (ClearCorp)
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Committed
Low
OpenERP Publisher's Warranty Team

Bug Description

In the account_voucher module, the currency rate is not well calculated. The method that write the account move line is not correct. It starts at line 227 in account_voucher.py:

    def _paid_amount_in_company_currency(self, cr, uid, ids, name, args, context=None):
        if not ids: return {}
        res = {}
        rate = 1.0
        for voucher in self.browse(cr, uid, ids, context=context):
            if voucher.currency_id:
                if voucher.company_id.currency_id.id == voucher.payment_rate_currency_id.id:
                    rate = 1 / voucher.payment_rate
                else:
                    ctx = context.copy()
                    ctx.update({'date': voucher.date})
                    voucher_rate = self.browse(cr, uid, voucher.id, context=ctx).currency_id.rate
                    company_currency_rate = voucher.company_id.currency_id.rate
                    rate = voucher_rate * company_currency_rate
            res[voucher.id] = voucher.amount / rate
        return res

This should be (diff output):

         for voucher in self.browse(cr, uid, ids, context=context):
             if voucher.currency_id:
                 if voucher.company_id.currency_id.id == voucher.payment_rate_currency_id.id:
- rate = 1 / voucher.payment_rate
+ rate = voucher.payment_rate
                 else:
                     ctx = context.copy()
                     ctx.update({'date': voucher.date})
                     voucher_rate = self.browse(cr, uid, voucher.id, context=ctx).currency_id.rate
                     company_currency_rate = voucher.company_id.currency_id.rate
- rate = voucher_rate * company_currency_rate
- res[voucher.id] = voucher.amount / rate
+ rate = company_currency_rate / voucher_rate
+ res[voucher.id] = voucher.amount * rate
         return res

I am posting a merge proposal with this change in a couple of minutes.

There is also a wrong currency_amount value calculation even if you apply the previous patch. This wrong calculation apply to only some lines of the move. I will get back on this bug about this later.

Tags: maintenance

Related branches

summary: - [6.1] [account_voucher} exchange rate calculation is not working if
+ [6.1] [account_voucher] exchange rate calculation is not working if
company currency isn't rate 1
Revision history for this message
Carlos Vásquez (ClearCorp) (cv.clearcorp) wrote :

To complete the bug description, we are using the last 6.1 openobject-addons branch, to test this error, just make a new database with demo data, install account_voucher, without any account plan. Set the company to any currency other than EUR (so it won't be rate 1) and to an invoice in another third currency and try to do a payment with any currency, the debit and credit amount will be wrong calculated.

Revision history for this message
Ravish(OpenERP) (rmu-openerp) wrote :

Hello Carlos,

I have checked your issue. But It's just a misconfiguration.

Let me explain

After creating a DB, you just have to configure company Header and Footer wizard , then try to install module. Because

When you first install a module ,then default company currency 's rate will be decided base on your company currency also all currency rates will applied base on which currency you have set on your company .

 Let's take one example

I have created my DB ans set company as EURO and then install account module,so currency rate will be load based on conversion of EURO .Now i have change my currency as CHF then you didn't see correct currency rate will apply .

So after creating , new DB ,run company header/footer wizard ,set your company currency then install account module .

Please try with above stated configuration and reply back to us .

Thanks!!!

Changed in openobject-addons:
status: New → Incomplete
Revision history for this message
Carlos Vásquez (ClearCorp) (cv.clearcorp) wrote :

Hi Ravish,

Thank you for your fast reply.

I don't agree with you. As I explained in comment #1, the point is to have a company currency with a currency rate different than 1.

For example:

I set USD to rate 1.
I have a company in CRC with rates changing every day at about 515.

I can't just set the CRC to rate 1 and USD to the according rate (for 515 it would be aprox 0.001942) because there are divisions involved, and divisions lose data. With these rates, if you convert $1500 using 515 CRC per 1 USD you have 772,500 CRC, which is expected in our economy. If you do it with 0.001942 USD per 1 CRC you have 772,399.59 CRC: 100.41 CRC less than it should be. This kind of error is not acceptable, and in the normal operation could lead to mistakes of several hundred USD per month.

There are several countries where this case applies, when you have an economy indexed to USD, but with a local currency that is very devaluated. Also this case applies if you have a multi-company configuración on different countries, where you need to set different currencies per company. You will have some companies with currencies with rates other than 1.

So the solution you are providing is just a special case of use for the multi-currency configuration, not the correct way to do it. Please look at my merge proposal, I think my code fixes the error.

Thanks

Revision history for this message
Carlos Vásquez (ClearCorp) (cv.clearcorp) wrote :

Hi,

I set this bug to new so you can re-triage. Please read comment #3 carefully.

Ravish's recommendation doesn't work because you don't always have the company currency set as base (rate 1).

To reproduce the bug, install a new DB with account_voucher. Set your company to another currency than EUR, I tried with CRC.

Then create an invoice in USD and try to register a payment in CRC. Check the amount_currency in the move lines.

Changed in openobject-addons:
status: Incomplete → New
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Carlos,

Yes, we got a same problem as per your scenario because of the exchange rate.

First I want to say this is not a bug, but sometimes it's happening with inconsistency due to exchange rate.

Let me explain in detail.
For 2nd scenario You have put a exchange rate = 0.001942 (1/515). Now the calculation is like.

1 CRC = 0.001942 USD
(?) CRC = 1500 USD , So 1500USD = 1500/0.001942 CRC = 772,399.59 CRC. which is the value you got on your 2nd scenario.

As in 1st scenario you got a value 772,500 CRC (1500*515 USD), So the difference is become more than 100CRC due to some decimal values.

You said that "I can't just set the CRC to rate 1 and USD to the according rate (for 515 it would be aprox 0.001942) " but the correct value is (1/515) = 0.001941748. If you put this exchange rate on USD then you will got a correct result on both secnario.

But the problem is we can't give more than 6 digits on decimal point because we have set a digits=(12,6) on rate field. If we have set a digit =(16,10), this is allow to set a 0.001941748 on exchange rate and return the following result on 2nd scenario.
1500/ 0.001941748 = 772499.830050037 which is totally nearest to your result.

So as per my "Opinion" we have to change the digits of rate field on res.currency.rate object like (12,6).

What do your think?

Thanks and waiting for your reply!

Revision history for this message
Carlos Vásquez (ClearCorp) (cv.clearcorp) wrote : Re: [Bug 980967] Re: [6.1] [account_voucher] exchange rate calculation is not working if company currency isn't rate 1

Amit,

I do think it is a bug. It isn't natural to use the weak currency as base.
And if you where in a multi-company situation, working in different
countries, you wouldn't be able to set the company's currency to base.

I think the precision on the rate is long enough, putting more decimals on
it would just slower calculations and increase the table size over time.

Please see my merge proposals attached to this bug. With 2 small changes I
got everything working. Now the voucher does the right calculations no
matter your currency configuration. I think this is a more permanent
solution.

If you find an error on my code let me know to fix it.

Thanks,
--
PS: escribí este email desde mi teléfono, por favor disculpe la brevedad y
cualquier error de escritura.

Carlos Vásquez
CTO · Director de Ingeniería
CLEARCORP S.A.

<email address hidden>
CR: +(506) 4000-CORP (4000-2677)
US: +1 (786) 472-4267
Cel: +(506) 8351-4484
skype: crvasquez
twitter: cvclearcorp

300 m. Este de la Escuela
Calle de Platanares
11402 San Jerónimo, Moravia
San José, Costa Rica

http://www.clearcorp.co.cr

tags: added: maintenance
Changed in openobject-addons:
assignee: nobody → OpenERP Publisher's Warranty Team (openerp-opw)
importance: Undecided → Low
importance: Low → Undecided
Revision history for this message
Somesh Khare (somesh.khare) wrote :

Hello Carlos,

Thanks for your contribution and for your branch.

We have created a separate branch regarding this issue and the details of the branch are as follows,

Branch: lp:~openerp-dev/openobject-addons/6.1-opw-574440-skh
Revision ID: <email address hidden>
Rev-no:6807

This branch is under the review of our experts and will be merged into the stable 6.1 if there is no regression found due to this code.

Thanks

Changed in openobject-addons:
importance: Undecided → Low
status: New → Fix Committed
Revision history for this message
Carlos Vásquez (ClearCorp) (cv.clearcorp) wrote :

There is still one problem with this subject.

For supplier payments (vouchers type = payment), the rate exchange move lines are not correctly calculated. I just uploaded a new version of my branch (lp:~cv.clearcorp/openobject-addons/6.1-account_voucher-rate) with some changes that correct this behavior.

Please update update your branch from mine before merging it to the upstream 6.1.

We are running these changes in several production systems without problems.

Thank you.

Jay Maniar (z3m-jay)
Changed in openobject-addons:
status: Fix Committed → Fix Released
Revision history for this message
Don Kirkby (donkirkby) wrote :

This bug is fixed in trunk, but not in 6.1. Any plans to merge the fix into 6.1?

Revision history for this message
Naresh(OpenERP) (nch-openerp) wrote :

@ Jay Maniar (z3m-jay): Please don't set the status to "Fix Released" the related MP is still Needs review and is not merged in 6.1
Setting the status to fix released means exactly the opposite.

Thanks,
Naresh Soni

Changed in openobject-addons:
status: Fix Released → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.