NOIE-REP Demand Response Data Collection - ercot.com€¦ · Web view– Word document notifying NOIEs and REPs as to whether they are required to participate in the Demand response

NOIE-REP Demand Response Data Collection Technical Specifications for 2019

August 1, 2019

PUC Subst. Rule §25.505(e) (5) requires that “Load Serving Entities (LSEs) shall provide ERCOT with complete information on load response capabilities that are self-arranged or pursuant to bilateral agreements between LSEs and their customers”.

Pursuant to this rule, ERCOT has the authority to require Non-Opt-in-Entities (NOIEs) and Retail Electric Providers (REPs) to report on their retail pricing and Demand response-related programs.

I. REP Specific Instructions:The first step in the REP Demand response data collection process will be for ERCOT to classify REPs as to whether or not they are required to submit information to ERCOT regarding Demand and price response participation within their company. The classification will be based on the REP’s summer weekday average load.

By August 1, 2019, ERCOT will issue a Market Notice to notify all REPs that the annual Demand Response data collection process is beginning and the specific timeline that will be followed.

ERCOT also will post a document to the MIS as official notification as to whether REPs are required to report such information to ERCOT or not. The report name for this file will be ‘DRDataParticipationStatus’; the file will be posted as described in the ‘Data Exchange Considerations’ section below. By August 15, 2019, the Authorized Representative for each REP that is required to report information should notify ERCOT via email ([email protected]) acknowledging this requirement.

REPs that are classified by ERCOT as having a reporting requirement and that do not have ESI IDs participating in Demand/price response programs are required to respond as such to ERCOT via email ([email protected]) on or before October 31, 2019.

REPs that are classified by ERCOT as having a reporting requirement and that have ESI IDs participating in Demand/price response programs are required to identify each of the Electric Service Identifiers (ESI IDs) for which they are the REP-of-Record on the ERCOT-defined snapshot date of September 30, 2019 and determine which of those ESI IDs were participating in one or more programs that are consistent with the categories described in the ‘Demand Response Data Definitions’ section which follows.

The REP shall compile a .csv file that follows the format described in the ‘REP Data Collection Technical Specifications’ section which follows. The REP shall submit the files to ERCOT via NAESB EDM or as an email attachment as described in the ‘Data Exchange Considerations’ section below.

1

mailto:[email protected]


ERCOT will validate the files and send response files back to the REP in two business days or less, with the results of the validation as described in the ‘REP Data Collection Technical Specifications’ section which follows. For REPs that submit files via NAESB, the response files will be sent via NAESB. For REPs that submit files as email attachments, the response files will be posted to the MIS as described in the ‘Data Exchange Considerations’ section below. REPs are required to investigate any errors reported by ERCOT, make necessary corrections and resubmit the complete file with corrections to ERCOT. ERCOT’s target accuracy is for 95% of the reporting REP’s ESIIDs submitted to have no errors, so REPs shall continue to correct and resubmit files until notified by ERCOT that the REP has achieved the required accuracy level. REPs are expected to complete this process on or before October 31, 2019. ERCOT will notify the Authorized Representative for each REP when they have achieved the required level of accuracy.

To facilitate the error correction process described above, REPs may request, by email addressed to [email protected], ERCOT to provide a file extracted from ERCOT systems listing the ESIIDs owned by the REP on September 30, 2019. The ERCOT provided file will also list the REP-of-Record date for that period of ownership, the Profile Group (“RES” or “BUS”) and the Meter Data Type. The file will be specific to each DUNs and will be posted to MIS by October 7, 2019 as described in the ‘Data Exchange Considerations’ section below.

In conjunction with the reporting described above, on September 30, 2019, ERCOT will send an email to the Authorized Representative for all REPs identified as having a reporting requirement containing links to an online survey to obtain details on specific deployment events for their programs. REPs identified as having a reporting requirement shall complete those surveys on or before October 31, 2019. The program categories for which deployment event details are applicable are as follows: CPP – Critical Peak Pricing, PR – Peak Rebates, OLC – Other Direct Load Control and OTH – Other Voluntary Demand Response Product.

Reporting Considerations:

All REPs identified as having a reporting requirement are required to either notify ERCOT that they do not have customers on demand/price response programs or to submit files as described in the ‘Data Exchange Considerations’ section which follows.

If an ESI ID is participating in more than one program or is participating in a program with a definition that spans multiple categories, the REP must list the ESI ID once for each category.

2


If an ESI ID is participating in a program and fails to reduce load or opts-out of any or all deployments, the ESI ID still should be included in the file submitted to ERCOT. If a program has not been deployed for the reporting period, or is deployed for only some of the participants, all ESI IDs that could have been deployed should be included in the file.

If an ESI ID is enrolled as a Load Resource or in an ERS Resource and is only deployed by ERCOT instruction, the ESI ID should not be reported as participating in one of the REP’s programs. If an ESI ID is enrolled in a TDSP sponsored Standard Offer Load Management program and is only deployed by the TDSP pursuant to an ERCOT instruction, the ESI ID should not be reported as participating in one of the REP’s programs. ESI IDs that participate in an ERCOT or TDSP program and also participate in a REP demand/price response program should be reported as participating in the applicable REP program. For such ESI IDs, deployment event reporting should be limited to deployments initiated by the REP and unrelated to ERCOT/TDSP deployments.

The ‘Direct Load Control Indicator’ field documented in the ‘REP Data Collection Technical Specifications’ section should be submitted with a value of either ‘Y’ or ‘N’ for an ESI ID in conjunction with one of the program categories. A value of ‘Y’ should be used to indicate that the REP or a 3rd party on behalf of the REP has the ability to exercise direct control of electrical equipment behind the customer’s meter to effectuate the demand/price response.

For example, if the customer is participating in the REP’s Peak Rebate program, and is paid the rebate based on the amount of load reduction associated with direct control by or on behalf of the REP, the ‘Direct Load Control Indicator’ should be set to ‘Y’. If, on the other hand, the demand/price response is under the customer’s control, the ‘Direct Load Control Indicator’ should be set to ‘N’. Note, that if the REP or third party can directly initiate a deployment, and the customer has the ability to opt-out of a deployment, the ‘Direct Load Control Indicator’ should be set to ‘Y’.

II. NOIE Specific Instructions:

The first step in the NOIE Demand response data collection process will be for ERCOT to classify NOIE TDSPs based on the NOIE’s summer weekday average load as to whether or not information for the NOIE TDSP is required by ERCOT regarding Demand and price response programs within the NOIE TDSP region.

By August 1, 2019, ERCOT will issue a Market Notice to notify all NOIE TDSPs and LSEs that the annual Demand Response data collection process is beginning and the specific timeline that will be followed.

3

ERCOT also will post a document to the MIS for each NOIE LSE and NOIE TDSP as official notification as to whether the Demand response information for specific NOIE TDSPs is required or not. The report name for this file will be ‘DRDataParticipationStatus’; the file will be posted as described in the ‘Data Exchange Considerations’ section below. By August 15, 2019

If the Authorized Representative at the associated NOIE LSE and NOIE TDSP are not the same, they should coordinate with each other to determine which entity is responsible for administering demand/price response programs for the NOIE TDSP. That Authorized Representative should take the lead in the Demand response data collection process, and, by August 15, 2019, should notify ERCOT via email ([email protected]) that they will be the designated Authorized Representative for that NOIE TDSP.

If the Authorized Representative for the NOIE LSE and NOIE TDSP is the same, that individual should notify ERCOT via email ([email protected]) acknowledging the participation requirement.

On September 30, 2019, ERCOT will send a link to the survey to the designated Authorized Representative for each NOIE TDSP identified as having a reporting requirement. If a NOIE receives that email and does not have any customers participating in Demand/price response programs, the NOIE should respond to ERCOT via email ([email protected]) as such on or before October 31, 2019.

If a designated Authorized Representative for a NOIE that has a reporting requirement and does have customers participating in Demand/price response programs that are consistent with one of the categories described in the ‘Demand Response Data Definitions’ section which follows, the NOIE should go to the survey link provided in the ERCOT email and complete the responses for each of the program categories. The survey should be completed by indicating the number of residential and non-residential customers participating in the each of the programs on September 30, 2019. The NOIE TDSP should also complete the deployment event section of the survey by providing details on specific deployment events. The program categories for which deployment event details are applicable are as follows: CPP – Critical Peak Pricing, PR – Peak Rebates, OLC – Other Direct Load Control and OTH – Other Voluntary Demand Response Product.

Reporting Considerations:

All NOIEs identified as having a reporting requirement in the August 1 email are required to either notify ERCOT that they do not have customers on

4




demand/price response programs or to respond to the ERCOT surveys referenced above.

If a customer is participating in more than one program or is participating in a program with a definition that spans multiple categories, the NOIE should include that customer in the counts for those programs.

If a customer is participating in a program and fails to reduce load or opts-out of any or all deployments, the customer still should be included in the counts for that program. If a program has not been deployed for the reporting period, or is deployed for only some of the participants, all customers that could have been deployed should be included in the counts for that program.

If an customer is enrolled as a Load Resource or in an ERS Resource and is only deployed by ERCOT instruction, the ESI ID should not be reported as participating in one of the NOIE’s programs. Customers that participate in one of these ERCOT programs and also participate in NOIE demand/price response program should be counted as participating in the applicable NOIE program. For such customers deployment event reporting should be limited to deployments initiated by the NOIE and unrelated to ERCOT deployments.

III. Data Exchange Considerations:

ERCOT is providing two methods of data exchange for purposes of the REP Demand response data collection process: 1) the NAESB process, which has been used for previous data collection processes, and 2) as email attachments for files inbound to ERCOT, and the MIS for files outbound from ERCOT. The emails used to send files to ERCOT may be by regular email or may be sent as encrypted email as described below. REPs choosing to send files using email should notify ERCOT at [email protected] of this decision,

A. NAESB

This method been used previously by REPs and continues to be available to them. This method provides for secure file exchange both inbound to and outbound from ERCOT. For REPS that opt to use this method, the NAESB file exchange will be used in both directions. The file naming conventions and file formats are described below in the ‘REP Data Collection Technical Specifications’ section below.

B. Posting ERCOT Outbound Files to the MIS:

ERCOT will post a document, ‘DRDataParticipationStatus’, on the MIS for all REPs and NOIEs to notify them as to whether or not they have a Demand response data collection requirement. For REPs that request it, ERCOT also will

5


post the ‘ESIID Cross Reference File’ on the MIS. For REPs that elect to send files to ERCOT via email, the response files from ERCOT will be posted to the MIS.

The ERCOT outbound files above will be posted as ‘Requested Information’ in the ‘Ad Hoc Information and Invoices’ section of the MIS. The screen shot below shows the location for these files:

C. Sending Files to ERCOT as Email Attachments:

REPs that choose send Demand Response data collection files to ERCOT as email attachments may choose to use either regular or encrypted email. ERCOT does provide the capability to Market Participants to send encrypted emails to ERCOT and recommends taking advantage of this capability.

ERCOT uses Proofpoint for sending and receiving encrypted emails and their attachments; since this application has a size limitation of 20 MB, larger files may need to be created and attached as .zip files.

REPs that choose to send files to ERCOT as encrypted emails will need to register the email address using the following link,

6

https://securemail.ercot.com/encrypt . The website will prompt the user to enter an email address and password.

To send a secure email to ERCOT, the REP will need to log in to the same link to compose the email, add attachments and click on ‘send’. Since there is no direct way to keep track of these emails, senders should consider checking the ‘Send me a copy’ box.

IV. File Name and Format Conventions for Email and MIS Files

A. Files sent to ERCOT as email attachments are required to follow the following name convention:

DUNs Report Name Date/Time counter

0000000000000. DRDataCollection.20191023113001999.csv

The Duns should be entered as either a 9- or 13-digit number. The date/time should be in a ccyymmddhhmmss format. The counter is a 3 digit field and may be used by the REP for their internal identification purposes. File format and content specifications follow those described in the ‘REP Data Collection Technical Specifications’ section below.

B. The file names of files posted at the MIS Ad Hoc location specific to the Demand response data collection process will be in the following format and will use the report names listed below:

report # duns number

RPT.00013239.0000000000000000.Report Name.csv

Report Names for Email and MIS Files:

DRDataParticipantStatus – Word document notifying NOIEs and REPs as to whether they are required to participate in the Demand response data collection process. A document is created for each Authorized Representative listing all affiliated entities.

DRDataESIIDCrossRerence – File of ESIIDs owned by REP on Sep 30, 2019 with additional information that may be used by the REP to

7

https://securemail.ercot.com/encrypt

pre-validate a DRDataCollection file before submitting it to ERCOT. This file will be posted by ERCOT on or before October 7, 2019, upon request by the REP. For REPs with a large number of ESIIDs this will be posted as a .zip file.

Data Element Comments Format

ESIID NumberThe ESIID is the basic identifier assigned to each Service Delivery Point (SDP).

Alpha numeric (36)

REP-of-Record- Date

Date the REP first took ownership of the ESIID for the period of ownership including September 30, 2019.

Numeric (8) yyyymmdd

Profile GroupRES or BUS – for the ESIID as of September 30, 2019.

Alpha numeric (3)

Meter Data TypeIDR or NIDR - for the ESIID as of September 30, 2019.

Alpha numeric (4)

DRDataCollectionERCOTResponse<counter> – File that acknowledges ERCOT receipt of a ‘DRDataCollection’ file from the REP and that contains information as to the status of the data submitted including any file format or mandatory data element errors. If the submitted file name has a counter appended by the REP, the response file will use the same counter. The file formats and field descriptions are as described in the ‘REP Data Collection Technical Specifications’ section below.

DRDataCollectionERCOTValidation<counter> – File that contains information as to any business validation errors in the DRDataCollection file. If the submitted file name has a counter appended by the REP, the response file name will use the same counter. The file formats and field descriptions are as described in the ‘REP Data Collection Technical Specifications’ section below. Note: if the ‘DRDataCollectionERCOTResponse’ file contains errors, this validation is not performed and no validation response file is returned.

8

V. Demand Response Data Definitions

4CP – Four Coincident Peak – rate incentives, predictor signals or direct load control provided to customers to encourage or cause them to reduce load during actual or potential Four Coincident Peak (4CP) intervals during summer months (June through September). Reducing load during such intervals lowers transmission charges. 4CP charges apply to large customers (peak demand ≥700 kW), and also to NOIEs at the boundary meter level.

RTP – Real Time Pricing - retail prices for all hours or intervals based on ERCOT Real-Time Settlement Point Prices for the premise Load Zone, calculated every 15 minutes, or other real-time wholesale price indicator(s).

BI – Block & Index – fixed pricing for a defined volume of usage, coupled with pricing, for usage exceeding the block, indexed to the Real-Time Settlement Point Prices for the premise Load Zone . Block prices and volumes may vary by time of day/week.

CPP – Critical Peak Pricing –prices that rise during critical peaks: limited duration periods of time identified by the LSE that usually correlate to high prices in the real-time wholesale market. Critical peak events may occur a limited number of times per year and typically are communicated a day in advance.

PR – Peak Rebates – a retail offering in which the customer is eligible for a financial incentive paid for load reductions taken during periods of time identified by the LSE and communicated to the customer during the prior day or the event day or both. LSE has defined a method to identify whether a customer has responded and to quantify the response amount. Payment (rebate) to customer is based upon the magnitude of the customer’s response.

Peak Rebate examples:

• No DLC: The REP sends an email one day prior if high prices are forecasted, and sends a reminder text/tweet the morning of the following day. The REP identifies responding customers using a recent similar weather day as a baseline to estimate what the customer’s load would have been. If the customer’s actual load during the predicted intervals was lower than the baseline, the REP agrees to pay the customer $X/kWh of reduction.

• DLC: REP sends email one day prior if high prices are forecasted, and sends a reminder text/tweet the morning of the following day. When high prices materialize, the REP sends a signal to the customer’s web-enabled thermostat to increase its set point by 3 degrees. The REP establishes a baseline for the customer to estimate what the customer’s load would have been. If the

9

customer’s actual load during the predicted intervals was lower than the baseline, the REP agrees to pay the customer $ X/kWh of reduction.

TOU – Time of Use — prices that vary across defined blocks of hours, with predefined prices and schedules. (As used here, does not apply to seasonal adjustments).

• TOU Example – free evening or free weekend hours

OLC – Other Direct Load Control – contracts that allow the LSE or a third party to control the customer’s load remotely for economic or grid reliability purposes. This category applies to Direct Load Control (DLC) not associated with the customer’s energy price, and with different deployment criteria than described elsewhere. (Avoid double counting if DLC data was reported in other categories.) Customer incentive is predefined and does not vary based upon the response.

• OLC Example - OLC (always has DLC) REP identifies a day on which high prices have, or are about to, materialize. The REP sends a signal to the customer’s web-enabled thermostat to increase its set point by 3 degrees. The REP agrees to pay the customer $10 / month for each summer month, and the customer agrees to allow the thermostat to be set higher 10 times during the summer for periods up to 2 hours long. If the customer overrides the REP thermostat setting during a month, the customer’s payment is reduced by $3.

OTH – Other Voluntary Demand Response Program – any retail program not covered in the other categories that includes a demand response incentive or signal. For NOIEs, that implement voltage reduction to reduce load, such programs should be reported under this category.

VI. REP Data Collection Technical Specifications

Data Collection will exclude the category below beginning Summer 2017 and onward.

FO – Financial Option – product where LSE purchases an option from the customer that is backed by a specified level of DR and uses it for portfolio trades in the wholesale market.

All information must be sent in a pipe delimited Comma Separated Values (CSV) file format via North American Energy Standards Board (NAESB) or as an attachment to an email sent to [email protected] and must contain all

10

required demand response data collection fields. All records sent in the file must be terminated by a Carriage Return Line Feed (CRLF).

File Name Requirements1

The recommended file naming convention is <DUNS><Reportname><datetime><counter>.csv in addition to any application file naming conventions used in transmitting the file.

For example, “999999999DRDataCollection20130323113001999.csv” where:

DUNS CR DUNS Number Numeric (9 or 13)

Reportname ‘DRDataCollection’ Alphanumeric (23)

datetime File transmission date/time stamp Datetime format = ccyymmddhhmmss

counter Counter with no specified value Numeric (3)

.csv Value of .csv mandatory in file name

At a minimum the filename must contain *.csv.* after decryption otherwise the file will be rejected by ERCOT. Files will be sent with a NAESB input-format of “FF”. Any file extension other than .csv, such as .xml or .x12 will fail at ERCOT.

There are three (3) files within this process that are sent and received via NAESB.

(1) DRDataCollection file will be the file sent by the Retail Electric Provider (REP) to ERCOT.

(2) DRDataCollectionERCOTResponse file is the acknowledgement sent by ERCOT to the REP with information as to the status of the data. The first response file is to communicate back to the REP any file format or mandatory data element errors.

(3) DRDataCollectionERCOTValidation file is sent by ERCOT to the REP with information as to the validation of the data. The second response file is to communicate back to the REP any business validation errors.

1 The TDTMS_EDM Implementation Guide is posted at http://www.ercot.com/mktrules/guides/data_transport

11

File Name Example 1: CR to ERCOT – Demand Response file submission

<DUNS><DRDataCollection><20130322012345><001>.csv

Filename Example 2: ERCOT to CR – Demand Response File validation response file

<DUNS><DRDataCollectionERCOTResponse><20130322012345><001>.csv

Filename Example 3: ERCOT to CR – Demand Response Data validation response file

<DUNS><DRDataCollectionValidationERCOTResponse><20130322012345><001>.csv

ERCOT will validate that all mandatory data elements are present and meet formatting requirements; and will send the first response file (see File 2 below for specification). ERCOT will send the response to the submitting REP via NAESB or via secure email to the email address provided by the REP.

ERCOT will conduct business validations and send the second response file (see File 3 below for specification). ERCOT will send the response to the submitting REP via NAESB) or an ERCOT approved alternative data transfer method.

If REP has file errors or business validation errors, the REP should make all necessary corrections and re-send the full file to ERCOT, using a new unique Report ID in the header record. ERCOT will use the last file sent for data analysis.

File 1 – (REP to ERCOT) Record Layout for the DRDataCollection file

Table 1 - Header record – Use this template to identify the data provided a unique tracking number and the sender or receiver.

Data Element

Texas SET Mandatory /

OptionalComments Format

Record

TypeMandatory Record Tag “HDR.” Alpha numeric (3)

12

Data Element



Report Name

MandatoryMutually defined report definition. Hard Code “DRDataCollection.”

Alpha numeric (80)

Report ID MandatoryThe unique report number designated by the Sender to be used in the DRDataCollectionERCOTResponse.

Alpha numeric

REP DUNS

NumberMandatory

Retail Electric Provider (REP) of record DUNS Number. Associated with the ESIIDs sent in the file.

Numeric (9 or 13)

Table 2 – Detail record - The DET record contains the ESIID level Demand Response information.

Data Element



Record Type

Mandatory Record Tag “DET.” Alpha numeric (3)

Record Number

MandatoryThe unique sequential record number starting with “1.”

Numeric (8)

REP DUNS

NumberMandatory

Retail Electric Provider (REP) of record DUNS Number associated with the ESIIDs sent in the file.

Numeric (9 or 13)

ESIID Number

MandatoryThe identification for the customer active within the category. The ESIID is the basic identifier assigned to each Service Delivery Point (SDP).

Alpha numeric (36)

Category Code

MandatoryCategory of Demand Response product the ESIID in the record is assigned. The acceptable codes are below.

Alpha numeric (3)

Direct Load

Control Indicator

MandatoryY or N – If the Demand Response can be initiated by LSE or 3rd party (other than the customer)

Alpha numeric (1)

13

Data Element



Start Date MandatoryThe date the ESIID commenced service under this category

Numeric (8) yyyymmdd

Table 3 - Summary record – This template is used to convey record totals of the number of DET records from the file being sent from the sender or receiver.

Data Element



Record Type

Mandatory Record Tag “SUM.” Alpha numeric (3)

Total Number of DET

Records

MandatoryTotal number of DET records, should be equal to the Record Counter in the last DET record. Use Zero if no records sent.

Numeric (8)

Table 4 - Category Codes (REP to ERCOT) (File 1, the DET record).

Category Code Category Description

4CP Four Coincident Peak

RTP Real Time Pricing

BI Block & Index

CPP Critical Peak Pricing

PR Peak Rebates

TOU Time of Use

OLC Other Load Control

OTH Other Voluntary Demand Response Product

The category below will not be used for data collection beginning Summer 2017 and onward.

14

FO Financial Option

File 2 – Record Layout for the DRDataCollectionERCOTResponse file (ERCOT to submitting REP)

Table 5 - Header record – First row of CSV - Used to designate the data to be presented, with a unique tracking number and an indication of the sender to ERCOT or receiver of the data set from ERCOT response.

Data Element

Mandatory / Optional Comments Format

Record Type

Mandatory Record Tag “HDR.” Alpha numeric (3)

Report Name

MandatoryMutually defined report definition. Hard Code “DRDataCollectionERCOTResponse.”

Alpha numeric (80)

Original Report ID

MandatoryReport ID as sent in the “DRDataCollection file.”

Alpha numeric (80)

REP DUNS

NumberMandatory

Retail Electric Provider (REP) of record DUNS Number receiving this response report information based on the original file submission.

Numeric (9 or 13)

Table 6 - ER1 record – Used to designate a record with an invalid value or format, with a reference to the original record in error.

Data Element


Record Type

Mandatory Record Tag “ER1.” Alpha numeric (3)

Record Number


Numeric (8)

ESIID Number

Mandatory The basic identifier assigned to each SDP. Alpha numeric (36)

15

Data Element


Original Record Type

MandatoryThe type of record in error. Valid values are DET, HDR, and SUM.

Alpha numeric (3)

Original Record Number

ConditionalOriginal DET Record Number sent from DRDataCollection report that is in error. Required if Original Record Type is DET.

Numeric (8)

Field Name

Mandatory Field name of record that is in error. Alpha numeric (80)

Error Descriptio

nMandatory Description of error. Alpha numeric (80)

Table 7 - ER2 record – used to designate a record with a missing mandatory field, with a reference to the original record in error.

Data Element



Record Type


Record Number


Numeric (8)

ESIID Number




Alpha numeric (3)


ConditionalOriginal DET Record Number sent from DRDataCollection report that is in error.

Required if Original Record Type is DET.Numeric (8)

Field Name

Mandatory Field name of record that is in error. Alpha numeric (80)

Error Mandatory Description of error. Alpha numeric (80)

16

Data Element



Description

Table 8 - Sum record – provides the sum of all records received in the original file, the number of records processed, and the number of DET records in error.

Data Element


Record Type


Total Number of

DET Records

MandatoryTotal number of DET records in the original DRDataCollection report.

Numeric (8)

Total Number of processed

DET Records

MandatoryTotal number of DET records processed without error from the DRDataCollection report.

Numeric (8)

Total Number of

Error Records

Conditional Total number of DET records in error. Numeric (8)

File 3 – Record Layout for the DRDataCollectionERCOTValidation file (ERCOT to submitting REP)

Table 9 - Header record – First row of CSV - Used to designate the data to be presented, with a unique tracking number and an indication of the sender to ERCOT or receiver of the data set from ERCOT response.

17

Data Element


Record Type

Mandatory Record Tag “HDR.” Alpha numeric (3)

Report Name

MandatoryMutually defined report definition. Hard Code “DRDataCollectionERCOTValidation.”

Alpha numeric (80)

Original Report ID

MandatoryReport ID as sent in the “DRDataCollection file.”

Alpha numeric (80)

REP DUNS Number

Mandatory

Retail Electric Provider (REP) of record DUNS Number receiving this response report information based on the original file submission.

Numeric (9 or 13)

Table 10 - ER3 record – used to designate a record that failed data validation, with a reference to the original record in error.

Data Element



Record Type


Record Number


Numeric (8)

ESIID Number




Alpha numeric (3)


ConditionalOriginal DET Record Number sent from DRDataCollection report that is in error.

Required if Original Record Type is DET.Numeric (8)

Field Name Mandatory Field name of record that is in error. Alpha numeric (80)

Error Description

Mandatory Description of error. Alpha numeric (80)

18

Table 11 - Sum record – provides the sum of all records received in the original file, the number of records processed, and the number of DET records in error.

Data Element


Record Type


Total Number of

DET Records

MandatoryTotal number of DET records in the original DRDataCollection report.

Numeric (8)

Total Number of processed

DET Records

MandatoryTotal number of DET records processed without error from the DRDataCollection report.

Numeric (8)

Total Number of

Error Records

Conditional Total number of DET records in error. Numeric (8)

Table 12 - Error Descriptions (ERCOT to REP) (File 3, the E3 record)

Error Description Long Description

Invalid-ESIIDESIID is not in ERCOT settlement system or as of Snapshot Date has an Inactive or De-energized Status

Not-ROR Reporting REP is not the REP of Record as of Snapshot Date

Start-Date-Before-ROR

Reporting REP was not the REP of Record as of participation start date (excluding submissions with an Invalid-Start-Date)

Invalid-Start-Date

A REP other than the submitting REP was the Rep of Record for some days occurring between the program Start Date to Snapshot Date

19

Start-Date-After-Snap-Shot

Start date for ESIID is after the specified Snapshot Date

4CP-Wrong-LP Profile Type for ESIID not BUSIDRRQ

RES-LP-Inconsistent

Profile Type for ESIID is RESHIWR or RESLOWR for category code BI or FO

Invalid-LP Profile Type for ESIID is NMLIGHT or NMFLAT

Invalid-Meter Category Code is RTP, BI, CPP, PR, or FO for ESIID with Meter Type NIDR

Duplicate-Row Input record is identical to a previous record except for sequence number

Matching-Consecutive-

Category/DLC-Codes

Input record is identical to the previous chronological record, based on start date, except for sequence number and start date

Example 1 – REP file sent to ERCOT (no errors)

File 1 - From REP to ERCOT

HDR|DRDataCollection|200608300001|123456789

DET|1|123456789|1001001001001|PR|Y|20120701|

DET|2|123456789|1001001001023|PR|Y|20120715|

DET|3|123456789|1001001001045|TOU|Y|20130201|

DET|4|123456789|1001001001045|PR|Y|20130201|

SUM|4|

File 2 - From ERCOT to REP

HDR|DRDataCollectionERCOTResponse|200608300001|123456789

SUM|4|0|


20

HDR|DRDataCollectionERCOTValidation|200608300001|123456789

SUM|4|0|

Example 2 – REP file to ERCOT with format error and a duplicate row



DET|1|123456789|1001001001001|PR|Y|0701|

DET|2|123456789|1001001001023|PR|Y|20120715|

DET|3|123456789|1001001001023|PR|Y|20120715|

DET|4|123456789|1001001001045|TOU|Y|20130201|

DET|5|123456789|1001001001045|BI|Y|20130201|

SUM|5|



ER2|1|1001001001001|DET|1|StartDate|InvalidValue

SUM|5|4|1|



ER3|1|1001001001001|DET|3|Duplicate-Row|Duplicate-Row

SUM|5|4|1|

Example 3 – REP file to ERCOT with data validation errors



21

DET|1|123456789|1001001001234|PR|Y|20120715|

DET|2|123456789|1001001005678|PR|Y|20120715|

DET|3|123456789|1001001004321|TOU|Y|20130201|

DET|4|123456789|1001001008765|BI|Y|20130201|

SUM|4|



SUM|4|0|



ER3|2|1001001004321|DET|3|ESIID|Not-ROR

SUM|5|4|1|

22

Table 13 – Common Errors – Suggested Fixes

Error Code Common errors / suggestions for fixes

Invalid-ESIIDCheck that all significant digits of ESIID were reported and none inadvertently set to zero by rounding

Check that ESIID is a valid ESIID.

Not-RORCheck if Rep-of-Record for ESIID on the Snap Shot Date.

If not the REP of Record, remove row.

Start-Date-After-Snap-Shot

Check start date of program.

If ESIID started on the program after the Snapshot Date, remove record from file. Otherwise, correct the start date of the program for the ESIID.

If any of the above errors apply to a row, no further validations are performed for the row.

Start-Date-Before-ROR

Check if Rep of Record for ESIID as of program start date reported.

Correct the start date on the program for the ESIID

Invalid-Start-DateCheck if Rep of Record for ESIID for entire date range of program start to Snapshot date.

Correct the start date of the program for the ESIID.

4CP-Wrong-LP Check ESIID profile code, must be BUSIDRRQ.

RES-LP-InconsistentCheck ESIID profile code, must start with BUS for the category code specified.

Invalid-LP Check ESIID profile code

Invalid-MeterCheck ESIID meter meter type, must be IDR for the category code specified.

Duplicate-Row Remove duplicate row.

Matching-Consecutive-

Category/DLC-CodesRemove matching row (with incorrect program start date).

23

NOIE-REP Demand Response Data Collection - ercot.com€¦ · Web view– Word document notifying NOIEs and REPs as to whether they are required to participate in the Demand response

Documents