Hi, Sounds like a painful conversation.
Several months ago, I looked at 2 years of my data (about 1800 transactions). I think my data is reasonably typical for someone in the US using gnucash their personal checkbook. Here is what I found, in case it is of use. My transactions are about 1/3 checks and about 2/3 debit card transactions. I have about 10 transactions/month that are identical to previous months except for date and check#. These include some fixed expenses like rent, and some common non-fixed ones like ATM withdrawals. For that data, it worked out that $ amount was by far the best matching element. After taking out the 240 repetive transactions, the remainder were almost all unique $ amounts. There were a number of $ amounts with 2 transactions, but not more than 2-300. Given a set of two of these dupes, they tended to be for the same payee, but widely differing dates/check #s. Description was close to useless for matching, with my data. My bank (Wells Fargo) doesn't provide payees for checks in the QIF files, and for debit card transactions the names stores use for their accounts are often different than what they have on their storefront. Date was problematic in my case also - I routinely have checks cashed 1 month after the date I wrote them. However this was still the next best matching element for me, for selecting from multiple repetitive transactions. Many of my repetitive transactions have no check# (ATM or auto-draft). Check# was great for checks, but I have no similar identifying number for any other transactions. All that being said, thank you for the generic import. I cobbled together a QIF importer using it, and I find it works very well. Almost all transactions have already been entered by hand, so the matcher gets heavy use. -Olaf On Sunday 13 February 2005 09:35 pm, Benoit Grégoire wrote: > > Well, either the matching algorithm needs to get much, much better, or > > there needs to be a way to manually match transactions... > > The algrithm is actaully very good in most cases. Apparently you've hit a > corner case as well as a bug caused by lack of sync between developers (and > my general lack of recent involvement in GnuCash development). > > On 2004-10-08, I changed date MATCH_DATE_NOT_THRESHOLD from 3 weeks to two > weeks, and dropped the punishement from -10 to -5 to avoid your very > problem. Checks cashed more than two weeks later is actually a fairly > common occurence. > Unfortunately, on 2004-11-27 Christian changed this check to to a hard > limit, thus removing ANY transaction more than two week apart from > consideration, no matter how well it matches. It's easy to understand, > from what I heard, checks are mostly extinct in Germany. > > Since I didn't do ANY gnucash development since 2004-11-15, I didn't spot > it untill today. I'll have to discuss with Christian how to best sync up. > > Your only solution for now is to downgrade to GnuCash 1.8.9. > > > I'll point this out-- in the years I was using Quicken, I don't recall > > that it ever failed to properly automatically match transactions. I > > understand that the traansaction matcher is probably still in its > > infancy and some paatience is needed. But my complaint is not simply > > Actaully it's quite mature, but you've hit a recently introduced bug. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
