After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763146 - Invalid exchange rate is recorded when entering multi-currency transaction
Invalid exchange rate is recorded when entering multi-currency transaction
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Currency and Commodity
2.6.11
Other Linux
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2016-03-05 19:26 UTC by Eduard Valiauka
Modified: 2018-06-29 23:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screen shot showing price editor, edit-exchange-rate, and transaction. (310.75 KB, image/png)
2016-03-08 00:15 UTC, John Ralls
Details
screencast when incorrect price is being recorded (1.08 MB, video/webm)
2016-03-08 06:08 UTC, Eduard Valiauka
Details
file from video (3.86 KB, application/x-gnucash)
2016-03-08 06:13 UTC, Eduard Valiauka
Details
empty amount (4.94 KB, application/x-gnucash)
2016-03-12 12:00 UTC, Eduard Valiauka
Details

Description Eduard Valiauka 2016-03-05 19:26:40 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
Comment 1 John Ralls 2016-03-08 00:15:48 UTC
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).
Comment 2 Eduard Valiauka 2016-03-08 06:08:41 UTC
Created attachment 323353 [details]
screencast when incorrect price is being recorded
Comment 3 Eduard Valiauka 2016-03-08 06:13:12 UTC
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.
Comment 4 John Ralls 2016-03-10 21:11:12 UTC
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.
Comment 5 John Ralls 2016-03-12 00:32:21 UTC
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.
Comment 6 Eduard Valiauka 2016-03-12 12:00:43 UTC
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
Comment 7 John Ralls 2016-03-14 00:57:23 UTC
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?
Comment 8 Eduard Valiauka 2016-03-14 20:17:41 UTC
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.
Comment 9 John Ralls 2016-03-15 17:33:11 UTC
(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.
Comment 10 John Ralls 2016-03-24 19:24:18 UTC
The auto-complete problem is fixed too for 2.6.12.
Comment 11 John Ralls 2018-06-29 23:47:47 UTC
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.