GNOME Bugzilla – Bug 481528
QIF importer should show imported transaction as possible duplicate if original transaction is split
Last modified: 2018-06-29 21:50:50 UTC
Add a split txn. Import a QIF statement which has that txn. The "Imported transactions with duplicates" column in the "Select possible duplicates" screen does not show this txn. This is a sample txn: 19/09/2007 Gift Assets:Bank 110 Expenses:Gift 100 Expenses:Taxes 10 The QIF statement has this entry: D19/09/2007 T-110.00 N PTHE GIFT SHOP M LLI ^ The duplicate txn has to be searched for and deleted later.
As I understand it from reading the code, the current criteria for finding possible duplicates is: 1. The transaction dates must be within a week of each other, and 2. Any one split of the existing transaction must have the same account and amount as any one split of the imported transaction. The example given meets the criteria, so it should be presented as a possible duplicate. I can reproduce this bug.
After further research and much hair pulling, it turns out that the list of criteria above is wrong. The actual criteria is: 1. The transaction dates must be within a week of each other, and 2. The transactions must have the same number of splits. 3. For each split in the existing transaction, there must be a split in the imported transaction with the same account and value. The example given does not meet the criteria, so it is not presented as a possible duplicate. So what should be done? If we want to switch to the criteria I gave in comment #1, then this is a tiny change (1 line of code). But that criteria might be too loose (too many false positives).
The bank statements that I am importing never have any splits. So, comment 1 criteria is what I want. If the account of a split is matching with the account in which I am importing and the value of that split is matching with the value of the txn being imported, then the txn of that split should be considered as possible duplicate. There should not be too many false positives then.
In example above, the imported transaction and the existing transaction have the same total ($110) and should be flagged as duplicates even though the existing transaction has more splits. A different situation is a paycheck deposit, where the imported QIF transaction - generated by your bank, say - ought to be flagged as a duplicate even though it does NOT have the same total as the existing transaction (since it only reflects "net" pay): Existing transaction Imported transaction ======================== ======================== Db Cr Db Cr Assets:Bank 100 Assets:Bank 100 Expenses:Tax 10 Income:Salary 110 Income:Salary 100 So how about this: If the transaction being imported contains only a debit/credit pair (i.e. two splits), then we use the criteria in comment 1. Otherwise, we continue to use the current criteria as shown in comment 2. This would allow the flexibility to accommodate the two examples discussed here, but use the more narrow criteria for imported transactions that have additional splits and are likely to reflect complete information (and have a larger chance of causing false positives.)
(In reply to comment #4) > So how about this: If the transaction being imported contains only a > debit/credit pair (i.e. two splits), then we use the criteria in comment 1. > Otherwise, we continue to use the current criteria as shown in comment 2. The bank statement that I am importing does not have any splits or debit/credit pairs. It just has credit (or debit, if amount is negative) txns from the bank point of view. Please refer to the sample QIF statement in my bug 481528 report.
By the time your bank's QIF transactions reach the duplicate checking stage, they have already been converted to balanced, GnuCash-style transactions using credit/debit pairs.
Created attachment 103713 [details] [review] Proposed patch This patch implements the changes described in comment #4. Included with this small code change is a large improvement to commenting throughout the file.
(In reply to comment #6) > By the time your bank's QIF transactions reach the duplicate checking stage, > they have already been converted to balanced, GnuCash-style transactions using > credit/debit pairs. Would it be better if a flag is set per QIF statement during parsing stage which is then used during the duplicate checking stage? It seems inconsistent to me if one logic is used for some txns and another for the rest when all are getting imported from the same QIF statement. I am being too picky here, I guess. Thank you, Charles Day, for all your time and effort. I will try your patch 103713 and report later.
In reply to comment #8: Just to clarify: Are you suggesting that the parser examine the QIF file, and if even one split transaction is found then the more restrictive criteria (comment #2) should apply to every transaction in the file? In any case, I don't think the bank will ever send you a QIF split transaction. Since they only know about one credit or debit for each transaction, that's all they can report to you. So the same rules (from comment #1) would apply to each transaction you receive from your bank. Let me know how the patch goes. Thanks for testing it!
(In reply to comment #9) > Just to clarify: Are you suggesting that the parser examine the QIF file, and > if even one split transaction is found then the more restrictive criteria > (comment #2) should apply to every transaction in the file? Yes. However, as you have pointed out, this issue will not affect me at all. > Let me know how the patch goes. Thanks for testing it! It worked! Thanks for everything.
Committed as r16953. Awaiting backport for 2.2.4.
Applied to branches/2.2 as r16971 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=481528. Please update any external references or bookmarks.