[GNC] Matching error in OFX import

[Simon Roberts]

Gach, yes, sorry meant to reply all, will pay attention in future,
hopefully not do that again :(

But FWIW, these transactions have different FITIDs and are in a single
import from a single file (and do not duplicate anything pre-existing).
But, I will get back when I'm not using 3.8. It's sad (but clearly nobody
here is in control of this!) that Ubuntu is packaging such an old version.

On Fri, Dec 30, 2022 at 7:08 PM Jean L <ripngo at gmail.com> wrote:

> Don't forget to reply to the list.
>
> Bear in mind: if you import an OFX file, match its transactions to some of
> your register transactions, the matched transactions will be silently
> ignored when you re-import the same OFX. That's by design. So if you match
> everything then re-import the same OFX, you'll have nothing to match.
>
> GC uses the FITID to verify that an OFX transaction was already imported
> and matched (it compares the FITID value of the transaction in the register
> to that in the OFX file). When GC imports an OFX transaction, it copies the
> OFX FITID to the register transaction.
>
> But yes, update to a recent version as there were bugs in this mechanism
> that were recently fixed.
>
> J
> On 12/30/2022 6:03 PM, Simon Roberts wrote:
>
> Yes, different FITIDs.
>
> I'm now finding that actually silently dumping some of these similar
> transactions. (But I've also discovered I'm not using the latest
> version--I'm on 3.8, so I think I should upgrade it and try again.)
>
>
>
> On Fri, Dec 30, 2022 at 6:57 PM Jean L <ripngo at gmail.com> wrote:
>
>> We might need a bit more info to give a useful answer. But just to be
>> sure:
>> - The FITID of the transactions in the OFX file are all different,
>> right? That's an absolute requirement, not just within a single OFX
>> file, but from ofx to ofx, the FITID is supposed to identify one and
>> only 1 transaction. If you re-download the same transaction the FITID is
>> supposed to be the same as the first time you downloaded it. GC uses
>> this to know which transactions have already been matched when it looks
>> at an imported OFX file.
>>
>> - Is the problem that you have similar transactions in your register
>> (that you've entered manually) with the same amount and close dates?
>> It's not impossible that GC is a bit confused because it finds 2 or more
>> transactions in your register than seem to match 1 or more transactions
>> in your OFX. In other words, GC does not have a way to figure out which
>> OFX transaction should be matched with which transaction in your
>> register if everything is very similar between them.
>> I must say I've never run into this issue, so I don't know for a fact
>> what GC does in that case.
>>
>> J
>>
>> On 12/30/2022 5:36 PM, Simon Roberts wrote:
>> > With the same caveat about my being new to this...
>> >
>> > My transaction records show regular, very similar, transactions. The
>> same
>> > institution, identical amounts, usually close but not identical dates.
>> >
>> > The importer's matcher is confused by these similar transactions. It
>> marks
>> > them in red and refuses to do anything with them directly. I can unmark
>> > them, and then get them to import, but there are other fields
>> (specifically
>> > there is a field "<FITID>" in the OFX file that seems like it should
>> > distinguish them, even if everything else is identical (I'm assuming
>> FITID
>> > is "Financial Transaction ID", but I could be wrong since that's just a
>> > guess!)
>> >
>> > In the interest of being clear, these "conflicting" transactions are in
>> the
>> > *same* OFX file, it's not trying to match against something already in
>> > place.
>> >
>> > Can I do anything to get this to behave more helpfully?
>> >
>> > Cheers,
>> > Simon
>> >
>> _______________________________________________
>> 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
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>
>
> --
> Simon Roberts
> (303) 249 3613
>
>

-- 
Simon Roberts
(303) 249 3613