Generic Account Mapper

Derek Atkins warlord@MIT.EDU
11 Nov 2002 15:08:49 -0500


Benoit Gr=E9goire <bock@step.polymtl.ca> writes:

> Personally, I don't really see the usefullness of the match categories as=
=20
> proposed.  There are to possibilities as to where the match functions are=
=20
> called.=20=20

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 stru=
cture=20
> is passed to the generic importer (which means they are called by the ofx=
 or=20
> HBCI modules.  In that case the protocol knows what are the best fields t=
o=20
> match with.  The gnc_imap functions don't have to know what they are=20
> matching, it should just match against one big table per source account. =
 The=20
> protocol module can try to match as many strings as it wants, in wathever=
=20
> order it wants.  Life would be perfect, except that we will then have a U=
I=20
> nightmare when we want to change the match manually.  The generic matcher=
=20
> will have no reliable way to know that a split was auto created and can b=
e=20
> 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 a=
re=20
> the transaction "Description" and "Note" fields, and the splits "Memo"=20
> fields.  So there is a finite number of "match categories".  The only way=
=20
> around that is to pass the match strings as part of the parameters of=20
> gnc_import_add_trans.  In that case the parameters would be some generic=
=20
> "match_string_1", "match_string_2" etc., but I think two would be enough.=
=20=20
> The strings would only be matched against a single table, with no type.  =
If=20
> match_string_1 doesn't match anything, try with match_string_2 on the sam=
e=20
> table.  I can't think of a case where matching against a single list of=
=20
> string per acount would give wrong or misleading results compared to matc=
hing=20
> against one table per priority.
>=20
> 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

--=20
       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@MIT.EDU                        PGP key available