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 <jra...@ceridwen.us> wrote: > > > On Feb 9, 2025, at 17:32, Bo Buckley <topherbuck...@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 > >
test.gnucash
Description: application/gnucash
_______________________________________________ gnucash-user mailing list gnucash-user@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.
