Generic Import Transaction Matcher empty - revisited

David Reiser dbreiser at earthlink.net
Tue Nov 22 09:55:09 EST 2005


On Nov 22, 2005, at 5:34 AM, 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}");

My experience with OFX imports is that MEMO will be the same for at  
least the same merchant, and sometimes for different merchants.  
TRNTYPE is also not likely to vary much. I would suggest putting the  
transaction date in your md5 input as means of ensuring you maintain  
uniqueness.


>
> I yet have to test it as I'm rebuilding gnucash at the moment.
>
> Question: should FITID be numeric?

Doesn't have to be. One of my credit card issuers uses: full credit  
card number+8 digit date+ 11 digits for amount (where the minus sign  
for a purchase appears mid FTID) + 6 digits for a sequence number in  
the download.

A couple other organizations just use a 9 or 10 digit number

> I'll find out later...
>
> -- 
>
> andrea at carpani.net
> http://www.carpani.net
> Andrea Carpani
> .a.c.
>
> -- 
> Andrea Carpani <ml at carpani.net>
>

--
David Reiser
dbreiser at earthlink.net



More information about the gnucash-user mailing list