UNMATCH NEAR MATCH??

Change the date of the existing Quicken transaction to something like one year in the future. That should remove the "near match" status, and make the downloaded transaction, "New". After accepting the downloaded transaction, change the date of the pre-existing transaction back to the correct date.

Ok thanks for the idea John. It there a place where I can report this bug?

Bruce.

It's not a bug.

True, actually it's 2 bugs. It shound never have called those transactions a near match, and it shouldn't have left me with no option but to overwrite an existing transaction.

I'll report the bugs via the Quicken email support.

Bruce.

It's a feature?

Tom Young

As soon as you (and the op) can demonstrate what a "near match" should be, and why it is not what it should be ... you might have a semblence of credibility.

Wow. Apparently, along with your ability to be a great resource and help to many goes a certain degree of pomposity.

Need some help getting that stick removed?

I'll be real liberal for this transaction and say:

Date should be within +/- 10 days per register

AND

Shares purchased should be within +/- 100% per register

AND

Amount invested should be within +/- 100% per register

This transaction FAILS on all tests.

Further, having a bail-out option of un-matching (just in case some similar transactions occur within near proximity of one another) seems like a reasonable safeguard, as does a manual match in case of user input error. (I'm assuming the FI info is always correct, which is a dangerous assumption, but I'll forgo that argument.)

How's that?

Maybe suggest that to Quicken?

Tom Young

In the face of innumerable possible user errors, including multiple errors for a single entry, determining what is and is not a possible match is "indeterminate".

In this case I'd have to agree with John. What happened to the download for the 1/30 dividend? A second reinvested dividend for (I'm assuming) the same security within a 2-week period where the first has not yet been cleared is a "possible" match and it might be safer to flag that possibility, as Quicken has done.

I think John was addressing only the "near match" issue. I hope he'd agree that having no simple unmatch feature is a bug.

Jerry

It wasn't the technical disagreement as much as it was the attitude.

When asked straightforward informational questions, I've seen him take an inordinate amout of time and effort to answer them. But, once in a while, one of "these" comes up, where the quality of Quicken, itself, is questioned, and the fangs come out.

Sorry, I digress.

I have no objection to suggesting improvements to Intuit ... but I don't equate desired improvements to bug fixes.

Your personal desires aren't the same (obviously) as the rules Quicken

There have been "near match" mis-matches since I began using Quicken, but I don't think that Intuit believes those mis-matches are bugs. The workaround I posted here, was also available for years at the Intuit support web site with no comments about it being a problem (ie, "bug"), nor anyplace to sign-up to be notified when it was "fixed" (which is usually the case when the article is about a known bug).

I believe the "near-match" is a special situation (for example; I know of no other "match" transaction that effectively replaces an existing register transaction, when accepted). So it seemed to me that since no one here posted specifics about how Intuit intended near-match transactions to work, it didn't make a lot of sense to be leaping to conclusions that called for that missing information.

I don't know why there is no "un-match near-match", but Intuit has certainly long been aware that near-matches are not always "matches", so it doesn't appear to be a lack of knowledge of the "problem" on their part preventing them providing that option. And Intuit clearly does understand that users may have reason to "unmatch" or "manually match" transactions, since Quicken already provides those options for some investment transactions and most, if not all, non-investment transactions.

I try not to assume that just because Intuit's intentions or reasons are not clear, anything I don't understand must be a bug. Sometimes the inexplicable turns out to be a bug, but I've found no benefit to jumping to that conclusion. Too often, I see users assuming something's a bug when it can be verified that it isn't.

Nothing happened to it. It downloaded on 1/30 and was entered in to the register.

Dividends don't "clear" so I'm not sure what you mean by that.

One thing I didn't notice before my first post was that the 1/30 transaction was a DIVIDEND, while the 2/12 transaction was a SHORT-TERM CAP GAIN.

So the price was wrong, the share count was wrong, the tranaction date was wrong, and the transaction type was wrong. I'd have a lot of difficulty calling that a near match.

Yes, that was my main point. and the only thing I reported to Quicken.

Bruce.

But, with the same lack of knowledge of Intuit's intentions or reasons you concluded that it *wasn't* a bug, so I guess it must be a feature?

Tom Young

For reasons I don't quite understand, sometime the word "bug" generates an emotional and defensive response. Having been programming for 40 years, I am quite comfortable with the term meaning a whole host of things, more generally categorized as "undesirable behavior", without assigning fault or blame. Some bugs easy to fix, but some may take a long time and much thought before finding a solution that covers the majority of cases. Some are bugs can be defects in original design, some in the implementation of that design, some are things simply cases not thought of in advance. For example, if the design calls for the user file to be trashed when they make a typo, that's a bug even if the implementation is perfect. Because we can't think of a solution today, does not make the bug any less undesirable, nor should the search for a solution ever be abandoned.

In all cases, "undesirable behavior" should be viewed as an opportunity to improve the product, whenever and wherever possible. Often just revisiting it with fresh eyes will yield a solution. The words the paying customer uses to describe the problem are irrelevant. It's the opportunity that counts.

Bruce.

That assumes that bugs are only introduced at the coding phase of development. Bugs can and often are introduced at requirements and design phases.

The personal desire was that Quicken would do a good job of determining if a downloaded transaction matched an existing transaction, and that he be given the opportunity to correct the program when it is wrong. That is reasonable behavior for a program. Making a mistake in matching transactions and offering no reasonable way to correct it does not sound like a very good job was done on requirements and design.

As a long term software developer, it is a bug or if I were being very generous, I'd call it a "feechur", certainly not a desirable behavior. But, at least it is working as coded.

The original UNIX designers were even more liberal than this. On their manual pages they listed as "BUGS" absolutely unavoidable program or function behavior that might surprise a user, even though there was no way to avoid that surprising behavior. I took this same approach with all the functionality that I designed and implemented and it never got me in any trouble. My users appreciated both the heads-up and the humility.

Different transaction types, possibly with different record formats, eh?

This could be a fairly wide-ranging problem that I think should be reported.

Jerry

I'm fairly new to Quicken but my experiences so far in various account types is that Quicken is much too willing to match or near match transactions. The code should always err on the side of safely. If they miss a match, you end up with an easily deleted duplicate. If they falsely match or near match and you don't catch it, a perfectly valid old record gets overwritten with the new transaction, destroying information. Reconstructing the old record can be a royal pain in the backside if you don't realize it immediately when it happens

Bruce.

I personally would rather see more false matches (I can't recall ever having seen any at all!) than have it miss duplicates, but only if there were a simple unmatch feature. But that isn't the point I was getting at.

Either (1) they are trying to match different investment transaction types or (2) they aren't.

If (1) then, depending on how many different transaction type formats they have, they may have erroneous or missing code for one or more of a possibly large number of cross-comparisons of different record types. These types of errors can lead to program instability or even damage to your DB.

If (2) then this is a coding error or perhaps there is damage to your Quicken installation or DB.

In either case, if I were a Quicken programmer I'd want to know about this case and I strongly suggest that you report it.

Jerry