Import transactions change proposal

[Greg Stark]

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
> grouped???

Well that's why you have a rent expense account. The goal is to recognize
which transactions should be balanced against this rent account.

--
greg