UNMATCH NEAR MATCH??
in [Quicken]
|
From: Notan on 15 Feb 2010 09:37 On 2/15/2010 3:36 AM, Jerry Boyle wrote: > > "Notan" <notan(a)ddressthatcanbespammed> wrote in message > news:JuGdnZv-hOJWWeXWnZ2dnUVZ_tadnZ2d(a)giganews.com... >> On 2/14/2010 7:44 PM, John Pollard 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. >> >> 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? > > 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. 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.
From: John Pollard on 15 Feb 2010 12:23 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. -- John Pollard news://<YOUR-NNTP-NEWSERVER-HERE>/alt.comp.software.financial.quicken Your source of user-to-user Quicken help
From: Bruce. on 15 Feb 2010 13:12 "Jerry Boyle" <jerryboyle(a)att.net> wrote in message news:hlb83k$1rn$1(a)news.eternal-september.org... > In this case I'd have to agree with John. What happened to the download > for the 1/30 dividend? Nothing happened to it. It downloaded on 1/30 and was entered in to the register. > 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. 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. > I think John was addressing only the "near match" issue. I hope he'd agree > that having no simple unmatch feature is a bug. Yes, that was my main point. and the only thing I reported to Quicken. Bruce.
From: TomYoung on 15 Feb 2010 13:14 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? Tom Young
From: Bruce. on 15 Feb 2010 13:37
"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. Bruce. |