OFX import showing already matched transactions?

[David Carlson]

On 8/21/2014 7:14 AM, Tracy wrote:
> Greetings,
>
> (GnuCash 2.6.3, Window 7 64-bit)
>
> I have downloaded transactions from my financial institution (in this
> case, transactions for a credit card) in QFX format, and I am working
> on importing these transactions into my register.
>
> The large majority of these transactions already exist in the register
> (were manually added from the transaction receipts), with the
> transaction date specified along with the exact amount of the
> transaction. However, there are occasions where the transaction does
> not get manually entered (no receipt was provided, receipt was lost,
> etc), hence the download and matching of transactions from the
> financial institution (it is easier to remember a "missed" transaction
> from two days ago than one from three weeks ago during statement
> reconciliation).
>
> When importing the QFX file, the "Generic import transaction matcher"
> window opens with the transactions listed, and some transactions
> already matched (reconcile) or partially matched (update & reconcile),
> and others listed as "Do not import" (which I assume means that the
> matcher was unable to identify the transaction with enough certainty
> to provide a match).
>
> Now, because I am new to GnuCash, I am somewhat untrusting of the
> automated matching process. Therefore, I double-click each transaction
> to ensure that the match is correct (and I change the import type to
> "reconcile" after I verify each match, because I do not want the Payee
> that I have in my register to be changed - is there a setting to cause
> "update & reconcile" to respect the Payee names in my register? I
> haven't found one, so far...).
>
> So, the problem. When I double-click on a transaction to verify the
> match, I am presented with a list of transactions which potentially
> match the transaction I am looking at. However, the presented list
> includes previously matched transactions. I believe this is incorrect
> behavior. If a register transaction has already been matched to an
> previously downloaded transaction, that transaction should not be
> offered for matching to a newly downloaded (ie. different)
> transaction. At the very least, it should be differentiated in some
> way, indicating to the user that it has been previously matched.
>
> To give an example, let's say that I visit Subway regularly, and that
> (being a creature of habit) I order the same thing frequently, thus
> resulting in transactions with the same amounts, the same payee, but
> different dates, as in:
>
> 8/10/14   Subway      3.99
> 8/11/14   Subway      3.99
> 8/13/14   Subway      3.99
> 8/17/14   Subway      3.99
>
> Now, if I download transactions on 8/15/14, and match them with the
> transactions in my register (thus matching the transactions from
> 8/10/14 an 8/11/14), then download transactions again on 8/16/14, when
> I go to match transactions again, I should not see the transactions
> from 8/10/14 and 8/11/14 offered as possible matches for the newly
> downloaded transactions (since they have already been previously
> matched). However, they do show up as potential choices, with no
> indication (at least, none that I have been able to identify) that
> they have been previously matched to a transaction....
>
> Now, I could understand if they showed up in the list of transactions
> but were flagged in some way as having been previously matched
> (highlighted, different color, a column indicating they were
> previously matched, something). I could even understand them not being
> presented at all (because they were previously matched).
>
> But from my point of view, as a user, there needs to be *some* way to
> differentiate "previously matched" transactions from transactions that
> are "unmatched", during the OFX/QFX import process - otherwise I'm
> going to end up matching two different transactions from my bank to a
> single transaction in my register (and then will end up potentially
> missing transactions, and having to go back through and search
> receipts during the statement reconciliation process to find out what
> went wrong).
>
> Am I missing some obvious feature or setting that would enable this
> behavior, or is this truly "expected behavior"?
>
> Tracy
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>

I really want to see other answers to this question. 

These are a couple of my observations as another user, not as a developer:
I think that if you have manually entered transaction(s) then download
an OFX file and find a transaction that matches one of your manually
entered transactions, the match may not be marking the manually entered
transaction as 'matched', as you say, and I agree that is probably
incorrect.  Perhaps the existing transaction(s) are marked but there is
no test to prevent a different new incoming transaction from being
matched to the same existing transaction.

On the other hand, if a downloaded transaction is accepted as 'new' or
is incorrectly matched to the wrong existing transaction, that incoming
transaction is remembered as having been seen, so a second try or any
transaction previously imported will not be imported again. 

The result seems to be that incoming transactions only get through once,
but they can be matched multiple times to the same existing
transaction.  This could leave some existing transactions as 'orphans'
that have not been matched to any incoming transaction, and could also
'lose' incoming transactions that were incorrectly matched, as they
cannot be imported again.  Perhaps the intent is to allow existing
transactions to be re-matched to the correct incoming transaction, then
to allow the previously mismatched incoming transaction to be imported
again.  If that is the case, it should be explained in the manual, and
there should be a warning along the line "That transaction has already
been matched.  Do you want to change it?"

It is still necessary to follow up your import with a manual reconciliation.

David C