OFX import not matching previous selections

Don Coleman don at coleman.org
Sat Jul 21 19:45:19 EDT 2007


Derek, thanks for your help.

So I've inlined some followup comments/questions below...

Derek Atkins wrote:
> Don Coleman <don at coleman.org> writes:
>
>   
>>> Is there anyplace where the bayesian matching system as it functions
>>> in gnucash is described, from the perspective of a naive user?
>>>       
>
> Not really.
>
>   
>>> Every month I have 6 deposits to the same account, where most have
>>> unique amount fields, and those that don't, have unique Description
>>> fields.
>>>       
>
> Define "Unique Description field" in this context..
>
>   
Gnucash in the account view labels two of the fields "Description", and 
another "Deposit".
After importing the QXF file, I get 6 entries:

     4 have the Description field set to "Deposit Check", but each have 
a different Deposit value.
    2 have the Description field set to "Metavant...".  These also  have 
different Deposit values (but may overlap with the 4 entries above).
>>> 1) recent accepted auto matches or manual choices should be weighted
>>> much stronger than past ones, and it should take a couple manual
>>> overrides before it stops suggesting old matches.
>>>       
>
> Nope, there's no timeframe in the weighting, so recent matches are not
> weighted any more than previous ones.
>
>   
>>> 2) both the Description and the Deposit/Withdrawal amounts should be
>>> used in the match algorithm.
>>>       
>
> Nope, only the description and memo (text) is used.
>
>   
>>> Is this not how it basically works?
>>>       
>
> Well, BASICALLY, yes.  It tokenizes the Desc and Memo and matches
> based on the tokens.
>
>   

Looking at the QFX files directly (this is from E*Trade bank), I see 
only "<MEMO>" entries.  No "<DESC>" entries.
If I download OFX files instead, I see only "<NAME>".

If E*Trade is only including one field, and they are all exactly the 
same value, then if I understand what you have stated here, I'm screwed 
-- the matching system will never be able to distinguish between the 
entires which all have the exact same value for what is put into the 
Description field in the accounts view.

So if I pre-process the QXF file to add a hand crafted "<DESC>" field (a 
simple script keying off the "<TRNAMT>" field, for in my particular 
case, this is the differentiator in my dataset -- I know if it's a 
deposit check for 10 dollars, its from Joe, and if it's for 20, it's 
from Jane) will gnucash then "figure out" this matching?

Another option is, how hard is this to add to gnucash?  Pointers to a 
source module would be appreciated (I'm an old-time C hacker, but have 
never looked at the internals of gnucash).

>>> Is there a mechanism for manually tweaking it?
>>>       
>
> Nope.
>
>   
>>> Can I look DB the contains the rules and/or the matches and their
>>> weightings?
>>>       
>
> It's just XML; go ahead.
>
>   
>>> Is there a way I can reset it, so at least I know I'm starting from scratch?
>>>       
>
> Not without manually extracting the data from your XML.
>
>   
>>> Given the regularity of the deposits I get, I'd be perfectly happy
>>> setting up matching rules manually, though I guess there is no way to
>>> do that...
>>>       
>
> Nope.  But the bayesian style matcher should do it correctly
> after your first correct match.
>
>   
>>> Thanks for any help,
>>> don
>>>       
>
> -derek
>
> -- 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 
>   

Thanks again!
don
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3229 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20070721/a09f17a3/attachment.bin 


More information about the gnucash-user mailing list