[GNC] Exchange Rate to Price Database issue with low transactions amounts

[list+gnucash at jdlh.com]

Bo:

Thank you for a good question!

John Ralls already gave you an answer, and it is correct. John writes 
the code, he knows whereof he speaks. But let me try to explain it a 
different way.

On 2025-02-09 04:36, Bo Buckley wrote:
> ...I recently tried to add a JPY checking account to my books....
> I noticed all smaller transactions (e.g. wire fees, interest, etc.)
> were all being converted incorrectly....
> ...you will see the following:
>
> Date Description Transaction Amount ExchangeRateGivenInTransferFundsDialog
> ExchangeRateRecordedInPriceDatabase
> 2025/01/29 Transfer Fee 110 0.0066 0.00909090909090909
> 2025/01/29 Transfer Fee 150 0.0066 0.00666666666666667
> 2025/01/29 Transfer Fee 200 0.0066 0.005
> 2025/01/29 Transfer Fee 300 0.0066 0.00666666666666667
> 2025/01/29 Transfer Fee 500 0.0066 0.006
> 2025/01/29 Transfer Fee 1000 0.0066 0.007
> 2025/01/29 Transfer Fee 2000 0.0066 0.0065
> 2025/01/29 Transfer Fee 5000 0.0066 0.0066
> 2025/01/29 Transfer Fee 10000 0.0066 0.0066

Thank you for clearly explaining what you did and what you saw. That is 
helpful. (I have not tried to reproduce it, I believe your evidence.)


> My expectation is that whatever is entered into the "Exchange Rate" will be
> used and saved into the Price Database. This is not happening....
This is an incorrect expectation. GnuCash does not behave this way. 
Exchange rates used in transactions might get saved to the Price 
Database, but as John said, there is only one entry per calendar day. 
Different rates on the same day will overwrite preceding rates. Exchange 
rates from the Price database might get used as the default value in the 
Transfer Funds dialogue, but what you enter there will take precedence.
> For the
> smaller transaction amount (in this example case < 5000 JPY) the Exchange
> Rate Recorded in Price Database appears to change on its own accord and not
> even linearly. What really stinks is that this all happens silently...
> My only guess is this has to be something to do with a rounding error....

Not quite rounding error. The conceptual mistake is to treat the 
exchange rate as fundamental. It is not. It is merely the ratio of value 
in currency A to value in currency B. AFAIK GnuCash does not even store 
that ratio.  It is the values in the two currencies which are fundamental.

In your example, when importing each transaction and filling out the 
Transfer Funds dialogue, I think you will have better results if you 
disregard the Exchange Rate field, and concentrate on entering the 
correct USD amount for the Expenses:Bank Service Charge account.

When the Transfer Fee was 1,0000 JPY, what was the USD amount of the 
service charge? If it was 64.42 USD, then enter that. The exchange rate 
field will show a rational number, maybe something like 3221/50000. That 
is approximately 0.00644, but exactly 64.42/1,0000.

When the Transfer Fee was 300 JPY, what was the USD amount of that 
service charge? If it was 1.93 USD, and you enter that, the rational 
number in the Exchange Rate field might be something like 193/30000. 
That is approximately 0.00643, but exactly 300/1.93.

And so on for a fee of 110 JPY, which might be a service charge of 0.71 
USD, with an exchange rate of 71/11000, approximately 0.00645.

> ... So two summarizing questions:
>
> 1. Is this a known bug on bugzilla? I could not find it via a Google
> mailinglist search or on bugzilla
The best answer is, the Exchange Rate computation is a feature, not a 
bug. However, we can also see from your observations that the Transfer 
Funds dialogue and how it applies to multi-currency transactions is 
confusing. Also, the documentation is inadequate. I totally agree about 
that. I enter such transactions all the time, and I still get confused 
by GnuCash's mechanisms.
> 2. Is there a known workaround?

Yes. When entering data into the Transfer Funds dialogue, do not enter 
numbers into the Exchange Rate field. Use it solely to check your work. 
Concentrate on entering the correct transaction value amounts in each 
currency in their two fields.

Does that help?
       —Jim DeLaHunt