Christopher Browne <[EMAIL PROTECTED]> writes:
> Ouch. I'm starting to get a tad concerned about how "fuzzy" this matching
> is starting to get.
Well, as long as the user has to put a "stamp of approval" on the
matches, I think it's OK. I'm currently working on an overhaul of the
QIF code that will support this as an optional step in the import. I
don't think the heuristics will be that hairy... really the amount
plus a date window is a fairly unique identifier.
> This sort of suggests that the system shouldn't quietly drop the
> transactions, but rather list them in parallel [e.g. - side by side] and
> provide the option of doing some combination of:
> a) Drop the one on the books in favor of the one being loaded,
> b) Drop the one being loaded,
> c) Keep both,
> d) [This starts getting questionable...] Merge data for the transactions
> together, say pulling all the non-blank fields from the input file
> in to replace what's in GnuCash.
I think (d) is an important option. Often the bank has some
information (tracking numbers, etc) that you don't have when you enter
the transaction, and you have memos and such that the bank doesn't
have.
Bill Gribble
