Thanks so much for digging into this John. Yes, I can confirm that after updating using flatpak to 5.10 I also no longer see this issue. I'm not familiar with the code base whatsoever, but I'm also surprised that commit is related to this issue.
If the "fix" can't be explained, it may be worth adding some sort of check/warning system for this. Two rough ideas come to mind: 1. Make an independent memory copy of the value of the user entered Exchange Rate when a user presses ok in the Transfer Funds dialog and check this against the value to be written to the Price Database. As you explained, this isn't expected to be an exact match, but something as simple as a console warning/error when the value is off by > X% would at least make it visible if it ever appeared again. The idea being that so long as the copy of the Exchange Rate is independent, and not used elsewhere other than this test, any shared memory errors that may be unintentionally introduced by compilation/etc can be identified at runtime. 2. Some unit test that mimics the test I created to exemplify this issue. Is there any way to recreate this behavior programmatically rather than gui clicks? Otherwise this may reappear accidentally sometime in the future and since it is a silent error, I'd be worried about this indefinitely. Thanks again! On Fri, Feb 14, 2025 at 1:17 PM John Ralls <jra...@ceridwen.us> wrote: > Bo, > > I tried your example file and CSV import today and found that I could > reproduce the incorrect rounding behavior in 5.9 but not in 5.10. I did a > bisect (a binary search through the commits, building and testing at each > stop) to locate exactly what commit fixed it. It was > https://github.com/Gnucash/gnucash/pull/2otherwise036 > <https://github.com/Gnucash/gnucash/pull/2036> and the fix was completely > accidental. Even in retrospect I can’t explain why the rounding was wrong > before that change and is correct after it. I did double-check by reverting > it on current stable and observing that the bad rounding reappears. > > So upgrade to 5.10 and you’ll be able to import your CSV file. > > Regards, > John Ralls > > > On Feb 12, 2025, at 01:00, Bo Buckley <topherbuck...@gmail.com> wrote: > > Dear Jim, > > Thank you for your reply. > > After b), you enter an exchange rate in the Exchange Rate field, press tab >> to move focus out of that field. See if the exchange rate in the equation >> to the right updates with the Exchange Rate you supplied. > > > Yes, it updates as expected, but does not change the observed behavior > after pressing OK. > > Another thing to try is to click the radio button by Debit Amount in the >> Transfer Funds dialogue, then in that field, enter a formula of <yen charge >> as a positive number> * 0.0066 . I expect Gnucash can calculate a USD debit >> amount and put it in that field. If the amount is a whole number of >> dollars, that is further evidence of a bug. >> > > Results for same test.csv import set: > Date Description Transaction Amount DebitAmountGivenInTransferFundsDialog > ExchangeRateRecordedInPriceDatabase > 2025/01/29 Transfer Fee 20 270*0.0066 89/13500 > 2025/01/29 Transfer Fee 110 175*0.0066 -29/4375 > 2025/01/29 Transfer Fee 175 110*0.0066 -29/4375 > 2025/01/29 Transfer Fee 270 20*0.0066 -0.0065 > > Note the header change from before as now I am entering the Debit amount > and not the Exchange Rate as requested. This is even more bizzare, but I > wasn't sure why you recommended using the positive JPY value so I tried > with the negative and got: > > Date Description Transaction Amount DebitAmountGivenInTransferFundsDialog > ExchangeRateRecordedInPriceDatabase > 2025/01/29 Transfer Fee 20 -270*0.0066 89/13500 > 2025/01/29 Transfer Fee 110 -175*0.0066 89/13500 > 2025/01/29 Transfer Fee 175 -110*0.0066 89/13500 > 2025/01/29 Transfer Fee 270 -20*0.0066 0.0065 > > which looks more reasonable. Although this doesn't really work as a > workaround as the real-world scenario isn't all for transactions for a > single date (i.e. I'd have to manually look up the exchange rate for each > date and input it into this Debit field for every transaction, over an > entire year of transactions). That sounds about as efficient as pen and > paper over GNUcash :D, so I hope to avoid that if possible. > > Assuming I make a temporary JPY expense account duplicate for everything. > Is there an efficient way of pushing these back to a USD expense account > after this bug is resolved? Or would that just be pushing off the > inevitable requirement for manually typing out every transaction again? > > Thanks again. > > On Wed, Feb 12, 2025 at 7:33 AM Jim DeLaHunt <list+gnuc...@jdlh.com> > wrote: > >> Bo: >> >> On 2025-02-11 04:30, Bo Buckley wrote: >> > Dear John, >> > >> > Thanks for your time again. I uploaded the video, test.gnucash and the >> > test.csv file used to import the example transactions to my Network >> > Accesible Storage. You should have public access here: >> > >> > https://gofile.me/7Ad2L/z8EsrYEzD >> >> I was able to watch your "output.mp4" video. Good idea to post it! It >> was more informative than I expected. >> >> I have three observations from watching the video: >> >> 1. Your interaction appears to be: a) Transfer Funds dialogue appears, >> b) you type in an exchange rate of 0.0066, c) you press the OK button on >> the Transfer Funds dialogue. >> >> 2. At the moment between b) and c), there is a difference between the >> value in the Exchange Rate field, and the equation just to its right. >> e.g. at 0'49" in the video, the Exchange Rate field reads "0.0066", and >> the equation reads "1 JPY = 0.009091 USD". This is an interesting >> contradiction. I would expect the value in the Exchange Rate field to >> replace the previous value in the equation. >> >> 3. The result of importing the transactions e.g. at 0'56" in the video >> is that the charges to the Expenses:Bank Service Charge account are >> whole numbers of USD. It as if the arithmetic did not realise that the >> minimum increment for USD is 0.01, and treated it as 1. >> >> This might well be evidence of a bug in this part of GnuCash, I'm not >> sure. It is possible, for example, that when the CSV import kicks off a >> Transfer Funds dialogue for one transaction, it mistakenly labels the >> minimum increment of USD with the minimum increment for JPY. For a lot >> of currencies, the minimum increment in both currencies will be the >> same, 0.01, so I can imagine this getting overlooked. >> >> But one workaround which might be interesting for you to try is to spend >> a little more time interacting with the Transfer Funds dialogue. After >> b), you enter an exchange rate in the Exchange Rate field, press tab to >> move focus out of that field. See if the exchange rate in the equation >> to the right updates with the Exchange Rate you supplied. >> >> Another thing to try is to click the radio button by Debit Amount in the >> Transfer Funds dialogue, then in that field, enter a formula of <yen >> charge as a positive number> * 0.0066 . I expect Gnucash can calculate a >> USD debit amount and put it in that field. If the amount is a whole >> number of dollars, that is further evidence of a bug. >> >> A workaround is not as good as a bug fix, but you can take advantage of >> it faster, while you wait for a bug fix. >> >> Thank you for diligently collecting evidence and for your clear >> explanations. I hope this helps, >> —Jim DeLaHunt >> >> >> > _______________________________________________ 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.
