One of the sides is not the default-currency, so an exchange rate is set.
this rate will always differ from the rate the system is provided with automatically (when no fixed currency conversion is set). This results in a “Difference Amount” which needs to be written off as “exchange gain/loss”.
now this is clear. But I would assume that the rate picked in the Payment Entry Document should be calculated from the 2 values that are involved. I see however that this is not done correctly which results into wrong “difference amount”.
See the example below where the exchange rate 0.141 appears automatically when providing the values (USD 3,481.21 & CNY 24,442.42) on both ends.
However 3,481.21 / 24,442.42 = 0.1424249 and not 0.141
the Difference Amount USD 34.34 therefore is way too high. It seems that my ERPNext instance always sets the rate USD/CNY to 0.141
Is there any way to make this work correctly automatically?
Re-calculating and adjusting to the correct rate is possible but requires quite some additional manual steps which makes working dreadful. I also believe there will me many occasions where we just wrote of a way too high exchange Gain/Loss because you are not always alarmed to need to correct the System.
But in order to get the difference amount to way smaller amount or in some cases to zero you could temporarily set it to 4 or 5 depending on what you get as your exchange rate. once this transaction is done, you could revert back to 3.
Yes in my case i had the exchange rate always showing at 0.412 (euro to omr) in the payment entry . I had set the Manual Exchange rate for the day and my sale orders and quotes where showing 0.41235. It was difficult to save the payment entry as it was always showing difference amount.
This is just a temporary solution until developers check into this
ok, got it. I believe it is less trouble to manually correct the exchange rate in the Payment Entry you are working in though.
Also imagining a situation where several or even many ppl work on accounting transactions at the same time I guess changing the precision back and forth constantly may be causing problems beyond being inefficient. I would not bare the risk to have a situation where the rounding precision is being changed while (even multiple) financial documents are created at the exact same moment.
are you @centaur aware whether this bug has been reported in the issues already?
Are you guys working with stored Currency Exchange rates? I was under the impression that the currency exchange rate overrides other calculations. We typically read this from a (governmental) reference, then the issue seems to not occur…
sorry I forgot to mention this … I do not have any manual currency exchange entries in my instance, so the system grabs them from fixer.io which (I believe) gets it from the European Central Bank.
I believe though that the rate in the multi-currency Payment Entry should be calculated from the values (money sent in currency A / money received in currency B). Only the creation of the “Difference Amount” should involve either the auto-fetched rate or a manual “Currency Exchange” entry (whether one existed).
