Generic Import Transaction Matcher empty - revisited

James Roman digitect at comcast.net
Tue Nov 22 22:53:18 EST 2005


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.
> 
-------------- 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/20051122/ca149346/attachment.bin


More information about the gnucash-user mailing list