Texas Market Test Plan/Retail Commercial Operations

Version 1.2
January 8, 2004

Prepared by 

Texas Test Plan Team
Retail Market Subcommittee Workgroup

Table of Contents
Table of Contents
Document History
Texas Market Test Plan
Purpose and Scope
Exclusions
Testing Assumptions
Testing Overview
Testing Website
Testing Signoff Worksheet (TSW)
Testing Flight Schedule
Testing Guidelines
In-Flight/Out-of-Flight Testing
System Changes
Testing Details
Data Loading
Certification
Testing Requirements of ERCOT and Market Participants
General Marketplace Requirements
CR Requirements
TDSP Requirements
ERCOT Requirements
PUCT Requirements
Market Flight Administrator Requirements
Details of Testing Phases
Technical Connectivity and Verification
End-to-End Testing
Point-to-Point Testing
ERCOT Testing on Demand (ETOD) Testing
Success Criteria
Scenarios and Testing Scripts
Business Process Scenarios
Test Scripts
Appendices
Appendix A - Testing Signoff Worksheet
Appendix B - Resources
Appendix C - Marketplace Issue Resolution Form
Appendix D - Texas Test Plan Team (TTPT) Participants
Appendix E – Texas Market Transactions
Document History 
Date/Version	Summary of Changes	
01-08-04 v1.2	· Re-formatted TMTP document; Defined Testing Guidelines section; added appendix; updated TX SET business process scenarios	
11-03-03 v1.11	· Updated Technical Connectivity and Verification section to include NAESB EDM data transport method.  Added references to NAESB EDM data transport throughout document.	
01-29-03 v1.10	· Updated to reflect ERCOT role as testing facilitator, Issue Resolution Process, transaction additions and testing requirements applicable to various market participants; deleted the term ITPTA	
09-19-02 v1.09	· Updated the Re-testing guidelines timelines to be consistent across sections.	
04-30-02 v1.09	· Revised Re-testing guidelines to provide for ERCOT notification to the TTPT Chair 	
04-26-02 v1.09	· Revised purpose and scope section and re-testing section to clarify that the TMTP was for the Retail Market	
04-11-02 v1.09	· Updated Re-testing guidelines to add clarification	
03-28-02 v1.09	· Incorporated edit following TTPT review on 3-15-02	
03-12-02 v1.09	· Revised re-testing section to reflect the use of automated testing	
02-10-02 v1.08	· Incorporate information on automated testing · Provided addition explanation for the use of Testing Sign-off Worksheet and Technical Connectivity Worksheet · Provided additional details on testing the Replacement FTP process · Included details on transactions not support by the ERCOT portal · Added section on Point-to-Point testing · Updated Texas Retail Testing website address to etod.ercot.com	
12-13-01 v1.07 Final	· Incorporated re-testing guidelines and change in ERCOT connectivity process	
10-29-01 v1.07 Draft	· Update to reflect changes required for testing during 2002	
08-29-01 v1.06 	· Update to reflect changes required for Flight 1001	
06-17-01 v1.05 Draft	· Update to reflect changes required for Flight 3801	
05-03-01 v1.04 Final	· Moved from DRAFT to FINAL · Changed all ‘Certification’ references to ‘Qualification’	
04-19-01 v1.04 Draft	· Added language to clarify testing for ERCOT Market Portal · Added section on Test Plan Change Control · Added language for provisional qualification guidelines · Deleted TTPT membership information and published on website	
03-14-01 v1.03	· Final Draft · Refreshed script table · Clarified success criteria · General syntax/grammar/consistency cleanup	
02-21-01 v1.03d	· Second draft	
01-23-01 v1.0d	· First draft	

Texas Market Test Plan 
Purpose and Scope
The purpose of this document is to define a market plan for testing retail commercial operations systems to support the Texas Electric Choice Market.  This document covers all retail testing requirements and procedures between ERCOT and the Market Participants (MPs) and Point-to-Point retail testing between MPs.  It provides the mechanism for ensuring that the central retail systems operated by ERCOT are functioning properly, and that the retail systems operated by MPs interface properly with both ERCOT’s systems and other MPs systems. The Texas Market Test Plan addresses the following: 
•	Testing Guidelines
•	Testing Details
•	Testing Requirements for Market Participants and ERCOT
•	Testing Phases
•	Success Criteria
•	Overview of Testing Scenarios for Certification in the Texas Market

The Texas Test Plan Team (TTPT) is responsible for maintaining and updating the information in this document as defined in Section 23.3 of the ERCOT Protocols. All references to testing in the document are directed to the Retail Market.  
Exclusions
The Texas Test Plan Team (TTPT) periodically reviews the Texas Market Test Plan to ensure all testing requirements are defined to meet the evolving Texas Electric Market. The only known issue that is not included in this version is:
·	XML - There are no scripts for testing XML-based transactions.
Testing Assumptions
·		MPs who wish to participate in the market using NAESB EDM or Replacement FTP, and the ERCOT Market Portal for conducting commercial retail operations in the Texas Marketplace will refer to this document for guidelines on these processes 
· 	MPs may elect to not participate in testing optional processes as identified in this document but will inform their trading partners and the Market Flight Administrator in advance. 
·		Automated internal processes will be used when testing.  Any areas that require manual interaction or data manipulation must be documented in advance in the Testing Signoff Worksheet and communicated to testing partners at the beginning of the testing cycle.  
•	   MPs planning to use the ERCOT Market Portal will indicate this in their Testing Signoff Worksheet.
·	  The Market Flight Administrator is the final authority on all levels of Business Process Certification among trading partners, including the verification that a party has successfully passed testing and is eligible to go into production. 
·	The Market Flight Administrator will moderate testing and report inconsistencies to ERCOT, RMS or an appropriate committee.
·	Functional Acknowledgements provide a critical audit trail.  All parties will send Functional Acknowledgements (FA/997) for all EDI transactions (except for the receipt of a 997, which would create an endless cycle) during testing.  Parties using the ERCOT Market Portal will receive web-based acknowledgements.  Parties should track and monitor acknowledgements sent and received.
•	ERCOT supports XML is an alternative method for submitting transactions to ERCOT, however, supporting details for a test of XML (e.g. Standards qualification, Connectivity, etc.) are not provided in the TMTP.  This Test Plan was optimized for testing Commercial Retail Operations using TX SET/ANSI X12 EDI transactions, and the ERCOT Market Portal.  

Testing Overview
Testing Website
The Market Flight Administrator maintains a Texas Retail Testing website that details the current status of the testing process.  The URL address for this website is:  
<http://etod.ercot.com/>
This website includes:
·		The Texas Marketplace Test Plan  (TMTP)
·	Test Scripts
·	Daily agenda and minutes of each conference call
·	TTPT meeting schedule
·	Testing contact lists
·	Frequently Asked Questions (FAQs) on the Testing Process
·	Testing Status - Each organization will be able to obtain a status of the testing process, including its own status.  Information will be secured by organization.
·	Architecture Market Links
·	File Cabinet for significant testing materials
·	Testing Sign-off Worksheet (TSW)
·	Technical Connectivity Worksheet

Testing Signoff Worksheet (TSW)
Each MP completes a Testing Signoff Worksheet (TSW) on-line. This worksheet includes basic contact information required for effective testing. It also identifies processes that will be tested including optional functions that the MP will use in their business plan and which they plan to test. The TSW can be found at the following link: 
<http://etod.ercot.com/Signoff.asp?Method=TOC>
Contacts
Parties must provide daily and emergency contact information for the test lead, and the test lead alternate. Issue Resolution procedures require that an executive level contact also be provided.
At least one Business Contact must be an employee of the Market Participant, not a vendor or service provider.
Exceptions to the Test Plan
Parties cannot arbitrarily require other parties to test certain features, scenarios or scripts, nor can they arbitrarily not test certain features, scenarios or scripts.  This Test Plan details full-testing requirements for MPs.  There are legitimate scenarios where a party will not support a feature or scenario that is identified in a test script.  In these cases, a party can claim an ‘exception to the Test Plan’.  These exceptions must be documented in the TSW, and must be approved by the Market Flight Administrator.  The Market Flight Administrator will review exceptions on a case-by-case basis to determine the impact on the Marketplace.  Parties that claim exceptions will not be required to test those features. Once approved, this information will be shared with trading partners.
Manually-Assisted Processes
Each party must identify the different processes that directly support data exchanges that require manual intervention.  Manual intervention increases the risk of errors or process failures.  X12-formatted files should never be altered manually except in the case of a simulated error for a test script. This information will be shared with trading partners.
Sample Transactions
To mitigate the risk of parties not being prepared, an important test step is the X12/TXSET validation of transactions.  Each MP is required to submit sample of all transaction types that the MP will use in testing and production.  Thesetransactions will be validated against the standards, and identify errors that violate the standard.  For ERCOT transactions, ERCOT will forward their transactions for validation.   For Point-to-Point transactions, each MP will also forward the sample transactions for validation. 
CRs choosing to test using the ERCOT Web Portal are required to submit a subset of the appropriate transactions for validation..
A list of sample transactions can be found in Appendix E. 
Testing Responsibilities
The ‘Testing Responsibilities’ section details the responsibilities each party has in the testing process.  This Test Plan is focused on testing the most significant features of the marketplace.  Many tests that were considered ‘internal’ tests were removed from the Test Plan to optimize it.  However, some of these tests were deemed important and as a result appear in the ‘Testing Responsibilities’ section of the TSW.  Also, each party has certain obligations prior to, during and after testing

Testing Flight Schedule
Test flights for the year are approved by the TTPT, RMS and TAC and are posted on the Texas Retail Testing Website.
http://www.ercot.com/Participants/Committees/ttp_comm.htm
Most Flights will take approximately 10 to 12 weeks including Connectivity. 
Testing Guidelines
In-Flight/Out-of-Flight Testing
Market Testing can be categorized as two types, In-Flight and Out-of-Flight testing.  In-Flight Testing consists of market approved scheduled flight tests, Out-of-Flight testing is considered only for those changes deemed an ‘emergency’. 

There are a defined number of test flights approved each year by the Retail Market Subcommittee, as directed by the PUCT.  As mentioned above, emergency changes are currently the only changes that will be considered for Out-of-Flight testing. Out of Flight testing requires advance notice to ERCOT and the Market Participant testing contacts listed on the testing website.  Upon confirmation of the ‘emergency’ change by the Market Flight Administrator, based on the scenarios described further in this section,  a mutually agreeable out of flight testing schedule will be developed between parties.   If an MP is unsure of the lead-time required, it is best practice to contact the Market Flight Administrator for guidance or clarification.

This section provides baseline requirements to assist a Market Participant in determining whether their change qualifies for out of flight testing, or needs to be tested in an approved test flight. .  These guidelines are intended to minimize risk to the Marketplace.  Market Participants (MPs) should follow well-defined internal change management processes that document results and demonstrate due diligence when making changes. 
Specific guidance on each of these areas is provided in detail below.

Out of Flight Testing
Emergency Changes
There are a number of scenarios that may dictate emergency action to resolve production problems. Out of Flight testing guidelines address situations like:
·	System failures, disaster recovery, and/or business resumption plan execution
·	Changes of failing internal or subcontracted entities - There are a number of situations that may require a party to quickly replace an entity because of production failures.
·	Current bank used by MP goes out of business
If a Market Participant encounters a situation that can be categorized by one of the above-mentioned scenarios, that MP must contact the Market Flight Administrator to determine an appropriate schedule for testing
Emergency changes considered for out of flight testing does not include market wide emergency changes that may occur due to a PUCT Ruling.

In Flight Testing
Certified Market Participant Changes Service Provider
A Market Participant who is certified in the Texas Marketplace with the current TX SET version that chooses to change their Market Interface Service Provider to another Market Interface Service Provider is required to execute tests during a scheduled market test flight. Market Interface Service Provider is a term used to refer to an MP’s internal organization or an outsourced company that provides both connectivity and translation services for an MP. There are no additional requirements if the MP chooses a Market Interface Service Provider that has successfully tested in the Marketplace provided they tested using the current TX SET version. This includes changes to internal organizations, external subcontractors, and/or external companies and service providers.
A MP that chooses to use a Market Interface Service Provider that has not successfully completed certification testing is required to contact the Market Flight Administrator to determine what Connectivity and Translator tests they are responsible for executing during the next scheduled market test flight
New Market Interface Service Provider Checklist
1.	 Provide new Testing Signoff Worksheets (TSW) and Technical Connectivity Worksheets (TCW) to all trading partners (as required by test flight).
2.	Provide transaction samples to ERCOT
3.	Receive feedback on transaction samples from ERCOT

New Trading Partnership
All new trading partnerships must go through the testing process as prescribed in the TMTP during a scheduled market test flight.

Certification Revoked by PUCT
There are scenarios where the PUCT will revoke a CR/REP’s certification.  In this case, retail market certification is also revoked.  The CR/REP will be treated as a new MP, and must complete all certification testing during a scheduled market test flight in order to re-enter the marketplace.

Dormant Market Participants
A certified MP may choose to not actively participate in the Marketplace.  Regardless of this decision, they are required to maintain certification according to the current Marketplace baseline, including TX SET version and associated emergency change controls.  A party that fails to maintain the current baseline certification loses its certification.  A MP that has certified in the current version is not required to re-test to enter the market.
All new trading partnerships must go through the testing process as prescribed in the TMTP during a scheduled market test flight.

Banking Changes
Trading partners must be notified when changes occur with the banking institutions they use. The changes may be caused by any number of reasons including bank mergers or upgrades to newer releases of ANSI standards. These changes may result in new routing codes, account numbers, format changes to the remittance advice or other changes that would effect one parties ability to deliver and/or reconcile invoices and payments. When such changes occur, it the responsibility of the party whose bank made the change to initiate testing with their trading partners. 
Testing should use one or more of the following methods to verify that payments and remittances between trading partners remain timely and accurate. 
•	Pre-note 
•	Live invoice
•	Penny test
•	Invoice/Remittance (RA001)

System Changes

During the normal course of Marketplace operations companies will need to make changes to their systems, including connectivity systems, translation systems, and other back-end systems including billing, metering, customer information, etc.  Once a party has qualified and is in production in the Marketplace, changes to systems can have a significant impact on trading partners and the Marketplace. 
System Change Assumptions 
·	System changes made by one MP can have an impact on trading partners (TPs) of that MP.
·	An MP should do sufficient internal testing, including regression testing, to minimize the impact of changes on its TPs.
·	An MP should communicate to its TPs clearly and early regarding changes to systems.  This includes advance notice of the change, copies of migration plans, etc…
·	An MP should identify a ‘back-out’ strategy where appropriate in case problems as a result of changes cannot be resolved quickly.
·	‘Translator systems’ include any hardware, software, and system configuration used to create the ANSI X12-compliant files sent to TPs.  It does not include mapping.
·	‘Connectivity systems’ include any hardware, software and system configuration used to deliver files to and from a TP.  It includes the GISB--based electronic delivery mechanisms (EDM). 
·	‘Service Provider’ is a vague term that can refer to many different types of entities used by MPs in the Marketplace.  These include connectivity, translation, testing, billing, metering, etc.
·	Market Interface Service Provider is a term used to refer to an MP’s internal organization or an outsourced company that provides both connectivity and translation services for an MP.
·	While many changes to systems will be intentional and planned; there are emergency scenarios, such as a system failure, where advanced planning and notice are not possible.

System Change Categories
Connectivity System Changes and/or Updates
Connectivity is defined as the systems used to send and/or receive files to/from your trading partners.  These include NAESB EDM for CR/TDSP/ERCOT communications as well as changes in security keys, IP addresses, DNS names, and DUNS numbers.

Connectivity Change Checklist
1.	Communicate the planned changes to communication systems Notification needs to be provided to the Market Participant testing contact listed in the Technical Connectivity Worksheet (TCW) on the website, in accordance with sign-up for an approved flight test
2.	Send new Technical Connectivity Worksheets and new Trading Partner Agreements to TPs where necessary, including changes to DUNS, IP address, name change, or any other change to the information on the Technical Connectivity Worksheet (TCW).
3.	Complete the change during the approved flight test and schedule migration date with each trading partner. If connectivity is the only change for that trading partner the migration date is not dependent upon the end of the flight test.

Major changes to communication protocols may require more rigorous testing.  Specific requirements for testing these changes will be defined within the specifications for the new communication protocol.   

Translator System Changes and/or Updates
Translators or systems used to perform the data transformation that create EDI ANSI X12 files may be changed or require upgrades.  These changes pose significant risks to individual participants and the marketplace as a whole.  All participants in the market should therefore address these changes with a clear understanding that;
·	ERCOT and market participants need to take responsibility for any changes they make in their data transformation system(s) and test with trading partners when they perceive a risk.
·	ERCOT and market participants need to do internal testing to help minimize the risk to the market.
·	Best practices include regression testing of translator changes using historical data.

Translator Change Checklist
1.	Communicate the planned changes to translator or data translation systems to the   Notification needs to be provided to the Market Participant testing contact listed in the Technical Connectivity Worksheet (TCW) on the website.
2.	Produce and send to the ERCOT Testing on Demand (ETOD) system transaction samples as defined for certification testing in the TMTP section on Technical Connectivity and Verification
3.	Notify trading partners of specific work plans.  Notification needs to be provided to the Market Participant testing contact listed in the Technical Connectivity Worksheet (TCW) on the website.
4.	Complete the change and confirm successful migration with each trading partner.

Back-end System Changes and/or Updates
RMS defines a company’s “back-end systems” as any part of an MP system that exists behind the direct communication interface or connectivity protocol (GISB, FTP, HTTP, etc.) with other MPs.  Once the data passes through the communication interface, the data enters the back-end system.  Because each MP's back-end system architecture is different, back-end systems could include, but are not limited to, the translation software, the business process management system, or the data management system (database).

ERCOT and/or MPs are required to take responsibility for any changes they make in their back-end system(s) and, if a potential risk is perceived, should test with trading partners to minimize that risk.  MPs should follow change management best practices, including extensive internal testing, regression testing on historical data, etc.

ERCOT and MPs are not required to test when changes are made to their back-end system(s).  As part of the company’s internal testing procedures, they may choose to test with all, some, or none of their trading partners, however, it is considered good business practice for MPs and ERCOT to communicate any changes, replacements, and/or upgrades to their trading partners.

Back-end System Change Checklist
1.	Where appropriate, notify TPs of the planned changes to back-end systems. Notification needs to be provided to the Market Participant testing contact listed in the Technical Connectivity Worksheet (TCW) on the website
2.	Where appropriate, communicate testing plans to TPs including cut-over, migration and back-out plans
3.	Where appropriate, coordinate and agree on plan schedules/milestones with TPs
4.	Complete the change and confirm successful migration with each trading partner

Marketplace Functional Changes
Marketplace functional changes can include the following:
·	New tracks, such as Continuous Service Agreement (CSA), Affiliated Retail Electric Provider (AREP), and Competitive Metering (COMET)
·	New TX SET versions, including normal and emergency change controls.
·	New transactions 
·	Outage proof of concept
·	New Connectivity Options (NAESB)
Marketplace Production Failures
Nearly all production failures and/or rejections increase the costs of the Marketplace.  Parties are required to work through any production failures directly with their TPs.  
Parties that habitually cause these failures may be required to conduct additional testing to demonstrate their certification.  Parties that are the victims of production failures can use the defined Issue Resolution Process after several direct attempts to resolve the problems have failed.

.

Testing Details
Synchronized Testing 
Synchronized testing requires that each party execute the same frame across all TDSPs.  For example, the day Frame 1 of End-To-End testing starts, all CRs will send in all of the transactions identified in Frame 1 to begin scripts they will test.  If CR #1 is participating in 5 TDSP territories, the CR will send a number of enrollment transactions; i.e., 1 transaction for each of the test scripts that involve enrollment for each of the 5 TDSPs. There is significant risk in this type of testing if parties are not prepared and cannot keep pace with the test schedule.
MP Testing Flights 
Testing “Flights” have been established to organize testing scenarios into pre-defined groups.  Specific details of these flights are covered in the section “Details of Testing Phases” herein below.  Flight testing will occur according to schedules announced by ERCOT, TTPT and the Market Flight Administrator.   
Scenarios
The TX SET workgroup has defined a number of business process scenarios.  The Test Plan is focused on exercising these scenarios; especially business processes that are frequently executed and/or may cause major problems.
Scripts
The Test Scripts defined in this document detail each step of the testing process for each Scenario.  There may be several test scripts for a defined business process scenario.  For example, a number of processes may be tested for both positive and negative (reject) results.  The Test Scripts are numbered using the defined TX SET scenario category (e.g. A, B) and a unique number.  The unique number is used to eliminate possible confusion in scripts.

Each Test Script is assigned a unique ESI ID number by each of the TDSPs.  When a CR begins testing with a TDSP, the CR will be given a list of ESI IDs and associated Test Scripts with Rate Class, Meter Type, Status of Current CR, Cycle Read Dates, Customer Name and Zip Code, and Meter Number when applicable.
The TDSP provides an ESI ID template to ERCOT and the CR prior to the start of the test. The CR must create their transactions using the data provided in the template.

	E.g.	ESI ID # 0000000000011234567	Test Script SF001
			ESI ID # 0000000000002223344	Test Script SF002

TDSPs will not designate ESI ID information for the automated scripts. CRs will develop ESI IDs that are compliant with ERCOT’s data conversion standards to ensure they pass validation requirements of the automated test system.
Frames
For End-to-End testing, each Test Script involves an exchange (request and response) of data between trading partners. Each step in the process is generally referred to as a ‘Frame’.  Frames can be broken down into steps or test days.  Each frame involves a two-week time period; i.e., two weeks of actual calendar time and one week of simulated system time.   . However, based on the amount of activity within a Frame, the Market Flight Administrator may alter this timing based on progress of the Market Participants.  To accommodate these changes, it may be necessary for an MP to bypass logic that enforces rules for exchanges that require waiting longer than the scheduled number of days.  Transition from one frame to the next should occur when the parties have successfully completed the current frame. MPs are required to keep up with the market testing pace. Should a situation arise where a market participant falls behind, the test will progress as fast as the slowest participant.. MPs that are consistently unable to keep up may be asked to leave the test.
Simulated System Dates for Tests
The Test Scripts identify two types of dates for each ‘frame’: the actual calendar date that the testing for that frame will begin, and the simulated system date for that frame.  Only business days will be used for the simulated system dates.
All tests will use simulated dates that are at least eight (8) weeks earlier than the actual date of the testing.  This provides time for the TDSPs to condition their Test Beds with relatively current and actual data. 
There may be times when system clocks are held on a particular frame/date to allow Market Participants to catch up or make fixes to their system, or times when system clocks are advanced multiple days within a short timeframe. The Market Flight Administrator will provide direction on these actions during the daily conference calls to ensure efforts are made to keep Market Participant system clocks synchronized 
Meter Read and Switching Cycles
The Test Scripts will test both on-cycle and off-cycle initial reads and switches.  Cycle types and dates will be explicitly identified for each script. Sufficient accounts will be established for the required profiles and number of testing CRs.
EDI versus ERCOT Market Portal
CRs can certify using either TX SET EDI with ERCOT and TDSPs, or by using ERCOT’s Market Portal to exchange transactions with ERCOT and EDI to exchange transactions with TDSPs.  CRs must complete EDI-based testing of Point-to-Point transactions with their trading partners.  For testing purposes, MPs are required to identify how they will test and complete testing using that approach. If a party chooses to test using EDI transactions, the party will automatically qualify for use of the ERCOT Market Portal.  All transactions must be tested prior to use in production. If a party chooses to test using the ERCOT Market Portal, they will not automatically qualify for use of EDI transactions with ERCOT.  Parties that complete certification using the ERCOT Market Portal that subsequently decide to use EDI with ERCOT will need to complete the certification testing using EDI.
Transactions that are not supported by the ERCOT Market Portal are the Point-to-Point transactions sent directly between trading partners;
	814_PC and PD, Customer Information Changes
	810_02, TDSP Invoice
	820_02, CR Remittance
	650_01, _02, _04, _05, Service Orders/Requests , and Disconnects for Non Pay 
Schedule Slippage
The Test Schedule and Test Bed data has been designed to allow for slippage. However, the time available for a Flight is generally very tight and it is imperative that all parties make every effort to maintain the established schedule.  If parties fall behind, the Market Flight Administrator may decide to delay the schedule to allow parties to catch up. MPs are required to keep up with the market testing pace. MPs that are consistently unable to keep up may be asked to leave the test.  
Testing Status Checklist 
The Market Flight Administrator maintains a secure section on the Texas Retail Testing website to track the progress of each entity through the testing process.  The MPs have the capability to view a Marketplace Summary report.  They are expected to update their individual status with the most current information on their testing progress. The status checklist can be found at the following link;
http://etod.ercot.com/Login.asp?DestURL=Checklist.asp?Method%3DTOC
A password is required to enter this portion of the website.
Risk Mitigation
The Test Plan includes several steps to mitigate the risk that parties cannot maintain the pace:
·		Connectivity and X12/TX SET Standards Certification - Parties begin End-To-End testing knowing that trading partner transactions have been validated against standards.
·	Weekend work may be incorporated into the schedule to expedite testing. 
·	Frames may be combined or otherwise adjusted to expedite testing, e.g., ERCOT may forward the 867_03 usage transaction in the same frame as it is received.
·		The Market Flight Administrator may grant an extension of time for the test Frame in the event a TDSP or a large number of MPs are not able to complete the frame.
·	The Market Flight Administrator may postpone a single Test Script for a given party. If a party is performing well on most scripts, but is having problems with one, the Market Flight Administrator may require the party to test this script at a future date.
·	The Market Flight Administrator may require a party to leave the current flight and move into a future testing flight, if the party misses more than two testing Frame deadlines or misses one or more critical deadlines established in the scripts.

Issue Resolution Process
Parties should work through issues and issues first with their trading partners.  If issues cannot be resolved in these forums, then parties are required to submit a Marketplace Issue form, found in Appendix C, to the Market Flight Administrator.  This form is used by the Market Flight Administrator to frame the issue for further clarification and mediation.
The Market Flight Administrator will have the initial call on the issue and will report resolution to RMS or other appropriate committee.  Where necessary, other parties will be engaged by the Market Flight Administrator to resolve the issue, including TXSET transaction experts, TTPT members, and others.  Details of the parties involved in the issue will remain confidential.  A high-level summary of the issue will be published in the ‘Issues’ database.
If resolution is not achieved, the issue will be raised through appropriate ERCOT committees and to the ERCOT Board if required. The PUCT will have final call on the issue resolution process. The process is intended to resolve issues at the lowest possible level and in a fair and equitable manner for all MPs.

Data Loading
Information in this section is applicable to TDSPs that intend to use End-to-End testing to certify CRs within their territory.  
TDSPs will develop the information necessary to establish test beds of customer information to be used by CRs and ERCOT during the testing process.  The number of required ESI IDs will depend on two factors; the number of scripts to be tested and the number of CRs testing with the TDSP’s area. Test Bed information will be available for the CRs and ERCOT approximately 3 weeks prior to beginning the test. 
The TDSP Test Bed must include an ESI ID for each test script.  Test scripts are designed to test the complete range of scenarios, including type/customer class and other characteristics.  Each CR will receive 1 ESI ID for each script to be tested from each of their TDSP trading partners. At a minimum, test scripts should test the account types listed in the table below.
Meter Type	Large Commercial  (>50kw)	Small Commercial	Residential	Total	
Interval Data Recorder	1			1	
Non-interval (Cumulative)		2	3	5	

Additional ESI IDs will be provided for any Auxiliary Flights that test ERCOT or other optional business processes. 
For a detailed list of ESI IDs, Scripts, Meter Types, and Rate Classes, refer to 

<http://etod.ercot.com/Scripts.asp?M=ESIIDTemplate&FlightNum=V1.5F1NEW>
Loading ESI IDs into ERCOT Systems
TDSPs must have their ESI ID Test Bed established at ERCOT approximately three weeks prior to testing.  The Test Bed will be loaded into ERCOT systems using the 814_20s or a CSV file, if appropriate. Prior to beginning a new flight of testing, Test Beds will be refreshed to ensure that all ESI IDs have been properly conditioned for the next flight.
Providing ESI IDs to CRs
Each TDSP will provide unique test ESI IDs to the CRs they will be testing with approximately three weeks prior to the first day of testing.  For each ESI ID, this list will include the actual ESI ID number and the Test Script number the ESI ID will test.  The customer name in the list will be comprised of a mock name including the CR, TDSP, and script number. The list should also include meter reading cycle, rate class, meter type, and any other helpful data for each ESI ID.  These ESI IDs will be sent to the CR and ERCOT via email using the template posted on the Texas Retail Testing website.
The ESI ID and service addresses need to be scrambled so the customer/premise is not identifiable.  ERCOT requires a unique service address / ZIP combination for any scrambled ESI IDs.  For each TDSP, the ESI IDs used for testing should include:
•	Script ID scenarios
•	Meter Types
•	Rate Classes
•	Simulated Customer name 
•	ZIP Code
•	Meter Number if required
Resetting the Test Bed
Test beds will be reset between flights.  The TDSPs and ERCOT will perform this activity.  ESI IDs within the Test Bed will be conditioned to match requirements of scripts that will be tested.
Certification
ERCOT and MPs must establish their readiness to participate in the marketplace.  This readiness certification process consists of two steps: Connectivity and Standards Certification, and Business Process Certification.  
Connectivity and Standards Certification
Connectivity and Standards Qualification requirements are some of the activities included in the "Prior to Test" list in the Testing Requirements section.  These steps must be successfully demonstrated to ERCOT and the Market Flight Administrator prior to the Market Participant being allowed to test.  
Connectivity and Standards Qualification requires ERCOT and all MPs to:
·		Complete the Testing Signoff Worksheet
·	Complete the Technical Connectivity Worksheet
·	Establish connectivity with trading partners.  This includes GISB EDM, NAESB EDM, and Replacement FTP EDM.
·	Demonstrate adherence with X12 and TX SET  
Once a Market Participant has successfully completed the Connectivity and Standards Certification process, they will qualify to begin business process testing.  Business Process Certification requires an MP to demonstrate that systems work according to the business processes defined by the PUCT Rulemakings and ERCOT Protocols via test scripts.  Any party that has completed Business Process Certification is considered “approved ” to process valid market transactions and move to production once formally notified by ERCOT and the Market Flight Administrator.
Business Process testing will involve validation of End-to-End and Point-to-Point processes.   These tests will enable MPs to establish the foundation required for successful trading partnerships in production.

997 Functional Acknowledgement (FA) Transactions
Parties are required to use Functional Acknowledgement transactions to notify their trading partners that:
a)	   Transactions have been received;
b)	They were either correct (positive) or incorrect (negative) according to X12 guidelines

Business Process Certification
Market Participants may chose to certify for all processes used within the Market, or they may receive partial certification by opting out of testing those processes that are considered optional. It is a requirement that all participants in the retail market successfully complete those tests that validate their capabilities to switch, move-in, move-out, process meter reads, invoices, make payments and provide remittance advices.  These processes are considered mandatory and will be covered by a collection of scripts defined by the Texas Test Plan Team.
The only processes that are considered optional are those listed below.  
§	CSA
§	Service Order Option 1
§	Outage Option 1
§	POLR

These processes must be validated through testing, and certification confirmation must be received from ERCOT and the Market Flight Administrator before an MP may use them in production.  Swimlanes for these optional processes can be found on the TX SET website at;
http://www.ercot.com/Tac/RetailISOAdHocCommittee/Customer/SET/keydocs/Keydocs.htm.

Testing Requirements of ERCOT and Market Participants
General Marketplace Requirements
Each MP in the Texas Market has specific requirements that must be met before it will be allowed to begin production processing.  The ERCOT Protocols and PUCT rules specify many of these requirements in detail.  Market Participants should thoroughly understand these requirements.
Trading partner agreements will not be required for a party to begin testing but may be required prior to moving into production. This will be determined by individual TDSPs.
Requirements specific to testing and validating Market Participant’s systems and processes are listed below. The following Texas Marketplace Test Plan (TMTP) requirements must be met before a Market Participant receives qualification that its systems are ready to go into production with their trading partners.
Additional qualification requirements that fall outside the scope of this document may be specified by the PUCT and/or ERCOT.
CR Requirements
Prior to Testing
·	Apply for PUCT REP Certification from the PUCT to participate in Market (not applicable to  Muni's/Coops)
•	Obtain DUNS number for testing entity.
·	Adhere to Protocol 15 - Customer Registration Business Processes
·	Adhere to Protocol 16 - Register as a Market Participant with ERCOT
·	Adhere to Protocol 23 - Texas Test Plan Team Retail Market Testing
·	Implement a dedicated test system
·	Identify whether testing with EDI or with the ERCOT Market Portal.
·	Provide trading partner information using the Technical Connectivity Worksheets to TDSPs and ERCOT
·	Complete the Testing Signoff Worksheet on-line; include specific details on required features that are not supported, test exceptions, manual processes
·	Identify bill scenarios (Muni's/Coops only)
·	Receive and review test ESI IDs from TDSP
·	Review Testing FAQ’s and provide additional FAQ's specific to the MPs processes and systems
·	Review the TX SET EDI implementation guides and data element matrices on the ERCOT website at; 
	<http://www.ercot.com/Tac/RetailISOAdHocCommittee/Customer/SET/keydocs/Keydocs.htm>
·	Submit X12 samples to the ETOD System for verification.
During Testing
·	Establish technical connectivity with ERCOT and TDSP trading partners
·	Participate in scheduled testing conference calls with the Market Flight Administrator, ERCOT and MPs (if participating in End-to-End testing)  
·	Adhere to the established test schedule.
·	Notify the Market Flight Administrator, the associated MP and ERCOT, via E-mail, when transactions are sent and received.
·	Update status on the testing checklist 
After Testing
·	Receive Certification letter from the ERCOT.
·	Submit market readiness letter to the PUCT
·	Migrate to production with ERCOT and trading partners
·	Receive production digital certificate from ERCOT
·	Exchange production PGP or GnuPG keys with ERCOT
·	Establish production connectivity with ERCOT
·	Exchange production PGP keys with trading partners
·	Establish production GISB EDM connectivity with trading partners.

TDSP Requirements
Before Testing
·	Adhere to Protocol 15 - Customer Registration Business Processes
·	Adhere to Protocol 16 - Register as a Market Participant with ERCOT
·	Adhere to Protocol 23 - Texas Test Plan Team Retail Market Testing
·	Implement a dedicated test system
·	Complete and submit the Testing Signoff Worksheet; include specific details on required features that are not supported, test exceptions, manual processes
·	Provide trading partner information using the Technical Connectivity Worksheet to registered CRs and ERCOT
·	Establish Test Bed of ESI IDs; include accounts to cover testing scenarios for each of the CRs
·	Provide ERCOT with all required Test Bed data 
·	Provide ERCOT and CRs with a completed ESI ID template
·	Read Testing FAQ’s prior to testing
·	Provide FAQ's to the Market Flight Administrator for compilation into the Master Marketplace Testing and Technical FAQ 
·	Review the TX SET EDI implementation guides and data element matrices on the ERCOT website 
·	Submit X12 samples to the ETOD System for verification.
During Testing
·	Establish technical connectivity with ERCOT and CR trading partners
·	Participate in scheduled testing conference calls with the Market Flight Administrator, ERCOT and MPs.  
·	Adhere to the established test schedule.
·	Notify the Market Flight Administrator, the associated MP and ERCOT, via E-mail, when you send and receive test transactions.
·	Update status on the testing checklist
After Testing
·	Receive Certification letter from the ERCOT.
·	Exchange production PGP or GnuPG keys with trading partner
·	Establish production GISB connectivity with trading partners
ERCOT Requirements
Before Testing
·	Adhere to Protocol 15 - Customer Registration Business Processes
·	Adhere to Protocol 16 - Register as a Market Participant with ERCOT
·	Adhere to Protocol 23 - Texas Test Plan Team Retail Market Testing
·	Establish a dedicated test system
·	Test and certify with the Market Flight Administrator that internal ERCOT central systems are functioning correctly, including transaction samples to the ETOD System. 
·	Complete and submit the Testing Signoff Worksheet; include specific details on required features that are not supported, test exceptions, manual processes
·	Provide trading partner information using the Technical Connectivity Worksheet to all new testing MPs
·	Read Testing FAQs prior to testing
·	Provide FAQs specific to the ERCOT processes and systems
·	Review the TX SET EDI implementation guides and data element matrices on the ERCOT website
·	Submit X12 samples to the ETOD System for verification
·	Establish technical connectivity with new CRs
During Testing
·	Participate in scheduled testing conference calls with the Market Flight Administrator and MPs.  
·	Adhere to the established test schedule.
·	Notify the Market Flight Administrator and the associated MP, via E-mail, when you send and receive transactions.
·	Update status on the testing checklist
After Testing
·	Exchange production PGP or GnuPG keys with MPs
•	Establish production connectivity with MPs.

PUCT Requirements
Before Testing
·	Provide oversight monitoring of the testing process that will be facilitated by the Market Flight Administrator. 
·	Confirm REP Certification application has been submitted (excludes Muni's/Coops)
·	Inform associated MPs of new MPs entry into marketplace
·	Identify current POLR information for specific TDSP areas
·	Participate in development of Flight calendar to ensure key market dates are met
·	Provide relevant information to new entrants to the market
During Testing
·	Monitor progress of the testing process
After Testing
·	Review qualification notification from ERCOT and the Market Flight Administrator on each Market Participant
·	Award appropriate certification to the MP

Market Flight Administrator Requirements
The Market Flight Administrator will act in an independent role throughout the testing effort.  Primary duties for the Market Flight Administrator will be to:
·	Maintain a testing contact list on the Texas Retail Testing Website.
·	Verify testing eligibility of MPs with ERCOT 
·	Ensure TSW is completed on-line by all testing TPs
·	Develop a consolidated list of testing FAQ’s and post on the Texas Retail Testing Website
·	Attend TTPT meetings
·	Review and provide input to TTPT agenda prior to meetings
·	Assist in facilitation of TTPT meetings
·	Assist TTPT in developing a standard Test Plan for Point-to-Point, End-to-End and ERCOT Testing on Demand business processes
·	Assist TTPT in developing Test Scripts
·	Facilitate End-to-End testing between ERCOT and MPs
·	Facilitate testing of Point-to-Point business processes between trading partners
·	Facilitate daily testing conference calls with MPs and ERCOT, and document results
·	Act as a issue resolution agent for technical and process issues between all MPs including ERCOT
·	Establish testing criteria in conjunction with TTPT.
·	Confirm that MPs have completed qualification testing
·	Establish adherence to TX SET standards by all MPs and ERCOT
·	Maintain MP testing status on a secured section of the Texas Retail Testing website
·	Provide link to other ERCOT and PUCT websites.
Issue Resolution Process
Parties should work through issues and issues first with their trading partners.  If issues cannot be resolved in these forums, then parties are required to submit a Marketplace Issue form, found in Appendix C, to the Market Flight Administrator.  This form is used by the Market Flight Administrator to frame the issue for further clarification and mediation.
The Market Flight Administrator will have the initial call on the issue and will report resolution to RMS or other appropriate committee.  Where necessary, other parties will be engaged by the Market Flight Administrator to resolve the issue, including TXSET transaction experts, TTPT members, and others.  Details of the parties involved in the issue will remain confidential.  A high-level summary of the issue will be published in the ‘Issues’ database.
If resolution is not achieved, the issue will be raised through appropriate ERCOT committees and to the ERCOT Board if required. The PUCT will have final call on the issue resolution process. The process is intended to resolve issues at the lowest possible level and in a fair and equitable manner for all MPs. 

Details of Testing Phases
As indicated in the Testing Overview/Certification Section,  certification testing consists of two steps: 1) connectivity and standards certification; 2) and business process certification, which is accomplished through End to End and Point to Point testing
Technical Connectivity and Verification
Each MP is required to establish technical connectivity with ERCOT using one of the communication protocols specified below:  
·	FTP Replacement/EBXML   
•	NAESB EDM 
•	GISB EDM (Flight 0104 only – all subsequent flights will use NAESB EDM)

Each MP is required to establish technical connectivity with their Trading Partners using a communication protocol specified below:  
•	GISB EDM (Flight 0104 only – all subsequent flights will use NAESB EDM)
·	NAESB EDM 
All parties should review the following documents to prepare for these tests.  Links to these documents can be found in Appendix B.
·	ERCOT FTP Replacement/EBXML document
·	NAESB EDM document
Establishing technical connectivity is a time consuming process.  New entrants to market testing should begin the effort as soon as possible.  Technical connectivity must be completed before any End-to-End Business Process testing can begin. 
Technical connectivity begins with prospective trading partners exchanging Technical Connectivity Worksheets.  This document can be found on the Texas Retail Testing website at <http://etod.ercot.com/TechCon.asp?Method=TOC>.  TDSPs and CRs will maintain current information on the website.  Copies of TCWs may be downloaded from the website and e-mailed to trading partners in addition.  TDSPs will schedule a date to begin connectivity testing with each new trading partner. 
Technical connectivity must be established for each unique DUNS number that is used by a market participant.  
FTP Replacement/EBXML Testing
Scripts for establishing FTP Replacement/EBXML with ERCOT can be found on the Texas Retail Testing website. Testing parties will use standard encrypted X12 formatted files in these tests.  MPs are required to use digital certificates to send encrypted EDI transactions to ERCOT.  Test digital certificates will be provided by ERCOT. 
The test script can be found on the website at:
http://etod.ercot.com/scripts.asp?Method=TOC

GISB EDM Testing (Flight 0104 ONLY)
Transactions exchanged point to point, from CRs to TDSPs, and to/from ERCOT will be sent via GISB EDM.  The Texas Data Transport Workgroup prepared a plan for the use of GISB EDM.  A link to this document is provided in Appendix B.  Participants should review this information.  The primary goals of this test are to establish connectivity, to transfer a large file, and to exercise the exchange failure process.
Scripts for establishing GISB connectivity can be found on the Texas Retail Testing website. Testing parties will use a standard X12 formatted file in this test.  Both encrypted and unencrypted files will be used to verify connectivity.  TDSPs , CRs, and ERCOT are required to establish and use PGP Keys to send encrypted EDI transactions to their respective trading partners .  This information is exchanged between trading partners using the Technical Connectivity Worksheets.

NAESB EDM Testing
Transactions exchanged point to point, and to/from ERCOT will be sent via NAESB EDM.  The Texas Data Transport Workgroup prepared a plan for the use of NAESB EDM.  A link to this document is provided in Appendix B.  Participants should review this information.  The primary goals of this test are to establish connectivity, to transfer a large file, and to exercise the exchange failure process.
Scripts for establishing NAESB EDM connectivity can be found on the Texas Retail Testing website. Testing parties will use a standard X12 formatted file in this test.  Both encrypted and unencrypted files will be used to verify connectivity.  TDSPs,CRs, and ERCOT are required to establish and use PGP Keys to send encrypted EDI transactions to their respective trading partners.  This information is exchanged between trading partners using the Technical Connectivity Worksheets.
The NAESB EDMtest scripts can be found on the website at:
http://etod.ercot.com/scripts.asp?Method=TOC
TXSET Verification
Automated validation of transaction samples to X12 and TX SET standards will be used for new CRs. Once transactions have been validated by the ETOD System, TDSPs will be able to review the results of the validation on the ERCOT website. 
The test script for validating transaction samples can be found on the website at: 
http://etod.ercot.com/Scripts.asp?M=Properties&FlightNum=TOD&ScriptID=TT193

All transactions must be validated in the ERCOT automated system before an MP will be allowed to participate in End-to-End testing.  
Transactions that are not compliant with X12 standards will be rejected using an FA/997 transaction in test and production.  Transactions that are not compliant with TXSET standards will be rejected using the defined transaction based on TXSET standards and ERCOT Protocols.
TXSET standards require that parties receiving a transaction send a Functional Acknowledgement (FA or 997) upon receipt of each transaction.  If the transaction is compliant with X12 standards, a positive FA/997 is sent.  If the transaction is not compliant with X12 standards, a negative FA/997 is sent rejecting the transaction. 
FA/997’s from ERCOT will be placed in each MPs mailbox. 
End-to-End Testing
End-to-End testing will be conducted between ERCOT, TDSPs that require some level of End-to-End testing, and their respective CRs. End-to-End testing includes processes that involve all three parties as well as those point-to-point processes that affect only the TDSP and CR.  This testing is designed to validate the End-to-End and Point-to-Point business scenarios outlined in the test scripts. This includes both EDI and ERCOT Market Portal CRs.
This test will utilize MP and ERCOT back-end systems to process through entire business scenarios.  
Each participant will be responsible for fulfilling their role within each business scenario by either sending or receiving the specified transactions.  Participants are dependent on each other to correctly send and receive transactions in a timely manner as detailed in the testing schedule to realize successful completion of this step of testing.
Each competitive retailer will have a role as a Current CR and a New CR for applicable scenarios.  
Scripts that will be used in the April test flight can be found on the Texas Retail Testing Website at 
Point-to-Point Testing
Point-to-Point testing is performed between TDSPs and their CR trading partners. It covers the processes in the marketplace that do not involve ERCOT.  Those processes include customer information updates, invoice and remittance, and service orders.  Point-to-Point testing is included within the End-to-End scripts covered above and can be found at the same website link. 
ERCOT Testing on Demand (ETOD) Testing
ERCOT Testing on Demand (ETOD) allows MPs to automatically validate the transactions they use in the Marketplace and to validate business processes as defined in the automated scripts located on the Texas Retail Testing Website
CRs must submit sample transaction to the ETOD system until they have successfully passed the validation process for X12 and TX SET compliance. All transactions that the CR intends to use in their business plan must be successfully tested. Once the transaction has passed validation, the ETOD system will document results and provide confirmation to the Market Flight Administrator, ERCOT and the respective TDSPs.
Once transaction samples have been validated, CRs must then execute the automated ETOD scripts. CRs that have successfully passed ETOD testing may be granted qualification by ERCOT and the Market Flight Administrator. All TDSP areas require ETOD testing at a minimum.  Some TDSP areas require End-to-End testing in addition to ETOD testing. Certification will not be issued until both testing paths are completed. Once CRs have established production connectivity, they will be allowed into the production market for the areas that do not require End-to-End testing. 

Success Criteria
The Texas Market Test Plan (TMTP) is designed to validate that a market participant is qualified to participate in the Texas Electric Retail Market after the following criteria have been met:
1.	Testing Signoff Worksheet is submitted to the Market Flight Administrator, and maintained on a continuous basis.
2.	Technical Connectivity is established with their trading partners through NAESB EDM, or Replacement FTP.
3.	Sample EDI files for each TX SET transaction set are validated against the ERCOT Testing on Demand (ETOD) System.  Market Participants are required to submit transactions until there are no errors detected. 
4.	Market Participants can receive into their system valid X12/TX SET transaction sets from ERCOT’s ETOD system..
5.	Successful completion of End-to-End Testing, as defined by the TTPT testing scripts.
6.	Checklist is maintained on the Retail Testing Website to monitor Market Participant’s completed transaction status during the lifecycle of the flight test.  
7.	Completion of all new functionality as defined by new TX SET Versions, Connectivity Upgrades, or Market Re-Designs
8.	 Notification is received from MPs trading partners indicating successful completion of the entire testing flight
Certification letter is received from ERCOT indicating all required business processes and associated scripts have been successfully tested.
Script Success Criteria, in addition to frame-by-frame results, is identified in each scenario to be tested.  Market Participants and the Market Flight Administrator will use this information to determine whether End-to-End tests have been successfully completed. Market participants that have not successfully completed all required scripts may be prohibited from or limited in production 
Any issues over whether a party has successfully completed testing will be mediated by the Market Flight Administrator.

Scenarios and Testing Scripts
Business Process Scenarios
Business scenarios have been defined by the TX SET Working Group. The scenarios below cover various business processes. Swimlanes associated with these business processes can be found on the following website;
http://www.ercot.com/Tac/RetailISOAdHocCommittee/Customer/SET/keydocs/Keydocs.htm
Test Scripts
As noted earlier, all scripts are considered mandatory unless the Market Flight Administrator and trading partners receive advance notification, and the Market Flight Administrator approves exceptions.   Any scripts that cannot or will not be tested should be documented in the Testing Signoff Worksheets (TSW) in the ‘Exceptions to the Test Plan’.  If the exception is a feature that is required but your implementation of that feature is delayed, provide documentation as to when this feature will be available in the “Required Features Not Supported” section of the TSW.
Detailed tests scripts can be found at 
<http://etod.ercot.com/Scripts.asp?Method=TOC>

Summary List of Test Scripts  
All test scripts used during current and prior testing flights can be found on the Texas Retail Testing website. TTPT has incorporated a number of script changes as the testing process has evolved. Detailed test scripts for each of the previous and current flights can be found at: 
<http://etod.ercot.com/Scripts.asp?Method=TOC>

Appendices
Appendix A - Testing Signoff Worksheet
The Testing Signoff Worksheet can be found online at: 
<http://etod.ercot.com/Signoff.asp?Method=TOC>
Appendix B - Resources
Marketplace Glossary, Implementation Guidelines, Business Process Flows/Protocols, TX SET Transaction Names:  

<http://etod.ercot.com/MarketLinks.asp>
<http://www.ercot.com/Participants/Index.htm>
GISB EDM Plan: 
<http://www.ercot.com/Participants/Committees/TDTWG_comm.htm>

ERCOT Replacement FTP EDM Plan: 
<http://www.ercot.com/Participants/Committees/TDTWG_comm.htm>

ERCOT Registration information can be found at: 

<http://www.ercot.com/mkt_part_apps/market_participant_application_f.htm>

Appendix C - Marketplace Issue Resolution Form
Issue Title:	
Date Identified:		
Date Submitted:	Submitted by:	
Parties Affected by Issue:	

Position 1	
Parties supporting Position 1: 	
Position 1 Summary of Supporting Logic (include any legislation, standards, etc.)   	
Position 1 Recommendations:   	
Position 2	
Parties supporting Position 2: 	
Position 2 Summary of Supporting Logic (include any legislation, standards, etc.)   	
Position 2 Recommendations:   	
Market Flight Administrator Position	
Comments:   	
Recommendation:   	
Status:	

Appendix D - Texas Test Plan Team (TTPT) Participants
The list of TTPT Participants can be found at: 
<http://etod.ercot.com/ttpt.htm>
The Test Plan List Server is testplan@ercot.com 
For distribution list additions or removals, send e-mail to postmaster@ercot.com with your full name, distribution list information and e-mail address. 
Appendix E – Texas Market Transactions
The following tables define the sample transactions that must be shared between trading partners. These transactions are used in the business process scenarios that are validated during market testing. Once the automated testing system is functional, the results of test validations will be made available to respective trading partners over the Texas Retail Testing website.
ERCOT Transactions (using FTP) for CRs and TDSPs using EDI
TDSP to ERCOT	ERCOT to TDSP	CR to ERCOT	ERCOT to CR	
814_04 814_09 814_13 814_20 814_25 814_27 814_28 824 (for ERCOT polled meters) 867_02 867_03 867_04 867_05 (if applicable) 997 	814_03 814_08 814_12 814_24 814_26 814_29 814_21 824 867_03 997	814_01 814_07 814_08 814_09 814_10 814_12 814_13 814_15 814_16 814_18 814_19 814_21 814_23 814_24 814_26 814_29 824 997	814_02 814_05 814_06 814_08 814_09 814_11 814_12 814_13 814_17 814_18 814_19 814_20 814_25 814_27 814_28 867_02 867_03 867_04 997	

Point-to-Point Transactions (Using FTP Replacement, GISB EDM, or NAESB EDM) for CRs using the ERCOT Market Portal  
CR to TDSP	
820_02 824 650s 814_PC 997	
Point-to-Point Transactions (using FTP Replacement, GISB EDM, or NAESB EDM)
TDSP to CR	CR to TDSP	
810_02 824 650s 867_03 (Non ERCOT) 814_PD 997	820_02 824 650s   814_PC 997