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