GNOME Bugzilla – Bug 661039
Autocompleted transactions use old currency/commodity prices
Last modified: 2018-06-29 23:01:34 UTC
I am using multiple currencies and have "Trading Accounts" enabled. I used the Price Editor to enter the exchange rate between two currencies. I entered a transaction requiring a currency conversion with the description "Bought Groceries." I entered a new exchange rate using the price editor. I entered a transaction requiring a currency conversion with a different description "Bought houseplants", and the transaction correctly picked up the new exchange rate. I entered a third transaction by typing "Bought Gro" and allowing Gnucash to autocomplete the description and amounts. Gnucash filled in the _old_ exchange rate. I expected it to either use the new exchange rate, open a dialog asking if it should use the new exchange rate, or open a dialog asking for an exchange rate with an option to update it. Instead, Gnucash silently used the old, incorrect exchange rate.
Yes autofill uses the old values. It is very handy, if you have often the same ammounts - and exchange rates. In every other case you must adjust the entries, e.g. salary might change from month to month, while the positions gross salary, tax, social insurance, ... are the same the amounts must be adjusted. In your case also the foreign exchange rate (FX) can be adjusted - right click for the context menu will show it you. Why do you expect, the change over time is more significant than the difference between various places: IMHO the FX in border towns is better than in the capital, which again is better than in the outback; in internet connected shops more recent and usually better than in shops only using ink and paper, ...? So how can we improve gnucash to met your expectations better? * Would a warning in the documentation be sufficient, if yes where? Suggestions for the text? * A preference "Use nearst FX in time instead of the last of a similar transaction"? * Or a drop down list with closest dates, the places and the FX? * Other ideas? Please reset the status to unconfirmed again, when you answer.
Fair enough, the situation is somewhat more complicated than I thought initially. Autofill is definitely great and works wonderfully in many circumstances: my loan payment is always the same so autofill makes it very easy to enter. Autofill also fills in the price of my mutual fund when money when from my paycheck to my mutual fund. It's in fact the same behavior as the present case, but didn't strike me as confusing or undesired for two reasons: 1) The price, number of shares, and dollar amount are all displayed on same line in the ledger so it's immediately visible to me what Gnucash is doing and when I need to correct its prices, and 2) I had far fewer mutual fund transactions, so it wasn't a big deal to adjust the prices slightly when my statements came. If you substitute share price for currency exchange rate, then you have the present case, which _does_ strike me as confusing and undesired. The use case is as follows: I'm entering many transactions, one transaction after another, that involve currency conversions. Several of the transactions don't autofill, so they use the most recent currency exchange rate, which is what I want. Then one autofills... good, less typing!... but it autofills a different exchange rate, one that was current a month ago, at the time of the last similar transaction. That's _not_ what I want. It's true that currency exchange rates differ by location as well as time, but even the "outback" exchange rate changes with time, so it seems to me unlikely that using a month-old rate is desired behavior. The core of what I see as the problem, I guess, is that when doing currency exchanges using trading accounts, the currency exchange rate is hidden in the splits of the transaction. The user doesn't see it unless they hit the "split" button. So the autofilled transaction looks fine to me: I spent 100 Eur on groceries, correct. I'd have to hit the "jump" button to go to the expense account, denominated in dollars, to have a chance of noticing that an old exchange rate was used. So, behaviors that I would find preferable: 1) Since currency exchange rates always change with time, always pop a dialog with some default filled in and a button that says "Use most recent value," or "Fetch Value," or even both buttons. The former would use the most recent presently available price and the latter would actually fetch the current price from the internet. or 2) Autofill should never fill in values that aren't presently visible to the user. If it wants to do so, then it should make the values presently visible. That is, if autofill needs to fill in an exchange rate as one of the splits of the present transaction, then it should activate the "split" button so that all of the splits become available. For this to work, the actual exchange rate should be visible, not just the values of each of the currencies. That is, seeing that my present transaction involves $16.32 which is 12.37 EUR doesn't help much, I need to see that the exchange rate is $1.31 per 1 EUR so that I can easily compare to adjacent transactions in the ledger and verify that Gnucash is using the rate that I want. or 3) For transactions involving currency exchanges, the exchange rate should be visible on the same line of the ledger as the other info so that I don't have to hit "split" to see it. Then it would be easy to scan down through the ledger and see whether Gnucash is using the values that I want it to use. or 4) The preference that you mention, "Use closest exchange rate in time" would allow me to get my desired behavior, I think. Thanks!
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 106671 ***
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. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=661039. Please update any external references or bookmarks.