Benoit Gr�goire <[EMAIL PROTECTED]> writes:
> Personally, I don't really see the usefullness of the match categories as
> proposed. There are to possibilities as to where the match functions are
> called.
The categories are to allow you to have multiple matches for some
string, "foo", based upon _what_ "foo" is. For example, in the QIF
world a DESCRIPTION "foo" might want to be mapped differently than a
PAYEE "foo", which is yet different from MEMO "foo".
> Option 1: Protocol level
> The match functions are designed to be called before the transaction structure
> is passed to the generic importer (which means they are called by the ofx or
> HBCI modules. In that case the protocol knows what are the best fields to
> match with. The gnc_imap functions don't have to know what they are
> matching, it should just match against one big table per source account. The
> protocol module can try to match as many strings as it wants, in wathever
> order it wants. Life would be perfect, except that we will then have a UI
> nightmare when we want to change the match manually. The generic matcher
> will have no reliable way to know that a split was auto created and can be
> changed by the user. So this brings us to:
You don't understand. The functions here are _just storage_. There is
no UI. You could implement either option-1 OR option-2 given my API.
> Option 2: Generic matcher level
> 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". The only way
> around that is to pass the match strings as part of the parameters of
> gnc_import_add_trans. In that case the parameters would be some generic
> "match_string_1", "match_string_2" etc., but I think two would be enough.
> The strings would only be matched against a single table, with no type. If
> match_string_1 doesn't match anything, try with match_string_2 on the same
> table. I can't think of a case where matching against a single list of
> string per acount would give wrong or misleading results compared to matching
> against one table per priority.
>
> Perhaps I missed something....
Yes, you are missing the fact that I'm just talking about storage here.
In order to store a map you have to know what you are matching against.
The fact that the importer knows you are matching against a description
doesn't help if you have no way to store that information.
-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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
