After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 506810 - QIF Import can mismatch account transfers
QIF Import can mismatch account transfers
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Import - QIF
2.2.x
Other All
: Normal normal
: ---
Assigned To: Derek Atkins
Derek Atkins
Depends on:
Blocks: backport
 
 
Reported: 2008-01-02 06:47 UTC by Charles Day
Modified: 2018-06-29 21:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
QIF file demonstrating the bug (609 bytes, text/plain)
2008-01-02 06:49 UTC, Charles Day
  Details
Small proposed patch (699 bytes, patch)
2008-01-08 04:05 UTC, Charles Day
committed Details | Review

Description Charles Day 2008-01-02 06:47:36 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.
Comment 1 Charles Day 2008-01-02 06:49:50 UTC
Created attachment 101972 [details]
QIF file demonstrating the bug
Comment 2 Charles Day 2008-01-03 03:52:25 UTC
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!
Comment 3 Charles Day 2008-01-08 04:05:57 UTC
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.
Comment 4 Derek Atkins 2008-01-20 18:13:09 UTC
Applied to trunk as r16877.
Awaiting backport.
Comment 5 Andreas Köhler 2008-01-30 20:34:14 UTC
Applied to branches/2.2 as r16897 for GnuCash 2.2.4.
Thanks a lot!
Comment 6 John Ralls 2018-06-29 21:58:12 UTC
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.