UNMATCH NEAR MATCH??
in [Quicken]
|
From: Jerry Boyle on 16 Feb 2010 09:21 "Bruce." <noone(a)example.net> wrote in message news:hle5gk$cll$1(a)news.albasani.net... > "Jerry Boyle" <jerryboyle(a)att.net> wrote in message > news:hle15s$si2$1(a)news.eternal-september.org... >> Different transaction types, possibly with different record formats, eh? >> >> This could be a fairly wide-ranging problem that I think should be >> reported. > > 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 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
From: Jerry Boyle on 16 Feb 2010 12:30 "Bruce." <noone(a)example.net> wrote in message news:hlee66$ih4$1(a)news.albasani.net... > "Jerry Boyle" <jerryboyle(a)att.net> wrote in message > news:hle9lm$cme$1(a)news.eternal-september.org... > >> Either (1) they are trying to match different investment transaction >> types or (2) they aren't. > > 1/30/2010 4.881 shares @ 10.87 $53.06 DIVIDEND > 2/12/2010 1.202 shares @ 10.723794 $12.89 SHORT-TERM CAP GAIN > > They called that a near match and upon accepting it, the first one was > overwritten by the second. 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. >> If (2) then this is a coding error or perhaps there is damage to your >> Quicken installation or DB. > > I have run validate and it finds no errors. 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.
From: John Pollard on 16 Feb 2010 12:43 TomYoung wrote: > On Feb 15, 9:23 am, "John Pollard" <8plus7...(a)gmail.com> wrote: >> TomYoung wrote: >>> On Feb 14, 6:44 pm, "John Pollard" <8plus7...(a)gmail.com> wrote: >>>> TomYoung wrote: >>>>> On Feb 13, 6:20 pm, "John Pollard" <8plus7...(a)gmail.com> wrote: >>>>>> Bruce. wrote: >>>>>>> "John Pollard" <8plus7...(a)gmail.com> wrote in message >>>>>>> news:hl6joe$nv0$1(a)news.eternal-september.org... >>>>>>>>> So what can I do? How do I tell Quicken that those are NOT >>>>>>>>> matches before accepting? >> >>>>>>>> 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? >> >>>>>> It's not a bug. >> >>>>> It's a feature? >> >>>> 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. >> >>> 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.) >> >> 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 *is* using ... but for the near-match failure to be a bug, >> it would have to be failing the rules that Quicken is intending to >> use (not the rules you prefer it use) ... and since we don't know >> what those rules are (or why they are what they are), it makes >> little sense to assume the problem is a bug. >> >> 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. >> > 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? 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? -- John Pollard news://<YOUR-NNTP-NEWSERVER-HERE>/alt.comp.software.financial.quicken Your source of user-to-user Quicken help
From: Jerry Boyle on 16 Feb 2010 12:53 "John Pollard" <8plus7isf(a)gmail.com> wrote in message news:hlelfh$d1u$1(a)news.eternal-september.org... > 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 ... Is this algorithm actually public, John? If so, where is it? Jerry
From: Bruce. on 16 Feb 2010 16:20
"Jerry Boyle" <jerryboyle(a)att.net> wrote in message news:hlekok$nqc$1(a)news.eternal-september.org... > Neither validate nor supervalidate find all DB errors 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. |