UNMATCH NEAR MATCH??
in [Quicken]
|
From: JimH on 15 Feb 2010 13:42 John Pollard wrote: > 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. 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.
From: Bruce. on 16 Feb 2010 10:38 "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. > 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. Bruce.
From: Jerry Boyle on 16 Feb 2010 06:27 "Bruce." <noone(a)example.net> wrote in message news:hlc4a2$jok$1(a)news.albasani.net... > "TomYoung" <sombodee(a)gmail.com> wrote in message > news:11737dbc-1527-4144-bfe4-f2da385123ea(a)k2g2000pro.googlegroups.com... >> 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? > > 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. 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.
From: Jerry Boyle on 16 Feb 2010 06:56 "Bruce." <noone(a)example.net> wrote in message news:hlc2pk$gst$1(a)news.albasani.net... > "Jerry Boyle" <jerryboyle(a)att.net> wrote in message > news:hlb83k$1rn$1(a)news.eternal-september.org... > 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. Different transaction types, possibly with different record formats, eh? This could be a fairly wide-ranging problem that I think should be reported. Jerry
From: Bruce. on 16 Feb 2010 08:10
"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 Bruce. |