Gain/Loss 1-Month: maybe a bug?

QWThomas

On a single security that split 10/1 in the past month, the Gain/Loss 1-Month column in Portfolio View has gone wildly wrong. On 5/30 there were 100 shares @ 588.14; on 6/30 there were 1000 shares @ 77.36. My computed 30-day Gain is $18546; the Portfolio View computed gain is $71468.60. I looked at the Price History, and it looks correct, as does the StckSplit transaction. Both Security Detail View charts look correct, and all other securities over an extended period of time have been spot-on. Data damage maybe, or a programming error in handling a Stock Split? Any thoughts?

Sherlock

What was the date of the split and the price of the security on 5/31 and on 6/1?

Note: 5/30 to 6/30 is 31-days.

q_lurker

I checked 30 day and 1 yr G/L values for one stock split (AAPL 4:1 in August 2020).  Quicken's numbers come out exactly as I calculate manually.  

Did the Stock Split go in as a StkSplt transaction?  You might try a delete and re-enter.

Your Quicken value suggests 77360 - 5891.2 = 71468.60.  That 5891.2 is awfully close to 10 x your 588.14 rather than 100 x .  Could there be another factor of 10 hiding somewhere?

Your price history data should be the $588 range up to the split then 1/10 of that building up to the current 77.36 value.  That is what you are seeing?  No improper bumps or other adjustments?

Both Security Detail View charts look correct ... 

I assume Both means price and market value.  The price chart adjusts rationally when you check/uncheck the "Split Adjust" box?   

QWThomas

Thank you, Sherlock and q_lurker, for your thoughts and suggestions. They were very helpful! Deleting the StockSplit transaction did not rationalize the G/L value. I tried backdating the Portfolio View to see when G/L went wrong, and the date was 6/17- on which I had no entered transactions. Copied file to check for general data problem- still no joy. Restored a backup from 6/10 and downloaded updates. Ignored auto-entry of split, and manually entered it. Result: same as original file. But when I looked at the Price History, I noticed that the split price change with the new download occurred on 6/17 rather than 6/11. When I changed the split date, the G/L value corrected. Went back to my original file, and did the same thing- with the same result: the correct value. A couple take-aways: one, the downloaded prices from the server were incorrect for several days; two, somewhere in Price History there's a data point holding split information. With the incorrect split date (6/11) and an automatic split data point in Price History, the split was being done twice. That was indeed the factor of 10. Once again, thanks for the help!

q_lurker

IMO, there are a couple of ongoing challenges with respect to downloaded prices on or around a stock split.  

 two, somewhere in Price History there's a data point holding split information.

First, you are right.  There is (can be) a hidden record with the price history records about a stock split occurring.  That record allows for the price history to be adjusted even if you don't own shares at that time and thus don't have a StkSplit transaction in your accounts.  The challenge there is that record might not be dated the same as a StkSplit transaction that you do have in your account transactions.  I suspect the date differences somehow correspond to trade vs settlement dates.  To resolve that contradiction, I find it necessary to determine the date for that hidden record (using the split adjust box on the Security Detail price graph), redate my StkSplit transaction to that date, then return the StkSplit transaction to the proper date. 

one, the downloaded prices from the server were incorrect for several days; 

This can develop from several forms, I believe.  In one, I frequently see 'Historical' prices come in as split-adjusted.  Those are the prices that can be backfilled in for a 30-day period, or 1-Year, 2-Year, 5-year periods.  If prices after a 2:1 split are in the $50 range and before the split were in the $100 range (real time, real world), the historical prices will download at 1/2 their true trading values for before the split (all adjusted into the $50 range).  If you already had the true trading prices in place, no harm, no foul; the historical values are not used.  But if you did not have those true trading values in place, the prices are effectively wrong for Quicken's application.  That may also occur for the 5-day data that comes from the "daily" source.  In essence, I also see times when I need to correct downloaded prices to reflect the correct real-world, real-time prices.  
   
 

QWThomas

Yes, in retrospect, I see that the issue for me was inferring the split date from the daily Price History. Using that date, my graphs and values all looked good. But, of course, when I downloaded the same prices yesterday, they had been corrected! Interesting, too, that the split information carried in Price History only seems to affect Gain/Loss calculations- and not Shares Held. That would have exposed the issue and the functionality on the first go-round. Maybe next time I'll let the program put the split transaction in automatically- and then adjust the prices so they graph correctly.