Import transactions change proposal
gsstark at mit.edu
Mon Feb 10 18:32:34 CST 2003
Christopher Browne <cbbrowne at cbbrowne.com> writes:
> 1. Ifilter performance gets increasingly /greatly/ ugly as the number
> of categories grows. Doing this totally automagically means that each
> transaction is a "category," and if there are thousands of transactions,
> that's not terribly nice.
No, each *account* is a category. This is *NOT* duplicate matching.
My hope is that the limited number of input data would result in reasonable
speed. The actual algorithm is pretty time-efficient I'm not too worried about
time. Space is a bigger concern.
> 3. What if a bunch of transactions are already very similar? For
> instance, my monthly rent goes in to the same payee for the same amount
> on the same day of each month. These transactions are 'essentially the
> same' for our purposes, and really should get collected together into
> one "category." It would sure be nice to collect them together; that
> cuts down on the number of categories, and means that rather than there
> being a bunch of "nearly similar" categories, one for each transaction,
> that there's just one category.
> But how do we provide a "user interface" that allows them to be so
Well that's why you have a rent expense account. The goal is to recognize
which transactions should be balanced against this rent account.
More information about the gnucash-devel