Import transactions change proposal

[Derek Atkins]

Nigel Titley <nigel at titley.com> writes:

> On Tue, 2003-02-04 at 19:01, Derek Atkins wrote:
> 
> > Then, of course, we need to improve the match mapper -- right now it
> > only matches on full-strings.  We would need to add logic to match on
> > partial strings, or perhaps even a scheme hook to allow the matching
> > to be a bit more pluggible.  I think the API needs some more thought,
> > now that we have a bit more experience with it.
> 
> Something that would help me enormously, and which doesn't seem to
> happen at the moment, is the ability to use the "number" column as part
> of the match criterion. At the moment, the matcher often fails to match
> cheques despite the fact that they have a unique number.

We're talking about two different things.  There are two matchings
that need to happen.  There is "duplicate detection", which is
matching an import txn to an existing txn.  I believe this is what you
are referring to.  This has nothing to do with the mapper API.
Besides, it should be able to match quite nicely on the amount and
date.

No, we're talking about the second type of matching, "far account
matching."  When you import transactions you know the import (near)
account, but you need to "guess" the far end of the transaction (for
double-entry balancing).  *THIS* is the "matcher" of which we're
discussing.

The two are quite separate, and very different.

> Nigel

-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