GNOME Bugzilla – Bug 458684
Import Transaction Mismatch
Last modified: 2018-06-29 21:43:43 UTC
Please describe the problem: Sent this problem to the user's mailing list and was directed here to file it as a bug report. I currently download the OFX file from my bank (Wachovia) in Quicken 2007 format in order to import my transactions. I get paid twice a month, the same amount each time. I do not enter this transaction manually, and I just let the import process create the transaction. The problem is that the auto-match keeps trying to match the NEW transaction to older previously imported transactions of the same account & dollar amount. Even if the previous transactions were cleared or even reconciled. I have to fix the match in the Import tool to have it create a new transaction instead of matching to the old one. If the transaction is accidentally matched to the old one, I cannot perform a re-import to try and get the transaction in there again. GnuCash has somehow associated the new transaction with the old one and it no longer shows up in the Import tool. Thankfully I've been able to catch this each time (I notice my balance is A LOT lower than it should be) and I just quit GnuCash without saving, do the import again and fix the mismatch. Steps to reproduce: 1. Import an OFX file with a regularly recurring transaction of a fixed dollar amount. 2. Import another OFX file that the same kind of transaction as in step one (same accounts and dollar amount, but for a different date). 3. GnuCash should try and match it to the old transaction instead of making a new one Actual results: Gnucash matches the new transaction to an old transaction and it can never be imported again if the mismatch is not fixed in the Import Tool. Requires quiting GnuCash before saving or rolling back to a previous account state to fix. Expected results: Gnucash should see the transaction as new and create a new transaction entry instead of matching to an old one. Does this happen every time? Yes Other information:
Thanks for reporting this issue. In fact I see the same thing with HBCI import every now and then. However, the problem here is that there is no unambiguous way for gnucash to tell apart the new and the old transaction. Gnucash cannot assume (only guess) that the new transaction hasn't been imported before (in contrast to the old transaction). I agree the algorithms should at least be biased a bit more towards accepting the new transaction as new, but they won't be able to completely resolve this ambiguity.
I can understand it not being able to tell if an uncleared transaction is new or old, but a reconciled one? Can't it check to see if the previous transaction was already cleared or reconciled before matching to it? When would a new imported transaction ever be matching a transaction that's already been reconciled?
Alright, after doing some more imports, I've found that the dollar amount doesn't have to be the same for this to happen. Just the Account it's associated with. I had some transactions I tried to Import (Gas from filling up the car) and it tried to match on some previous ones that I had already cleared. I had to, again, force it to make a new transaction instead of matching to previous one already entered. The dollar amounts weren't even close (one was around $15 the other about $23), but the account it tried to match to was the same. Can you at least try and see about making it not match on transactions that have already cleared or reconciled?
If the source if import (HBCI, OFX) contained some kind of uniq id, couln’t that be added as a description to the transaction, e.g.: Imported from HBCI: 123423123213 (maybe just a MD5 hash of date, amount, description). Then, whem trying to match transactions, and you are considering an old transaction that contains the “imported from” stanza, only match if the hash is missing. If the considered transaction was entered manually, only then allow it to be more fuzzy about the date, just as now. I think this would fix this bug and make the whole process more stable.
There is no unique ID that I can see in the OFX file I'm importing. I download it from my bank in the "Quicken" format to get it. The MD5 hash seems like an overly complicated way of doing it (even though it isn't technically that complicated). There may be some case where comparing against previously cleared transactions is needed (I don't know of any, but my use is very basic), but I can see no reason why it should ever match on a reconciled transaction. I don't understand why the importer can't just check and see if the transaction it's comparing against has either cleared or reconciled (a simple "if/else"). I know the devs are busy with more pressing issues, especially with the recent Windows release. But after seeing that one of the developers has noticed the same issue I'm wondering why this hasn't been changed to a Confirmed status.
Quote: "I know the devs are busy with more pressing issues, especially with the recent Windows release. But after seeing that one of the developers has noticed the same issue I'm wondering why this hasn't been changed to a Confirmed status." My mistake on the above. I've been working in Launchpad with Ubuntu more recently and was thinking of their Bug Statuses. I see "NEW" is actually the Confirmed status here.
Note that for HBCI, using the reconciled status does not work: You often get a transaction listed from HBCI again, even if you locally reconciled your account. In that case, you need to match it. But true, using the MD5 hash is overkill. This should solve the issue quite reasonable (replace HBCI with OFX when needed): * When importing a new transaction that does not match, add this description to the transaction: „Imported from HBCI: <date of transaction in HBCI data>“ * When matching against an existing transaction, and the user agrees to the match, add this description: „Matched to HBCI transaction: <date of transaction in HBCI data> * Now, when you are comparing a new HBCI transaction to some existing ones, and they contain the „Imported from“ or „Matched to“ tags, only consider them to be the same when the date is equal. This makes sure that every transaction is only matched once, and that a new transaction can’t be mistaken for an old one. Of course, instead of abusing the description, a special attribute of Transaction could be introduced − I leave that to whoever implements this. Greetings, Joachim
I've just moved from GnuCash 2.2 to 2.4.4 and am still seeing the analogous problem when I import my QFX bank files. If I import the same file a second time, it ought to show me the full list of transactions, and show that there is a match to each of the lines. Then I can figure out if the match is legit or not. What is does instead is a sloppy match the first time I import, then when I figure out what's wrong and try re-importing, it just shows me an empty list. If you just disabled the "feature" that makes it ignore the new transactions, I could manage. As it is, my accounting has gotten mangled and this is keeping me from fixing it.
Here's one other thing: back when I used my own spreadsheet for my checkbooks, each new transaction would be recorded with an "open" date, but each closed transaction had both an "open" date and a "closure" date, which came from the bank statement. If GnuCash did this, we could look at the two dates and decide whether the match was correct or not. Also a match should require that the quantities are exactly the same and the check numbers match if they are present. There are complex cases I'm not sure how to deal with. For example, when I write a check for my VISA bill, there is the date that I wrote the check, the date that the bank closed the transaction, and the date that the VISA closed the transaction. Given that the transaction shows up in both accounts, I suppose it could be listed a different closure date each time.
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=458684. Please continue processing the bug there and please update any external references or bookmarks.