In the course of working on and testing bug 763146 [1] the reporter discovered an interesting auto-completion bug: If the transaction that's being copied is multi-currency and was created in the other register (so the transaction currency is for a different currency from the present register's) then attempts to edit the debit/credit amount will produce incorrect results. The problem was made more obvious because the reporter's currency, BYR, trades at around 21000 to the USD, so the incorrectly calculated values and prices were 0 after rounding, causing GnuCash to blank the cells.
On investigating I found that the most obvious problem was that the calculations were being run in the wrong direction because of the transaction currency to account currency mismatch. Adding a line to gnc_split_register_autocompletion() to change xaccTransSetCurrency() didn't fix the problem, though, because the split values weren't changed by that call. Adding code to recalculate the split values does correct the problem. While it seems pretty obvious to me that recalculating the split values after re-setting a transaction's currency is The Right Thing To Do, I'm worried anyway. Can anyone think of use cases where it's not the right thing to do? Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=763146 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
