Let us know what happens/

--
Michael Gordon
MVP
"Ajay" <Nunya[at]biz.com> wrote in message
news:x3y1y6zach0j$.gtjgyvbmcuvg$.dlg[at]40tude.net...
- quote -

On Sun, 8 Aug 2004 19:02:37 -0500, Michael Gordon, MVP wrote:

- quote -

1) Nope. I get the same error message.
2) I'll look for 2005.

Thanks for all the help and putting up with my annoyance.

--
-Ajay
PGP key ID = 0xCC93989F
Key can be found on http://wwwkeys.pgp.net
or
http://pgp.mit.edu:11371/pks/lookup?...3989F&op=index
Post private responses in news group alt.anonymous.messages
with the word "Ajay" in the subject line.

Two possible solutions:
1) though you can't delete or edit it, can you mark it as void?
2) upgrade to Money 2005 when it comes out -- it finds and deletes these
hidden transactions.

--
Michael Gordon
MVP
"Ajay" <Nunya[at]biz.com> wrote in message
news:1cfuvlomffh33.mmm6oocqyc00.dlg[at]40tude.net...
- quote -

On Sun, 08 Aug 2004 21:10:57 GMT, Cal Learner-- MVP wrote:

- quote -

Aaaackkk! As Bill the Cat would say. But we're so close! I did as
you said, and here's where I'm at:

After importing the edited qif file, Money merged the import with what
must be the invisible table entry. Great! But alas, it imported as
an epay. I'm sure the table has this transaction memorialized as an
epay.

Well, no problem, if I could delete it, it should delete the entry
from the table as well, and everything will balance out. But no, an
attempt to delete produces the error message:

"This online transaction has not been completed. You need to send
this payment again to complete the transaction before deleting it."

Which I would do, except the transaction is dated in the past and can
not be edited (can't change the date or the unsent epay status).

So I've brought the offending "ghost" transaction into the light, but
don't seem to have a way to kill it.

If you don't have a ready fix for this, I'll contact Microsoft.
Thanks for all your help. It was educational!

Oh - a possible solution that is inelegant? I suppose I could enter
an account adjustment deposit for the exact same amount and mark both
as reconciled, but that's not very satisfying for some reason.
--
-Ajay
PGP key ID = 0xCC93989F
Key can be found on http://wwwkeys.pgp.net
or
http://pgp.mit.edu:11371/pks/lookup?...3989F&op=index
Post private responses in news group alt.anonymous.messages
with the word "Ajay" in the subject line.

In microsoft.public.money, Ajay wrote:

- quote -

I would export a QIF file from that account. If the $68.89
transaction is in that QIF file, I would edit the QIF file to remove
everything but the first line and the single record that corresponds
to the transaction.

I would then File-> Import the modified QIF an hope you can get it to
match. If it then becomes visible, you should be able to deal with
it.

If the problem continues, I would contact Microsoft support.

On Sun, 08 Aug 2004 19:14:22 GMT, Cal Learner-- MVP wrote:


- quote -

Thank you very much. It has, at least, identified a problem. The log
results of the operation produced by the recommended downloaded
salvage utility:

Warning: Transaction Account= Bank Checking , Payee=Dish Network ,
Date=12-19-2003, Amount=-68.8900 is broken.
Warning: broken records in system table.

After running the utility, the problem remains. Add to this the
specific transaction was archived in an archive file. In opening and
working with the archive file, I find the specific entry mentioned in
the log above does not exist. It is my vague recollection this was a
transaction I deleted, or more likely, canceled as an epay.

So what now? The log entry refers to the system table, an ominous
name to be sure. Somewhere I should fear to tread?

-Ajay
PGP key ID = 0xCC93989F
Key can be found on http://wwwkeys.pgp.net
or
http://pgp.mit.edu:11371/pks/lookup?...3989F&op=index
Post private responses in news group alt.anonymous.messages
with the word "Ajay" in the subject line.

In microsoft.public.money, Ajay wrote:

- quote -

Hmm. Let us know if
http://support.microsoft.com/default...13&Product=mny
and which part did it for you.

I'll bet this is really obvious and simple, but here goes:

For months now I have been trying to track down why viewing all
transactions in the register show a correct balance, and when viewing
only unreconciled transactions the amount is always off by (68.89).
This has spanned several months of balancing and is consistently the
same amount.

It's like there are invisible transactions that do not get calculated
when switching from reconciled to unreconciled views. No, there is
no single transaction that totals 68.89.

I am using MM2002, if that helps.

Thanks,

-Ajay
PGP key ID = 0xCC93989F
Key can be found on http://wwwkeys.pgp.net
or
http://pgp.mit.edu:11371/pks/lookup?...3989F&op=index
Post private responses in news group alt.anonymous.messages
with the word "Ajay" in the subject line.