Import transactions change proposal

[Nigel Titley]

On Tue, 2003-02-04 at 23:03, Derek Atkins wrote:
> 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.

Okay, I'll keep quiet.... sorry

Nigel