On Tue, 2003-02-04 at 23:03, Derek Atkins wrote: > Nigel Titley <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
