UNMATCH NEAR MATCH??
in [Quicken]
|
From: TomYoung on 14 Feb 2010 11:59 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? Tom Young
From: John Pollard on 14 Feb 2010 21:44 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. -- John Pollard news://<YOUR-NNTP-NEWSERVER-HERE>/alt.comp.software.financial.quicken Your source of user-to-user Quicken help
From: Notan on 14 Feb 2010 22:51 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?
From: TomYoung on 15 Feb 2010 00:26 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.) How's that? Maybe suggest that to Quicken? Tom Young
From: Jerry Boyle on 15 Feb 2010 05:36
"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. Jerry |