Generic Import Transaction Matcher empty - revisited
Derek Atkins
warlord at MIT.EDU
Mon Nov 28 09:34:12 EST 2005
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
More information about the gnucash-user
mailing list