UNMATCH NEAR MATCH??

I was stating their 2 possible "design intents", not what their possibly erroneous code actually did. We as users can't know which of the 2 cases is their intent, but in either case I don't think they should have generated a near-match.

Neither validate nor supervalidate find all DB errors, nor do they find any possible corruption in your Quicken installation or bugs in the Quicken code or in your particular computer system. If it's corruption in your DB or system they probably won't be able to reproduce the problem, nor will you likely be able to find it. Lots of flaky things happen with complicated programs on complicated systems that we just have to live with. Hopefully the problems are all as minor as this one.

Regardless, the behavior of this case still looks fishy to me and it may be a relatively harmless symptom of a more serious underlying problem. It may be as designed but I strongly suspect that is not the case. I still think this obviously erroneous near-match should be reported as a possible bug. If it's as designed they should let you know. If it's an obvious coding bug or one that they can reproduce, they might fix it. If they can't reproduce the problem they probably won't do anything - which is exactly what will happen if you don't report it.

If you have a blanket definition of "feature", such that every characteristic of a piece of software must be a bug or a feature ... then, yes. Since that seems like an unenlightening, if not downright misleading, classification, I don't think of it that way.

I posted why I concluded it wasn't a bug; based on the fact that Intuit chose to publish a method for achieving a "make new" result (publicly implicitly acknowledging that near-matches were not always valid "matches"); instead of: staying silent, modifying Quicken to have a "make new" option for near matches, or providing an option to be notified of an upcoming "fix". Still, I'd be happy to change my response to: "I don't believe it's a bug"; though I doubt if that had been my original response, it would have changed your approach.

Of course, if whatever a user doesn't like, or agree with, is a bug, then the term bug, too, becomes pretty meaningless.

Disagreements with the near-match results have been around for a long time, and Intuit has had plenty of time to alter the near-match criteria or provide an option to make a near-match, new ... all they did was explain how to accomplish the same results as "make new", which I have not found to be their usual reaction to what they believe is a bug. It may not be conclusive evidence; but I think, better than making up standards on the fly just to "prove" that Intuit isn't following them.

Frankly, I believe that, if a lack of an arbitrary level of precision is considered a bug, and Intuit adopted the standard you offered, that there would still be complaints that +/- 99% (or +-98% ... etc.) was a bug. At what degree of precision would all users agree no bug exists?

Is this algorithm actually public, John? If so, where is it?

Jerry

I'm sure that's true but keep in mind my database is only a couple of weeks old after a from scratch conversion from Money, so there hasn't been much opportunity for the gremlins to have done their evil on my database.

On the other hand, had I not taken note of the bug overwriting a false near match, I'd be very suspicious of damage causing my records to mysteriously disappear.

This seems like a particularly troublesome bug as the default for Quicken is to automattically accept transactions. By the time you notice what's been happening, perhaps not for weeks, recovering could be a major pain.

Bruce.

I don't recall ever seeing the criteria for a near-match anywhere.

What I did see was an Intuit knowledge base article providing basically the same "workaround" for a mismatched near-match that I posted at the beginning of this thread. I can no longer find that article.

--------------------

Tell me how investment transaction matching works

For Quicken to identify a match, everything about the transaction must be the same: the security, action, number of shares, price, amount, and the ratio if it's a stock split. The dates must match exactly.

Quicken uses a scoring system to decide if a transaction is a match, a near match, or new. If you think a new transaction might actually be in your transaction list, find it and check the fields for data entry errors in this order:

In this field Verify that the following is correct Security This field must match exactly, or the transaction is marked New. Date The dates must be the same for an exact match. If the dates differ by more than 14 days, Quicken considers the transaction new; if less than 14 days Quicken may mark the transaction a Near Match unless there are additional discrepancies.

Action If you have a linked checking account, the action must match exactly. Stock splits The ratio must be an exact match. Price, Number of shares, Amount Any difference in one of these prevents the transaction from being marked Match. When the difference in any of these is too great, Quicken marks the transaction New.

--------------------

Based on the above it seems like the transaction listed by the OP should not have been marked a Near Match. The dates were off by less than 14 days, which in and of itself could make them Near Matches, but there *were* "additional discrepancies.

Tom Young

I start off with the assumption that the code can do a good job because I watched Money make only correct matches for about 16 years. On the other hand, I've already seen bad matches and bad near matches in Quicken in a few weeks.

One time Money did try to make a match for a transaction about 30 days older. But that was easily fixed because the number of days was configurable. I shorted it to less than a month and it never made a bad match again. I don't know what algorithm it used, only that it worked very well for me.

It didn't have the concept of a near match.

Bruce.