The movements with currency exchange only was created when the payment is full

[Luis Torres - http://www.vauxoo.com]

You can generate an new invoice in dollars, with an type of change of an date, and create a new payment for the invoice with other type of change to the invoice, but not full payment, and validate the payment, and you can see that not created movements for the account the currency exchange.

Now complete the payment of the invoice, and now yes created the moves for the account of currency exchange.

http://www.youtube.com/watch?v=k_kZm22cgIc

I had expected that by each payment I can see the moves with the currency change

[Luis Torres - http://www.vauxoo.com (luis-cleto-)]

Hi!
This bug have much time,and I not have known about progress.
I like know the status of this bug, please!
Regards

[Ravi Gohil (OpenERP) (rgo-openerp)]

Hi Luis Torres,

Sorry for inconvenience.

You are right that the movements for currency exchange is created when the payment is full but the amounts recorded in exchange accounts are correct, that is, it is calculated as per the currency rates defined of the actual payment dates, so this should not be considered as a bug rather a kind of improvement suggestion.

And such improvements can be done in trunk version and not the stable series, hence, changing the assignation of the bug.

Thanks.

[Moisés López - http://www.vauxoo.com (moylop260)]

Hello Amit,
Excuse me.
Where is the branch with this commit?

[Amit Parik (amit-parik)]

Hello Lopez,

I just confirmed it, our R&D team will make the branch for this.

Thank you!

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

Hello Amit & Naresh

Here is the reason why we, at vauxoo, regard this behavior as a bug,

From Wiley
13 ACCOUNTING FOR FOREIGN CURRENCY TRANSACTIONS AND HEDGING FOREIGN EXCHANGE RISK
page 16 in document [1] says:

"
...
The FASB reasoned that users of financial statements are best served by reporting the effects of
exchange rate changes on a firm's financial position in the accounting period in which they occur,
even though they are unrealized and may reverse or partially reverse in a subsequent period,
...
"

Fasb in document [2] Page 8, Section Foreign Currency Transactions says:

"
...
Foreign currency transactions may produce receivables or payables
that are fixed in terms of the amount of foreign currency that will be received or paid. A change
in exchange rates between the functional currency and the currency in which a transaction is
denominated increases or decreases the expected amount of functional currency cash flows upon
settlement of the transaction. <b> That increase or decrease in expected functional currency cash
flows is a foreign currency transaction gain or loss that generally shall be included in
determining net income for the period in which the exchange rate changes.</b>

...

"

IASB/IFRS in document [3] page 2 says:

'''
...
A foreign currency transaction shall be recorded, on initial recognition in the functional currency, by applying
to the foreign currency amount the spot exchange rate between the functional currency and the foreign
currency at the date of the transaction.

At the end of each reporting period:
(a) foreign currency monetary items shall be translated using the closing rate;
(b) non-monetary items that are measured in terms of historical cost in a foreign currency shall be translated
using the exchange rate at the date of the transaction; and
(c) non-monetary items that are measured at fair value in a foreign currency shall be translated using the
exchange rates at the date when the fair value was measured.

<b>Exchange differences arising on the settlement of monetary items or on translating monetary items at rates
different from those at which they were translated on initial recognition during the period or in previous
financial statements shall be recognised in profit or loss in the period in which they arise.
</b>
...
'''

Taking into account the knowledge that is available regarding recording transactions in foreign currencies
and considering that we, all OpenERP Community People, want our Openerp Suite be the best and stick to
the best practices available when it comes to accounting and IFRS recording, we want to enforce that this
behavior that is regarded by us as wrong be fixed, if help is wanted we are available to keep this channel open
and cooperate in the means that are meant necessary

Please can you make available the branch for this bug,

Thanks in advance

[1] http://www.wiley.com/college/bcs/0471173975/ch13.doc

[2] http://www.fasb.org/cs/BlobServer?blobcol=urldata&blobtable=MungoBlobs&blobkey=id&blobwhere=1175820909452&blobheader=application%2Fpdf
[3] http://www.ifrs.org/Documents/IAS21.pdf

[Frederic Clementi - Camptocamp (frederic-clementi)]

For your information, Luc & I already spent dozens of hours in 2011 on multicurrency account_voucher topics working with Fabien Pinckears.

This point is one of the long list of huge problem we have with the account_voucher which prove that integration of account_voucher with bank_statement is defective by design.

You simply cannot calculate exchange rate differences on partial payments if you want, the voucher also be able to handle multi-currency, write-offs, partial/full payment on multiple invoices (voucher lines)... too many possibilities -> impossible to tests correctely -> impossible to de-bug...(+ the huge performance issues)

After so much time & money lost on our side (because of account_voucher), we decided to stop using it and I advice you not loosing you time as well.

-> FYI we work with that now : http://bazaar.launchpad.net/~banking-addons-team/banking-addons/bank-statement-reconcile-70/files

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

Thanks for the advice Frederic, in the meantime we will keep pushing in order to reach
any advance in this key point

we have linked a branch with a possible solution to this issue not expecting it to land
in the stable branch but in the trunk branch

we will try to push harder to get it merged into the trunk.

Best Regards