Ercot protocols Section 19: Texas Standard Electronic Transaction November 21, 2009




Yüklə 47.24 Kb.
tarix14.04.2016
ölçüsü47.24 Kb.
ERCOT Protocols

Section 19: Texas Standard Electronic Transaction

November 21, 2009


Texas Standard Electronic Transaction 1

19.1 Overview 1

19.2 Methodology 1

19.3 Texas Standard Electronic Transaction Definitions 2

19.4 Texas SET Change Control Documentation 14

19.5 Texas SET Acceptable Extended Character Set 16

19.6 Texas SET Envelope Standards 16

19.7 Advanced Meter Interval Data Format and Submission 17


Texas Standard Electronic Transaction


This Section of the Protocols contains an overview of the purpose and scope of the Texas Standard Electronic Transaction (TX SET), and a series of definitions identifying the use of each transaction. It also refers to the full implementation guidelines, which will be posted on the Market Information System (MIS) maintained by ERCOT. The specific implementation guidelines are not included either in the body of these Protocols or as an attachment to these Protocols.

19.1 Overview


TX SET describes the standard electronic data transactions, implementation guides, Protocols, principles and procedures that enable and facilitate the processes of Customer Choice in the deregulated Texas electric market. The full implementation guidelines and change control process documents shall be published on the MIS by ERCOT and shall define and serve as the standard electronic Protocols for the applicable TX SET transactions among all Market Participants (MPs) and ERCOT.

This Section shall cover:

(1) Transactions between Transmission and/or Distribution Service Providers (TDSPs) (refers to all TDSPs unless otherwise specified) and Competitive Retailers (CRs) and ERCOT.

(2) Subcommittee and ERCOT responsibilities.

(3) Change control process.

19.2 Methodology


In developing and maintaining the implementation guides, the appropriate ERCOT Technical Advisory Committee (TAC) subcommittee, or its designated working group shall:

(1) Develop standardized transactions, which support documented ERCOT market business requirements across all MPs and ERCOT;

(2) Develop Electronic Data Interchange (EDI) transactions using ANSI ASC X12 standards;

(3) Develop Extensible Markup Language (XML) transactions as needed;

(4) Develop other spreadsheets, templates, comma separated value (CSV) files, etc. as needed;

(5) Develop processes and procedures to be followed in the development of TX SET;

(6) Follow ‘Best Practices’ as identified in the overall technology market place related to development of TX SET;

(7) Develop and follow processes and procedures and follow these for the management of changes to TX SET; and

(8) Develop and follow processes and procedures for the release of new versions of TX SET.

19.3 Texas Standard Electronic Transaction Definitions

19.3.1 Defined Texas SET Transactions


(1) Service Order Request (650_01)

This transaction set:

From the CR to the TDSP via point to point Protocol, is used to initiate the original Service Order Request, Cancel Request, or Change/Update Request.

For every 650_01, Service Order Request there will be a 650_02, Service Order Response transaction.

(2) Service Order Complete, Complete Unexecutable, Reject Response, or Notification of Permit Required (650_02)

This transaction set:

From the TDSP to the CR via point to point Protocol, is used to send a Complete, Complete Unexecutable, Reject, or Notification of Permit Required Response to the CR’s original, Cancel Request, or Change/Update Service Order Request.

For every 650_01, Service Order Request there will be a 650_02, Service Order Response transaction

(3) Suspension of Delivery Service Notification or Cancellation (650_04)

This transaction set:

(a) From the TDSP to the CR via point to point Protocol, is used to notify the CR of a Suspension of Delivery Service Notification or to cancel the Suspension of Delivery Service Notification.

(b) From Municipally Owned Utility/Electric Cooperative (MOU/EC) TDSP to CR, used to notify CR of disconnect/reconnect of delivery service for non-payment of wires charges.

(4) Suspension of Delivery Service Reject Response (650_05)

This transaction set:

From the CR to the TDSP, is used to notify the TDSP of a rejection of a Suspension of Delivery Service Notification or rejection of a Cancellation of a Notification of Suspension of Delivery Service. The CR can only reject for invalid data.

(5) TDSP to CR Invoice (810_02)

This transaction set:

From the TDSP to the CR, is an Invoice for wire charges as listed in each TDSP Tariff, (i.e., delivery charges, Late Payment charges, discretionary service charges, etc.). This TX SET transaction may be paired with an 867_03 (Monthly Usage) to trigger the Customer billing process.

(6) CR to MOU/EC TDSP Invoice (810_03)

This transaction set:

From the CR to the MOU/EC TDSP, is an Invoice for monthly energy charges, discretionary, and service charges for the current billing period. This transaction set will be preceded by an 867_03 (monthly usage) to trigger the Customer billing process.

(7) Maintain Customer Information Request (814_PC)

This transaction set:


  1. From a CR to the TDSP, is used to maintain the information needed by the TDSP to verify the CR’s end use Customer’s identity (i.e., name, address and contact phone number) for a particular point of delivery served by the CR. A CR shall be required to provide TDSP with the information to contact the Customer and to continuously provide TDSP updates of changes in such information.

  2. This transaction set will be transmitted from the CR to the TDSP only after the CR has received an 867_04 Initial (Start) Meter Reading from the TDSP for that specific move-in Customer. Also the CR will not transmit this transaction set and/or provide any updates to the TDSP after receiving an 867_03, final meter read for that specific move-out Customer.

(c) From a MOU/EC TDSP to CR, is used to provide CR with updated Customer information (name, address, membership ID, home phone number, etc.) for a particular point of delivery served by both the MOU/EC TDSP and the CR and to continuously provide CR updates of such information.

(8) Maintain Customer Information Response (814_PD)

This transaction set:

From the TDSP to the CR, or from the CR to MOU/EC TDSP, is used to respond to the 814_PC, Maintain Customer Information Request.

(9) Enrollment Request (814_01)

This transaction set:

From a new CR to ERCOT, is used to begin the Customer enrollment process for a switch.

(10) Enrollment Reject Response (814_02)

This transaction set:

From ERCOT to the new CR, is used by ERCOT to reject the 814_01, Enrollment Request on the basis of incomplete or invalid information. This is a conditional transaction and will only be used as a negative response. If the 814_02, Enrollment Reject Response is not received from ERCOT, the new CR will receive the 814_05, Switch/Move-In Response from ERCOT.

(11) Switch/Move-In CR Notification Request (814_03)

This transaction set:

From ERCOT to the TDSP, passes information from the 814_01, 814_16, or 814_24 (move-out where Continue Service Agreement (CSA) exists), with the addition of two data elements:

(a) The TDSP associated with this Premise; and

(b) The available switch date.

This transaction set will be initiated by ERCOT and transmitted to the TDSP in the event of a Mass Transition.

(12) Switch/Move-In CR Notification Response (814_04)

This transaction set:

From the TDSP to ERCOT, is used to provide the scheduled meter read date that the TDSP has calculated and pertinent Customer and Premise information in response to an Enrollment Request, Move-In Request, Move-Out to CSA Request initiated by a CR or a Mass Transition of Electric Service Identifiers (ESI IDs) initiated by ERCOT. The historical usage, if requested by the submitter of the initiating transaction, will be sent using the 867_02 transaction.

(13) Switch/Move-In Response (814_05)

This transaction set:

From ERCOT to the new CR is essentially a pass through of the TDSP’s 814_04, Switch/Move-In CR Notification Response information. This transaction will complete the new CR’s Enrollment Request.

(14) Drop Due to Switch/Move-In Request (814_06)

This transaction set:

From ERCOT to the current CR, is used to notify a current CR of a drop initiated by a Enrollment Request or drop notification due to a pending move-in from a new CR.

(15) Drop Due to Switch/Move-In Response (814_07)

This transaction set:

From the current CR to ERCOT, is used to respond to the 814_06 initiated by an Enrollment/Move-In Request. If rejected, this transaction will trigger the CR objection process, as allowed by Public Utility Commission of Texas (PUCT) rules.

(16) Cancel Switch/Move-In/Move-Out/Mass Transition DropRequest (814_08)

This transaction set:

(a) From ERCOT to the TDSP, is used to cancel an Enrollment Request, a Move-In Request, a CSA Move-In Request, Move-Out Request, or Mass Transition Drop Request.

(b) From ERCOT to the current CR, is used to cancel a Drop Due to Switch (forced Move-Out or Switch) Request, a Move-Out Request, or a Mass Transition Drop Request.

(c) From ERCOT to the new CR, is used to cancel an Enrollment Request, a Move-In Request, or a Mass Transition Drop Request.

(d) From the current CR to ERCOT, is used to cancel a Move-Out Request. (e) From the new CR to ERCOT, is used to cancel an Enrollment Request or a Move-In Request.

(f) From ERCOT to the CSA CR, is used to cancel a CSA Move-In Request.

(g) From ERCOT to the requesting CR/POLR, is used to cancel pending transactions involved in a Mass Transition.

(17) Cancel Switch/Move-In/Move-Out/Mass Transition Drop Response (814_09)

This transaction set:

(a) From the TDSP to ERCOT, is used in response to the cancellation of an Enrollment Request, a Move-In Request, a CSA Move-In Request, Move-Out Request, or a Mass Transition Drop Request.

(b) From the current CR to ERCOT, is used in response to the cancellation of a Drop Due to Switch (forced move-out or switch) Request, a Move-Out Request, or a Mass Transition Request.

(c) From the new CR to ERCOT, is used in response to the cancellation of an Enrollment Request, a Move-In Request, or a Mass Transition Drop Request.

(d) From ERCOT to the current CR, is used in forwarding the response of the Customer cancel of a Move-Out Request.

(e) From (CSA) CR to ERCOT, is used in response to the cancellation of a CSA CR Move-In Request.

(f) From ERCOT to the submitter of an 814_08, is used to reject the cancellation request.

(g) From POLR to ERCOT, is used in response to the cancellation of pending transactions due to a Mass Transition.

(18) Drop to Affiliate REP (AREP) Request (814_10)

This transaction set is no longer valid as of March 8, 2007 (Reference Project No. 33025, PUC Rulemaking Proceeding to amend Commission Substantive Rules consistent with §25.43, Provider of Last Resort (POLR)

.

(19) Drop Response (814_11)



This transaction set:

(a) ERCOT will send a reject response using the 814_11, Drop Response within one (1) Retail Business Day to the current or notifying the CR that the request is invalid.

(b) From ERCOT to the current CR in response to a Mass Transition.

(20) Date Change Request (814_12)

This transaction set:

(a) From new CR to ERCOT, is used when the Customer requests a date change to the original Move-In Request.

(b) From ERCOT to the current CR is a notification of the date change on the Move-In Request from the new CR.

(c) From ERCOT to the TDSP, is used for notification of a move-in or move-out date change.

(d) From the current CR to ERCOT, is used when the Customer requests a date change to the original Move-Out Request.

(e) From ERCOT to the New CR is notification of the date change on the Move-Out Request from the current CR.

(f) From ERCOT to the CSA CR, is used for a notification of a date change on the Move-Out Request only.

(21) Date Change Response (814_13)

This transaction set:

(a) From ERCOT to new CR, is used to respond to the requested date change to the original move-in date on the 814_12, Date Change Request.

(b) From the current CR to ERCOT, is used to respond to the requested date change to the original move-in date on the 814_12, Date Change Request sent by the new CR.

(c) From the CSA CR to ERCOT is used to respond to the requested date change to the original move-out date on the 814_12, Date Change Request.

(d) From the TDSP to ERCOT, is used to respond to the requested date change to the original move-in or move-out date on the 814_12, Date Change Request.

(e) From ERCOT to the current CR is used to respond to the requested date change to the original move out date on the 814_12, Date Change Request.

(f) From the new CR to ERCOT, is used to respond to the requested date change to the original move-out date on the 814_12, Date Change Request sent by the current CR.

(22) Drop Enrollment Request (814_14)

This transaction set:

From ERCOT to the POLR or designated CR in response to a Mass Transition.

(23) Drop Enrollment Response (814_15)

This transaction set:

From POLR or designated CR to ERCOT in response to a Mass Transition.

(24) Move-In Request (814_16)

This transaction set:

From the New CR to ERCOT, is used to begin the Customer enrollment process for a move-in.

(25) Move-In Reject Response (814_17)

This transaction set:

From ERCOT to the new CR, is used by ERCOT to reject the 814_16 Move-In Request on the basis of incomplete or invalid information. This is a conditional transaction and will only be used as a negative response. If the 814_17 Move-In Reject Response is not received from ERCOT, the CR will receive a 814_05 Switch/Move-In Response.

(26) Establish/Delete CSA CR Request (814_18)

This transaction set:

(a) From the new CSA CR to ERCOT, is used to establish the owner/landlords’ new CSA CR in the registration system.

(b) From the current CSA CR to ERCOT, is used to remove an existing CSA CR from the registration system.

(c) From ERCOT to the current CSA CR, is used for notification that the owner/landlord has selected a new CSA CR.

(d) From ERCOT to the MOU/EC TDSP, is used to validate the CSA relationship information in the MOU/EC TDSP’s system.

(e) From ERCOT to the MOU/EC TDSP, is used for notification of CSA deletion.

(27) Establish/Delete CSA (Continuous Service Agreement) CR Response (814_19)

This transaction set:

(a) From ERCOT to the new CSA CR is used to respond to the 814_18, Establish/Delete CSA CR Request enrolling the new CSA CR in the registration system.

(b) From ERCOT to the current CSA CR is used to respond to the 814_18Establish/Delete CSA CR Request deleting the current CR from the registration system.

(c) From the current CSA CR to ERCOT is used to respond to the 814_18 Establish/Delete CSA CR Request notifying the current CSA CR that the owner/landlord has selected a new CSA CR.

(d) From the MOU/EC TDSP to ERCOT is used to provide a response to the 814_18.

(28) Create/Maintain/Retire ESI ID Request (814_20)

This transaction set:

(a) From the TDSP to ERCOT is used to initially populate the registration system for conversion/opt-in.

(b) From the TDSP to ERCOT is used to communicate the addition of a new ESI ID, changes to information associated with an existing ESI ID, or retirement of an existing ESI ID.

(c) From ERCOT to current CR, and any pending CR(s) is notification of the TDSP’s changes to information associated with an existing ESI ID.

(29) Create/Maintain/Retire ESI ID Response (814_21)

This transaction set:

(a) From ERCOT to TDSP, is used to respond to the 814_20, Create/Maintain/Retire ESI ID Request.

(b) From the current CR and any pending CR(s) to ERCOT, is used to respond to the 814_20, Create/Maintain/Retire ESI ID Request.

(c) From the new CR to ERCOT, is used to respond to the 814_20, Create/Maintain/Retire ESI ID Request.

(30) Continuous Service Agreement (CSA) CR Move-In Request (814_22)

This transaction set:

From ERCOT to CSA CR, is used to start a CSA service for the ESI ID.

(31) CSA (Continuous Service Agreement) CR Move-In Response (814_23)

This transaction set:

From the CSA CR to ERCOT is used to respond to the 814_22, CSA CR Move-In Request.

(32) Move-Out Request (814_24)

This transaction set:

(a) From the current CR to ERCOT, is used for notification of a Customer’s Move-Out Request.

(b) From ERCOT to the TDSP, is notification of the Customer’s Move-Out Request. If a CSA agreement exists on the ESI ID, then the 814_03, Switch/Move-In CR Notification Request is sent instead of the 814_24 Move-Out Request.

(33) Move-Out Response (814_25)

This transaction set:

(a) From the TDSP to ERCOT to the current CR, is used to respond to the 814_24 Move-Out Request. If a CSA agreement exists on the ESI ID and ERCOT sent the 814_03, Switch/Move-In CR Notification Request instead of the 814_24 Move-Out Request, the TDSP will then respond with the 814_04 Switch/Move-In CR Notification Response.

(b) From ERCOT to the current CR is used to respond to the 814_24, Move-Out Request.

(34) Ad-hoc Historical Usage Request (814_26)

This transaction set:

(a) From the current CR to ERCOT, is used to request the historical usage for an ESI ID.

(b) From ERCOT to the TDSP, it is a pass through of the current CR’s 814_26, Ad-hoc Historical Usage Request.

(35) Ad-hoc Historical Usage Response (814_27)

This transaction set:

(a) From the TDSP to ERCOT, is used to respond to the 814_26, Ad-hoc Historical Usage Request.

(b) From ERCOT to the current CR, is a pass through of the TDSP’s response to the 814_26, Ad-hoc Usage Request.

(36) Completed Unexecutable or Permit Required (814_28)

This transaction set:

(a) Is for move-ins and move-outs where a permit is required, or the work is not completed for some reason (completed unexecutable).

(b) For a move-out, this transaction is from the TDSP to ERCOT, and from ERCOT to the current CR, to notify the current CR the move-out was unexecutable. Upon sending this transaction, the TDSP closes the initiating move-out transaction. The CR must initiate corrective action and resubmit the Move-Out Request.

(c) For a move-in, this transaction is from the TDSP to ERCOT, and from ERCOT to the new CR, or the current CR for energized accounts, to notify the CR that the work was completed unexecutable, or that a permit is required. Upon sending this transaction to notify the new CR of a completed unexecutable, the TDSP closes the initiating transaction. The new CR must initiate corrective action and resubmit the Move-In Request.

Upon sending the 814_28 (PT) transaction to notify the New CR that a permit is required, ERCOT will allow the TDSP twenty (20) Retail Business Days to send the 814_04 due to permit requirements. After the twenty (20) Retail Business Days if no 814_04 is received, ERCOT will then issue an 814_08. If the move-in is cancelled due to permit not received, ERCOT will note the reason in the 814_08.

(37) Response to Completed Unexecutable or Permit Required (814_29)

This transaction set:

From the CR (current CR for a move-out or a new CR for a move-in) to ERCOT, and from ERCOT to the TDSP (and to the current CR for a move-in of an energized account) is used to notify the TDSP that the CR has received the 814_28, Response to Completed Unexecutable or Permit Required or to reject the 814_28, for invalid data. The CR is not permitted to reject the 814_28 for any other reason.

(38) CR Remittance Advice (820_02)

This transaction set:

From the CR to the TDSP, is used as a remittance advice concurrent with a corresponding payment to the TDSP banking institution for a dollar amount equal to the total of the itemized payments in the 820_02. This transaction will reference the 810_02 Invoice by ESI ID. If payment and remittance are transmitted together to a financial institution, this implementation guide may be used as a baseline for discussion with the payer’s financial institution. All “must use” fields in the 820_02 must be forwarded to the payer’s financial institution and be supported by the payee’s financial institution.

A single payment sent via the bank and a single remittance sent to the TDSP can include multiple Invoices, however a one to one correlation must exist between the payment submitted to the bank and the corresponding remittance advice to the TDSP.

(39) Remittance Advise (820_03)

From the MOU/EC TDSP to the CR, is used as a remittance advice concurrent with a corresponding payment to the CR banking institution for a dollar amount equal to the total of the itemized payments in the 820_03. This transaction will reference the CR’s Customer account number and ESI ID. If payment and remittance are transmitted together to a financial institution, this implementation guide may be used as a baseline for discussion with the payer’s financial institution. All “must use” fields in the 820_03 must be forwarded to the payer’s financial institution and be supported by the payee’s financial institution.

(40) Application Advice (824)

This transaction set:

(a) From the CR to the TDSP, is used by the CR to reject and/or accept with exception the 810, Invoice sent by the TDSP.

(b) From ERCOT to the TDSP to reject the 867_03, Monthly Usage transactions sent by the TDSP.

(c) From the CR to ERCOT to reject the 867_03, Monthly Usage transactions sent by ERCOT.

(d) From the MOU/EC TDSP to the CR is used to reject the 810_03 Invoice sent by the CR.

(41) Historical Usage (867_02)

This transaction set:

(a) From the TDSP to ERCOT, is used to report historical usage.

(b) From ERCOT to the CR, it is essentially a pass through of the TDSP’s 867_02, Historical Usage.

(42) Monthly Usage (867_03)

This transaction set:

(a) From the TDSP to ERCOT, is used to report monthly usage.

(b) From ERCOT to the CR, is essentially a pass through of the TDSP’s 867_03, Monthly Usage.

(c) From ERCOT to the TDSP or CR for ERCOT polled services.

(43) Initial Meter Read Notification (867_04)

This transaction set:

(a) From the TDSP to ERCOT is used to report the initial read associated with a Enrollment Request or a Move-In Request.

(b) From ERCOT to the new CR is used to report the initial read associated with a Enrollment Request or a Move-In Request.

(44) Functional Acknowledgement (997)

This transaction set:

From the receiver of the originating transaction to the sender of the originating transaction, is used to acknowledge the receipt of the originating transaction and indicate whether the transaction passed ANSI X12 validation. This acknowledgement does not imply that the originating transaction passed TX SET validation. CR, TDSP, or ERCOT shall respond with a 997 within 24 hours of receipt of an inbound transaction.

Functional Acknowledgements provide a critical audit trail. All parties must send Functional Acknowledgements (FA/997) for all EDI transactions. Parties will track and monitor acknowledgements sent and received.

(45) Unplanned Outages: Outage Status Request (T0)

This transaction set:

From a CR to TDSP, is used to request Outage status. This is not a required transaction for an Option 1 CR reporting Unplanned Outages.

(46) Unplanned Outages: Trouble Reporting Request (T1)

This transaction set:

From a CR to TDSP, is used to report an Outage or service irregularity requiring near Real Time Outage response. This is a required transaction for an Option 1 CR to electronically transmit to the TDSP for every valid outage or service irregularity reported.

(47) Unplanned Outages: Trouble Report Acknowledgement (T2)

This transaction set:

From a TDSP to CR, is used to acknowledge the receipt of a Trouble Request with either an acceptance or a rejection response. This is a required transaction for the TDSP, when an Option 1 CR utilizes the Trouble Reporting Request transaction.

(48) Unplanned Outages: Outage Status Response (T3)

This transaction set:

From a TDSP to CR, is used to provide status information for a previously submitted Outage Status Request message. This is a required transaction for the TDSP when an Option 1 CR utilizes the Outage Status Request transaction.

(49) Unplanned Outages: Trouble Completion Report (T4)

This transaction set:

From a TDSP to CR, is used by the TDSP to notify the CR that the trouble condition has been resolved. This is a required transaction for the TDSP when an Option 1 CR utilizes the Trouble Reporting Request transaction.

19.3.2 Additional SET Transactions


The appropriate TAC subcommittee, or its designated working group, will develop additional transactions as required.

19.4 Texas SET Change Control Documentation

19.4.1 ERCOT TAC Subcommittee Responsibilities


The appropriate ERCOT TAC subcommittee, or its designated working group, will continue to:

(1) Upgrade the standards as needed (based on ideas from MPs, changes to the Protocols or changes in communication standards e.g. changes in ANSI ASC X12 standards), and



(2) Coordinate timing for changes in any of the TX SET transactions.

19.4.2 ERCOT Responsibilities


ERCOT will facilitate the activities listed in Section 19.4, Texas SET Change Control Documentation, by overseeing the change control activities of the TX SET transactions.

19.4.3 Dispute Process


A Market Participant may dispute technical requirement(s) identified in the TX SET Implementation Guide by registering the dispute with ERCOT and the appropriate subcommittee or working group.

19.4.4 Change Control Process


The appropriate TAC subcommittee, or its designated working group, shall make modifications and additions to TX SET transactions in accordance with this Section. TX SET transactions will be expanded and modified to accommodate market or regulatory requirements on an ongoing basis. It is understood that change control is vital in order to allow the market to function successfully on a daily basis. Each MP will rely on established, documented, and tested transactions, yet must have a process by which to modify, test, and implement changes in an efficient, effective, timely, and well-coordinated manner. This change control document provides the process by which changes to the standards may be discussed, reviewed, accepted, and implemented.

19.4.5 Responsibilities of TAC Subcommittee


In order to accommodate the change control process, ERCOT in conjunction with the appropriate TAC subcommittee, or its designated working group, will maintain, publish, and post the standards and the ongoing modifications/enhancements to these standards on the MIS. A consolidated new release of the standards will be published and electronically posted based on the nature and priority of changes requested. The consolidated new release publication will encompass all changes implemented during the period subsequent to the last released publication and will be posted to the MIS.

19.4.6 Submission of Proposed Changes


An Entity proposing a change shall notify ERCOT and/or the TAC subcommittee/designated working group chairperson(s). ERCOT will notify MPs of any change requests. MPs may participate in ERCOT sponsored change control discussions. The TAC subcommittee/designated working group will review and develop a resolution to the change/modification and publish the results. ERCOT will then notify the Entity proposing the change/modification of the results.

19.4.7 Priority Classifications of Standard Electronic Transaction Changes


The appropriate TAC subcommittee, or it’s /designated working group, will classify all proposed changes and enhancements in one of the following two categories:

19.4.7.1 Emergency Change Request


Changes/enhancements to the guidelines must be updated as soon as reasonably practicable. If the current standards cannot accommodate Customer choice and an urgent modification of the standard is required, the appropriate TAC subcommittee, or its designated working group, will classify a requested change as an emergency change.

19.4.7.2 Non-Emergency Change Request


Changes/enhancements to the guidelines must be updated by the next release following adoption. If the suggested modifications/enhancements will address immediate regulatory and competitive market issues and mandates, but do not meet the requirements for emergency change, the appropriate TAC subcommittee, or its designated working group, will classify a requested change as non-emergency. Non-emergency may be implemented with a redline to the guideline if it does not affect production.

19.5 Texas SET Acceptable Extended Character Set

19.5.1 Alphanumeric Field(s)


For use on an alphanumeric field, TX SET recognizes all characters within the basic character set. Within the extended character set, TX SET recognizes all character sets except all select language characters found in Section (4) of X-12 Standards Application. Segment/data element gray box guidelines for alphanumeric fields take priority over ANSI standards where the TX SET guidelines further limit acceptable values for a segment/data element.  TX SET guidelines cannot extend the acceptable values to characters that are not allowed by ANSI standards for a segment/data element.

19.6 Texas SET Envelope Standards

19.6.1 ERCOT Validation


ERCOT acts as the certificate authority and generates a digital certificate on behalf of each Market Participant (MP). The MP must be identified uniquely within the ERCOT System.

19.7 Advanced Meter Interval Data Format and Submission


Transmission and/or Distribution Service Providers (TDSPs) will provide fifteen (15)-minute interval data to ERCOT from provisioned Advanced Meters using an ERCOT specified file format submitted via North American Energy Standards Board (NAESB) on at least a monthly basis.

PUBLIC


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azrefs.org 2016
rəhbərliyinə müraciət

    Ana səhifə