Generic Import Transaction Matcher empty - revisited

[Andrew Sackville-West]

Derek Atkins wrote:
> 
> 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.

oh man I love it....

:)

A

> 
> -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
>>>
>>
> 
> 
>