GNOME Bugzilla – Bug 106671
autocomplete on multi-currency txn should require exchange-rate dialog
Last modified: 2018-06-29 20:28:58 UTC
I started gnucash 1.8 and when it read my datafile written by 1.6 many of the splits were wrong. gnucash 1.8.1, gnucash-1.8.1-1.RH7.3.i386.rpm Many of them were unbalanced. I see many instances of this in the console: Warning: PrintAmountInternal: Bad numeric. and Error: gnc_split_register_get_con...(): Cannot convert transaction -- no splits with proper conversion ratio For instance, a split which should be 350 166 100 166 782 instead shows up as 156.65 74.30 44.76 74.30 350 (in the 782 account) However, the splits appear correct in other account windows.
You must have a multi-currency transaction.. GnuCash handles multi-currency transactions very differently than 1.6. In particular, it converts all values and displays them in the "local currency" of whatever register you have open. So, if you have an account in USD, all numbers are displayed in USD. If you have another account in GBP, all values are displayed in GBP. The PrintAmountInternal generally means that there was an error in the math, probably trying to compute the "local value". The "cannot convert transaction" means that you are trying to display a transaction in a register (generally a GL) where none of the commodities match the display commodity. I thought I had fixed this before 1.8.1, but I might have missed a case. So, can you answer the following questions: - What locale are you in? - What default currencies do you have set in your preferences? - What are the commodities of the source and destination accounts when you get this particular message? - What kind of register are you using when you get this message (i.e., what did you do to open the specific register where you noticed this problem)? - Also, is there any chance you can supply the XML (either from 1.6 or 1.8 -- the XML should be equivalent) of the "offending" transactions?
My locale is almost certainly english. I'm in the US. $ env | grep -i lang LANG=en_US Default currency is US dollars. First account: type=Bank, commodity=USD Second account: type=Cash, commodity=IDSXX (a cash management fund at my broker) That cash/IDSXX seems a little weird. I wonder if I should change it to a "Mutual Fund". It's generally pegged at $1/share because it is cash management. I will leave it as is until you fully understand the problem. I originally noticed the wackiness when I tried the new (to me) Jump button to go from the checking account to the cash management account. However, I can also see the problems when I bring up the account by double-clicking on it in the accounts tree. I could probably supply the XML if I knew how to track it down. I'll see if I can figure out how to read the file and find the specific transaction. I wonder if there are any other accounts that will have this sort of problem.
Working with Derek I think there is a problem with GNUcash's handling of autocompleted transaction quantities when the two accounts use a different currency. He says that autocompletion pulls hidden entries, so if you change the visible field, other hidden parameters are not adjusted. Consider a recurring transfer from checking (bank, USD) to a brokerage cash management account (cash, CMF01). The cash management fund is fixed at $1/share. If you start out with monthly transfers of $250, then switch to $350, I think the autocompletion will screw things up because you will pull $350 from checking, and it will translate into 250 shares of CMF01, because you were not given the option of editing the share quantity for the other account. I guess this is not a problem when both accounts are in the same currency because a discrepancy in the quantities shows up as an imbalance, not an exchange rate. short term: auto-completion should not ocurr when one of the accounts is a different "currency" and its ledger display doesn't display a price or exchange rate. In the case where the ledger DOES display a price or exchange rate, the user typically has to enter that ledger to adjust quantity anyway, so it is a mere annoyance. long term: Someone should come up with a refinement to the user interface to allow all parameters of the autocompletion to be edited, so that this problem does not go unnoticed in the future. If possible, I would like the ability to edit the price/shares/value of each element of the split, even if the current ledger doesn't display price/shares. I have several recurring transactions of this type (regular investment transfers into up to 4 different mutual funds). I suspect this would be tricky to code.
Well, this was certainly true in 1.6; I don't know if it's still true in 1.8. At least, I _thought_ I handled this case in 1.8... Can you actually (in 1.8) use the autofill function for a multi-commodity transaction and have it NOT bring up the exchange-rate dialog?
fixed the summary to be more accurate. Reopened bug.
*** Bug 130451 has been marked as a duplicate of this bug. ***
Note to self: this also works in reverse. Autocompletion should just completely reset the rate-cell information to zero, which should bring up the exchange-rate dialog in the right cases, and not in others (ala bug 130451)
Confirmed, this bug is still in 1.9.2. Changing to register component. I think that the transfer dialog should _always_ come up when remembering an entered multi-currency transaction. Even if the register amount is the same as before, the exchange-rate may not be.
Um, yeah, that was sort of the point, which I said in comment #7 -- whenever you autocomplete a multi-currency txn it should always raise the exch-rate dialog.
*** Bug 161518 has been marked as a duplicate of this bug. ***
*** Bug 160820 has been marked as a duplicate of this bug. ***
*** Bug 403317 has been marked as a duplicate of this bug. ***
*** Bug 578683 has been marked as a duplicate of this bug. ***
In r22735 which I checked in back in January, 2013, I changed things so you get an exchange rate prompt for an autofilled transaction if the debit or credit cell is changed after it is autofilled. If you autofill a transaction and then accept it without any change then you don't get a prompt. This isn't exactly what is asked for here, but perhaps it's close enough.
*** Bug 661039 has been marked as a duplicate of this bug. ***
*** Bug 720845 has been marked as a duplicate of this bug. ***
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=106671. Please continue processing the bug there and please update any external references or bookmarks.