Generic Import Transaction Matcher empty - revisited

[James Roman]

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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20051128/f4aca50f/attachment.bin