GNOME Bugzilla – Bug 641863
Change exchange rate/amount on existing transaction bug with Trading Accounts
Last modified: 2018-06-29 22:53:23 UTC
This is in the Transfer Funds window, inputting or editing the exchange rate of a two-currency transaction. There actual bug only occurs with Trading Accounts ON. I have recreated the bug starting from a new file: File > New File Currency - GBP Accounts to create - A Simple Checkbook Apply, save as XML. File > Properties - Use Trading Accounts checked. Assets > Current Assets > New Account Account Name: USD Bank Security/currency: USD (Us Dollar) Account Type: Bank In USD Bank account register: New transaction Transfer: Expenses Withdrawal: 100 Transfer Funds Window: Exchange rate: set to 1.6 Currency Transfer Shows: 1 GBP = 1.600000 USD 1 USD = 0.625000 GBP (so far so good) To Amount (greyed out as Exchange Rate checked): 160.00 *NOT CORRECT* Ignore this and select OK Account Expenses shows expense of GBP 62.50 which is the correct amount. Now edit the transaction's exchange rate (in USD Bank), and put 62.50 in the To Amount field (overwriting the 160.00), the rates shown flip around so show: 1 GBP = 0.625000 USD 1 USD = 1.600000 GBP *NOT CORRECT* Select OK and the expense account now shows a GBP 160.00 expense. So the To Amount field is calculating wrongly, and will create the wrong amount if it is selected (but not if the exchange rate is selected despite showing the wrong amount). OK same scenario but with Trading Accounts OFF Transfer: Expenses Withdrawal: 100 Transfer Funds Window: Exchange rate: set to 1.6 Currency Transfer Shows: 1 USD = 1.600000 GBP 1 GBP = 0.625000 USD *NOT Correct* To Amount (greyed out): -160.00 *Not Correct* Ok so everything's wrong, but by inverting the exchange rate to 0.625, the figures then correct showing: 1 USD = 0.625000 GBP and 1 GBP = 1.600000 USD, and To Amount 62.50, which is all fine. The transaction updates correctly. Another point is that when editing the exchange rate from the currency of the other account (GBP), the exchange rate is also inverted so then there are 4 possible combinations: Trading ON, GBP Account, rate GBP per USD e.g. 1.60 and To Amount wrong Trading ON, USD Account, rate USD per GBP e.g. 0.625 and To Amount wrong Trading OFF, GBP Account, rate USD per GBP e.g. 1.60 Trading OFF, USD Account rate GBP per USD e.g. 0.625 This is all highly confusing and prone to input error!
Combinatios should read: Trading ON, GBP Account, rate GBP per USD e.g. 0.625 and To Amount wrong Trading ON, USD Account, rate USD per GBP e.g. 1.60 and To Amount wrong Trading OFF, GBP Account, rate USD per GBP e.g. 1.60 Trading OFF, USD Account rate GBP per USD e.g. 0.625
After much wondering why a USD transaction was showing the wrong GBP amount in the transaction report, I have discovered another aspect of this bug. If, when inputting/editing a transaction's exchange rate, something incorrect is inadvertantly input (which is almost certain given the confusing nature of this bug), the inverted (incorrect) exchange rate can get stored in the price editor list, and so mess up reports. This whole process is rendered even more error-prone considering the exchange rate of OFX-imported transactions is always 1 (bug 577032), which means every imported multi-currency transaction needs to be manually edited. Has anyone looked at this yet?
Hi Ian, I probably bumped into the same issue, see bug 651889. Can you test the patch?
Bug 651889 has been closed as fixed. That fix will appear in GnuCash 2.4.7 and is also included in the development version. Since you are on Windows, can you try and install tomorrow's nightly build [1] and check if your bug is fixed in that version ? Please report your findings in this bug. Thank you. [1] http://code.gnucash.org/builds/win32/trunk/
(In reply to comment #4) > Bug 651889 has been closed as fixed. That fix will appear in GnuCash 2.4.7 and > is also included in the development version. > > Since you are on Windows, can you try and install tomorrow's nightly build [1] > and check if your bug is fixed in that version ? > > Please report your findings in this bug. Thank you. > > [1] http://code.gnucash.org/builds/win32/trunk/ I have tested this with windows version svn r20792. This has been partly fixed, but not completely. The exchange rate/to amount handling when *inputting* a new transaction seems to work, and gives the correct, expected results in the different currency accounts. However there is an error when editing the exchange rate of an existing transaction when edited from the account of the currency *not* the one used when inputting. I.e. if a USD/GBP transaction is input via the USD account, then editing the exchange rate afterwards from the GBP account gives the wrong exchange rate/to amount, and vice versa. It seems that the Transfer funds dialog/exchange rate is tied to the transaction but does not realise what account it is being invoked from.
Ah, I see what you mean. That is indeed still a problem. @Mathieu: would you we willing to look into this problem as well ? I have changed the title of this bug slightly to reflect the outstanding issue.
This is harder to fix. The logic assumes that the currency of the transaction is the currency of the opened account. This is true when creating transactions, but not always true when modifying existing transactions. Solving this will have a higher impact on the code we seem to have a design issue here. The whole exchange rate dialog handling is already messy... Excerpt from split-register-control.c to illustrate this: /* Check if the txn- and xfer- commodities are the same */ if (gnc_commodity_equal (txn_cur, xfer_com)) { (...) if (expanded) message = _("The two currencies involved equal each other."); (...) } This effectively blocks editing exchange rates in expanded (split) mode, when accessing from the other account. As Ian pointed out, the work-around is to always edit the transaction from the account it was created in.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=641863. Please continue processing the bug there and please update any external references or bookmarks.