v6rc2 account_voucher - foreign curency in supplier voucher posts slightly incorrect rounding

[Vadim - Enapps LTD]

I have the following settings:

Base curency - USD
Purchase journal - USD and HKD
ex rate as at 31/12 - 7.782170

Part 1 - bug in supplier voucher

I created a new supplier voucher for 258.7 HKD dated 31/12
In the account_move_line table the entries are:

credit USD 33.24;HKD -258.70;
debit USD 33.24;HKD 258.68;

The calculations for the foreign curency, shouldnt be translated to base and then back, but just posted in as follows:
credit USD 33.24; HKD -258.70;
debit USD 33.24;HKD 258.70;

If I do the same operation via the normal purchase invoice screen, all is recorded correctly 258.70.

Part 2 - improvements needed to foreign curency payments

I will take the scenario from Part 1 (the invoice) , go to make the payment by clicking the Pay invoice button.

I would like to settle the amount in HKD as well. I have a HKD bank acount and a HKD bank journal for that purpose, so I select that from the journal dropdown menu.
The total stays at 258.70, yet Instead of displaying the original foreign curency amount in the transactions window, I see the 258.68, which is easy to figure out that it got converted from the base curency back into the payment curency and the generated account_move_line entries are as follows:

credit 33.24;-258.70;
debit 33.24; 258.68;

By looking in the db, I can see that the account_voucher_line has no foreign curency fields and therefore, I expect this will lead to more problems. I suggest to introduce a bit more accounting consistency as follows:

1 - database changes - account_voucher_line table - add the 'invoice_currency_amount'

2 - view changes - voucher changes in the transactions window:
a) add a non-editable field 'Invoice curency' - obtain value from the account_move_line
b) add a non-editable field 'Curency Original Amount' - obtain value from the account_move_line
c) add a editable field 'Curency Amount' which will be driven by foreign_curency _ids of the specific invoice and recorded in account_voucher_line.invoice_currency_amount.
d) add a non-editable field 'Curency Open Balance' which is the value of (b)-(c)

3) change the calculation algorithm, so the entries generated in the account_move_line as a result of posting the voucher is:

credit USD 33.24; HKD -258.70;
debit USD 33.24;HKD 258.70;

The above will also sort out the issue of being able to generate the exact aged reports even when we have partial multicurency payments and other complex scenarios, which I believe currently is limited only to the base curency.

Hope this is all clear.
Regards,

Vadim

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Vadim,

I have checked your bug specification with latest updated code:
Part-1: I have successfully Implemented the part-1 specification.You can check the attached screen shot.
Part-2: The part-2 specification is not generic issue so we can not consider this for implementation.
The related voucher contains all amounts in assigned journal currency only (If the journal currency is blank then the amount : company currency.) and you can see base currency (company Currency) converted amount in DR or CR with amount currency fields in Journal Items Page.

Hope this will help you.

Thanks.

[Vadim - Enapps LTD (vadim-enapps)]

thank you Vinay, p1 is sufficient for now. I guess i will do p2 myself, no problems.

Can you please release the code for p1, so I can test as well?

[Vadim - Enapps LTD (vadim-enapps)]

Sorry, I am not sure that I understood what you mean by implemented - fixed or replicated?

if you fixed it then its fine, if you replicated and you havent had the same issue, then probably I should have supplied the rest of settings for the curency:
rounding factor - 0.010000
Computational accuracy: 4

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Vadim,

You can take the latest updated code from LP:
https://code.launchpad.net/~openerp

Thanks.

[Vadim - Enapps LTD (vadim-enapps)]

Sorry to be a pest:

I updated all to the latest trunk, restarted the server, created a new db and I still have the same issue.

[Vadim - Enapps LTD (vadim-enapps)]

Sorry, this issue seems to still be present

[Vadim - Enapps LTD (vadim-enapps)]

Sorry, forgot to make a new db. part 1 fixed, yet there is a new bug. I will open a new bug.