Re: Ability to change "Downloaded Payee"?

Andrew <[email protected]> Sun, 26 May 2024 09:47:12 -0400
Newsgroups alt.comp.software.financial.quicken
Organization A noiseless patient Spider
Message-ID <[email protected]>
On 5/25/2024 1:37 PM, John Pollard wrote:
> On 05/25/24 8:00 AM, Andrew Schmidt wrote:
>> I had two checks written within a few weeks of each other for the same 
>> amount.  One cleared, and I accepted the transaction.  The other did a 
>> few weeks later, but I noticed that Quicken matched the wrong 
>> transaction with the first check during the first download....so I had 
>> to accept this second transaction for the wrong payee the second time 
>> (via a manual match).
>>
>> Net effect is, of course, the same. Both checks are now cleared.  But 
>> the "Downloaded Payee" field in the register shows 'Check 2120' where 
>> 'Check 2019' should be and visa-versa.
>>
>> Long explanation of why I'm asking if that is something that can be 
>> manually edited so the fields are correct.  I can't find anyway to do 
>> that, and really, perhaps it shouldn't be allowed to in reality.  
>> Being anal, it just bothers me (but I'd get over it).
> 
> 
> None of the "Downloaded ...." fields can be changed - and for good reason.
> 
> They are intended as a permanent record of what was in the download; 
> changing them would destroy that record ... and achieve no useful 
> purpose. You should consider all the "Downloaded ...." fields as already 
> "correct.
> 
> In your specific case, you created the "problem" when you accepted 
> Quicken's mismatch of the first downloaded check transaction. Quicken 
> does not always get the matches correct (though it usually does for 
> downloaded check transactions). So the user has to be on guard for 
> Quicken mismatches.
> 
> When you say, "But the "Downloaded Payee" field in the register shows 
> 'Check 2120' where 'Check 2019' should be and visa-versa", it sounds 
> like you have it backwards.
> 
> The transaction that has "Check 2120" in the "Downloaded Reference" 
> field, should have check# 2120 in the Quicken Check# field and the payee 
> name for check# 2120 in the Payee field. The same logic for Check# 2019. 
> Looked at another way: instead of changing the "Downloaded Payee", 
> change the Quicken register payee.
> 
> {You could also effectively undo the "match" by using "Cut 
> transaction(s)"/"Paste transaction(s)" to remove, then re-add, the same 
> transaction to the account. The result will be to remove all the 
> "Downloaded ...." fields  from each transaction. See footnote below.]
> 
> I think it's unlikely that there will be any problem if you leave things 
> as they are, but there is at least one possible problem that might arise.
> 
> One of the "Downloaded ...." fields is "Downloaded ID", which is a 
> unique transaction ID (assigned by the financial institution - or 
> Intuit) which identifies a specific transaction. Quicken uses that 
> unique ID to filter out any possible duplicate downloaded transactions - 
> that is, any downloaded transaction with a "Downloaded ID" that is the 
> same as the Downloaded ID for an existing Quicken transaction in the 
> same account, will be ignored by Quicken.
> 
> Also your Quicken transaction "Posting Date" may cause you problems if 
> the two checks cleared in different Statement Periods. See footnote below.
> 
> 
> [ (*) Before doing the Cut/Paste transaction, you might want to manually 
> record the "Downloaded Posting Date" for each of the 2 transactions. 
> Once the transactions have been Pasted (and lost their "Downloaded ..." 
> values), you can tell Quicken what the Posting Date was for each 
> transaction by: right-clicking the transaction, holding down CTRL while 
> left-clicking "Copy transaction(s)", and entering the manually saved 
> "Downloaded Posting Date" in the Quicken "Posting Date" field (which is 
> NOT the same as the Downloaded Posting Date). Quicken uses the "Posting 
> Date" for reconciles; and the Posting Date is automatically updated with 
> the value of "Downloaded Posting Date" when a downloaded transaction is 
> Accepted.]

Thanks John, yes, I know it's to be permanent (which is why I said "...t 
shouldn't be allowed to in reality".) I figured that I can't do it, but 
I'd give this NG a shot.  And I do know and berate myself for creating 
the situation in the first place. :-)

-- 
-----------------------------------------------------------
Regards -

- Andrew