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

[sunfish62 at yahoo.com]

I hesitate to jump in here, since you've already got the best advisor in John, but...

You keep entering the exchange rate, and it's been stated clearly before that the exchange rate is not stored and is not reliable. 

You mentioned in passing previously that you don't know the destination amount, and also that the JPY fees are entered into a JPY account, which explains your not knowing how much that turns into in USD. I think the proper solution here would be to create a separate transaction fees expense account denominated in JPY, thus obviating the need to rely on an inaccurate exchange rate altogether. 

I believe that GnuCash can provide USD amounts for these JPY expenses in the reporting system. 

⁣David T.​

On Feb 10, 2025, 8:18 AM, at 8:18 AM, Bo Buckley <topherbuckley at gmail.com> wrote:
>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
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>gnucash-user mailing list
>gnucash-user at gnucash.org
>To update your subscription preferences or to unsubscribe:
>https://lists.gnucash.org/mailman/listinfo/gnucash-user
>-----
>Please remember to CC this list on all your replies.
>You can do this by using Reply-To-List or Reply-All.