On Mon, 15 May 2000 21:18:16 CDT, the world broke into rejoicing as
Glen Ditchfield <[EMAIL PROTECTED]> said:
> I'd like the looser rules for matching imported entries with existing
>entries.
Ouch. I'm starting to get a tad concerned about how "fuzzy" this matching
is starting to get.
> The .qif files I get from my bank contain descriptions like
> "CHQ#00452-0041093240" for a cheque. I suppose the digits after the dash are
> some sort of tracking number; at any rate, when I type the cheque into
> Gnucash I can't predict what they will turn out to be.
>
> ATM withdrawal descriptions look like "GM W/D 000915". In this case I
> do know what the trailing digits will be, but I don't want to type
> them or the spaces, because I'm lazy.
>
> Of course, for cheques and even some ATM withdrawals, the date in the
> .qif file won't be the date on which I wrote the cheque or made the
> withdrawal.
Indeed.
> For my purposes, I think I would like an existing entry in an account
> to match an imported entry if
> - the amounts match,
> - the existing entry's description is a prefix of the imported entry's
> description, and
> - the existing record's date is on or before the imported record's date.
The problem is that this starts leading us towards the possibility of the
software deciding to throw out transactions because they _appear_ similar.
THAT would be a bad thing.
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.
--
If you ever drop your keys into a river of molten lava, let'em go,
because, man, they're gone.
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
