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.
