Skip to content

DOCUMENT REVISION HISTORY

Date/Version Summary of Changes
January 19, 2001 / 1.1

  • Removed references to X.509

  • Specified time change synchronization

  • Specified PGP parameters

  • Grammatical clean-up
June 25, 2002 / 2.0
June 27, 2003 / 2.1

  • Updated to include Texas Retail Market specifications for v 1.6 Implementation

  • Corrected sections to be in sync with most updated v 1.6 TDTWG TX Market Imp guide
July 28, 2003/2.2 Updated to reflect Market Participant comments
August 18, 2003/2.3 Updated Test Plan, Moved FTP to Appendix D, remove merge created duplicate section.
December 10, 2003 / 2.4 Added appendix F – To address Content-type
December 03, 2005 Re-Org / Cleanup
December 07, 2005 / 2.5

  • Additional Cleanup formatting, punctuation, language. Added numbers to section headers to easily identify and locate.

  • Changed Acknowledgements / Reponses section to identify separately each type of acknowledgement or response.

  • Fixed “email” spelling and made consistent throughout. Changed fail-over to failover and made consistent throughout.

  • Corrected bulleting formatting for some sections.
February 26, 2006 / 2.6 Continued formatting and cleanup after December working group meeting feedback
February 28, 2007 Final Formatting and clean up
April 26, 2007

  • Added information for Flat File (FF) data exchange in support of TX SET 3.0 implementation.

  • Also included FF naming convention requirements from Retail Market Guide changes discussed at MCT 04/26/2007.
December 3,2008

  • Added information for LSE Flat File (FF) data exchange in support of interim solution for Advance Metering.

  • Also included LSE FF naming convention as discussed in TDTWG meeting on 11/5/2008.
November 10, 2010 RMS approved change control process. See the Executive Summary.
June 19, 2013 / 2.9 Added information to CSV Flat File (FF) data exchange in support of paragraph (e)(5), P.U.C. Subst. R. 25.505, Resource Adequacy in the Electric Reliability Council of Texas Power Region, “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”. RMS approved 6/19/13.
August 1, 2013 / 2.9 Un-boxed language regarding CSV Transmission Demand Response File.
June 4, 2014 / 2.10 File type definition for Aggregate Load Resources in Security-Constrained Economic Dispatch (SCED). New file types supported are – Site Data, Event Data, NIDR meter reads and Interval data meter reads. RMS approved 6/3/14, effective 6/4/14
December 9, 2015 / 2.11 Name change from TDTWG to TDTMS
May 3, 2016 / 2.12 RMGRR126 - Add new CSV file type for business level response of CBCI process
July 24, 2016 / 2.12 Revised cover page and footer to correspond with unboxing of RMGRR126.
June 6, 2023 / 2.13

Removed Section 2.2.5.9, FTP, and references to FTP from Section 2.2.5.10, ERCOT Architecture Notes. Sections 2.1, General Guidelines, 2.3.1, General Guidelines, 4.1, General Guidelines, and 7.1, Test Script, also updated to represent the current Retail Operations and Market Testing guidelines.

Clarified and directed Market Participants to a single source for information that pertains to file content and formatting for:

  • Section 2.2.5.3 “CSV Transmission” – Customer Billing Contact Information (CBCI) single-source reference is Retail Market Guide (RMG) Section 9, Appendices, Appendix F6, Customer Billing Contact Information.

  • Section 2.2.5.3 “Demand Response File” – file content and formatting single-source reference to Other Binding Document, Demand Response Data Definitions and Technical Specifications.

  • Section 2.2.5.4 “LSE Transmission” – file content and formatting single-source reference both located in the RMG Section 7.15, Advanced Meter Interval Data File Format and Submission; also RMG Section 9, Appendix G, ERCOT Specified File Format for Submission of Interval Data for Advanced Metering Systems.

1. EXECUTIVE SUMMARY

This document defines the Internet Data Transport protocol and rules as defined by the Texas Data Transport and MarkeTrak Systems Working Group (TDTMS) for the deregulated Electric marketplace in Texas and as approved by the Texas Retail Market.

This document is intended to be used as a supplement to the NAESB EDM Standards v1.6 and does NOT supersede any Public Utility Commission of Texas (PUCT) orders. The NAESB EDM Version 1.6 is available to NAESB members only at http://www.NAESB.org.

The Technical Implementation section of this document includes technical requirements discovered during the initial implementation. These should be taken into consideration in order to support a successful implementation and to be compliant with this guide.

Revisions to this guide shall be reviewed by the TDTMS and approved by the Retail Market Subcommittee (RMS).

2. BUSINESS PROCESSES

2.1. General Guidelines

Production Technical contacts should be identified for each Market Participant Company. The contact information should be made available to ERCOT and associated Market Participant companies. contact information is available in the FlighTrak application at https://testsa.ercot.com/workcenter/. Market Participants must have access to FlighTrak and must fill out the Production Specifications Issue for each Market Participant Data Universal Numbering System (DUNS). Please contact ERCOT Retail Operations Team if you have any questions on how to get access to FlighTrak or how to complete this issue.

2.1.1. NAESB EDM Standard References

Based on Texas Data Transport and MarkeTrak Systems Working Group’s (TDTMS) review of the NAESB EDM Version 1.6, the following sections were determined to be relevant and subject to the following modifications and clarifications to the TDTMS’s implementation of NAESB EDM 1.6:

(1) Section entitled BUSINESS PROCESS AND PRACTICES, Subsection C. Electronic Delivery Mechanism Related Standards, the Sub-Subsection entitled Standards: Standards 4.3.7 through 4.3.15 inclusive.

(2) Section entitled TECHNICAL IMPLEMENTATION - INTERNET EDI/EDM & BATCH FF/EDM, subject to the following modifications and clarifications:

2.1 - In the Data Dictionary For INTERNET EDM the Format of the Business Name transaction-set refers to specific 8-character codes that are not relevant for our purposes.

2.2 – EEDM 702 error code will be used for format failures identified post decryption and before the ASC X12 997 transactions can be produced.

4.0 – Under the Subsection entitled RECEIVING TRANSACTIONS, the Sub-Subsection entitled URL/CGI Implementation Guidelines is an example transaction flow and is general information only. This Sub-Subsection shall not be construed as to impose any requirements on any CRs, TDSPs, or ERCOT.

The NAESB EDM Version 1.6 is available to NAESB members only at http://www.NAESB.org.

2.1.2. System Changes

Parties are required to communicate NAESB EDM server maintenance schedules to their trading partners. This shall be done via email and, if applicable, web server.

Prior to making a change, parties are required to communicate proposed NAESB EDM V 1.6 deployment changes to TDTMS. As needed, the TDTMS will work with the parties in order to determine if the change is consistent with Market standards. If it is viewed that the implementation of the change would indeed deviate from the NAESB EDM V 1.6 Standard, the TDTMS will address the issue with the Market Participant party to identify and mitigate risk. For items that have different interpretations the TDTMS will work with NAESB in order to attempt to ensure the ambiguity does not exist in future version releases of NAESB EDM standards. It may be possible for the Texas market to deviate from the standard protocol for NAESB EDM V 1.6. This could be allowed if it is determined the protocol originally created for gas, was not completely appropriate for electric. Communication of these type issues can be done via email. All attempts will be made to avoid deviation from the NAESB standards.

2.1.3. Common Codes

Texas Retail Market supports the use of 13 digit common code, which typically is DUNS plus four.

2.1.4. Daylight Savings Time

Clocks shall be rolled forward and backward at 2:00 AM Central Prevailing Time to accommodate daylight savings time changes.

2.1.5. File Names

File names must be unique over time. See Section 2.2.5.3, CSV Transmission, for CBCI filename requirements and Section 2.2.5.4, LSE Transmission, for LSE filename requirements from Retail Market Guide.

2.1.6. Exchange Failures

The following procedure is the minimum recommendation:

A protocol failure occurs any time a sending party’s NAESB EDM server cannot connect to the receiving party’s NAESB EDM server. For example, if a server tries to connect to a server and fails, or tries to post a file and fails, this is a protocol failure.

An exchange failure occurs when a sending party’s NAESB EDM server has had continual protocol failures over a thirty-minute period. Each party is required to try at least 3 times over the thirty-minute period before flagging an exchange failure.

Email shall be used to notify partners of protocol and exchange failures. This shall assist in rectifying and documenting problems.

When a protocol failure occurs, it is recommended that the sending party wait 15 minutes, then retry the NAESB EDM transfer. If a second protocol failure occurs, the sending party should wait another 15 minutes, and then retry the NAESB EDM transfer. For example, the first protocol failure happens at 1:00 AM, the second happens at 1:15 AM, and the third happens at 1:30 AM.

Automatic failover systems are recommended but not required by this plan at this time.

It is recommended that exchange failures be monitored closely, and the appropriate internal Trading Partner escalation procedures put in place in the event they occur.

2.2. ERCOT Specific Business Processes

All reasonable attempts should be made to comply with this section. Market Participant legacy systems that cannot meet the requirements of this section must contact ERCOT in order to be granted an exception.

2.2.1. Common Codes

The Texas Market has implemented a 9-13 digit DUNS numbering system and many entities have the same base 9 digits. ERCOT requires a unique common code for each Market Participant Company.

2.2.2. Inbound Login values

ERCOT requires unique User Identification (UID) and password for each Market Participant.

ERCOT has the market responsibility to provide reporting by Market Participant and to be able to provide data transparency and tracking.

ERCOT security policies are such that each Market Participant receives their own unique UID/Password combination.

2.2.3. Outbound Login Values

ERCOT will “push” messages to each Market Participant using a unique UID/password combination.

2.2.4. Data Security

It is mandatory to use PGP encryption software (version 6.5 or later) or other software compliant with OpenPGP/RFC 2440 and contain only one encrypted file per payload.

ERCOT will only manage one single public key per market participant without regard to transport protocol.

ERCOT could allow multiple Market Participants to sign the ERCOT public key with the same private key.

  • This would require minimal changes but it deviates from internal ERCOT security practices.

ERCOT could encrypt multiple Market Participants with the same single public key.

  • This would require minimal changes but it deviates from internal ERCOT security practices.

2.2.5. File Naming Convention

2.2.5.1 X12 Transmission

The file name prior to encryption must have an extension of “.edi”.

2.2.5.2 XML Transmission

The file name prior to encryption must have an extension of “.xml”.

2.2.5.3 CSV Transmission

In support of the Texas Standard Electronic Transaction (Texas SET) Implementation Guides the transmission of Flat File (FF) (.csv) will be required for the transmission of Customer Billing Contact Information (CBCI).

The file name prior to encryption must have an extension of “.csv”. Rules that apply to individual projects in regard to file name will also apply. (i.e., LIH-\<file name>.csv)

The market-approved CBCI file naming convention, formatting and data content requirements, along with examples are available in the Retail Market Guide (RMG), Section 9, Appendices, Appendix F6, Customer Billing Contact Information.

Demand Response File

Pursuant to P.U.C. Subst. R. 25.505, Resource Adequacy Reporting Requirements in the Electric Reliability Council of Texas Power Region, “Load serving entities (LSEs) will provide ERCOT with complete information on load response capabilities that are self-arranged or pursuant to bilateral agreements between LSEs and their customers”.

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.

The market-approved Demand Response file naming convention, formatting and data content requirements, along with examples, are available in the Other Binding Document, Demand Response Data Definitions and Technical Specifications.

2.2.5.4 LSE Transmission

In support of the Transmission and/or Distribution Service Provider’s (TDSP’s) Advanced Metering deployment, the market created and approved an ‘.lse’ FF that TDSPs would be required to utilize for their transmission of Advanced Metering System (AMS) data to ERCOT and Smart Meter Texas (SMT). These ‘.lse’ files will contain settlement quality 15-minute interval data for both load and generation.

Naming convention rules that apply to individual projects in regard to file name will also apply.

The market approved ‘.lse’ file naming convention, formatting and data content requirements are available in the RMG Section 9, Appendices, Appendix G, ERCOT Specified File Format for Submission of Interval Data for Advanced Metering Systems. The ‘.lse’ minimum data record file size restrictions can be referenced in the RMG, Section 7.15, Advanced Meter Interval Data File Format and Submission.

2.2.5.5 Aggregate Load Resources in SCED Transmission

Qualification as a Load Resource is a pre-requisite for the provision of demand response in the ERCOT Ancillary Services markets and Real-Time Energy Market (aka Security-Constrained Economic Dispatch (or SCED). Since the ERCOT market opened in 2002, the fleet of Load Resources has been limited to single-site Loads. Due to limitations in various ERCOT systems and to technological barriers to entry, aggregations of Loads have been unable to qualify as Load Resources.

Enabling access to the ERCOT markets for Aggregate Load Resources (ALRs) offers the prospect of broader customer participation in electricity supply and demand, and could increase the pool of participants in ERCOT’s real-time energy and day-ahead Ancillary Services markets.

This document sets forth the detailed requirements for data formatting in that market interface.

In order to gather the necessary data for Aggregate Load Resources in SCED from the QSEs, ERCOT is using 4 inbound file types and 6 outbound file types. Two of the inbound file types were created specifically for this project. The other two inbound file types are already being used at ERCOT and are being repurposed to satisfy the needs of the Aggregate Load Resources in SCED Project.

Type of Data File Extension Delimiter Inbound Report Name Formatting Validation Response Report Name Business Validation Response Report Name
Site Data .csv Pipe ALRISSiteData ALRISSiteDataERCOTResponse ALRISSiteData.ERCOTValidation
Event Data .csv Pipe ALRISEventData ALRISEventDataERCOResponse ALRISEventData.ERCOTValidation
NIDR Data .nidr Comma ALRISNIDRData N/A ALRISNIDRData.ERCOTValidation
Advanced Meter Data .lse Comma ALRISIntervalData N/A ALRISIntervalData.ERCOTValidation

The recommended naming convention for file type to ERCOT is as follows:

Field Name Description Data Type
QSE DUNS Duns and Bradstreet Number of QSE Numeric (9 or 13)
ReportName

One of the following:

  • ‘ALRISSiteData’

  • ALRISEventData

  • ALRISNIDRData

  • ALRISIntrervalData

 Alphanumeric (23)
DateTime File transmission date/time stamp Datetime format = ccyymmddhhmmss
Counter Counter with no specified value Numeric (3)
File extension Mandatory extension type in file name

ALRISSite & ALRISEvent files

  • .csv

ALRISNIDR file

  • .nidr

ALRISIntervalData file

  • .lse

Example File names:

111111111ALRISSiteData201303180930101.csv

111111111ALRISEventData201303180930101.csv

111111111ALRISNIDRData201303180930101.nidr

111111111ALRISIntervalData201303180930101.lse

The naming convention for File level validation and Business level validation responses sent from ERCOT to market participants is as follows:

Field Name Description Data Type
QSE DUNS Duns and Bradstreet Number of QSE Numeric (9 or 13)
ReportName

One of the following:

  • ALRISSiteDataERCOTResponse

  • ALRISSiteData.ERCOTValidation

  • ALRISEventDataERCOTResponse

  • ALRISEventData.ERCOTValidation

  • ALRISNIDRData.ERCOTValidation

  • ALRISIntrervalData.ERCOTValidation

 Alphanumeric (23)
DateTime File transmission date/time stamp Datetime format = ccyymmddhhmmss
Counter Counter with no specified value Numeric (3)
File extension Mandatory extension type in file name .csv

Example Filenames:-

111111111ALRISSiteDataERCOTResponse201303180930101.csv

111111111ALRISSiteData.ERCOTValidation201303180930101.csv

111111111ALRISEventDataERCOTResponse201303180930101.csv

111111111ALRISEventData.ERCOTValidation201303180930101.csv

111111111ALRISNIDRData.ERCOTValidation201303180930101.csv

111111111ALRISIntervalData.ERCOTValidation201303180930101.csv

2.2.5.6 Best Practices

Any method that ensures uniqueness in the file name can be used.

As an example, a file name can consist of sender DUNS number, Texas Set transaction type, time stamp, process id, counter and appropriate extension.

File name length must not exceed 100 characters.

Example:

1039940674000-81404-20030308235900-64532-0001.edi

1039940674000-NIDR86703-20030308235900-64532-0002.xml

1039940674000-IDR86703-20030308235900-64532-0003.edi

2.2.5.7 Character Set
Allowable Characters

  • Uppercase letters (A through Z); and lowercase letters (a-z)

  • Numbers zero through nine (0 through 9)

  • Underscore (“_”), Dot (“.”) or Dash (“-“).

Spaces are not permitted in the file name.

2.2.5.8 Encryption

The file name after encryption must have an extension of “.pgp”.

Example:

1039940674000-81404-20030308235900-64532-0001.edi.pgp

1039940674000-NIDR86703-20030308235900-64532-0002.xml.pgp

1039940674000-IDR86703-20030308235900-64532-0003.edi.pgp

2.2.5.9 ERCOT Architecture Notes

The current ERCOT architecture is designed and implemented in support of:

  • Data security – One and only one Market Participant can login, extract and deliver data per mailbox.

  • Integrity – ERCOT ensures that data sent and received from Market Participants is contained within individual Market Participant directory structures to prevent data mixing thereby reducing the possibility for competitive advantages.

  • Transparency – Tracking data by Market Participants is greatly enhanced using this method.

  • ERCOT supports NAESB EDM v1.6 for communication with Texas Retail Market Participants.

Timeliness – Each Market Participant has its own data thread and is not affected by another Market Participant. If a single Market Participant floods the pipeline it will only affect their thread and the remainder of Market Participants are unaffected. This reduces competitive disadvantages by others flooding.

2.3. Market Rules / Requirements

2.3.1. General Guidelines

The approved Texas Data Transport and MarkeTrak Systems Working Group (TDTMS) transaction data transport protocol platform for transactions between Competitive Retailers (CRs), Transmission and/or Distribution Service Providers (TDSPs), and ERCOT is North American Energy Standards Board Electronic Delivery Mechanism (NAESB EDM) standard version 1.6.

All CRs, TDSPs, and ERCOT are required to be NAESB EDM Internet ready for testing and certification according to the approved timeline on the Texas Retail Market Testing website.

Specifics regarding data transport should be made available to associated trading partner prior to connectivity testing. As changes are made these should be made available to trading partners as well. This information could include URLs, protocol and exchange failure processes and contact information, and test exceptions.

3. Technical Implementation

3.1. URL

Each party should maintain one production URL and one test URL, at a minimum.

3.2. HTTP 1.1

HTTP (Hypertext Transfer Protocol) is the World Wide Web application protocol that runs on top of the Internet's TCP/IP suite of protocols. HTTP 1.1 addresses some of the issues that are not considered or addressed in HTTP 1.0 such as hierarchical proxies, caching, persistent connections, and virtual hosts.

Instead of opening and closing a connection for each application request, HTTP 1.1 provides a persistent connection that allows multiple requests to be batched or pipelined to an output buffer. The underlying Transmission Control Protocol (TCP) layer can put multiple requests (and responses to requests) into one TCP segment that gets forwarded to the Internet Protocol (IP) layer for packet transmission. Because the number of connection and disconnection requests for a sequence of "get a file" requests is reduced, fewer packets need to flow across the Internet. Since requests are pipelined, TCP segments are more efficient. The overall result is less Internet traffic and faster performance for the user. HTTP 1.1 decompress the files, a server will compress them for transport across the Internet, providing a substantial aggregate savings in the amount of data that has to be transmitted.

3.3. SSL

The SSL (Secure Socket Layer) protocol runs above TCP/IP and below HTTP. It uses TCP/IP on behalf of the higher-level protocols, and in the process allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.

SSL addresses fundamental concerns about communication over the Internet and other TCP/IP networks:

  • SSL server authentication allows a user to confirm a server's identity. SSL-enabled client software can use standard techniques of public-key cryptography to check that a server's certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the client's list of trusted CAs. This confirmation might be important if the user, for example, is sending a credit card number over the network and wants to check the receiving server's identity.

  • SSL client authentication allows a server to confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client's certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the server's list of trusted CAs. This confirmation might be important if the server, for example, is a bank sending confidential financial information to a customer and wants to check the recipient's identity.

  • An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition, all data sent over an encrypted SSL connection is protected with a mechanism for detecting tampering--that is, for automatically determining whether the data has been altered in transit.

In Summary the SSL protocol performs the following

  • Authenticates the server to the client

  • Allows the client and server to select the cryptographic algorithms, or ciphers, that they both support

  • Optionally authenticates the client to the server

  • Uses public-key encryption techniques to generate shared secrets

  • Establishes an encrypted SSL connection

3.4. Data Security

All NAESB EDM V 1.6 transactions are to be treated as confidential and must be encrypted. Receipt of un-encrypted ‘clear-text’ ASC X12 transactions should be treated as an exchange failure that needs to be corrected.

It is mandatory to use PGP encryption software (version 6.5 or later) or other software compliant with OpenPGP/RFC 2440 and contain only one encrypted file per payload.

OpenPGP Parameters:

  • Public Keys are generated using the El Gamal algorithm.

  • Key expiration is recommended at 2 year intervals, any market wide upgrade, or if the security of a key is compromised. This is at the discretion of the Market Participant.

  • User ID should be in format “name (organization) \<email address>” with email address being optional.

  • All NAESB EDM payloads (transactions) will be encrypted with digital signatures applied using the DSS standard

  • OpenPGP compression must be used.

3.4.1. Key Management

Market Participant’s public key should be self-signed and sent to all Market Participants and ERCOT that they wish to do business with in the Texas Market. The recommended procedure for sending the self-signed public key is via an email attachment sent to the appropriate authority designated by each party. Test and production keys will have different key names, fingerprints, and key id.

The received public key shall be verified by comparing the fingerprint of the public key by verbal communication. Encrypted data can be in binary form.

3.5. Differences between EDM Versions 1.4 and 1.6

GISB EDM 1.4 NAESB EDM 1.6
Uses HTTP 1.0 Uses HTTP 1.1
Not Secure Secure Communication using SSL 128 Bit or better Encryption
Suggest to Use PGP 2.6 or higher It is mandatory to use PGP encryption software (version 6.5 or later) or other software compliant with OpenPGP/RFC 2440 and contain only one encrypted file per payload.
Testing procedures are not standardized Additional Testing guidelines

1.4 data elements

from, to, input-format, request-status, server-id, time-c, to **, transaction-set, trans-id

1.6 data elements

from **, input-data, input-format, receipt-disposition-to, receipt-report-type, receipt-security-selection, refnum, request-status, server-id, time-c, to **, transaction-set, trans-id version
Added error codes EEDM110 to EEDM119
Added warning code WEDM102 to WEDM104
Changed the minimum Server Hardware Configuration

3.6. Acknowledgements / Responses

3.6.1. EDM Responses

Parties shall continue to send EDM responses.

3.6.1.1 HTTP Response

The HTTP response indicates that some file was received at a specified time. It does not always verify that the file could be decrypted or is a valid readable transaction file with regard to content and structure.

In general, this standard format for error notification applies to the posting of an error message after sender’s session has been disconnected. This error notification has the potential of occurring only after the original HTTP Response is returned with an “ok” or a warning (WEDM999 format) for the request-status value, not an error (EEDM999).

3.6.1.2 EEDM responses

If an error notification is given, a NAESB WGQ Error Notification contains two body parts nested within a multipart/report outer envelope. The first body part contains human readable content in HTML. The second body part contains machine readable content in plain text. Additionally, consenting trading partners can mutually agree to digitally sign error notifications. If digital signatures are used, the multipart/report containing the NAESB WGQ Error Notification is used to create a digital signature body part, identified by a content-type of application/pgp-signature. Both the multipart/report NAESB WGQ Error Notification and application/pgp-encrypted digital signature body parts are combined in a multipart/signed envelope.

These can be captured outside of the initial transfer session but are to be sent back as an EEDM Error response. The original receiver initiates a POST of the Error Response to the original sender with an input-format of “error”.

3.6.2. Acknowledgements

3.6.2.1 Functional Acknowledgement

Parties shall send transaction functional acknowledgements (997). The NAESB EDM v1.6 HTTP response only indicates that some file was received at a specified time. It does not verify that the file could be decrypted or is a valid readable transaction file with regard to content and structure.

997s are required for the Texas Retail Market. 997 acknowledgements are expected within 1 Retail Business Day of receiving the transaction. Retail Business Day is defined in Chapter 2 of the ERCOT Protocols.

3.6.2.2 TA1 Acknowledgement

TA1 is an interchange level acknowledgement. TA1 validations are a mutually agreed transaction for the Texas Market. TA1 validations can be supported by ERCOT if requested.

3.7. MIME “Content-type”

Allowing for the MIME “Content-type” element with encrypted payload is necessary since trading partners may be using systems that support sending this element. This element has been available since the advent of GISB EDM v 1.5 and is included in the NAESB EDM v 1.6 standard. Texas Data Transport and MarkeTrak Systems Working Group (TDTMS) is including the use of this element in order to be compliant with the NAESB EDM v 1.6 standard.

Sender may or may not include this element at this time. The Receiver must be able to process this data element if received.

Per RFC 1767, here is the usage for X12 and Flat files.

Example1 (X12 data file):

Content-type: application/EDI-X12

ISA~00~ ~01~AAA6300300~14~1234567890000 ~14~2345678900000

... more data from the X12 file…

IEA~1~000003616

Example 2 (CSV Flat file):

Content-type: application/EDI-CONSENT

HDR|MTCRCustomerInformation||123456789|

... more data from the Flat file…

SUM|5|0|0|

Example 3 (LSE Flat File):

Content-type: application/EDI-CONSENT

00000001,100000000000000,4,20080510000000,20080510235900,Y,N

00000002,0,0,0,0,0,0,900,01,01,-1,0.0,0.0,CST

00000003,UNIQUETRANID0123456789

00000004,20080519112825,Z

00000030,ATTRIBUTE_VALUE_PAIRS,MRE=666666666,Sender=666666666,Receiver=183529,REP=111111111

10000000,68.29,A,,69.17,A,,67.99,A,,67.99,A,,

10000001,66.81,A,,66.52,A,,67.11,A,,67.11,A,,

10000002,67.11,A,,66.52,A,,66.81,A,,66.82,A,,

10000003,67.7,A,,68.87,A,,68.58,A,,68.87,A,,

10000004,69.47,A,,107.73,A,,230.76,A,,228.11,A,,

10000005,231.94,A,,228.4,A,,230.17,A,,233.7,A,,

10000006,25.18,A,,21.95,A,,246.36,A,,247.83,A,,

10000007,259.61,A,,283.45,A,,303.16,A,,313.76,A,,

10000008,325.83,A,,336.72,A,,350.26,A,,354.38,A,,

10000009,358.5,A,,30.27,A,,361.74,A,,366.45,A,,

10000010,365.86,A,,369.39,A,,369.69,A,,368.21,A,,

10000011,371.45,A,,39.69,A,,367.63,A,,369.39,A,,

10000012,371.15,A,,369.68,A,,368.51,A,,369.98,A,,

10000013,370.57,A,,373.51,A,,373.22,A,,369.39,A,,

10000014,370.86,A,,369.98,A,,368.81,A,,365.57,A,,

10000015,364.39,A,,34.68,A,,36.8,A,,284.03,A,,

10000016,309.64,A,,308.76,A,,302.88,A,,296.1,A,,

10000017,286.68,A,,279.91,A,,24.29,A,,189.55,A,,

10000018,190.43,A,,161.59,A,,10.68,A,,114.79,A,,

10000019,108.9,A,,107.14,A,,101.55,A,,98.61,A,,

10000020,94.78,A,,4.49,A,,95.66,A,,92.42,A,,

10000021,84.77,A,,80.94,A,,80.94,A,,80.35,A,,

10000022,80.35,A,,80.35,A,,7.29,A,,77.41,A,,

10000023,77.71,A,,76.82,A,,77.41,A,,7.82,A,,

3.8. Internal Testing Recommendations

This is a list of tests that should be conducted internally by the CR, TDSP, or ERCOT during testing prior to market implementation.

Stress Test – Ability to send and receive large production files (e.g. 10MB minimum uncompressed).

Failover test – Test any processes triggered by a protocol or exchange failure.

4. Market Testing Requirements

4.1. General Guidelines

The Texas Standard Electronic Transaction Working Group (Texas SET) shall publish testing procedures for transactions using NAESB EDM v 1.6.

Each Market Participant’s NAESB EDM V 1.6 administrator’s email address and contact information are required to be identified in the Prod Specifications and Contacts by DUNS report in FlighTrak. This Contact information and / or email address will be used for communicating protocol and exchange failures and other related communications.

The NAESB EDM V 1.6 test shall be performed with a minimum sample of one payload file. Volume testing is performed on an as needed basis.

CRs, TDSPs, or ERCOT shall maintain the pace of the test as published by the Testing Administrator.

4.2. Testing Goals

Establish NAESB EDM connectivity including Internet connections and encryption compatibility between all parties (CRs, TDSPs, ERCOT).

Validate that payload data files can be sent.

Validate that payload data files can be decrypted.

Validate that the NAESB EDM time-stamp and trans-id is being delivered and verified by both parties

Validate that protocol failures are handled properly.

Validate that exchange failures are handled properly.

Validate that encryption/decryption and digital signature failures are handled properly.

4.3. Testing Administrator

The Testing Administrator shall coordinate timing and transactions with Market Participants and/or ERCOT to facilitate testing. The Testing Administrator shall administer testing for point-to-point (between CRs,TDSPs, and ERCOT) transactions using NAESB EDM v 1.6.

The Testing Administrator shall verify CRs, TDSPs, and ERCOT as NAESB EDM v 1.6 capable after successful testing has been completed.

4.4. Testing Dispute Resolution

All CRs, TDSPs, and ERCOT are encouraged to resolve NAESB EDM v 1.6 problems with each other. A dispute is a problem where two associated trading partners (CRs, TDSPs, or ERCOT) cannot agree on who is responsible for the problem and/or how to fix the problem. If a transport problem affects other parties then the dispute should be brought before the Texas Data Transport and MarkeTrak Systems Working Group (TDTMS) and Testing Administrator for resolution.

Transaction disputes that cannot be resolved between CRs, TDSPs, and ERCOT shall be brought to the attention of the Testing Administrator for resolution.

If CRs, TDSPs, and ERCOT agree that the TDTMS and/or the Testing Administrator cannot adequately resolve the transaction dispute, the Testing Administrator shall raise the dispute to the appropriate ERCOT Executive Management.

5. Appendix A

5.1. Example Messages

5.1.1. Typical HTTP Header

POST /cgi-bin/NAESB1.6 HTTP/1.1
Referer: http://www.get.a.life/upl.htm
Connection: Keep-Alive
User-Agent: Batch Browser 1.1.
Host: localhost
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data; boundary=---------------------------87453838942833
Content-Length: 5379

5.1.2. Typical Success message

Content-Type: multipart/report; report-type="gisb-acknowledgement-receipt"; boundary=" NAES16"
--NAES16
Content-type: text/html
\<HTML>\<HEAD>\<TITLE>Acknowledgement Receipt Success\</TITLE>\</HEAD> \<BODY>\<P> time-c=20030719082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
\</P> \</BODY>\</HTML>
-- NAES16
Content-type: text/plain time-c=20030719082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
--NAES16--

5.1.3. Typical Error Message

Content-Type: multipart/report; report-type="gisb-acknowledgement-receipt"; boundary=" NAES16"
-- NAES16
Content-type: text/html
\<HTML>\<HEAD>\<TITLE>Acknowledgement Receipt Error\</TITLE>\</HEAD> \<BODY>\<P>
time-c=20030719082855*.NAESB WGQ Electronic Delivery Mechanism Related Standards
request-status=EEDM106: Invalid To Common Code Identifier*
server-id=coolhost*
trans-id=234423897*
\</P> \</BODY>\</HTML>
-- NAES16
Content-type: text/plain
time-c=20030719082855*
request-status=EEDM106: Invalid To Common Code Identifier*
server-id=coolhost*
trans-id=234423897*
--NAES16—

5.1.4. Typical Warning Message

Content-Type: multipart/report; report-type="gisb-acknowledgement-receipt"; boundary=" NAES16"
-- NAES16
Content-type: text/html
\<HTML>\<HEAD>\<TITLE>Acknowledgement Receipt Warning\</TITLE>\</HEAD> \<BODY>\<P>
time-c=20030719082855*
request-status=WEDM100: Transaction Set Sent, Not Mutually Agreed*
server-id=coolhost*
trans-id=234423897*
\</P> \</BODY>\</HTML>
--NAESB16--
Content-type: text/plain
time-c=20030719082855*
request-status= WEDM100: Transaction Set Sent, Not Mutually Agreed *
server-id=coolhost*
trans-id=234423897*
--NAESB16--

5.1.5. Typical Signed Receipt

Content-Type:multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature";
boundary=SIGNEDNAESB16
-- SIGNEDNAESB16
Content-Type: multipart/report; report-type="gisb-acknowledgement-receipt"; boundary="NAESB16"
-- NAESB16
Content-type: text/html
\<HTML>\<HEAD>\<TITLE>Acknowledgement Receipt Success\</TITLE>\</HEAD> \<BODY>\<P>
time-c=20030719082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
\</P> \</BODY>\</HTML>
-- NAESB16
Content-type: text/plain.
time-c=20030719082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
-- NAESB16--
-- SIGNEDNAESB16
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//JV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGquMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9BrnHOxEa44b+EI==ndaj
-----END PGP MESSAGE-----
--SIGNEDNAESB16--

6. Appendix B

6.1. HTML Testing Tool

Instructions:

  1. Open the edmupload.htm page in an editor replace the String “Target URL” with the URL of the receiver and save the file.

\<Form ENCTYPE="multipart/form-data" ACTION="Target URL" METHOD=POST>

  1. Open the edmupload.htm page in Internet Explorer (Netscape navigator or any Browser) and fill the following

  2. Fill the From common code identifier with Sender Duns or Common Code Identifier

From:(Common Code/Duns ) 183529049

  1. Fill the to common code identifier with Receiver Duns or Common Code Identifier.

To :(Common Code/Duns) 987654321

  1. Fill the Deliver Receipt to with where you want receipt to be sent to.

Deliver Receipt To: 183529049

  1. Type the file name or browse to the file by clicking on the button

Send this file: C:\testdata\Naesbtest.edi.pgp

  1. Submit the form by clicking on “Send File” button

  2. If the target server is protected by basic authentication it will prompt for user name and password

  3. Type the username and password and press “ok” or “Enter”

  4. Browser will display the response, a typical success message is as follows

Upload OK

File Saved at (time- c): 19960123203618

Status (request- status): ok

Server (server- id): SERVER

Transaction ID (trans- id): 232323897

6.2. The HTML Page

<HTML>
<HEAD>
<TITLE>NAESB WGQ 1.6 File Upload</TITLE>
<H1><CENTER>NAESB WGQ File Upload</CENTER></H1>
</HEAD>
<HR>
<BODY>
<form ENCTYPE="multipart/form-data" ACTION="Target URL" METHOD=POST>
<table align="center"><tr><td colspan="2">
<b>Enter Common Code Identifier for From and To</b></td></tr>
<br>
<tr><td>
From:(Common Code/Duns)</td><td>
<input TYPE="text" NAME="from" SIZE=30 VALUE=""><br></td></tr>
<tr><td>To:  (Common Code/Duns)
</td><td><input TYPE="text" NAME="to" SIZE=30 VALUE=""><br></td></tr>
<tr><td>NAESB WGQ EDM Version:</td><td>
<input TYPE="text" NAME="version" SIZE=30 VALUE="1.6"></td></tr>
<tr><td>Deliver Receipt To:</td><td>
<input TYPE="text" NAME="report-disposition-to" SIZE=30 VALUE="Receipt Disposition to "></td></tr>
<tr><td>Receipt Type:</td><td>
<input TYPE="text" NAME="receipt-report-type" SIZE=30 VALUE="gisb-acknowledgement-receipt"></td></tr>
<tr><td colspan="2">For  requesting signed receipts also include:</td></tr>
<tr><td>Receipt Type:</td><td>
<input TYPE="text" NAME="receipt-security-selection" SIZE=30 VALUE="signedreceipt-
protocol=required, pgp-signature; signed-receipt-micalg=required, md5"></td></tr>
<tr><td>Format of this file:</td><td>
<input TYPE="text" NAME="input-format" SIZE=30 VALUE="X12"><br></td></tr>
<tr><td>Send this file:</td><td>
<INPUT NAME="input-data" TYPE="FILE" value=""></td></tr></table><br>
<center><input TYPE="submit" VALUE="Send File"></center><br>
</form>
</BODY>
</HTML>

7. Appendix C

7.1. Test Script

All connectivity testing should be completed according to the Flight Test Scripts Workbook and Testing Requirements Matrix – TX SET X.X for a specific flight. These scripts can be found on the ERCOT website at https://www.ercot.com/services/rq/lse/trt/index under Key Documents.

8. Terms and Definitions

8.1. Basic Authentication

A security method for web servers that requires the use of a user name and password to enter a web site.

8.2. Batch Browser

A web browser that is capable of uploading data automatically.

8.3. CGI

Common Gateway Interface, the specification that notifies an HTTP server about how to communicate with server gateway programs.

8.4. Decryption

A method using Pretty Good Privacy or another security program to decode data that you have received. In PGP, the sender encrypts with the receiver's public key, and the receiver decrypts with his own private key.

8.5. Databases

Software that allows the user to store, to organize and to retrieve large amounts of information in a specified format. Examples of this software include: Oracle, Informix, Sybase, dBase, and SQLserver.

8.6. Digital Signature

The method used by Pretty Good Privacy when the receiver of information verifies the identity of the sender. It also determines whether the data has been corrupted or tampered with since leaving the sender.

8.7. EDI

Electronic Data Interchange. The phrase given to the standard, electronic format that translates business data in order to conduct business by way of computers.

8.8. EDM

Electronic Delivery Mechanism. The NAESB-defined specification that describes and enables secure, reliable business-to-business E-commerce data exchange.

8.9. Encryption

Using PGP or another security program to scramble (encrypt) the transferred data in a manner that can be unscrambled (decrypted) at the receiving end.

8.10. Firewall

Some form of hardware or software used to protect a company’s internal network from access by unauthorized users via the Internet.

8.11. Flat file (FF)

A computer file that contains printable characters.

8.12. HTML

Hypertext Markup Language. A set of tags that govern graphical and textual interface viewed through some sort of web browser.

8.13. HTTP

Hypertext Transfer Protocol. A protocol used by web browsers to transfer information about location, etc.

8.14. Interchange

A group of transaction sets sent electronically by a Trading Partner.

8.15. ISP

Internet Service Provider. A company that provides access to the Internet.

8.16. Multipart forms

A standard specification for passing files and associated information using HTTP, as defined in RFC 1867.

8.17. PGP

Pretty Good Privacy Security software used to protect data transfer between computers communicating over the Internet.

8.18. Secure Sockets Layer (SSL)

A cryptosystem that allows SSL-enabled browsers to send and receive information privately across the Internet public domain.

8.19. TCP/IP

Transmission Control Protocol/Internet Protocol -- the fundamental protocol of the Internet upon which most other protocols, HTTP, FTP, etc., is built.

8.20. Trading Partner

Companies that have established a trading agreement in order to exchange business transactions in the EDI format.

8.21. Web server

An application supporting some form of web interaction, such as a web page or access by a batch browser.

8.22. X12

A universal business standard for electronic communication between computers defined by Accredited Standards committee of ANSI.