Expected Behavior
EarningReports.AccessionNumber / FinancialStatements.AccessionNumber should report HasValue == true (and Value should resolve without falling back) whenever Morningstar supplies an EDGAR accession number for the filing, the same way the sibling filing-metadata fields FileDate, FormType, PeriodType and PeriodEndingDate do.
Actual Behavior
Both generated AccessionNumber classes use DefaultPeriod => "OneMonth":
Common/Data/Fundamental/Generated/EarningReportsAccessionNumber.cs:34
Common/Data/Fundamental/Generated/FinancialStatementsAccessionNumber.cs:34
while every other filing-metadata field in the same classes defaults to ThreeMonths (EarningReportsFileDate.cs:34, EarningReportsFormType.cs:34, EarningReportsPeriodType.cs:34, FinancialStatementsFileDate.cs:34, FinancialStatementsPeriodEndingDate.cs:34).
Morningstar never populates the 1M slot of the accession number, so:
HasValue (which only checks EarningReports_AccessionNumber_OneMonth, line 69) is false on every row;
Value (line 74) misses the default and only returns a result through the MultiPeriodField.Value fallback (first populated period);
- the
ThreeMonths slot carries the accession number on the large majority of rows (and Value does resolve to it through the fallback, so Value and HasValue disagree on every populated row).
A related gap: the two AccessionNumber fields have only 1M/2M/3M/6M/9M periods, while FileDate, FormType, PeriodType and PeriodEndingDate also have a TwelveMonths period, so the accession number of an annual report (10-K) is never exposed even though its file date and period end are.
Measured with History<Fundamental> over 2005-01-01..2024-01-01 in a cloud backtest (LEAN v2.5.0.0.18057):
| ticker |
rows |
AccessionNumber.HasValue |
AccessionNumber.Value non-empty |
AccessionNumber.ThreeMonths non-empty |
FormType.HasValue |
| AAPL |
4781 |
0 |
4781 |
4781 |
4781 |
| XOM |
4781 |
0 |
3690 |
3690 |
3690 |
| IBM |
4781 |
0 |
n/a |
4703 |
4703 |
Users who guard on has_value (the documented idiom for multi-period fields) conclude the accession number is missing from the dataset.
Potential Solution
The generator that emits Common/Data/Fundamental/Generated/* should pick ThreeMonths as the default period for the two AccessionNumber fields, matching the other filing-metadata fields (or, more generally, derive the default from the periods the data dictionary actually populates). Alternatively HasValue could be defined as HasValues() for fields whose default period is never populated.
Reproduction
class AccessionProbe(QCAlgorithm):
def initialize(self):
self.set_start_date(2024, 1, 2)
self.set_end_date(2024, 1, 3)
self.add_equity("SPY", Resolution.DAILY)
def on_data(self, data):
sym = Symbol.create("AAPL", SecurityType.EQUITY, Market.USA)
rows = list(self.history[Fundamental](sym, datetime(2005, 1, 1), datetime(2024, 1, 1)))
self.log(f"has_value={sum(r.earning_reports.accession_number.has_value for r in rows)} "
f"three_months={sum(bool(r.earning_reports.accession_number.three_months) for r in rows)} rows={len(rows)}")
Output: has_value=0 three_months=4781 rows=4781.
Support reference: Intercom conversation 215475820156709.
Expected Behavior
EarningReports.AccessionNumber/FinancialStatements.AccessionNumbershould reportHasValue == true(andValueshould resolve without falling back) whenever Morningstar supplies an EDGAR accession number for the filing, the same way the sibling filing-metadata fieldsFileDate,FormType,PeriodTypeandPeriodEndingDatedo.Actual Behavior
Both generated
AccessionNumberclasses useDefaultPeriod => "OneMonth":Common/Data/Fundamental/Generated/EarningReportsAccessionNumber.cs:34Common/Data/Fundamental/Generated/FinancialStatementsAccessionNumber.cs:34while every other filing-metadata field in the same classes defaults to
ThreeMonths(EarningReportsFileDate.cs:34,EarningReportsFormType.cs:34,EarningReportsPeriodType.cs:34,FinancialStatementsFileDate.cs:34,FinancialStatementsPeriodEndingDate.cs:34).Morningstar never populates the 1M slot of the accession number, so:
HasValue(which only checksEarningReports_AccessionNumber_OneMonth, line 69) isfalseon every row;Value(line 74) misses the default and only returns a result through theMultiPeriodField.Valuefallback (first populated period);ThreeMonthsslot carries the accession number on the large majority of rows (andValuedoes resolve to it through the fallback, soValueandHasValuedisagree on every populated row).A related gap: the two
AccessionNumberfields have only 1M/2M/3M/6M/9M periods, whileFileDate,FormType,PeriodTypeandPeriodEndingDatealso have aTwelveMonthsperiod, so the accession number of an annual report (10-K) is never exposed even though its file date and period end are.Measured with
History<Fundamental>over 2005-01-01..2024-01-01 in a cloud backtest (LEAN v2.5.0.0.18057):AccessionNumber.HasValueAccessionNumber.Valuenon-emptyAccessionNumber.ThreeMonthsnon-emptyFormType.HasValueUsers who guard on
has_value(the documented idiom for multi-period fields) conclude the accession number is missing from the dataset.Potential Solution
The generator that emits
Common/Data/Fundamental/Generated/*should pickThreeMonthsas the default period for the twoAccessionNumberfields, matching the other filing-metadata fields (or, more generally, derive the default from the periods the data dictionary actually populates). AlternativelyHasValuecould be defined asHasValues()for fields whose default period is never populated.Reproduction
Output:
has_value=0 three_months=4781 rows=4781.Support reference: Intercom conversation 215475820156709.