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

[Bo Buckley]

Dear John and Jim,

Thank you for your replies. Though I'm not sure they solve my problem.

Consequently for best results enter the correct amount in the register and
> the value in the exchange rate dialog and let GnuCash calculate the
> price/exchange rate.
>

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.
>

Both your answers appear to point to instead of entering an Exchange Rate,
to enter the Debit Amount in USD. But in this example, and in most of my
real-world scenarios, I don't have this number in USD and would like to use
an Exchange Rate to calculate it. The examples in this issue are bank
transfer fees that were charged in JPY to my JPY based checking account. I
also have bank transfer fees that are charged in other separate USD based
checking accounts. I want all bank transfer fee expenses to be within a
single USD based expense account. Is this not an expected use case?

Regardless, I'm really not understanding the point of the "Transfer Funds"
dialog if you can't reliably enter an Exchange Rate. Why have the input
Exchange Rate and "Fetch Rate" if it will potentially be silently
overridden?

Price is calculated when necessary as the ratio amount/value and is rounded
> only as needed to be represented by a ratio of two 64-bit integers.
>

By "Price" here, you are referring to the Price Database entry
Currencies:JPY:JPY:Price right? "Amount" is the transaction amount I'm
importing in JPY, e.g. 10,000, right? What then is "value" with regards to
a GNUcash element?  Also how is "when necessary" defined? In my example, I
already have a correct Exchange Rate (i.e. Price entry in Price Database)
of 0.0066 for 1/29/2025. It would be my assumption that recalculating it
would be unnecessary if such a price already exists. Am I misunderstanding
something?

Price is calculated when necessary as the ratio amount/value and is rounded
> only as needed to be represented by a ratio of two 64-bit integers.
> Consequently for best results enter the correct amount in the register and
> the value in the exchange rate dialog and let GnuCash calculate the
> price/exchange rate.
>

@John Ralls, would you be able to point to where in the codebase this is
handled (i.e. where the Exchange Rate from the Transfer Funds Dialog is
taken and how the Price Database entry Price is calculated?) I'd understand
a lot better seeing the code. Otherwise I'm lost on why this has to be left
as a known rounding error and cannot be handled some other way.

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.


I think this is just a misunderstanding of what I was trying to say. I
understand that there is only one price per day, and all will be
overwritten; this seems reasonable to me and not unexpected.


> 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.


This is precisely the problem I'm trying to point out, it doesn't seem to
take precedence. Compare the values in my csv/table provided for the
columns ExchangeRateGivenInTransferFundsDialog and
ExchangeRateRecordedInPriceDatabase. There you will see that despite
entering 0.0066 for all Exchange Rates in the dialogue, the actual recorded
Price (i.e. exchange rate) varies unexpectedly when recorded to the Price
Database. I'm also now seeing this noted in the docs at
https://gnucash.org/docs/v5//C/gnucash-guide/currency_trading_accts.html:

Whereas if Exchange Rate is selected and entered, the exact value is not
> often recorded due to the rounding errors.
>


> 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.


I may be misunderstanding something, but aren't those the same thing? I.e.
0.0066 USD * ExchangeRate = 1 JPY. The ratio of 0.0066 USD / 1 JPY is the
Exchange Rate, which is what is stored in the Price Database, no? If not,
then what are you referring to specifically when you say "value" as it
pertains to a GNUcash element?

Thanks again in advance!

On Mon, Feb 10, 2025 at 7:09 AM <list+gnucash at jdlh.com> wrote:

> 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
>
>