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/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 > <mailto:list%2bgnuc...@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.
