"earnings per share" not being updated (Fidelity data)
Author: superticker
Creation Date: 6/1/2019 4:05 PM
profile picture

superticker

#1
Updates for "earning per share" are not showing up in the Data Manager logs for the Fidelity static provider. It's my understanding everyone else is getting them, so my system is at fault somehow. All other static updates, like "estimated earnings updated" are working fine. On-demand updates are working fine.

I seriously doubt the problem is in the *.WLF files because I'm adding new symbols in the WL datasets constantly, so new *.WLF files are always being added. But nothing about "earnings per share" for any stock is showing up in the Data Manager log. The log doesn't even show that the "earning per share" provider is even attempting to update.

I have Data Manager check boxes for [1] Fidelity Investments, [2] Equity Summary Scores, [3] Fidelity Estimated Earnings Data for Securities, and [4] Fidelity Fundamental Data for Securities all checked. I have tried toggling these check marks on and off restarting WL between. That didn't help.

Is the problem in the WL *.config file? If so, which item in there needs adjusting?
profile picture

Eugene

#2
Hi Mark,

I recall you had an EPS issue last month:

FundamentalDataSeries("earnings per share",...) throws FormatException

Apparently it's either incorrect FundamentalDataSeries aggregation and/or "corrupt" Fidelity data. It's an interesting observation that on demand data update is working fine. I'll add this to the already existing bug report.

As long as [4] is checked I doubt that there's a WL config issue.

QUOTE:
The log doesn't even show that the "earning per share" provider is even attempting to update.

Hmm, what I'd try is delete the cache folder for the fundamental provider in question and retry update:

C:\Users\Windows username\AppData\Roaming\Fidelity Investments\WealthLabPro\1.0.0.0\Data\..
profile picture

superticker

#3
QUOTE:
As long as [4] is checked I doubt that there's a WL config issue.
It's checked, but I'm not sure that's even required. If I remember right ... I "think," when I first started using WL, I never had [4] checked, but I still got "earnings per share" updated in the Data Manager log. There was a period of several months ago when I had it unchecked. But it's been checked for the last two months. Do you think unchecking it started this problem?

QUOTE:
I'll add this to the already existing bug report.
But I think this problem is unique to me. Are you suggesting my action of unchecking [4] Fidelity Fundamental Data for Securities for several months, then re-checking it for two months created this problem? Is that the bug that's being reported? I was kind of thinking something isn't getting reset in the *.config file when the check box gets re-checked.

So what in the *.config file gets changed when [4] Fidelity Fundamental Data for Securities gets re-checked?

QUOTE:
... I'd try is delete the cache folder for the fundamental provider in question and retry update
But new stocks, which don't have any existing *.WLF files cached are getting added all the time. If it was the *.WLF files, then all the new stocks would be working since [4] was re-checked.

I'm not convinced we know what the real problem is yet.

It's my understanding the only fundamentals that get saved to disk are earnings-per-share and estimated earnings. All others are simply saved in volatile RAM memory but not stored on disk. Is this correct?
profile picture

Eugene

#4
QUOTE:
But new stocks, which don't have any existing *.WLF files cached are getting added all the time.

By virtue of on demand data update enabled, I guess.

QUOTE:
Do you think unchecking it started this problem?

I think that "earnings per share" is part of what's offered by "[4] Fidelity Fundamental Data for Securities".
profile picture

superticker

#5
QUOTE:
I think that "earnings per share" is part of what's offered by "[4] Fidelity Fundamental Data for Securities".
In that case, then the "bug" is once you turn [4] off, it's not possible to turn it back on again by re-checking the box with on-demand updates enabled. Report that as the problem.

I'm wondering why that is a problem? The check box "stays checked" once I re-check it, so it's getting registered okay. There must be an internal state that's not getting re-enabled after the box gets re-checked. The developer should eliminate that "redundant" internal state.

For a moment, I was thinking on-demand updates might be interfering with it. But I only visit 15% of my stocks in my datasets each day, so 85% of them should be getting static updates, which is not happening.

What's the difference between the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider directories? Which directory has the earnings-per-share data? Look at the Modified Date stamp and file sizes in the attachment and see if anything doesn't look right to you.
profile picture

Eugene

#6
QUOTE:
What's the difference between the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider directories? Which directory has the earnings-per-share data?

"WSOD" stands for Wall Street On Demand. I guess that FidelityWSOD* delivers the majority of fundamental data items except ESS and split/dividend. My understanding is that FidelityFMDFundamentalProvider is the provider for the split/dividend data. Being irregular (split) and quarterly (dividend) data they don't consume much space. So the file size ranging from 1KB to 9KB does not appear to be an issue. Neither are some timestamps in the past for e.g. OA, OAPH, OEUH because those symbols ceased trading.

QUOTE:
In that case, then the "bug" is once you turn [4] off, it's not possible to turn it back on again by re-checking the box with on-demand updates enabled. Report that as the problem.

Honestly I don't think it's the problem. Nonetheless you can try a "fresh start" to verify:

1. Shut down WLP
2. Rename the WealthLabPro folder at: C:\Users\Windows username\AppData\Roaming\Fidelity Investments\WealthLabPro\ to something like WealthLabProX
3. Start WLP, check all the Fidelity fundamental data providers and run "Update All Data"

If it works well, I'd revert to the WealthLabProX backup with a few omissions: without WealthLabConfig.txt and the Fidelity fundamental data folders.
profile picture

superticker

#7
QUOTE:
some [*.WLF] timestamps in the past [very old] for e.g. OA, OAPH, OEUH because those symbols ceased trading.
So you're saying when you press the Delete Symbols button on the Fidelity Data tab of Data Manager, it only deletes those symbols in the datasets, but it does not delete any of the cached data (like *.WLF files) on disk. I didn't know that. It would be nice if it did. (Not a high priority fix, though.)

QUOTE:
If it works well, I'd revert to the WealthLabProX backup ... without WealthLabConfig.txt and the Fidelity fundamental data folders.
I'm assuming you mean without the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider folders, but keep all the others.

I did discover the "devenv.exe /diff" utility in Visual Studio so I can compare WealthLabConfig.txt.new with WealthLabConfig.txt.old. I would like to get to the bottom of this problem if you're willing to fix it. There are times when the WL application ABENDs when it asks you to refresh your password and you don't do it in time. I know files like WealthLabConfig.txt don't get closed properly when that happens. If you could fix that password-refreshing ABEND problem, that may fix many other things. Any ABENDing problem is a high priority fix.

You could also write-through all changes--immediately--to disk of the WealthLabConfig.txt file (i.e. write-through caching). Then it won't be sensitive to ABENDs. But fixing all the ABEND causes would be the preferred solution.
profile picture

Eugene

#8
QUOTE:
So you're saying when you press the Delete Symbols button on the Fidelity Data tab of Data Manager, it only deletes those symbols in the datasets, but it does not delete any of the cached data (like *.WLF files) on disk.

WLP/D does not delete the cached data by design.

QUOTE:
I'm assuming you mean without the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider folders, but keep all the others.

Right, that's what I'm saying.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).