GNOME Bugzilla – Bug 763146
Invalid exchange rate is recorded when entering multi-currency transaction
Last modified: 2018-06-29 23:47:47 UTC
Preconditions: Asset account's currency: USD Expense account's currency: BYR Price database has at least one BYR-USD exchange rate Steps: 1. Enter a transaction in a BYR expense account 2. Select USD account to transfer money from 3. Enter exchange rate 1 BYR = 1/21000 USD 4. Go to price database AR: price database contains the exchange rate 1 BYR = 21 000 USD. In case there are no BYR-USD exchange rate in the database, then GC stores 1 USD= 21 000 BYR which is correct. Thank you in advance
Created attachment 323331 [details] Screen shot showing price editor, edit-exchange-rate, and transaction. I can't replicate this. The transaction-based price always goes to USD->BYR or nowhere if the BYR->USD is on the same day as the transaction. I tried with the books root currency being both USD and BYR (the latter is shown in the screenshot).
Created attachment 323353 [details] screencast when incorrect price is being recorded
Created attachment 323354 [details] file from video Video and the file attached. In the video: 1. when entering multi-currency transaction in a BYR account, 1 BYR=21000 USD exchange rate stored - invalid 2. when entering transaction in a $ account, 1 BYR = 0 USD exchange rate is stored - also invalid. I did not specify this in the ticket description, but in fact I have experienced this behaviour before.
I couldn't get the video small enough to attach, so view it here: https://www.dropbox.com/s/m3qzp6xlsns7rtr/Get%20Started%20with%20Dropbox.pdf?dl=0 Using your test file (which I renamed to BYRtest to keep it straight, as you might imagine I have lots of test files), the vid shows me resetting the existing price to 1/21000 and creating another transaction on the same date starting in Expenses::Books. Note that the price doesn't change. Creating yet another transaction but on a different date creates a new price USD->BYR. However, when I go the other way, from Expenses:Books to Savings Account, I *do* see the zeroing of the exchange rate. I'm investigating that part.
OK, I found a bunch of things, fixes for which I've pushed. Please test if you can. There are fedora nightly builds at https://copr.fedorainfracloud.org/coprs/gjanssens/gnucash-maint/; the commit you want is 18e6100. It may take up to 24 hours for the build to complete.
Created attachment 323755 [details] empty amount Thanks. Unfortunately I cannot say for sure whether the issue is fixed or not because there is another annoying issue. 1. Open attached file 2. Open Expenses->Books 3. Start typing "a" 4. Gnucash suggests the values from pervious transaction 5. Change the amount from suggested 65 933.40 to smth else 6. tap enter Result: Expense amount in Books is empty, unable to edit exchange rate. In Saving account amount is 3.21, it is possible to edit exchange rate. I tried debugging the steps above and the only thing I can say is that the statement "gnc_commodity_equal (txn_cur, xfer_com)" (split-register-control.c:1407) is evaluated to true for some reason on step 6. When entering the transaction from the savings account, everything is fine. In my personal gnucash file (not a test one), however, the situation is opposite - I can only enter in BYR expense accounts. When entering the transaction in USD account, the amount is empty
I've figured out that that problem is caused by auto-completing transactions which were created in a register for the other currency. In other words, you made the first "a book" transaction in Savings Account. That caused the transaction currency to to be set to USD, and when you let gnucash auto-complete the transaction in Books it compares the transaction currency with the "other account" currency (and since you're in Books the other account is Savings Account) finds they're the same, and decides not to run the Transfer Dialog to get a rate. Meanwhile another bit of code has looked at the two accounts, decided that they have different currencies, and set the price to 0/1 in anticipation of the Transfer Dialog being called to set the rate. There's special logic in GnuCash that blanks the credit/debit cell if the rate is 0. With that information I think that you can work around the problem and test this bug while I figure out how to get auto-completion to not set the transaction currency so that it will stay with the register where the transaction is created. An aside: Do you really use fractions of a BYR in ordinary transactions?
OK. I can confirm that the issue is no longer reproducible in maint branch. Just want to confirm that the following statements are correct: 1. In case there is a price to the current date, new exchange rate is not added to the database 2. Only rates above 1 are stored. Do I need to open another ticket for the issue with autocompletion? > An aside: Do you really use fractions of a BYR in ordinary transactions? Never. BYR does not have fractions. BYN will.
(In reply to Eduard Valiauka from comment #8) > OK. I can confirm that the issue is no longer reproducible in maint branch. > Just want to confirm that the following statements are correct: > 1. In case there is a price to the current date, new exchange rate is not > added to the database That depends. If the price on the date was created with the price editor then the only way to change it is with the price editor. If the price is from a transaction then a new transaction will overwrite it if the price rounded to the "larger" currency's (USD in this case) smallest unit is different. That's to prevent the price jitter that used to happen when one had several FX transactions in a single day. A Finance::Quote price will replace an older one, and also any transaction-based prices. > 2. Only rates above 1 are stored. Certainly the case for BYR, but in cases where the rate is close to 1 the direction of the first price created on the day will be preserved even when the price is < 1 because it's not very much < 1 so rounding won't be losing significant digits. > > Do I need to open another ticket for the issue with autocompletion? No, I'm working on it. BTW, another work-around: If you enable trading accounts it works properly. > > > An aside: Do you really use fractions of a BYR in ordinary transactions? > Never. BYR does not have fractions. BYN will. OK. I asked because of the BYR-cents in your example.
The auto-complete problem is fixed too for 2.6.12.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=763146. Please update any external references or bookmarks.