For the stocks S and IMGN, the line ...

CODE:
Please log in to see this code.

throws the FormatException: "Input string was not in a correct format"

Yes, it only happens with these two stocks. Yes, I tried reloading Chart history. No, the earnings per share for them isn't set to "infinity" or something weird like that for these two stocks. Yes, the FundamentalDataSeries call seems to work for all other stocks.

I'm using the following Catch routine below to handle it in my code library.

CODE:
Please log in to see this code.

"Reload chart history" might not help refresh the fundamental data. In the first place, try updating the fundamental provider (Update All Data). If that doesn't help try this:

1. Navigate here: c:\Users\username\AppData\Roaming\Fidelity Investments\WealthLabPro\1.0.0.0\Data\..
2. Find the fundamental provider's folder (there's more than one with Fidelity)
3. Open the subfolders S and I and delete the respective .WLF files for the instrument
4. Update the fundamental data

If still no go this looks like a glitch in the fundamental data itself on Fidelity's end. In this case you might want to contact them as there isn't much we can do.

I tried deleting all the .WLF files for S and IMGN, then Updating All Data this morning. That didn't help. In the attachment, I've included a screenshot of both stocks with the earnings per share showing. I don't see anything irregular about the earns values. Do you? As I said in the initial post, I think all their EPS values are fine. There are many days where their EPS values are negative, but many stocks have that problem.

I think the problem is with the FundamentalDataSeries("earnings per share",...) itself. Why on earth would it be trying to parse a string into Int32 in the first place when all the earnings data should be in double floating point to begin with? I don't think the format conversion (parsing) problem has anything to do with the actual earnings values themselves. And I don't think the guys at Fidelity know anything about the WL code.

---
On an unrelated note, the Data Manager static log hasn't shown any "earning per share" updates for two or so months for any stock. I have a call into Fidelity to investigate that (And they verified the static EPS update problem at their end.), but I haven't heard back. However, I've only been waiting a week. Apparently, they have to email someone to get an answer on why the earnings-per-share static server is down. My point is that all earnings per share numbers are from on-demand services, not the static provider. But that doesn't seem to affect WL operations as shown by the screenshots for any stock.

Interesting - I have data on "earnings per share" as recent as 5/6/2019 for the eleven stocks below. It checks for out of date fundamentals. This was run on my SP500. It is showing one overdue symbol, VFC(and the Fidelity website shows VFC earnings date of 1/18)...

CODE:
Please log in to see this code.

It picks up fundamental data like this...

CODE:
Please log in to see this code.

QUOTE:
I have data on "earnings per share" as recent as 5/6/2019

That's interesting. Let's compare Data Manager settings. Mine are in the screenshot. The Fidelity consultant also had the Yahoo provider checked. (I don't use Yahoo, only Fidelity.)

Can you get the FundamentalDataSeries("earnings per share", 4, 0) call to work on S and IMGN?

Data Manager settings are pretty close...

@superticker

I run your code on S and IMGN against the data by Zacks Adjusted EPS, Morningstar and StockPup fundamental providers:

CODE:
Please log in to see this code.

Works just fine. In no case a FormatException is thrown. Could you zip (.WLF isn't a supported file extension) and attach your Fidelity files please?

April 2020: StockPup fundamental provider decommissioned, feed taken offline.

suoerticker - I don't currently track S or IMGN and don't want to do a DM run off schedule. I'll have the data tomorrow and can try it.
(edit)If you want to post an illustrative script, we can compare apples to apples (and it will save me some work)

QUOTE:
Could you zip and attach your Fidelity files please?

The data files have been zipped along with a screenshot (spliced together) of the actual error message WL throws.

If you can't reproduce the problem in Post# 7, that suggests to me we are looking in the wrong place somehow. I don't think it's a data source issue. But then, what's left? And why does it only affect these two stocks?

The error message states the FundamentalDataSeries function is failing the parse a string into Int32. But do you think that's what's really happening? There's no reason this function should be doing that in the first place. This isn't right.

Thanks. I do not have access to the Fidelity data but as a workaround I just built a dummy fundamental provider to read "earnings per share" from your WLF files. The exception message is thrown as long as the aggregate parameter of FundamentalDataSeries is > 1.

I'm going to file a bug report. It should be easy to reproduce given that we have the evidence.

QUOTE:
The exception message is thrown as long as the aggregate parameter of FundamentalDataSeries is > 1.

Interesting. I'm not sure what that has to do with parsing strings to Int32. I always use 4 quarters so I get a trailing twelve months (TTM) of the stock earnings to cancel out any seasonal effects.

I'm a little confused why this problem occurs with only two stocks and not others? Not so easy to reproduce without the right WLF files. And I doubt my Fidelity WLF files are that different from other providers. But it will be interesting to see if LenMoz can reproduce the problem with his Fidelity WLF files since you seem to suggest this problem is earnings data dependent somehow. Weird.

Thanks very much for helping and getting to the bottom of it. My Catch routine seems to handle the FormatException okay.

Just to confirm, S and IMGN raise the format exception for me, too. And I found MNK, PRGO, and VFC similarly fail.
Here's a simple test script...

CODE:
Please log in to see this code.

QUOTE:
Just to confirm, S and IMGN raise the format exception for me, too.

I was wondering if the problem was that I was using on-demand data (since my static provider isn't working) and everyone else is using a static provider. But I see, since others are having problems, that the data source isn't the problem.

Yes, I knew there were a few other stocks having problems, but I couldn't remember which ones they were. What's weird is that my code library has been using this fundamental function for two years and I haven't really noticed problems until now.

Thank you both for getting to the bottom of this weird behavior.

It's hardly about the way the data is obtained (on demand vs. DataSet update). Supposedly this is a bug with aggregation inside FundamentalDataSeries. Hence it appears when > 1 on certain data points only. We'll add it to the bug list.