Generic Account Mapper

Christian Stimming stimming@tuhh.de
Wed, 13 Nov 2002 18:03:04 +0100


Just some follow-up comments:

Benoit Grégoire wrote:

> Personally, I don't really see the usefullness of the match categories as 
> proposed.  


Ok, but it doesn't hurt you either. Derek "really wants" this :-) and 
sees benefit for that in the QIF context, so we could just do it. If 
you, for OFX, only want to store all matches in one big table, then just 
use only one single category and you should be fine. For HBCI, I can 
live without it, but having it is certainly nicer.

> There are to possibilities as to where the match functions are 
> called.  
> 
> Option 1:  Protocol level [...]

> Option 2:  Generic matcher level


Speaking for both GUI and map-storage, Option one is not really viable. 
Here's why: The match-map is empty in the beginning. It only gets filled 
inside the matching GUI, which, by definition, is generic-importer code 
domain and *not* protocol-code. Therefore all calls to the matching map 
will probably only happen inside the generic code. Actually this renders 
protocol-specific category names pretty useless :-) . Whatever.

What we need is this: The protocol code has to pass some data type to 
the generic importer. Currently this is "just" the ready-for-use 
Gnc-Transaction*, but for this matching purposes we can easily define 
our own Importer-Transaction data type. That type would also hold the 
strings (and categories?) that should be matched against.


> Here, we are in Gnucash world.  The only strings available for matching are 
> the transaction "Description" and "Note" fields, and the splits "Memo" 
> fields.  So there is a finite number of "match categories".  


That's another option, but at least in the HBCI case I would prefer to 
have a number of different matching strings. I will put the information 
from the matching strings into the transaction's description, but 
already with some strings concatenated, which means that some 
information is already lost. Therefore I would prefer to have a 
generic-importer transaction data type where I can fill in the 
additional matching strings.

Christian

PS: I'm again out of town until end of the Weekend, Nov 17.