Christopher Browne <[EMAIL PROTECTED]> 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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
