Ok agreed. There'd need to be a mechanism to skip individual split import as well.
On Thu, 7 May 2020, 8:17 am Derek Atkins, <de...@ihtfp.com> wrote: > What if there are no matches? > Then the LHS won't be empty. > > -derek > Sent using my mobile device. Please excuse any typos. > On May 6, 2020 8:09:03 PM Christopher Lam <christopher....@gmail.com> > wrote: > > > 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@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 > >> dbrei...@icloud.com > >> > >> > >> > >> > On May 6, 2020, at 2:50 PM, Jean Laroche <rip...@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 > >> >> dbrei...@icloud.com > >> >>> On May 6, 2020, at 2:16 PM, Jean Laroche <rip...@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 > >> >>>> dbrei...@icloud.com > >> >>>> _______________________________________________ > >> >>>> gnucash-user mailing list > >> >>>> gnucash-user@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@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@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@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.