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.
