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.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
