GNOME Bugzilla – Bug 341076
Strange register behaviour on importing transactions (OFX, MT940, HBCI)
Last modified: 2018-06-29 21:03:47 UTC
This concerns the register behaviour when transactions are being imported through the "generic transaction matcher" in src/import-export/import-main-matcher.h, which is used by OFX import, MT940 import, and HBCI import. I'll explain with MT940 import with the example file doc/examples/downloaded.mt940 because that one is the easiest to reproduce. Here's what I do: 1. Click File->Import->Mt940 2. Select the file doc/examples/downloaded.mt940, also attached below 3. The dialog "Select Account" appears. I select just any account, say A, and click Ok. 4. The dialog "transaction matching" appears, with exactly one transaction. 5. I click on the checkbox "A" (for "add") for that transaction if it's not already checked. 6. I click on the rightmost column entry "New, UNBALANCED" and select just any other account as the transfer account. Then I click "Ok". 7. I click "Ok" to finally import this transaction. So far everything is fine. Now I'll simulate that I downloaded this transaction again, so I don't "add" it as a new transaction but instead only reconcile the existing transaction: 8. Repeat steps 1, 2, 4, 9. Click the checkbox "R" (for "reconcile") Then click Ok to reconcile this. Expected result: The register of the account A should look as beforehand. But instead: There is one extra empty line shown, see screenshot below. This line goes away if it is selected or if the cursor is moved. (Sorry, no more time today, I'll add more explanation later.)
Created attachment 65046 [details] screenshot with unexpected empty line
Created attachment 65047 [details] example import file
Is it possible to reproduce with an ofx file instead of mt940? I don't have a new enough aqbanking to enable mt940. I tried with an ofx file, but it didn't work exactly. When I tried the second import, it said "match missing". Also, am I supposed to have a register open during import to see this?
re ofx: In theory, yes, this could be reproduced by OFX as well. However in practice OFX has a unique transaction identifier, which will be used by the ofx module to automatically match the imported transaction with the already existing one, so you won't see the "transaction matching" dialog when you import the second time. That's why I explained it with MT940 or HBCI here. To explain in more detail what to do in the second import: Yes, you should have the register of account A opened during the import. Then 8. choose File->Import->MT940 as explained above; 9. choose the file as before 10. The dialog "transaction matching" appears, with exactly one transaction. 11. I click on the checkbox "R" for reconcile 12. The rightmost column probably says "no match", so I click on this text line 13. The dialog "match transaction" appears, and I have the previously imported transaction as the only choice. I select that one and click "Ok". 14. I click "Ok" to finish the importing. Expected and Observed result as above. If the OFX import identifies the transaction by its unique transaction ID during the second import, the dialog in step #10 probably doesn't appear anyway. If it does, then can continue with the other steps and in the end you should observe the same strange register behaviour. This is probably related to bug#150569 -- the importing modules (OFX, HBCI, MT940) create a (gnucash) "Transaction" for each to-be-imported transaction, but these are all not yet committed until the user hits "Ok" to finish the importing. Then, those transactions that should only reconcile existing transactions will be deleted (as the one described here in the second import). The other ones will be committed as new transactions. The bug#150569 complains that if the user doesn't select a "other account" for each of them, they might be created unbalanced. But as explained in the other bug, this cannot be fixed unless we introduce a new data type, say "ImportedTransaction", that holds all the same data except that it does not yet belong into a real (gnucash) "Account". If we have such a new data type, then the importing modules will no longer create actual "Transaction"s but instead only those "ImportedTransaction"s, and only those that really should be newly created will be converted into the actual "Transaction" when the importing is finished.
*** Bug 432044 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=341076. Please continue processing the bug there and please update any external references or bookmarks.