Created attachment 373258 [details] del-account-cross-currencies-issue.gnucash Deleting an account allows moving of all transaction of that deleted account into another account having a non-matching currency. This is an unexpected ability and seems undesired as the values in the moved transactions will become nonsensical. ===Setup Windows 10 GnuCash 3.5 ===Repo 1. Open attached gnucash file 2. Select the Bank-USD account with the mouse 3. Press the delete button 4. In the delete UI, select the Bank-EUR account 5. Continue ===Result The single $100.00 USD transaction from Bank-USD account is moved to Bank-EUR account. The value of this transaction in its new location is €100.00 EUR. And its split to account 'Expense1-USD' still has a value of $100 USD. This transaction has now become nonsensical. ===Expected The UI in step 4 should not allow movement of transactions between accounts in non-matching currencies. ===Notes I could imagine a feature that would allow movement of transactions between accounts with differing currencies. Many use cases would need to be managed including 2+ currencies in splits, trading accounts, fixed/per-day exchange rates for every involved currency, etc. If such a bulk change/migrate codebase is created, parts of it could be shared with a find/replace workflow.
Comment on attachment 373258 [details] del-account-cross-currencies-issue.gnucash FYI This is an SQLite 3.x database.
I'm looking into stopping account deletion moving transactions to accounts with a different commodity. I don't know enough about multicurrency to implement allowing moving transactions only in specific situations.
Viewing this from the Ux perspective, I still see two major groupings: 1) such a bulk move is a valid request and must deal with the complexities I mention in the OP notes. A request like this is probably a bulk error correction. My thinking is that a small set of transaction can be done individually by the user. But if there are hundreds of transactions, then this is a situation where the user made many errors over an extended period of time. Yes, it is possible the user did a bulk import into an account with the wrong currency. But if that's so, could not they re-import into a correct account? Caveat, sometimes bank servers are irritant at reissuing data already given. So careful consideration on this is needed. 2) such a bulk move is not a valid request. Therefore, a simpler code check in step 4 could in that UI filter out accounts that don't match the current account's commodity/currency. If the user wants to make changes to the account of a transaction, they can do it one transaction at a time. This approach is more conservative and protective from accidental self-harm. Personally, I lean towards (2), the simpler UI and logic. If such bulk functionality as (1) is still desired, then I can image a UI that is almost the same as today but includes a "[x] force commodity change" checkbox in that UI so a user is made aware and acknowledges they are about to do something dangerous. But then all the issues of the OP notes needs to be considered.
Jean Laroche is already working on this, see https://github.com/Gnucash/gnucash/pull/708.
PR 708 is cleaned up and merged to master, it will be in this weekend's 3.903 release. The approach taken is that if there is more than one subaccount the delete bails for being too hard and tells the user to rearrange things on the account page, perhaps one subaccount at a time. If moving a whole subaccount the currency mismatch doesn't matter and there's no complaint. If you want to move transactions to an account with a different commodity/currency it will warn you but offers the opportunity to go ahead and do it.
