[GNC] Import matcher shortcomings, OFX realm (at least)

[Christopher Lam]

Are you discussing qif or ofx. The main difficulty is qif code written 20
years ago and has not modernised.

The multi to multi issue will always be very difficult, hence I'd
previously imagined a two pane register, qif/ofx on left, existing register
on right, and drag and drop to marry up the splits. A successful pairing
removes line on both panes out of sight. Matching is complete when the LHS
is empty.

On Thu, 7 May 2020, 3:39 am David Reiser via gnucash-user, <
gnucash-user at gnucash.org> wrote:

> Overall, yes. But this case presents a many-to-many sorting out vs. the
> one-to-many resolution in QIF. And none of those unique IDs exist in the
> gnucash file until the transactions have finished being imported.
> --
> Dave Reiser
> dbreiser at icloud.com
>
>
>
> > On May 6, 2020, at 2:50 PM, Jean Laroche <ripngo at gmail.com> wrote:
> >
> > QIF is a lot worse the OFX. OFX transactions have a unique ID, which QIF
> ones don't have...
> >
> > On 5/6/20 11:48 AM, David Reiser wrote:
> >> Thanks, Jean.
> >> I think the QIF importer has some code that detects multiple possible
> matches and pops up a “select the right match” dialog/window. Perhaps that
> can be reworked/incorporated. I don’t use QIF too much, but I think that
> particular behavior gets triggered in a step a little closer to the final
> import sequence than the General Matcher window gets to when it has decided
> it has already identified matches.
> >> --
> >> Dave Reiser
> >> dbreiser at icloud.com
> >>> On May 6, 2020, at 2:16 PM, Jean Laroche <ripngo at gmail.com> wrote:
> >>>
> >>> I have run into this issue as well! Thanks for looking into it.
> >>> I'll try to fix it. What should really be done here, I'm guessing is
> that the matcher should not match several transactions to the same one.
> This may not be super easy to fix, but I'll take a look.
> >>> Jean
> >>>
> >>> On 5/6/20 11:00 AM, David Reiser via gnucash-user wrote:
> >>>> Michael Fross said:
> >>>>> I have to keep importing the same QFX file over and over until I get
> >>>>> “nothing to import” message. If I don’t, it seems to miss
> transactions in
> >>>>> the file. Not sure about QIF, but Maybe it’s similar.
> >>>>>
> >>>>> Michael
> >>>> Ok, I’ll split this out into another discussion.
> >>>> The need for multiple attempts at importing the same ofx file to get
> all the transactions imported is probably a result of a shortcoming in the
> matcher code when multiple same-dollar-value transactions (or nearly the
> same if Commercial ATM fee threshold is set to anything greater than 0.00)
> appear in the ofx file. One very common cause of such cases is vending
> machine transactions.
> >>>> If you never enter any of the same-value transactions manually, and
> only import them, then you’ll probably be OK, because the matcher will
> suggest that all the transactions should be Added rather than matched.
> >>>> If, however, you have even one of the same-value transactions entered
> manually, and a set of 5 same-value transactions incoming in the import
> file, the matcher’s default behavior is to display all 5 incoming
> transactions as having a good candidate match. The problem is that all five
> of those incoming transactions are pointed at a single transaction in the
> gnucash file. If you blithely click OK in the Matcher window, the import
> process matches the first incoming transaction to the existing transaction.
> Then when the second same-value transaction gets examined, the matcher says
> “Oh, I already matched that existing transaction, I’ll ignore this one”.
> And all subsequent same-value transaction that had reported they had a
> match in the file are ignored because the candidate match is already taken.
> >>>> Matching can be even messier if you have, say, 4 transactions of
> $2.00 entered in your data file, but 7 $2.00 transactions coming in with
> the import.
> >>>> The reason sequential imports work is that once a candidate is
> matched and the import process ends, the next time the import process is
> launched, that first transaction is no longer a candidate match because it
> now has an imported transaction ID associated with it (and the transaction
> ID prevents the incoming transaction from appearing at all anymore), and
> the matcher moves on (sometimes only one candidate transaction at a time).
> >>>> I did file a bug on this several years ago, but the matcher’s default
> match identification has not changed. What was added is the ability to
> double click a transaction in the matcher dialog window to see alternative
> transactions to match against. If you see multiple transactions in your
> matcher window with the same dollar value, you must inspect the potential
> matches for each one and select a different one from the top candidate
> picked by default for all the same-value transactions.
> >>>> I hope this explanation helps reduce the number of repeat imports you
> have to use.
> >>>> Dave
> >>>> --
> >>>> Dave Reiser
> >>>> dbreiser at icloud.com
> >>>> _______________________________________________
> >>>> gnucash-user mailing list
> >>>> gnucash-user at gnucash.org
> >>>> To update your subscription preferences or to unsubscribe:
> >>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >>>> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> >>>> -----
> >>>> Please remember to CC this list on all your replies.
> >>>> You can do this by using Reply-To-List or Reply-All.
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>