GNOME Bugzilla – Bug 506810
QIF Import can mismatch account transfers
Last modified: 2018-06-29 21:58:12 UTC
Please describe the problem: In certain cases, QIF transactions that have transfers between two accounts will not import properly. Steps to reproduce: 1. Import the attached QIF file. Actual results: The second transaction, a withdrawal from checking, is instead imported as a second withdrawal from savings. Expected results: The second transaction is imported as a withdrawal from checking. Does this happen every time? Yes. Other information: If the order of the last two transactions in the file are reversed, the import works correctly. This bug appears similar to bug #114724, but it is actually different because it is not specific to investment accounts. This bug is caused by a flaw in the QIF importer's matching algorithm. The current criteria for matching two qif-splits together, one-to-one, is that they use the same date, the same amount, and that the second split is a transfer to/from the first split's account. However, there is no check that the first split is a transfer from/to the second's account. Example: Two splits have the same date and amount. The first split, in account X, is a transfer from account Y. The second split, in account Z, is a transfer to account X. Under the existing matching criteria, these two splits can be matched up, causing an incorrect import.
Created attachment 101972 [details] QIF file demonstrating the bug
I have a rough idea about how to fix this, but its a big change. When reading in the QIF file, why not build separate lists of transactions in the QIF importer - one list for each QIF account - just like what already exists in the QIF file. Then when the importer goes to look for matches, I can search for possible matches in the correct account only. Fixes the bug, plus a potentially large gain in performance as it eliminates searching transactions in irrelevant accounts!
Created attachment 102365 [details] [review] Small proposed patch Here is a small patch for this bug. It is just a quick fix that doesn't get the performance advantage described in my previous comment. Let me know if you think that using string=? is dangerous here. I tested it on a very large QIF, as well as the QIF attached earlier, and it fixed the problem in both cases.
Applied to trunk as r16877. Awaiting backport.
Applied to branches/2.2 as r16897 for GnuCash 2.2.4. Thanks a lot!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=506810. Please update any external references or bookmarks.