Source: https://www.federalregister.gov/documents/2001/12/28/01-32005/revised-public-utility-filing-requirements
Timestamp: 2018-07-18 03:41:22
Document Index: 728094956

Matched Legal Cases: ['§\u200935', 'art 35', 'art 35', '§\u2009205', 'art 35', '§\u200935', 'art, 121']

Federal Register :: Revised Public Utility Filing Requirements
Revised Public Utility Filing Requirements
A Proposed Rule by the Federal Energy Regulatory Commission on 12/28/2001
Written comments must be received by the Commission by January 28, 2002.
66 FR 67134
67134-67151 (18 pages)
Docket No. RM01-8-000
01-32005
Order Seeking Comments on Proposed Data Sets
A. Suggestion To Postpone Action on Proposed Rulemaking Pending Completion of Comprehensive Review of Market Monitoring Information
B. Proposed Data Sets
D. Additional Discussion on Data Elements
1. Company Identification Data Elements
2. “Contract_service_agreement_id”
3. “Contract commencement _dt” and “begin_ date”
4. “Contract termination_dt,” “cancellation of_contract,” “actual_termination_ dt,” and “end_date”
5. “Rate,” “rate_min,” “rate_max,” and “rate_desc.”
a. Contractual Rate Data
b. Transaction Rate Data
6. “Product_name,” “product_type_ name,” “product_sub type_name,” “increment_name,” “increment_peaking_ name” and “term_name”
7. “{Registered}”
8. “Ferc designation”
9. Identifying Nonconforming Contracts
E. Electronic Format
III. Public Comment Procedure
https://www.federalregister.gov/d/01-32005 https://www.federalregister.gov/d/01-32005
Start Preamble Issued December 20, 2001.
Federal Energy Regulatory Commission (Commission), DOE.
Order seeking comments on proposed data sets.
As contemplated in the notice of proposed rulemaking issued by the Federal Energy Regulatory Commission (Commission) earlier in this proceeding, Revised Public Utility Filing Requirements, (66 FR 40929), FERC Stats. & Regs. ¶ 32,554 (2001) (NOPR), this order invites comment on a proposed set of uniform data elements for public utilities' quarterly electronic filings that would accompany the final rule. Uniform data sets are necessary to ensure that the requested data is reported in a consistent, informative manner by all reporting public utilities.
H. Keith Pierce (Technical Information), Office of Markets, Tariffs, and Rates, Federal Energy Regulatory Commission, 888 First Street, NE., Washington, DC 20426, (202) 208-0525
Barbara D. Bourque (Information Technology Information), Office of Markets, Tariffs, and Rates, Federal Energy Regulatory Commission, 888 First Street, NE., Washington, DC 20426, (202) 208-2338
Gary D. Cohen (Legal Information), Office of the General Counsel, Federal Energy Regulatory Commission, 888 First Street, NE., Washington, DC 20426 (202) 208-0321
Issued December 20, 2001.
On July 26, 2001, the Commission issued a notice of proposed rulemaking in this proceeding, Revised Public Utility Filing Requirements, 66 FR 40929, FERC Stats. & Regs. ¶ 32,554 (2001) (NOPR), proposing to revise the Commission's filing requirements for public utilities. The Commission is currently engaged in reviewing the comments filed in response to the NOPR.
Among other matters, the NOPR stated that “[l]ater in this rulemaking process, we plan to conduct further proceedings to develop the instruction manual to be used to make Index of Customer filings, which will define the data elements to be included in Index of Customers filings.” Uniform data sets are necessary to ensure that required data are reported in a consistent, informative manner by all reporting public utilities.
As explained in the NOPR, the Commission is considering requiring public utilities to make quarterly electronic filings when we issue a final rule in this proceeding. As explained in the text of proposed § 35.10b, the filing requirements would pertain to every jurisdictional electric service, under part 35 of the Commission's regulations, 18 CFR Part 35, that was effective some time during the reporting quarter. In this order, we invite comment on a proposed set of uniform data elements for public utilities' quarterly electronic filings that would accompany the final rule.
As explained above, we are currently engaged in reviewing the comments filed in response to the NOPR and, with one exception, will not address those comments here. The exception is the issue raised in some comments to the NOPR that the Commission should postpone action on the proposals in the NOPR pending completion of the Commission's comprehensive review of the information needed by the Commission for market monitoring purposes.
This argument maintains that, if the Commission's comprehensive review of market monitoring information concludes that the transactional data proposed in the NOPR to be reported in Index of Customers filings are later found to be unnecessary, then issuance of a final rule requiring the electronic filing of that information (and posting of that information on a website) would result in public utilities incurring unnecessary expenses to establish procedures to collect and report these data. The same commenters also argue that it would be wasteful to force public utilities to design and implement procedures to report transactional data for market monitoring purposes, merely to have those reporting requirements withdrawn, once the Commission completes its review of needed market monitoring information.
We find these arguments without merit because, although the Commission has not completed its comprehensive review of market monitoring data, we believe that the information proposed to be reported would be the minimum needed for market monitoring purposes, even if we later determine that additional data also will be necessary. Moreover, as we noted in the NOPR, we Start Printed Page 67135believe that the proposed reporting requirements would improve the quality of information reported to the Commission by prescribing that public utilities report information in a consistent, accessible format.
Attached to this order are tables specifying proposed data elements that identify (with greater detail than provided in the NOPR) the information to be reported in Index of Customers filings. The Index of Customers is intended to electronically collect data on all jurisdictional contracts, including, among other matters, data concerning service agreements, bilateral contracts, rate schedules, and interconnection agreements. As such, many different types of jurisdictional services must be accommodated by the data elements. Depending on the service(s) offered by a particular public utility, it may have to submit data for only a certain subset of the data elements identified in the Appendices. The data elements are organized to show what data are required for various types of services.
To aid in identifying the data elements, we have included definitions (in many cases, with examples). We have also identified whether the data elements are to be filed as file identification information, contract data, and/or transactional data. For the sake of clarity, certain data elements that will be system-generated have been omitted from these tables. Some data elements will appear in more than one section; others will be unique to a section. For instance, the “company_name” data element will be used to identify the respondent, filing agent, buyer, or seller, depending on where it is entered into the system.
We received several comments concerned with the appropriate time increment for reporting pricing data for transactions (i.e., whether the pricing data should be reported in hourly or even shorter increments). We are proposing that, if a price changes during a day, then respondents should submit high, low, and (weighted) average prices on a daily basis for those transactions that are shorter than a day. If prices remain unchanged for two days or more, they may be reported as a single datum entry. We invite comments from a computer systems perspective about whether filing pricing data this way would be less burdensome than submitting pricing data for each period of time a unique price is charged (i.e., if a power sale involved five price changes in an hour, it would be filed as five transactions for that hour).
It is our desire to collect Index of Customer information in the least burdensome way. We have tried to follow OASIS standards wherever possible to minimize the introduction of new data elements or formats. If commenters see a way for the proposed data sets to match up better with the OASIS Standards and Communication Protocols Document, version 1.4 (OASIS S&CP Document), they should address this in their comments.
In the attached tables, there are a number of field definitions that include the term {registered} in the list of valid entries. This means that we will allow other terms to be entered into the field, but only after they have been approved by the Commission and entered into the validation tables for that field. The reason for this is to ensure data integrity. If we allowed free form text in these fields, it would hinder our ability to perform meaningful searches of the data because companies do not always use the same name for the same item, or there may be misspellings. We invite respondents to submit other proposed entries for these fields either as part of this NOPR process or at any time in the future.
The first table (Appendix A) is an overview of the types of data we propose to collect, identifying the sections of the data collection: filer identification, contract data, and transaction data. The first three columns indicate which data elements pertain to each section. File Identification Information, designated by an F in the first column, provides information about the identity of the filer and the party on whose behalf the filing is being made (if different). The data must be filed by every public utility filing an Index of Customers report. Contract Data, identified by a C in the second column, include the contract data elements that every public utility filing an Index of Customers must provide to describe its contracts.
Every jurisdictional service that was effective some time during reporting quarter must be included on the Index of Customers. This includes services for which service agreements have already been filed with and approved by the Commission, services for which service agreements conform with filed and approved standard forms of service agreements, rate schedules, and unique services such as individually negotiated bilateral agreements. Transactional Data, shown by a T in the third column of Appendices A and B, identifies the transactional data elements that every public utility filing an Index of Customers must provide to describe its power sales. To the extent that a public utility makes no power sales during the applicable quarter, it is not required to report any transactional data in its Index of Customers filing for that quarter. The NOPR proposed to require transactional data for every electric commodity sale, whether the rate was cost-based, market-based, under a rate schedule, or under a tariff. In addition, if any other services are approved for market-based rates in the future, they will have to be reported in this section.
The second table (Appendix B) is a detailed look at the data elements including their format. Where applicable, we have identified the analogous OASIS data element. We have also included the intended field length and a list of valid entries. This table is intended for computer and technical personnel to review. Respondents are encouraged to comment on these items which will aid the successful development of the system.
The third table, shown in Appendix C, shows which elements will be required for short term transmission contracts and which will be required for long term transmission contracts.
The NOPR proposes that public utilities report in the Index of Customers all of their sales transactions, “including book outs and net outs.”[1] A number of parties’ comments expressed concern about how the Commission would define the “book outs” and “net outs” that must be reported in the Index of Customers, contending that including “book outs” and “net outs” would be burdensome and that “book outs” are nonphysical transactions that should not be reported.
In industry parlance, a “book out” is the offsetting of opposing buy-sell transactions (e.g., a sale of 100 MW from A to B and a sale of 90 MW from B to A would result in these transactions being booked-out and treated as a 10 MW sale from A to B). A “net out” is similar, but instead concerns the offsetting of dollars rather than MW (e.g., if A owes B $2,700 and B owes A $3,000, the transactions are netted out and treated as a single transaction of $300).
As noted by many parties, the Commission found in Morgan Stanley Capital Group, Inc., 69 FERC ¶ 61,175 at 61,696 (1994), as modified in 72 FERC ¶ 61,082 at 61,435-36 (1995) (Morgan Stanley) that we would not extend our power marketer reporting requirements to purely financial transactions [2] and in Start Printed Page 67136 New York Mercantile Exchange, 74 FERC ¶ 61,311 at 61,987 (1996) (NYMEX), we found that we lack jurisdiction under sections 203 and 204 of the FPA over the trading of electricity futures contracts approved for trading by the Commodity Futures Trading Commission (CFTC). We held, however, that we do have jurisdiction under §§ 205 and 206 of the FPA over transactions that go to physical delivery. Intervenors contend, based on our precedent in Morgan Stanley and NYMEX, that we should not require the reporting of “book outs” and “net outs” in the Index of Customers.
Subsequent to issuance of Morgan Stanley, respondents' quarterly transaction reports have reported their “book outs” and “net outs” of physical transactions on an aggregated basis. Reporting these book outs and net outs of physical transactions is appropriate because the underlying transactions are not purely financial transactions. Our proposal in the NOPR does not rewrite the line we drew in Morgan Stanley or in NYMEX. The same transactions for which book outs and net outs are currently reported in quarterly transaction reports are to be reported in the Index of Customers. The comments filed in response to the NOPR have not persuaded us to reconsider this issue.
However, to avoid confusion, we will give specific guidance as to which book outs or net outs must be reported under the proposals in the NOPR, as clarified in this order. In Morgan Stanley and NYMEX, the Commission stated that it has jurisdiction over those transactions that go to physical delivery, and does not have jurisdiction over purely financial transactions. However, commenters suggest that booked-out transactions do not go to physical delivery and, therefore should not have to be reported. We note that, in Morgan Stanley and NYMEX, the Commission was distinguishing between transactions that were purely financial, i.e., transactions usually performed in the futures market, and physical transactions, i.e., scheduled sale or purchase transactions to meet load. Commenters are not drawing the line between futures transactions and physical transactions, but between physical transactions that are delivered in full and those that are offset either all or in part (e.g., they argue that two offsetting 100 MW sales result in no deliveries; thus nothing need be reported on either transaction despite the fact that the sales were not financial positions but in fact physical power sales that were offset similar to a net interchange between two control areas). Just because a MW for a sale was not used to meet a distant load but instead met a more local load due to scheduling and physics does not change the fact that each individual transaction of such a series of offset transactions is a physical transaction. Accordingly, we clarify that we are proposing that sales of power that are offset through a book out or net out based on the physical characteristics (i.e., location of source and sink) of the transactions must be reported as separate transactions.
Morgan Stanley did not address the issue of whether book outs and net outs are to be reported on an aggregated or disaggregated basis. In the absence of specific guidance on this issue, respondents have elected to file this information on an aggregated basis. To provide the public and Commission with more useful information, we clarify that, under the proposal in the NOPR, public utilities would be required to report book outs and net outs of physical transactions on a disaggregated basis showing each individual leg of the transaction that generated the book out or net out.
The majority of the data elements are self-explanatory: contact_name, contact_address, contact_email and the like. However, several data elements require additional discussion.
Appendix A identifies the data elements “company_name,” “company_duns” and a series of related data elements necessary to identify a contact person, address and means of contact. These data elements will be used to collect data on the multiple parties related to the filing of the report and the information contain in the report. The data collection anticipates the need to collect information on up to three types of parties: (a) Filing Agent—the company or organization making the filing with the Commission (this could be the public utility itself, or an organization such as a law firm making the filing on the utility's behalf; (b) Seller—the public utility providing services; and (c) Purchaser—the buyer of the public utility's service(s). Not all data elements will be required for all parties. For example, there is no need for a company DUNS [3] number for the filing agent. For the purchaser, the Commission intends to require only company name and the associated DUNS number. No contact data will be required. A separate Index of Customers filing will be required for each public utility. Each filing is required to include the name (contact_name) and location information for at least one contact person. Contacts can be listed for the filing agent and/or the seller.
The Commission is not proposing any particular method for a utility to create unique contract service agreement identifiers. However, whatever method a utility adopts should be readily relatable to any service or revenue a utility must report (such as in a Form No. 1 filing, rate proceeding, or Commission audit).
The contract commencement date is the initial date service commenced under the contract. This date, once established, does not change in subsequent quarterly Index of Customers filings.
Electric utility contracts may provide for several unbundled services under a single contract. The purpose of the “begin_date” data element is to identify the initial date an individual service commenced. This date can differ from the date service commenced under a contract, or from other services under a contract. This date, once established, does not change in subsequent quarterly Index of Customers filings.
The distinction between “contract_commencement_date” and “begin_date” can best be illustrated with an example. Power sales or transmission might be provided under a contract before various ancillary services (also provided for under the contract) are commenced. Under this scenario, the date service under the contract commences would be reported under the “contract_commencement_date” data element and the date when each ancillary service commenced would be reported with its own “begin_date.”
The “contract_termination_dt” data element is intended to capture the expected initial contract's termination Start Printed Page 67137date. If the contract terminates during the reporting period, then the flag “cancellation_of_contract” should be provided, as well as the actual termination date (i.e., “actual_termination_dt”).
Electric utility contracts may provide for several unbundled services under a single contract. The purpose of the “end_date” data element is to identify the date an individual service terminates. This date, once established, does not change in subsequent quarterly Index of Customers filings.
The first three of these data elements will be used to collect both contract and transaction information. However, the definitions for the required data are different, depending on whether the rate information is applicable to contract data or transactional data.
Appendix A proposes four rate related data elements: “rate,” “rate_min,” “rate_max” and “rate_desc.” [4] The “rate” element is a numeric input that should reflect the stated rate during the reporting period. The “rate_min” and “rate_max” data elements should report the lowest and highest rate for any unit of service received during the reporting period as provided in the contract. For contracts with stated rates, the rate information in all three data elements would be the same. The “rate_desc” data element can be completed as simply as stating “maximum approved rate.” However, if a cost-based rate is discounted or negotiated below the FERC-approved maximum rate, then the utility must describe the method by which the rate is calculated. This may be as simple, for example, as “Stated rate,” or, if based on some index, an example would be “Fixed cost of $x.xxxx plus 80% of Index Price Y.” The rate data element, in this instance, may be left blank. Market-based power sales contracts need not provide any rate information for the contract record. That information will be collected in the transaction record.
Appendix A proposes three rate-related data elements: “rate,” “rate_min,” and “rate_max.” The rates required for these data elements should be solely for the respondent's services or sales under a FERC tariff. As noted above, we are proposing that in lieu of submitting minute-by-minute data, respondents should submit high, low, and weighted average prices on a daily basis for those transactions which are shorter than a day.
Public utilities filing transaction data on power sales will be required to include transaction data for all products and services (whether market-based or cost-based) related under the terms of the contract to the power sale.
The transaction data element “total_transaction_charge” is the total revenue for the transaction period received from the customer for the service or sale under the terms of the contract. This would include revenues received for all services related to a product that is the subject of the transaction report. The “total_transaction_charge” is also to include all other applicable revenue for other services provided under the contract, such as ancillary services or bundled transmission provided by the respondent or others under the contract.
The purpose of these data elements is to identify the service provided (product_name), along with some general characteristics of the service to improve analysis of the data. For example, “product_ name” could be “schedule system control and dispatch;” “product_type” could be “transmission;” and “product_sub_ type” could be “ancillary service.”
We are proposing to require the data element “term_name” because the Commission often establishes different reporting and other requirements for short-term, as opposed to long-term, contracts. For example, as shown in Appendix C, the standard form of service agreement provided by Order No. 888-B [5] requires significantly less information for short-term transportation as compared to long-term transportation. The Commission does not propose in this NOPR to change the standard form of service agreements.
Various proposed data elements require the use of codes to identify certain services and other information. The Commission proposes, to the extent possible, to use the codes and definitions already accepted and in use on the OASIS system. For example, for the data element “product_name,” the Commission proposes to use SC—Scheduled system control and dispatch, and RV—Reactive supply and vol. control from the OASIS S&CP Document data set.[6] The Index of Customers, however, will require the reporting of more than just the OATT services. Therefore, the OASIS registered codes do not reflect the variety of services offered by utilities under Part 35 of the Commission's regulations.
We invite comments as to whether the same voluntary industry working group(s) that seek industry consensus and periodically recommend revisions to the OASIS S&CP Document would be available to aid the Commission in developing and maintaining the various codes for Index of Customer Data Sets, or whether another approach would be preferable.
The “ferc_designation” data element is designed to identify the FERC-approved designation for the tariff or rate schedule that identifies the terms and conditions of service and the applicable rates. These data are the same as required by § 35.9(a) and 35.9(b)(1) of the Commission's regulations. We have revised the OASIS data element for “tariff_designation” because the data element also applies to sales provided under a rate schedule.
We invite comment on whether respondents should identify nonconforming contracts as part of their Index of Customers submittals.
The Commission is developing software to capture, manage, and disseminate its data. We invite interested parties who wish to participate in a pilot test of this data collection to contact Barbara Bourque at barbara.bourque@ferc.gov.
This order specifies the data sets that we are considering adopting as part of a final rule in this proceeding. Prior to taking final action on this proposal, we are inviting comments from interested Start Printed Page 67138persons on the proposals discussed in this order and fully set out in the attachments. The Commission invites interested persons to submit comments, data, views and other information concerning matters set out in this order.
To facilitate the Commission's review of the comments, commenters are requested to provide an executive summary of their position on the issues raised in this order, including any revisions they would suggest to the proposed data sets (along with the reasons supporting their suggested revisions), along with any related matters or alternative proposals that commenters may wish to discuss. Commenters are requested to identify each specific question posed by this order that their discussion addresses and to use appropriate headings. Commenters should make comments as specific as possible, and when comments address specific data elements or issues, use the same terms as are used in this order. Commenters should separately identify any additional issues they wish to raise. Commenters should double space their comments.
Comments may be filed on paper or electronically via the Internet and must be received by the Commission within 30 days after publication of this order in the Federal Register. All comments, whether submitted electronically or in a paper filing, should be preceded by a caption identifying the name (Public Utility Filing Requirements) and docket number (Docket No. RM01-8-000) of this proceeding and should reference that they are being filed in response to this order. Those filing electronically do not need to make a paper filing. For paper filings, the original and 14 copies of such comments should be submitted to the Office of the Secretary, Federal Energy Regulatory Commission, 888 First Street, NE., Washington DC 20426.
For the convenience of Commission Staff, we request that paper filings be accompanied by a computer diskette copy in a Commission-prescribed format (see discussion immediately below). We request that the accompanying computer diskette should have a label providing the following information: Docket No. RM01-8-000; the name of the filing entity; the software and version used to create the file; and the name and telephone number of a contact person. Any discrepancies between the paper filing and the accompanying diskette will be resolved by reference to the paper filing.
Comments filed via the Internet must be prepared in WordPerfect, MS Word, Portable Document Format, or ASCII format. To file the document, access the Commission's website at www.ferc.gov and click on “e-Filing,” and then follow the instructions for each screen. First time users will have to establish a user name and password. The Commission will send an automatic acknowledgment to the sender's E-Mail address upon receipt of comments.
In addition to publishing the full text of this document in the Federal Register, the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the Internet through FERC's Home Page (http://www.ferc.gov) and in FERC's Public Reference Room during normal business hours (8:30 a.m. to 5 p.m. Eastern time) at 888 First Street, NE., Room 2A, Washington, DC 20426.
Interested persons may file comments on the proposed data sets as discussed in this order and shown in Attachment A to this order within thirty (30) days of the date of publication of this order in the Federal Register, as discussed in the body of this order.
End Signature Start Printed Page 67139
Start Printed Page 67140
Start Printed Page 67141
Start Printed Page 67142
Start Printed Page 67143
Start Printed Page 67146
Start Printed Page 67147
Start Printed Page 67148
Start Printed Page 67149
Start Printed Page 67151
1. See FERC Stats. & Regs. ¶ 32,554 at 34,071-72.
2. We note, however, that in Docket No. RM02-3-000 we are proposing to revise the Uniform System of Accounts (USofA) to require reporting on derivatives, and we are seeking comment on the extent to which marketers should be required to follow the USofA and what information, if any, should be reported by these entities.
3. DUNS numbers refer to the Data Universal Numbering System, maintained by Dun and Bradstreet.
4. When a split savings price is paid, this would be reported in the “rate_desc.” data element.
5. See Promoting Wholesale Competition Through Open Access Non-discriminatory Transmission Services by Public Utilities and Recovery of Stranded Costs by Public Utilities and Transmitting Utilities, Order No. 888, 61 FR 21540 (May 10, 1996), FERC Stats. & Regs. ¶ 31,036 (1996) (Order No. 888), order on reh'g, Order No. 888-A, 62 FR 12274 (March 14, 1997), FERC Stats. & Regs. ¶ 31,048 (1997) (Order No. 888-A), order on reh'g, Order No. 888-B, 81 FERC ¶ 61,248 (1997), order on reh'g, Order No. 888-C, 82 FERC ¶ 61,046 (1998), aff'd in part sub nom., Transmission Access Policy Study Group, et al. v. FERC, 225 F. 3d 667 (D.C. Cir. 2000), cert. granted in part and denied in part, 121 S. Ct. 1185 (2001).
6. OASIS S&CP Document, Appendix A-2, AS_TYPE.
[FR Doc. 01-32005 Filed 12-27-01; 8:45 am]