Downloaded Transaction from One Payee not showing

Recently I noticed that when I download my back statement that transactions
from Toys "R" Us are not showing up in my register. I have check the ofx
file and the transaction is there. I have not noticed this behavior with any
other Payees. I have tried deleting Toys "R" Us from the payee list, but it
has not helped. Any ideas?

Alon
Thu Aug 07 12:01:01 CDT 2008

bump, any help?

Cal
Thu Aug 07 12:13:02 CDT 2008

In microsoft.public.money, Alon wrote:

>Recently I noticed that when I download my back statement that transactions
>from Toys "R" Us are not showing up in my register. I have check the ofx
>file and the transaction is there. I have not noticed this behavior with any
>other Payees. I have tried deleting Toys "R" Us from the payee list, but it
>has not helped. Any ideas?

On your AccountList, does the ToReview column have any
entries that say TransactionsToRead?

What OS are you using?

How are you downloading? Web site or what? And if Web Site
can you save the file to disk and File->Import->DownloadStatement?

What version of Money are you using?

Alon
Thu Aug 07 14:35:02 CDT 2008

To Review does not have any entries. I am using Windows XP. I am
downloading from a website. I am using Money 2007 Deluxe.
File->Import->DownloadStatement results in the same problem.

Cal
Thu Aug 07 20:04:20 CDT 2008

In microsoft.public.money, Alon wrote:

>To Review does not have any entries. I am using Windows XP. I am
>downloading from a website. I am using Money 2007 Deluxe.
>File->Import->DownloadStatement results in the same problem.

Seems odd. I wonder if somehow the <FITID> for those is some
non-unique string that has been used previously. That is a long
shot. The same <FITID> should never be used for different
transactions.

You could try copying one of the problem transactions from the OFX
into a reply from <STMTTRN> to </STMTTRN> as in this example:


<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20080703170000
<TRNAMT>-25.73
<FITID>85160835M0701
<SIC>5300
<NAME>AJAX ROCK RENTAL
</STMTTRN>

Alon
Fri Aug 08 09:25:00 CDT 2008

Here you go

<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20080804190000
<TRNAMT>-73.24
<FITID>3743668119200808040005
<REFNUM>1080804F821749000660
<NAME>POS TOYS R US/9930 ALABAMA S
<MEMO>9930 ALABAMA ST REDLANDS 0804 S
</STMTTRN>

Cal
Fri Aug 08 09:47:23 CDT 2008

In microsoft.public.money, Alon wrote:

>Here you go
>
><STMTTRN>
><TRNTYPE>DEBIT
><DTPOSTED>20080804190000
><TRNAMT>-73.24
><FITID>3743668119200808040005
><REFNUM>1080804F821749000660
><NAME>POS TOYS R US/9930 ALABAMA S
><MEMO>9930 ALABAMA ST REDLANDS 0804 S
></STMTTRN>

I see no problem with that transaction.

If somehow, and this seems very unlikely,
"<FITID>3743668119200808040005" has been used before for a different
transaction from that FI, that could explain it.

For an experiment, you could make a copy of your OFX file (new
name), and change "<FITID>3743668119200808040005" into
"<FITID>3743668119200808040005A". Then File->Import that modified
OFX file into a test copy of your *.mny file. See if Money accepted
that transaction as a new transaction.

Alon
Fri Aug 08 10:48:02 CDT 2008

That worked.... now what?

Cal
Fri Aug 08 11:15:08 CDT 2008

In microsoft.public.money, Alon wrote:

>That worked.... now what?

It proves out the idea that the problem is a previously-used FITID.

The next time you download a new T.R.U. transaction, and it does not
work, compare the FITID with the previously-seen value. It should be
different. If it is not, you could try to report the situation to
the FI in the hopes that they fix if for the future. Yet somehow the
FIs are not as eager to track and fix bugs as you would imagine.

If you are more disillusioned, just enter the missing transaction
into the register by hand.

Alon
Fri Aug 08 11:29:05 CDT 2008

So the FITID is supposed to be unique for every single transaction, correct?
I have noted this some problem with 2 or 3 transactions from this same Toys
'R' Us.

Cal
Fri Aug 08 11:42:04 CDT 2008

In microsoft.public.money, Alon wrote:

>So the FITID is supposed to be unique for every single transaction, correct?

Yes.

>I have noted this some problem with 2 or 3 transactions from this same Toys
>'R' Us.

While the same transaction downloaded later should have same FITID,
a different transaction should have a different FITID. That's how
Money identifies that it has or has not previously seen a
transaction.

Alon
Tue Sep 02 13:13:06 CDT 2008

Cal,

I just noticed this issue again and am wondering what the root cause is.
What ensures the ID is unique? Could that fact that I have data going all
the way back to 2000 in my file be an issue?

Alon :)

"Cal Learner-- MVP" wrote:

> In microsoft.public.money, Alon wrote:
>
> >So the FITID is supposed to be unique for every single transaction, correct?
>
> Yes.
>
> >I have noted this some problem with 2 or 3 transactions from this same Toys
> >'R' Us.
>
> While the same transaction downloaded later should have same FITID,
> a different transaction should have a different FITID. That's how
> Money identifies that it has or has not previously seen a
> transaction.
>