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

[Bo Buckley]

Thank you for another reply John.

What you explain makes sense to me, but it is not the observed behavior
from my version of GNUCash. If it were the same, I would not have an issue.

Let me use your same example values.

You postulated an exchange rate of $0.66/100¥. Suppose you have two splits,
> one for 175¥ and one for 270¥.  The first one is $1.155, but there’s no
> such thing as half-pennies in US currency so it gets rounded to $1.16. The
> second is 1.782 and is rounded to $1.78. The *stored numbers* for the first
> split are 175¥ (amount) and $1.16 (value), *implying* a price of 116/17500
> or ~.006685714285714… $/¥, The second split stores an amount of 270 and a
> value of 1.78, *implying* a price of 178/27000 or ~.006592595


Take the following values (Note I leave in two extra examples of 110 JPY
and 20 JPY as the exhibit extreme examples:
Date Description Transaction Amount
2025/01/29 Transfer Fee 20
2025/01/29 Transfer Fee 110
2025/01/29 Transfer Fee 175
2025/01/29 Transfer Fee 270

Within the Transfer Funds Dialog for each, I manually set the Exchange Rate
to 0.0066. As you explained, I would expect that I get

The second split stores an amount of 270 and a value of 1.78, *implying* a
> price of 178/27000


But what I actually get is a price of 1/135, which if brought to a common
denominator would be 200/27000, not 178/27000. Thats over by 200/178 or ~12%

Moving forward to the 175 JPY case, I again enter 0.0066 as the exchange
rate in the Transfer Funds dialog expecting whatever I specify to be used
instead of any existing entry in the Price Database. Now I would expect
based on your explanation:

The *stored numbers* for the first split are 175¥ (amount) and $1.16
> (value), *implying* a price of 116/17500


But instead, I see the Price Database entry is now updated to have a value
of 1/175, which bringing to the common denominator would be 100/17500 not
116/17500.  Thats under by 110/116 or ~ 5%.

This alone should be alerting, but moving forward to the more extreme
examples brings further alarm.

For the 110 case, I again enter 0.0066 manually for the Exchange Rate, and
would expect based on your explanation that 110 JPY * 0.0066 would give
0.726 USD then rounded off to 0.73 USD. Or a price of 73/11000, but in face
the Price Database records 1/110 as the Price. Matching denominators that
would be an expected price of 73/11000 vs an actual price of 100/11000.
Thats over by 100/73 or ~ 37%.

Even more extreme, for the 20 JPY case, entering in 0.0066 for the Exchange
Rate, I would expect from your explanation to see 20*0.0066 = 0.132 USD
rounded to 0.13 USD, with a price of 13/2000, but instead the Price
Database records 0. Not an ratio of 64 bit ints. Not a decimal
representation, but flat out 0. The Match Transaction Dialog, even after
pressing OK in the Transfer Funds Dialog, will still give an error
"UNBALANCE (need price to transfer JPY-20 to acct Expenses:Bank Service
Charge)!" ... i.e. the same error as prior to setting the exchange rate.

If I then press apply and close, and view the JapaneseChecking account (see
attached), You will see all the results I described above. I'm also
attaching the test.gnucash file that was used to generate these numbers.

Looking forward to your reply and thanks again.

On Mon, Feb 10, 2025 at 1:25 PM John Ralls <jralls at ceridwen.us> wrote:

>
> > On Feb 9, 2025, at 17:32, Bo Buckley <topherbuckley at gmail.com> wrote:
> > @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.
> >
> There is no one place.  The price database is implemented in
> libgnucash/engine/commodity.cpp. The transfer dialog, of which the exchange
> rate section is a part, is in gnucash/gnome-utils/dialog-transfer.c.
> Transaction balancing is in libgnucash/engine, with pieces of it in
> Transaction.cpp, Split.cpp, and Scrub.cpp. IIRC transaction currency
> selection happens somewhere in gnucash/register/ledger-core/ but I don’t
> know offhand which file.
>
> For the rest, you need to understand that the price database entry is a
> record of the last price retrieved or calculated on a particular day.
> (That’s not quite true, but let’s not digress into why not, it’s not
> important for the discussion at hand.
>
> Each split has an amount of and a value. I explained what those are in my
> previous letter. They don’t have an explicit price.
>
> Perhaps an example will help. You postulated an exchange rate of
> $0.66/100¥. Suppose you have two splits, one for 175¥ and one for 270¥.
> The first one is $1.155, but there’s no such thing as half-pennies in US
> currency so it gets rounded to $1.16. The second is 1.782 and is rounded to
> $1.78. The *stored numbers* for the first split are 175¥ (amount) and $1.16
> (value), *implying* a price of 116/17500 or ~.006685714285714… $/¥, The
> second split stores an amount of 270 and a value of 1.78, *implying* a
> price of 178/27000 or ~.006592595…. (GnuCash uses the exact rational number
> internally; decimals are used only for display.)
>
> I said “implying” because while one of those prices might get stored in
> the price database it’s quite possible that neither will or that the price
> in the price database will get overwritten later.
>
> GnuCash must work this way in order for transactions, accounts, and the
> book to balance and stay balanced. The price database is there to calculate
> values for reports and the Accounts page, but reports have an option to
> calculate a average cost from individual splits, and that option is the
> only one that will allow the Trial Balance report to balance.
>
> Regards,
> John Ralls
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import.png
Type: image/png
Size: 79151 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20250210/d5943ef6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.gnucash
Type: application/x-gnucash
Size: 5479 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20250210/d5943ef6/attachment-0001.bin>