Map f1_elc_op_mnt_expn table

[aesharpe]

This one was harder to map because the row_literal values differed more year to year than the other tables. But it wasn't too crazy.

Noteworthy things:

• A blank row_literal for row 84 that I labeled as row_type=header

• One dbf_only=True where row_literal was (561) Load Dispatching in 1994 and was broken into (561.1) Load Dispatch-Reliability, (561.2), Load Dispatch-Monitor and Operate Transmission System, and (561.2) Load Dispatch-Monitor and Operate Transmission System in later years of dbf and in xbrl.

• A couple very close calls with naming. Ex: the transmission overhead line expense row literal maps to overhead_line_expense and the distribution overhead line expense row literal maps to overhead_line_expenses. Oye.

• Some unmapped xbrl_factoid rows pertaining to energy storage. Seems like they are so new they aren't even in the 2022 FERC Form 1 PDF?:

  • maintenance_of_energy_storage_equipment
  • maintenance_of_energy_storage_equipment_other_power_generation
  • maintenance_of_energy_storage_equipment_transmission
  • operation_of_energy_storage_equipment
  • operation_of_energy_storage_equipment_distribution
  • operation_of_energy_storage_equipment_transmission_expense
  • power_purchased_for_storage_operations

Here's a snapshot of the 2022 FERC Form 1 PDF with no mention of the maintenance_of_energy_storage_equipment_transmission field. In the xbrl taxonomy it is labeled: 570.1 Maintenance of Energy Storage Equipment.

How should I deal with these unmapped xbrl factoids?

[codecov]

Codecov Report

Base: 85.4% // Head: 85.4% // No change to project coverage 👍

Coverage data is based on head (51187cd) compared to base (d1d417b).
Patch has no changes to coverable lines.

Additional details and impacted files

@@          Coverage Diff          @@
##             dev   #2114   +/-   ##
=====================================
  Coverage   85.4%   85.4%           
=====================================
  Files         72      72           
  Lines       8336    8336           
=====================================
  Hits        7119    7119           
  Misses      1217    1217           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[zaneselvans]

I made a couple of small tweaks to the mapping, which you can check out in the file diffs.

All of the dbf_only = TRUE rows need to have an xbrl_factoid value created for them -- a reasonable placeholder that can play the same role as the xbrl_factoids do in aligning the old DBF row numbers with each other when they have changed. Any row that does not have an xbrl_factoid value (e.g. the header rows) will be dropped from the DBF data, which isn't what we want to have happen, this applies to the old row 84 which was associated with FERC Account 561.

There's something kind of weird going on with row 84 from 2006 (when it first gets broken out into a bunch of sub-accounts, 561.1, 561.2, 561.3, etc.) and 2012, when row 84 becomes blank. It seems like from 2006-2012 they may have been rporting both 561 and all of the sub accounts, so I'm not sure if those dollars are getting reported more than once. I added a note about this. It's not a mapping issue (except that we needed a factoid for the old row 84). Just something to keep track of in the transforms, for whoever does that.

On the brand-new energy storage accounts, it looks like they updated the FERC Form 1 in March of 2022, with a new version that is supposedly valid through 2025, and now instead of distributing a PDF, it's a zipfile filled with HTML versions of all the forms, so I guess I'll do some "save as PDF" and add the new versions to our documentation archive. The new Form 1 seems to include the storage accounts.

Because those storage accounts only ever appear in the XBRL, they do not need to be included in the DBF-to-XBRL mapping.

[aesharpe]

All of the dbf_only = TRUE rows need to have an xbrl_factoid value created for them -- a reasonable placeholder that can play the same role as the xbrl_factoids do in aligning the old DBF row numbers with each other when they have changed. Any row that does not have an xbrl_factoid value (e.g. the header rows) will be dropped from the DBF data, which isn't what we want to have happen, this applies to the old row 84 which was associated with FERC Account 561.

Thanks, I think I just forgot to do it here

[zaneselvans]

I moved this record to where it should be in the ordered table. Not sure why it showed up here.

[zaneselvans]

Looked like this was miscategorized.

[zaneselvans]

Tried to come up with a reasonable category name here.