There's a misunderstanding here.
This is what GC does:
- It looks at the OFX transaction, which always has an FITID.
- IF GC sees this FITID in one of the register transactions, it skips the OFX transaction, because it's already been imported (when a transaction gets imported from the ofx, the online_id is copied into the register transaction, that's how GC remembers it's already imported the transaction). - If the FITID is not found in the register, GC assumes that this is a new transaction and attempts to match it with existing transactions in your register. BUT: . It only looks at register transactions that have NO FITID (i.e., register transactions that you entered manually, typically) . Among those, it looks for transactions that match pretty closely for the date and the amount. . It picks the one with the highest matching score, if that score is above a user-adjustable threshold.
So in the case you outline below, if the register transaction has the 
same FITID as your ofx transaction, the ofx transaction will NOT be 
imported (it will be just skipped).
I think I don't quite understand the problem you're having. Is it that 
you're importing OFX transaction and they're not matching register 
transactions that you entered manually?
Or is it that they're being imported despite the fact they were imported 
previously?
J.

On 7/27/20 1:31 PM, Fross, Michael wrote:
Thanks Jean / John for your thoughts.  There is a register entry that matches, IMHO, very closely.   I increased the Match Display Threshold from 1 to 3, and then to 6 (which appears to be the highest value allowed.)  Every transaction from the import says "Match Missing."
Digging around a bit, for the transaction in question, the QFX file 
contains the FITID of 202007210003:
<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20200721120000
<TRNAMT>54.00
<FITID>202007210003
<NAME>ACH Electronic Credit
<MEMO>Expenses
</STMTTRN>

My GNUCash file contains, for the same transaction has the online id being 202007210002
         <split:slots>
           <slot>
             <slot:key>online_id</slot:key>
             <slot:value type="string">202007210002</slot:value>
           </slot>

The online_ID is ...002 instead of ...003.  Changing the QFX file to match the online_id value seemed to work.  Now my question is why would this be different for *lots* of transactions.  Everything worked normally in v3, but this would not have changed as part of the release. I'll check a few more problem transactions and see if I can detect a pattern.  Perhaps Citibank is paying games....
Michael

On Sun, Jul 26, 2020 at 4:57 PM jean laroche <rip...@gmail.com <mailto:rip...@gmail.com>> wrote:
    To get a match you have to have a transaction in the register that's
    sufficiently similar to the one you're importing, and that has not been
    imported/matched before.
    In your case, it could be one of these reasons (I can't see the image):
    - There's no matching transaction in your register (no existing
    transaction has amount close, and a date close to the imported one)
    - There's a matching transaction but it's already been matched to an
    imported transaction at some point so it's not available to be matched
    to the new imported one.
    - There's a matching transaction that's available, but the match score
    is below the threshold that allows the transaction to be shown as a
    potential match. Too large a date mismatch can cause that.

    Can you check whether you're in one of these 3 cases? If you're in case
    3, you can lower the minimum matching threshold in the preferences and
    see if that helps.
    J.


    On 7/26/2020 2:44 PM, John Ralls wrote:
     > If there's no matching transaction already in the account then
    there's nothing to clear. In that case only adding or not makes sense.
     >
     > Regards,
     > John Ralls
     >
     >
     >> On Jul 26, 2020, at 1:56 PM, Fross, Michael <mich...@fross.org
    <mailto:mich...@fross.org>> wrote:
     >>
     >> Hello all,
     >>
     >> I sent this earlier this month and didn't see any reply so I
    thought I
     >> would try again.   Has anyone else seen these issues?  I use
    Citibank and
     >> perhaps it's a Citibank issue, but I did not have this problem
    on v2 or v3.
     >>
     >> Thanks all.  I appreciate the help.
     >>
     >> Michael
     >>
     >>
     >> On Sat, Jul 4, 2020 at 9:48 AM Fross, Michael <mich...@fross.org
    <mailto:mich...@fross.org>> wrote:
     >>
     >>> Hello all,
     >>>
     >>> I typically download QFX files from my banks every day or two,
    import them
     >>> to clear them in Gnucash.  Worked great.  However, ever since
    upgrading to
     >>> v4, the importer seems to have trouble matching.  Most of the
    imported
     >>> transactions are listed in the importer as (A)dd, but when I select
     >>> (C)lear for them it says match missing.
     >>>
     >>> This has occurred for several accounts.  Here is a simple
    credit card
     >>> example, although for my checking account, there are dozens
    like this.  The
>>> top portion shows the register with the Sprint bill cleared. The date,
     >>> amount, and name (mostly) match.
     >>>
     >>> [image: image.png]
     >>>
     >>> Not sure if there is just something wrong with my setup or
    not.  Perhaps a
     >>> bug?  Are others experiencing this?  Any ideas to get the
    matcher matching
     >>> again?  Something need to get cleared out?
     >>>
     >>> For those of us in the US, happy Independence Day.  Thank you
    all for your
     >>> assistance.
     >>>
     >>> Michael
     >>>
     >> <image.png>_______________________________________________
     >> gnucash-user mailing list
     >> gnucash-user@gnucash.org <mailto: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 <mailto: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 <mailto: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.

Reply via email to