Generic Import Transaction Matcher empty - revisited

[Derek Atkins]

Oh.  Well THAT is illegal.  You should complain to your bank about
that.  Tell them quicken fails to import the transactions, and
that when you asked Intuit about they they told you to complain to
the bank and that the bank was violating the OFX Specification.

-derek

Quoting James Roman <digitect at comcast.net>:

> Unfortunately, the OFX files from my bank number each FITID from 1 to X.
> The next month they start the sequence over again (numbering the
> transactions in the OFX file).
>
> In my instance I would prefer falling back to some alternate numbering
> schema, where an actual duplicate transaction could be identified.
>
> On Mon, 2005-11-28 at 09:34 -0500, Derek Atkins wrote:
>> Perhaps the importer should just be changed to allow a FITID of '0'
>> to mean "no id" and ignore duplicates?
>>
>> -derek
>>
>> James Roman <digitect at comcast.net> writes:
>>
>> > Thanks for the response. I am leaning towards using perl as well. I was
>> > planning on changing FITID to DTPOSTED+daily sequence number. I think
>> > your suggestion has merit, though. I didn't like the idea of being at
>> > the mercy the export program with the sequence number. I think that the
>> > only required fields (other than the bogus FITID) are DTPOSTED, TRNAMT
>> > and TRNTYPE. Using these three fields seems like it might be the most
>> > complete.
>> >
>> > I'm going to think about this for a day or two. All my transactions are
>> > listed at the same date stamp for DTPOSTED. I want to consider some sort
>> > of odd situation, like whe you first sign up for automatic deposits,
>> > when they deposit one dollar, and then take it back immediately.
>> > Additionally, I wonder what would happen if I had multiple accounts with
>> > a bank.
>> >
>> > Let me know how your solution comes along.
>> >
>> > Below is the section from the OFX Specification of FITIDs. They do not
>> > need to be numeric,but should be less than 255 characters (I'd avoid <,
>> >> or / as they might be interpreted as a field.
>> >
>> > 3.2.3 Financial Institution Transaction ID <FITID>
>> > Format: A-255
>> > An FI (or its Service Provider) assigns an <FITID> to uniquely identify
>> > a financial transaction that can
>> > appear in an account statement. Its primary purpose is to allow a client
>> > to detect duplicate responses. Open
>> > Financial Exchange intends <FITID> for use in statement download
>> > applications, where every transaction
>> > (not just those that are client-originated or server-originated)
>> > requires a unique ID.
>> > An <FITID> also uniquely identifies the closing statement in <CLOSINGRS>
>> > and <CCCLOSINGRS>.
>> > Again, the OFX client should detect repeated closing statements
>> > (duplicate downloads) using these
>> > identifiers.
>> > FITIDs must be unique within the scope of an account but need not be
>> > sequential or even increasing.
>> > Clients should be aware that FITIDs are not unique across FIs. If a
>> > client performs the same type of request
>> > within the same scope at two different FIs, clients will need to use FI
>> > + <ACCTID> + <FITID> as a
>> > globally unique key in a client database. That is, the <FITID> value
>> > must be unique within the account and
>> > Financial Institution (independent of the service provider).
>> > Note: Although the specification allows FITIDs of up to 255 characters,
>> > client performance
>> > may significantly improve if servers use fewer characters. It is
>> > recommended that servers use
>> > 32 characters or fewer.
>> > For example: The two spawned payments mentioned in section 3.2.1 are
>> > processed and later downloaded
>> > in a <STMTRS>. The first payment’s <STMTTRN> would list
>> > <SRVRTID>8765:4321,
>> > <RECSRVRTID>1234:5678, and <FITID>9999:8888:7777. The second payment
>> > would be described in a
>> > <STMTTRN> containing <SRVRTID>8765:4322, <RECSRVRTID>1234:5678, and
>> > <FITID>6666:5555:4444.
>> > Usage: Bank statement download, investment statement download
>> > Elements of this type: <CORRECTFITID>, <FITID>, <RELFITID>, and
>> > <REVERSALFITID>
>> >
>> > On Tue, 2005-11-22 at 11:34 +0100, Andrea Carpani wrote:
>> >> Il giorno lun, 21-11-2005 alle 18:16 -0500, James Roman ha scritto:
>> >>
>> >> > Since I don't expect my bank to fix this problem soon, I'll 
>> have to come
>> >> > up with an way of modifying these numbers to make them unique. Ideally,
>> >> > I should probably come up with a way that if I exported 
>> overlapping date
>> >> > ranges, it would identify them as the same transaction. Anyone have any
>> >> > suggestions how I might accomplish this?
>> >>
>> >> I have a similar problem in that my bank uses 0 as FITID in OFX files
>> >> for all transactions this results in a single imported transaction.
>> >> I'm creating a perl script that changes FITID for each transaction
>> >> setting it to a md5 string
>> >>
>> >> $T{FITID} = md5_hex("$T{TRNTYPE}.$T{TRNAMT}.$T{MEMO}");
>> >>
>> >> I yet have to test it as I'm rebuilding gnucash at the moment.
>> >>
>> >> Question: should FITID be numeric?
>> >> I'll find out later...
>> >>
>> >> --
>> >>
>> >> andrea at carpani.net
>> >> http://www.carpani.net
>> >> Andrea Carpani
>> >> .a.c.
>> >>
>> > _______________________________________________
>> > gnucash-user mailing list
>> > gnucash-user at gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available