Cost basis missing after transfer to new acct

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

jo

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? My Add transaction has 0 Total Cost and that's because there is a 0 in the Price Paid field. ( 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. 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.

jo

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

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.

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.

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.

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

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

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

No One You Know wrote: ...

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

No place holders that I could find. I haven't yet experimented with Qph, because i'm not convinced that's where the problem lies. There is another thing that I noticed, and perhaps you know the answer. In my Portfolio view of the original account, I display the year to date income for each security in one of the columns. When I transfer that security to the new account, the income is no longer reflected. it is 0. This occurs in both my true file and the test file.... income history does not follow with the security. The only thing I can think of is that Quicken thinks you only want to see the income of the security as earned in its current account... kinda strange assumption if that is what is happening. Can you verify?

Since I've had so much difficulty with this and really need to get my records straight, I'm working around this by removing all records of the transfer, and first trying transferring in the reverse direction. Since there are way fewer holdings to fix up if I have to, it won't be as burdensome to correct. If things transfer correctly in that direction, I'll give the smaller account a dummy account number and name, and rename the larger, composite one to what it really is now. Basically flip the definitions of the accounts. And if it doesn't transfer in that direction either (I don't expect it to), the smaller account has a manageable # of transactions that I will simply manually enter them into the real account as if they were originally made there.

Yesterday, after an online update, I got a bunch of messages from Quicken that my holdings in the account to which I transferred everything do did not match my Quicken holdings in several positions. Everything in Quicken matched my brokerage statements and the onine account positions, but Quicken insisted that I was missing a few small purchases of shares that came in through dividend reinvestment and one stock dividend. Having not touched either of these holdings for years, and never having a complaint about them in a Compare Holdings process before, I have no clue as to why, only after doing the transfer, i got discrepancies. I think it was at that point that i started deleting the REmove and Add security transactions. I don't have time to debug Quicken. and if it's not a bug, it's a very obscure set of circumstances that is not documented.

jo

Assuming I'm fully understanding what your seeing, it seems to me it can't be any other way.

The Portfolio tab is a snapshot, "As of" the date selected.

If you have elected to have the Portfolio tab "Group by" Account, Quicken can't show you what is not in that account. You wouldn't want Quicken to show you the income you earned in the old account for a security that you don't even own in that old account on the "As of" date, right"? Likewise, how/why would Quicken transfer the income earned by a security in the old account to the new account, when it was not earned in that account?

If you want to see the total income for a given security (without regard to which account it was earned in), elect to "Group" the Portfolio tab by Security. When I do this, I see the same total income for a security the day before I transfer holdings and the day after I transfer those holdings.

Ok, I get the reasoning. I do have group by account in Portfolio. My thinking is I'd rather have the income follow the security, not the account that it is in. I'll have to see what the Group by Security view looks like. Don't remember why I set it up this way.

jo