Cost basis missing after transfer to new acct

Posted by John Pollard on April 26, 2009, 9:23 pm

Please log in for more thread options

jo wrote:

>> jo wrote:

>>>> jo wrote:

>>>>> I had this happen once before long ago and there was no solution

>>>>> except to manually enter the lost cost basis of every holding. It

>>>>> looks like the problem still exists. With the exception of pure

>>>>> stock holdings (I think that is the only category that worked),

>>>>> the cost basis for every bond, preferred, unit trust, etc is

>>>>> zeroed out after a transfer of holdings from one brokerage acct

>>>>> to another. I think it should work between different firms, but

>>>>> this is even more straightforward: it's the same brokerage firm

>>>>> but a different office and acct #. Since the cost basis is

>>>>> clearly held by quicken in the sending acct, I don't understand

>>>>> why it doesn't transfer with the asset. Any ideas on why it fails

>>>>> and any simple work around other than manual entry?

>>>>> Using Quicken Home and Business 2008.

>>>> What method did you use to transfer the securities?

>>>> How are you determining that the cost basis is zero?

>>> I used the Shares Transferred between Accounts option in the

>>> Investments section, first specifying all assets, and then today,

>>> as a test, I repeated it with a single asset (a bond). It results

>>> in a Remove transaction in the sending account and an Add- shares

>>> transaction in the receiving account. I look at my Portfolio and for

>>> any kind of asset except stock, the cost basis colum is 0. I can

>>> also run the canned Portfolio Value and Cost Basis report and see

>>> the same 0 value cost basis.

>> What do you see for Total Cost when you Edit the Add Shares

>> transasction the new account?

>> I tested this (using a "Bond" type security) in Q2008 Premier and

>> Q2009 RPM, and I don't see any problem.

> Interesting. You mean when you go to Portfolio and look at the asset

> after the transfer, it has a cost basis in the new account?

Absolutely, yes. And it has worked correctly in every single version of
Quicken I have ever used.

> My Add transaction has 0 Total Cost and

> that's because there is a 0 in the Price Paid field.

Well that is informative ... but I can't tell you how it is happening.

There should be one Add Shares transaction (in the new account) for every
"lot" in the old account. And each Add Shares transaction should show the
Total Cost of the lot it represents in the old account.

As far as I can tell, there is no reason for the Add Shares transaction to
have the "Price Paid" field involved in the transaction at all. The
"transfer" should care less what the price/share was of the purchase in
the old account ... it should only care about the Total Cost you paid for
the shares of that lot. And that's what it does in every version of
Quicken I have used.

> ( except for stocks, which have the correct info in all fields), so I

> guess we have to ask why there is no Price Paid being transferred.

As mentioned above: the "price paid" (per share) should not play any part
in the new cost basis (unless the price paid for the shares in the old
account was zero ... creating an "old" cost basis of zero).

I have no idea why you have a price paid of zero ... but I would start by
looking at your price history for the securities involved.

[Also look at a Portfolio Value report for the old account on the day
before you "transferred" the shares to the new account.]

> Can't imagine why there should be a distinction in the way the

> different asset classes are treated, or why a bond transfer works for

> you but not for me.

I suspect it's some data corruption. I have NEVER seen your problem in
any Quicken version I have used.

Start by recalculating your investment account "registers". Hold down the
CTRL key and enter "Z" in each account.

If that doesn't help, try Validating a Quicken Copy of your data. If the
Validated Copy does not exhibit the problem, make that Validated Copy your
regular Quicken file.

You should also check you price history file for zero prices; and you
should consider renaming your price history file, and recreating the price
history. [Your Quicken price history file is named QDATA.QPH, where QDATA
is the name of your Quicken data.] There are multiple ways to recreate
your price history, though none are guaranteed to get every historical
price back.

--

John Pollard

Posted by jo on April 26, 2009, 10:50 pm

Please log in for more thread options

> jo wrote:

> >> jo wrote:

> >>>> jo wrote:

> >>>>> I had this happen once before long ago and there was no solution

> >>>>> except to manually enter the lost cost basis of every holding. It

> >>>>> looks like the problem still exists. With the exception of pure

> >>>>> stock holdings (I think that is the only category that worked),

> >>>>> the cost basis for every bond, preferred, unit trust, etc is

> >>>>> zeroed out after a transfer of holdings from one brokerage acct

> >>>>> to another. I think it should work between different firms, but

> >>>>> this is even more straightforward: it's the same brokerage firm

> >>>>> but a different office and acct #. Since the cost basis is

> >>>>> clearly held by quicken in the sending acct, I don't understand

> >>>>> why it doesn't transfer with the asset. Any ideas on why it fails

> >>>>> and any simple work around other than manual entry?

> >>>>> Using Quicken Home and Business 2008.

> >>>> What method did you use to transfer the securities?

> >>>> How are you determining that the cost basis is zero?

> >>> I used the Shares Transferred between Accounts option in the

> >>> Investments section, first specifying all assets, and then today,

> >>> as a test, I repeated it with a single asset (a bond). It results

> >>> in a Remove transaction in the sending account and an Add- shares

> >>> transaction in the receiving account. I look at my Portfolio and for

> >>> any kind of asset except stock, the cost basis colum is 0. I can

> >>> also run the canned Portfolio Value and Cost Basis report and see

> >>> the same 0 value cost basis.

> >> What do you see for Total Cost when you Edit the Add Shares

> >> transasction the new account?

> >> I tested this (using a "Bond" type security) in Q2008 Premier and

> >> Q2009 RPM, and I don't see any problem.

> > Interesting. You mean when you go to Portfolio and look at the asset

> > after the transfer, it has a cost basis in the new account?

> Absolutely, yes. =A0And it has worked correctly in every single version o=

> Quicken I have ever used.

> > My Add =A0transaction has 0 Total Cost and

> > that's because there is a 0 in the Price Paid field.

> Well that is informative ... but I can't tell you how it is happening.

> There should be one Add Shares transaction (in the new account) for every

> "lot" in the old account. =A0And each Add Shares transaction should show =

the

> Total Cost of the lot it represents in the old account.

> As far as I can tell, there is no reason for the Add Shares transaction t=

> have the "Price Paid" field involved in the transaction at all. =A0The

> "transfer" should care less what the price/share was of the purchase in

> the old account ... it should only care about the Total Cost you paid for

> the shares of that lot. =A0And that's what it does in every version of

> Quicken I have used.

> > ( except for stocks, which have the correct info in all fields), so I

> > guess we have to ask why there is no Price Paid being transferred.

> As mentioned above: the "price paid" (per share) should not play any part

> in the new cost basis (unless the price paid for the shares in the old

> account was zero ... creating an "old" cost basis of zero).

> I have no idea why you have a price paid of zero ... but I would start by

> looking at your price history for the securities involved.

> [Also look at a Portfolio Value report for the old account on the day

> before you "transferred" the shares to the new account.]

> > Can't imagine why there should be a distinction in the way the

> > different asset classes are treated, or why a bond transfer works for

> > you but not for me.

> I suspect it's some data corruption. =A0I have NEVER seen your problem in

> any Quicken version I have used.

> Start by recalculating your investment account "registers". =A0Hold down =

the

> CTRL key and enter "Z" in each account.

> If that doesn't help, try Validating a Quicken Copy of your data. =A0If t=

> Validated Copy does not exhibit the problem, make that Validated Copy you=

> regular Quicken file.

> You should also check you price history file for zero prices; and you

> should consider renaming your price history file, and recreating the pric=

> history. =A0[Your Quicken price history file is named QDATA.QPH, where QD=

ATA

> is the name of your Quicken data.] =A0There are multiple ways to recreate

> your price history, though none are guaranteed to get every historical

> price back.

> --

> John Pollard- Hide quoted text -

> - Show quoted text -

I've already done everything you mention except create a new QPH file
and recalculate the registers. I don't see the need for that since a)
the registers are accurate (though how they can be with a 0 total
amount in the ADD transaction) B) the prices in the history file are
fine, with no 0 values; If they had 0 values I doubt that they would
calculate total value correctly in the Portfolio view of the original
account the day of the transfer. I still have that account defined in
Quicken and can move back and forth in date to see things before and
after the transfer and everything calculates as it should until it
reaches the receiving account. All lots of holdings transfer
individually and all have the same problem if they are not stocks.
This is so strange. I'm going to create a simple test file with just
two accounts and a couple of assets and see if it still happens. I
know this happened the last time I merged accounts but I can't
remember the solution.

jo

Posted by jo on April 27, 2009, 2:09 pm

Please log in for more thread options

> > jo wrote:

> > >> jo wrote:

> > >>>> jo wrote:

> > >>>>> I had this happen once before long ago and there was no solution

> > >>>>> except to manually enter the lost cost basis of every holding. It

> > >>>>> looks like the problem still exists. With the exception of pure

> > >>>>> stock holdings (I think that is the only category that worked),

> > >>>>> the cost basis for every bond, preferred, unit trust, etc is

> > >>>>> zeroed out after a transfer of holdings from one brokerage acct

> > >>>>> to another. I think it should work between different firms, but

> > >>>>> this is even more straightforward: it's the same brokerage firm

> > >>>>> but a different office and acct #. Since the cost basis is

> > >>>>> clearly held by quicken in the sending acct, I don't understand

> > >>>>> why it doesn't transfer with the asset. Any ideas on why it fails

> > >>>>> and any simple work around other than manual entry?

> > >>>>> Using Quicken Home and Business 2008.

> > >>>> What method did you use to transfer the securities?

> > >>>> How are you determining that the cost basis is zero?

> > >>> I used the Shares Transferred between Accounts option in the

> > >>> Investments section, first specifying all assets, and then today,

> > >>> as a test, I repeated it with a single asset (a bond). It results

> > >>> in a Remove transaction in the sending account and an Add- shares

> > >>> transaction in the receiving account. I look at my Portfolio and fo=

> > >>> any kind of asset except stock, the cost basis colum is 0. I can

> > >>> also run the canned Portfolio Value and Cost Basis report and see

> > >>> the same 0 value cost basis.

> > >> What do you see for Total Cost when you Edit the Add Shares

> > >> transasction the new account?

> > >> I tested this (using a "Bond" type security) in Q2008 Premier and

> > >> Q2009 RPM, and I don't see any problem.

> > > Interesting. You mean when you go to Portfolio and look at the asset

> > > after the transfer, it has a cost basis in the new account?

> > Absolutely, yes. =A0And it has worked correctly in every single version=

> > Quicken I have ever used.

> > > My Add =A0transaction has 0 Total Cost and

> > > that's because there is a 0 in the Price Paid field.

> > Well that is informative ... but I can't tell you how it is happening.

> > There should be one Add Shares transaction (in the new account) for eve=

> > "lot" in the old account. =A0And each Add Shares transaction should sho=

w the

> > Total Cost of the lot it represents in the old account.

> > As far as I can tell, there is no reason for the Add Shares transaction=

> > have the "Price Paid" field involved in the transaction at all. =A0The

> > "transfer" should care less what the price/share was of the purchase in

> > the old account ... it should only care about the Total Cost you paid f=

> > the shares of that lot. =A0And that's what it does in every version of

> > Quicken I have used.

> > > ( except for stocks, which have the correct info in all fields), so I

> > > guess we have to ask why there is no Price Paid being transferred.

> > As mentioned above: the "price paid" (per share) should not play any pa=

> > in the new cost basis (unless the price paid for the shares in the old

> > account was zero ... creating an "old" cost basis of zero).

> > I have no idea why you have a price paid of zero ... but I would start =

> > looking at your price history for the securities involved.

> > [Also look at a Portfolio Value report for the old account on the day

> > before you "transferred" the shares to the new account.]

> > > Can't imagine why there should be a distinction in the way the

> > > different asset classes are treated, or why a bond transfer works for

> > > you but not for me.

> > I suspect it's some data corruption. =A0I have NEVER seen your problem =

> > any Quicken version I have used.

> > Start by recalculating your investment account "registers". =A0Hold dow=

n the

> > CTRL key and enter "Z" in each account.

> > If that doesn't help, try Validating a Quicken Copy of your data. =A0If=

the

> > Validated Copy does not exhibit the problem, make that Validated Copy y=

our

> > regular Quicken file.

> > You should also check you price history file for zero prices; and you

> > should consider renaming your price history file, and recreating the pr=

ice

> > history. =A0[Your Quicken price history file is named QDATA.QPH, where =

QDATA

> > is the name of your Quicken data.] =A0There are multiple ways to recrea=

> > your price history, though none are guaranteed to get every historical

> > price back.

> > --

> > John Pollard- Hide quoted text -

> > - Show quoted text -

> I've already done everything you mention except create a new QPH file

> and recalculate the registers. I don't see the need for that since a)

> the registers are accurate (though how they can be with a 0 total

> amount in the ADD transaction) =A0B) the prices in the history file are

> fine, with no 0 values; If they had 0 values I doubt that they would

> calculate total value correctly in the Portfolio view of the original

> account the day of the transfer. I still have that account defined in

> Quicken and can move back and forth in date to see things before and

> after the transfer and everything calculates as it should until it

> reaches the receiving account. =A0 =A0All lots of holdings transfer

> individually and all have the same problem if they are not stocks.

> This is so strange. =A0I'm going to create a simple test file with just

> two accounts and a couple of assets and see if it still happens. =A0I

> know this happened the last time I merged accounts but I can't

> remember the solution.

> jo- Hide quoted text -

> - Show quoted text -

John, I did make a test file as I mentioned and everything worked as
you reported (correctly). I have no evidence of corruption in my
regular file and actually don't think this smacks of corruption (other
things would be going haywire), but something is obviously effecting
my transfers. I also did the CTRl-Z you suggested, with no changes.

I'm going to continue to experiment with things to see if I can come
up with a combination that either reproduces it in the test file or
works properly in my original.

jo

Posted by No One You Know on April 27, 2009, 3:35 pm

Please log in for more thread options

jo wrote:

> John, I did make a test file as I mentioned and everything worked as

> you reported (correctly). I have no evidence of corruption in my

> regular file and actually don't think this smacks of corruption (other

> things would be going haywire), but something is obviously effecting

> my transfers. I also did the CTRl-Z you suggested, with no changes.

> I'm going to continue to experiment with things to see if I can come

> up with a combination that either reproduces it in the test file or

> works properly in my original.

You might check to see if any of the securities in the old account had
placeholders.

[Also, the price history file can appear to be ok even when it has some
corruption that interferes with other activities. Renaming .QPH,
downloading historical prices for the new .QPH, and retrying the transfer
should be a fairly simple process. Backup first, so you can revert back
it things don't improve.]

--

John Pollard

Posted by Andrew on April 27, 2009, 8:02 pm

Please log in for more thread options

No One You Know wrote: ...

"No One You Know"?? We all know John (!).

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

- Andrew