1. 1 Update from ERCOT Retail Market Services to RMS November 14, 2002

2. 2 Retail Market Update Topics –ERCOT’s Master Project Plan –GISB 1.4 Update –Texas Set Version 1.5 –Data Transparency and ETS –Move-In/Move-Out Issues/Initiatives –Quick Recovery Team Update –Market Synchronization Activities –IDR Meter Usage Report –Non-IDR Meter Usage –Resettlement Update

3. 3 Master Project Plan Update

4. 4 Master Project Plan 2002 Planned Projects –46 Projects in progress –27 Projects completed between August 1 st and November 1 st –5 Projects continuing on into 2003 for completion –5 Projects removed from the 2002 plan (require reprioritization for 2003) 2003 Project Continuing into 2003 for completion include: –PR-20153 Amended POLR Process –PR-20117 Internal Map Testing and Verification –PR-20111 ERCOT Transaction Processing Hardening Initiative –PR-20079 Change Deployment Instructions_PRR281 –PR-20067 Simultaneous Procurement of Ancillary Services

5. 5 Master Project Plan (cont.) 2002 Projects removed from active status (would require reprioritization to proceed) –PR-20068 Interzonal Congestion Management: Interim Fix completed; any further effort will be a new project and go through prioritization process –PR-20071 Two Settlement System: Manual fix announced to market and ERCOT Board of Directors. If automated solution desired a new project request will be submitted and prioritized –PR-20080 Define OOME as Instructed Deviation: PRR282 withdrawn and project canceled –PIP106 Direct Load Control: Deleted from 2002 Active Project List and has been prioritized for 2003 and included in the Master Priority List –PR-20083 Ratcheting of OOME: Project withdrawn

6. 6 Master Project Plan (cont.) Next Steps… –Conduct Project Management Office Procedures Training in the month of November –Available ERCOT resources aligned and scheduled against Q1 2003 projects by December 6 th 2002 –Start High Priority Projects identified in master priority list resources as resources are available –Monthly project prioritization adjustments and recommendations: ERCOT Executive Steering Committee Market Committees and Subcommittees ERCOT IT and Business Support Teams –Finalize and distribute documentation on the project request/prioritization process

7. 7 Provide a GISB 1.4 implementation to replace FTP Provide a migration path toward NAESB 1.6, which is a secure data transport Deliverables Support for HTTPS and GISB 1.4 Roll-out to production Migration of Market Participants to HTTPS or GISB 1.4 Provide a GISB 1.4 implementation to replace FTP Provide a migration path toward NAESB 1.6, which is a secure data transport Deliverables Support for HTTPS and GISB 1.4 Roll-out to production Migration of Market Participants to HTTPS or GISB 1.4 Development of code is complete Server build out is complete Database configuration is complete Working on application configuration Working on network configuration Project Scope/Deliverables Timeline 10/15 Development Configuration Testing Sign off by ERCOT Upcoming Milestones/Market Impacts Budget YTD Forecast Var. Capital $0.70M $0.103M $0.140M [$0.070M] Expense $0.0M $0.00M $0M $0.0 Financial Milestones Executive Summary of Status Overall Financial Risk Staffing Risk Schedule Risk Technical Risk Bus.Align/ Scope Risk PR-20134 GISB 1.4 Sign off by ERCOT Migration of Market Participants All of these could be affected by any delays experienced in network configuration/setup. CompletedIn ProgressScheduled Outbound network configuration is not complete. Working with Network group to get the port opened to proxy server. End of Sept Labor Recorded 492hrs (Original SOW states 400hrs) Issues/Actions 10/2510/2811/12/153/174/1 Migration of Market Participants

8. 8 GISB 1.4 Update

9. 9 RMS agreed at August meeting to move forward with implementing GISB 1.4 at ERCOT Internal testing and implementation of a GISB 1.4 interface is underway at ERCOT, –Production Sign-off scheduled delayed to 11/18 All production components are in place as of 10/11 Testing uncovered errors in outbound transmission requiring a vendor software patch; will be testing the week of 11/4 –Acceptance Testing and Market Participant Testing – 10/15-11/8 TDTWG is surveyed market participants to finalize migration readiness dates –Preliminary migration schedule reviewed at 10-4-02 TDTWG –Market Participant migration will begin week of 11-25-02; ERCOT will work individually with participants in any change of date for testing and migration. –Goal is to complete migration by April 1, 2003

10. 10 Texas Set V.1.5 Presented by: Dave Odle Thursday, November 14th, 2002

11. 11 V1.5 Coordination Team Accomplishments/Goals Established Timeline for V1.5 Project as a Market. Completed –Established Project Phases –Established the Solid date of 2/24/03 as Flight Test Begin Date –Established April as month of Production Implementation Established clear understanding of V1.5 Requirements. Completed –Reviewed all functional change controls approved by TX SET –Published, circulated, and reviewed ERCOT Conceptual System Designs –Published regularly updated FAQ document

12. 12 Established open and up-front communication. Completed –Created a dedicated web page for documentation, FAQ docs, and notes –Created email address for one central point of contact –Periodic Conference Calls and Face-To-Face meetings –Created several pieces of documentation to assist the market with research and analysis Continuing efforts for Project Success. In Progress –Continued improvements in communication –Project Status and tracking –Production Implementation Plan –Flight Test coordination with the TTPT V1.5 Coordination Team Accomplishments/Goals (Cont.)

13. 13 Project Status Summary Exolink provides EDI services for: Calpine, Entergy Disco, Entergy Retail, GEXA, Republic, STEC retail, TCE, Tara Energy, Systrends provides EDI services for: Occidental, Sharyland, Tenaska ESG provides EDI services for: ACN Energy, Cirro Group, Coral Energy Markets, Dynegy, Sempra Energy Solutions, Tractebel Energy Markets, UBS Warburg

14. 14 Implementation Plan Objectives –Ensure all parties know the status of the implementation effort –Minimize down time –Work as a team Approach: Big Bang –All parties roll-out ALL 1.5 functionality over the same weekend

15. 15 PROPOSED TIMELINE AND SCHEDULE STILL BEING DEVELOPED BY THE MARKET COORDINATION TEAM Friday, April ? at 5 p.m. ERCOT stops accepting all Transactions ERCOT processes queued 1.4 transactions Friday Midnight 1.4 transactions processed and ready for pickup by MPs ERCOT Upgrades Software Internal Testing Sunday, April ? at 5 p.m. ERCOT begins accepting 1.5 Inbound Normal 1.4 operations Normal 1.5 operations Wednesday, April ? at 5 p.m. ERCOT stops accepting Initiating Transactions = Conference Call

16. 16 Next Steps Begin Monthly Face to Face Meetings (Dates Set) for project status/issues, testing, and Production Implementation fine tuning. –Nov 21 st (Thursday) –Dec 19 th (Thursday) –Jan 23 rd (Thursday) –Feb 20 th (Thursday) –Mar 20 th (Thursday) –April 14 th (Monday) – tentative depending on production implementation schedule

17. 17 ERCOT Data Transparency (ETS)

18. 18 ERCOT Data Transparency ERCOT/Market Issues  Issues facing ERCOT and Market Participants… – Market Participants are unable to see their submitted transactions CRs do not know status of submitted requests Unable to easily identify ‘if’, ‘when’, and ‘where’ transaction failures occur – ERCOT difficulty in identifying failed transactions Data located throughout multiple databases Unable to easily determine transaction failure point – Internal system and component health Unable to easily identify system or component failures Unable to identify lost transactions when components fail or are restarted

19. 19 ERCOT Data Transparency ERCOT/Market Requirements  What do Market Participants and ERCOT need to know? –PUC How is the market performing over time? –Protocol compliance –Transaction volumes –Transaction Success (Business Process) –Market Participants What is the status of my transactions? –Protocol compliance –Transaction volumes and status –View/Research transactions

20. 20 ERCOT Data Transparency ERCOT/Market Requirements –ERCOT Retail Market Services How is ERCOT and the Market performing now and over time? –Transaction Success –Protocol compliance –Backlog Transactions –State of current processing environment –Performance throughput and availability –ERCOT IT How are ERCOT systems performing now and over time? –State of current processing environment –Backlog Transactions –Performance throughput and availability

21. 21  What do Market Participants and ERCOT need to see? –Daily update on all CR transactions All initiating transactions received All ERCOT responses –List of all other associated transactions All requests sent to TDSP All transactions returned by TDSP –Timeliness of responses Transactions both ‘in’ and ‘out’ of protocols –Failed Transactions Transactions without a response –Cancelled Transactions ERCOT Data Transparency ERCOT/Market Requirements

22. 22 ERCOT Data Transparency Existing ERCOT/Market Reports  Existing ERCOT Reports –Market Participant Transaction Report (“Dark Side”) Daily EDI activity “in” and “out” of ERCOT (FTP) –Siebel Report Daily ESIID transaction status by Market Participant –997 Report Daily EDI file receipt with 997 transactions

23. 23 ERCOT Data Transparency Stakeholders and Needs ERCOT IT ERCOT Retail CRs TDSPs PUC Performance and Throughput Backlogs State of Current Environment View and Research Transaction StatusTransaction Success Protocol Compliance

24. 24 ERCOT Data Transparency Business and Operational Concerns  Business Environment –Market changes – Regulatory mandates – Transaction Management  Operational Infrastructure –System availability – Component integrity – System capability Business ActivityBusiness Intelligence Monitor system performance at or near real-time Provide system and component availability summaries Monitor processes that have dependencies on other parties Provide transaction timing analysis for all Market Participants based on protocols Identify failure points within the transaction life-cycle Proactively target failed transactions for reprocessing Provides Visibility into the Business Environment and Operations Infrastructure

25. 25 ERCOT Data Transparency Model For Improvement Transaction Database Provide VISIBILITY into transactions within ERCOT Systems…. See near “real-time” transaction data Monitor transaction flows within ERCOT Provide transaction status for Market Participants Provide a mechanism to more easily identify Market Participant issues Develop operational metrics reports Develop Executive Summary reports Improve speed and effectiveness of business operations Incorporate advanced business logic to proactively identify and resolve issues

26. 26 ERCOT Data Transparency ERCOT Interim Solution  ERCOT Interim Internal Solution – ESIID Tracking System (ETS) Complete life-cycle view of transactional data …Near-real time updating of ETS database (every 10 minutes) …Transactions are monitored from FTP inbound to FTP outbound …Transactions are purged from database once business process is complete Daily reporting of all ‘open’ transactions …Reports include all internal system component touch points and their respective timestamps …Reports will identify successful, failed, and out of protocol transactions …Reports are both ‘batch’ and ‘on-demand’

27. 27 ERCOT Data Transparency ERCOT Interim Solution  ERCOT Interim Internal Solution – Daily reporting of all ‘open’ transactions Transaction Flow Report …Identifies the last system component that the transactions hit and their corresponding timestamps by Global ID Transaction Success Report …Identifies how successful ERCOT was in processing a response transaction Protocol Report …Provides a view of ERCOT’s protocol compliance for each transaction type

28. 28 Data Logs FTP TCHPaperfree Seebeyond LodestarSiebel Lodestar App Server Lodestar DB Server Siebel App Server Siebel DB Server EAITCHPaperfreeFTP Internet ERCOT Frame ERCOT EDI PIPELINE (PRODUCTION) Portal Transaction Transparency Warehouse Data EventsLogging Reports Archive

29. 29 Queue Depths & E-ways FTP TCHPaperfree Seebeyond LodestarSiebel Lodestar App Server Lodestar DB Server Siebel App Server Siebel DB Server EAITCHPaperfreeFTP Internet ERCOT Frame ERCOT EDI PIPELINE (PRODUCTION) Portal Component Availability Transactions RelatedLogging Reports Summary

30. 30 Future ERCOT Data Transparency Project Deliverables Q2 - 03 Siebel Report 997 Report MP Report Siebel Report 997 Report MP Report Trans Flow Trans Success Protocol Siebel Report 997 Report Portal Trans Flow Trans Success Protocol New Reports PUC Reports Data Archive Summary Rpt - Transactions % Cancelled % Failed % Reprocessed -System Avail -Component Avail -Trans Flow Rates -Volume Trending Competitive Metering Reports? Billing Summaries? CR/TDSP Summaries By Area? MTD/QTD ESIID Usage Summaries? Auto Reprocess Q1 - 03 Nov 02In Place Siebel Report 997 Report MP Report Trans Flow Trans Success Protocol Capture MM PUC Reports Data Archive Market Reports ERCOT Visibility Market Metrics / Visibility Scorecard / Dashboard

31. 31 ERCOT Data Transparency Project Benefits  How do Market Participants and ERCOT benefit? –PUC Knowledge of overall Market performance –Transactions ‘in’ and ‘out’ of protocol –Identify transaction failure points within the Market –Ability to perform independent queries –Market Participants Better able to manage customer expectations –Ability to research transactions for customers –Able to identify where each transaction is located –Reports identifying backlog, successful, failed, and out of protocol transactions –Ability to perform independent queries

32. 32 ERCOT Data Transparency Project Benefits  How do Market Participants and ERCOT benefit? –ERCOT Retail Market Services Able to identify and repair failed transactions –Research problem transactions –Reports identifying backlog, successful, failed, and out of protocol transactions –Summary reports on transaction volumes –Enhanced capabilities to perform root cause analysis on transaction failures –Ensure data synchronization between Siebel and Lodestar –ERCOT IT Know when system and components are unavailable –Knowledge of current processing status of all components –Performance throughput and transaction volumes –Ability to trend anticipated volume levels for system reliability –Potential for real time volume-based performance tuning

33. 33 ERCOT Data Transparency Day in the Life – Pre ETS Typical day for a Registration Analyst Additional IT & Business Resources

34. 34 PUCT / MPs can access data directly ERCOT Data Transparency Day in the Life – Post ETS NEW day for a Registration Analyst Responsive to special Market requests Proactively search for failed transactions

35. 35

36. 36

37. 37

38. 38

39. 39

40. 40

41. 41

42. 42

43. 43 RMS Update on Move-In / Move-Out Task Force November 14, 2002

44. 44 MIMO Workshop Progress –32 Concepts have been discussed 7 Concepts were dismissed for various reasons 1 Concept was determined as solved in Version 1.5 3 Concepts were combined into other concepts 21 Concepts in Task Force –6 Concepts approved by RMS on 10/16 –6 Concepts will be taken to RMS for vote on 11/14 –9 Concepts are currently tabled until additional information can be obtained

45. 45 Approved Concepts Questions from RMS 1.Does this concept require a coordinated implementation? 2.What parties are affected by the implementation of this concept? 3.What is the follow-up plan to ensure the concept is implemented? 4.What enforcement or accountability will we use to ensure the concept is implemented?

46. 46 Recommendations Clarification of Switch vs. Move-In A switch transaction is to be used when a customer wants to switch providers without changing their premise; it is intended to switch a customer from one CR to another. A Move-In is used when different customer is requesting power at an ESI ID than the customer that was formerly associated with the ESI ID whether or not the premise is de- energized. It needs to be noted that a CR using a Move-In transaction to affect a switch violates procedures that have been put in place by the Public Utility Commission including Customer Protection rules. Misuse of the Switch or Move-In transactions may result in disciplinary action from the PUC.

47. 47 Concepts for RMS vote Mid-Term –Pending 814_06s –Retired ESI Ids –Invalid ESI ID Retry Short-Term –Processing Efficiency –Canceling Move-Ins with Move-Outs. –Handling Switch after 650 Disconnect

48. 48 Concepts for RMS vote Pending 814_06s (MIMO will take to RMS November 14 th ) –This concept involves ERCOT holding 814_06s until the morning of 2 days prior to the effective date (5 days on 814_06s from switches) on the 814_04 and 814_12s to the submitting REP for Move-Outs until the morning of 2 days prior to the effective date on the 814_25. This concept also involves ERCOT rejecting any Cancels, Date Changes, or new transactions that are dated prior to the effective date for the transaction that is scheduled. –This concept is essential to processing multiple pending transactions (not currently in place in the market), but adds significant benefit to the current CSA issues.

49. 49 Concepts for RMS vote Pending 814_06s (continued) 1.Does this concept require a coordinated implementation? Yes, between all CRs and ERCOT. 2.What parties are affected by the implementation of this concept? CRs and ERCOT. 3.What is the follow-up plan to ensure the concept is implemented? Test Flight for implementation and a published implementation date. 4.What enforcement or accountability will we use to ensure the concept is implemented? Test Flight (TTPT) 5.What supporting efforts/documentation is needed? Requires Protocol Revision to adjust the protocol timing for the 814_06 and the 814_25. Requires Protocol Revision to adjust the way ERCOT treats an 814_12 and 814_08. Requires adjustments to Visios (Swim Lanes). Requires changes to ‘Flow pages’ in implementation guides for 814_12 and 814_08.

50. 50 Concepts for RMS vote Retired ESI Ids (MIMO will take to RMS November 14 th ) This recommendation is intended to develop how retired ESI Ids are handled when there is a REP of Record. The volumes of these are ‘temp’ meters. When a TDSP needs to retire an ESI ID that has a REP of Record, they will send a 650_04 with a new code to the CR. The CR must use this new code to create a Move-Out on the ESI ID. After the Move-Out is complete, the TDSP will send the 814_20 retire to ERCOT. –This replaces the current manual process of using e-mails for this notification 1.Does this concept require a coordinated implementation? Yes 2.What parties are affected by the implementation of this concept? CRs and TDSPs 3.What is the follow-up plan to ensure the concept is implemented? Test Flight for implementation and a published implementation date. 4.What enforcement or accountability will we use to ensure the concept is implemented? Test Flight (TTPT) 5.What supporting efforts/documentation is needed? Requires change to Implementation guides (650) and How to use guide Requires new or revised visios (Swim Lanes)

51. 51 Concepts for RMS vote Invalid ESI ID Retry (MIMO will take to RMS November 14 th ) If a Move-In rejects for Invalid ESI ID, ERCOT will hold and retry the Move-In at a regular interval of time for 48 hours (only counting hours on business days, but not only business hours.) After the retry period has expired, if the Move-In is still in a reject status for Invalid ESI ID, ERCOT will send an 814_17 to the submitting CR. 1.Does this concept require a coordinated implementation? No 2.What parties are affected by the implementation of this concept? CRs and ERCOT (CRs need to allow for a longer period of time on the return of the 814_17 or 814_05) 3.What is the follow-up plan to ensure the concept is implemented? Internal testing at ERCOT. 4.What enforcement or accountability will we use to ensure the concept is implemented? The CRs will be able to verify the success/failure 5.What supporting efforts/documentation is needed? Need to modify metrics to allow for holding Invalid ESI Ids for retry. Requires Protocol Change Recommended Change Control for ‘How to Use Guide’

52. 52 Concepts for RMS vote Processing Efficiency (MIMO will take to RMS November 14 th ) –CRs­CRs need to closely evaluate the timing between when the customer service rep hangs up the phone with the customer and when the 814_16 is sent to ERCOT. There are cases where there may be 1 to 2 days that elapse before the transactions are sent. Tightening up this timeline can help the market to meet the requested date. It is recommended that the CRs manage this time and try to keep it within a reasonable range. There may be times when evaluating statistics on processing efficiencies that recommendations may be made to a specific CR or group of CRs to improve their turn-around times. These recommendations should be given their due regards. All market metrics need to be measured starting at the time the initiating transaction is sent to ERCOT (placed in the folder on the ERCOT FTP site) and ending at the time the response transaction is made available for the CR to retrieve from ERCOT. CR vendors’ processing times are not figured into market metrics.

53. 53 Concepts for RMS vote Processing Efficiency (Continued) –TDSPs­In an effort to improve market transaction turn-around times on Move-Ins, Move-Outs, Switches, and Drop to AREPs, it is recommended that the TDSPs set a target goal of a 10 hour processing time on the following transactions. The goal would be that these times be met a percentage of the time (detailed below) regardless of the time of day or day of week. From when the 814_03 is made available for the TDSP to sending the 814_04 to ERCOT. From when the 814_24 is made available for the TDSP to sending the 814_25 to ERCOT. –The TDSPs should maintain a system up time of at least 100 hours a week including a minimum of 10 hours of up time required every business day.

54. 54 Concepts for RMS vote Processing Efficiency (Continued) –ERCOT­In an effort to improve market transaction turn-around times on Move-Ins, Move-Outs, Switches, and Drop to AREPs, it is recommended that ERCOT set a target goal of a 2.5 hour/ 8 hour processing time on the following transactions. The goal would be that these times be met a percentage of the time (detailed below) regardless of the time of day or day of week. Receipt of 814_16 to making the 814_03 available for the TDSP. Receipt of 814_01 to making the 814_03 available for the TDSP. Receipt of 814_24 to making the 814_24 available for the TDSP. Receipt of 814_24 to making the 814_03 available for the TDSP. Receipt of 814_10 to making the 814_03 available for the TDSP. Receipt of 814_04 to making the 814_05 available for the CR. Receipt of 814_04 to making the 814_11 available for the CR. Receipt of 814_04 to making the 814_14 available for the CR. Receipt of 814_04 to making the 814_22 available for the CR. Receipt of 814_25 to making the 814_25 available for the CR. –ERCOT should maintain a system up time of at least 100 hours a week including a minimum of 10 hours of up time required every business day.

55. 55 Concepts for RMS vote Processing Efficiency (Continued) Percentage of Time –With the current method of measuring Turn-around time (detailed below), the TDSPs are meeting the expectation of 10 hours 44.4% of the time. It is proposed that using the same measuring method, the TDSPs set a goal to improve this to 50% by January 1, 2003. From January 1, 2003, it is proposed that the TDSPs use a goal of 20% higher by July 1, 2003. (i.e., if the Turn-around time on January 1, 2003 is 51.6%, the goal for July 1, 2003 would be 71.6%). –With the current method of measuring Turn-around time, (detailed below), ERCOT is meeting the expectation of 2.5 hours 40.1% of the time on the transactions detailed above. It is proposed that using the same measuring method, ERCOT set a goal to improve this to 50% by January 1, 2003 on all the transactions detailed above. –With the current method of measuring Turn-around time, (detailed below), ERCOT is meeting the expectation of 8 hours 80.4% of the time on the transactions detailed above. It is proposed that using the same measuring method, ERCOT set a goal to improve this to 90% by March 1, 2003 on all the transactions detailed above.

56. 56 Concepts for RMS vote Processing Efficiency (Continued) Turn-around Time –Taking a month and timing the inbound transaction from the FTP delivery time at ERCOT to the outbound transaction FTP delivery time at ERCOT and subtracting them will measure the turn-around time for ERCOT. These times are then averaged across the transactions detailed above. –Taking a month and timing the outbound transaction from the FTP delivery time at ERCOT to the inbound transaction FTP delivery time at ERCOT and subtracting them will measure the turn-around time for the TDSPs. These times are then averaged across the transactions detailed above. –Weekends, downtime, batch times, scheduled maintenance, planned outages, and unplanned outages are not considered in the measurements.

57. 57 Concepts for RMS vote Processing Efficiency (Continued) –There is an understanding when Market Participants begin to actively participate in a pilot mode or enter full retail open access; they may not be able to perform to these efficiencies immediately. There is an expectation that these Market Participants will make every effort to ensure a healthy market by being mindful of processing efficiencies. DecJanFebMarAprMayJunJul 10% 20% 30% 40% 50% 60% 70% 80% 90% First goal of 50% by January 1, 2003 Implementatio n of Texas SET version 1.5 Second goal of 20% higher by July 1, 2003 Allowing for some hardening after implementation of version 1.5

58. 58 Concepts for RMS vote Processing Efficiency (Continued) 1.Does this concept require a coordinated implementation? No 2.What parties are affected by the implementation of this concept? CRs, TDSPs, and ERCOT 3.What is the follow-up plan to ensure the concept is implemented? MIMO will review metrics as agreed upon 4.What enforcement or accountability will we use to ensure the concept is implemented? Metrics reports 5.What supporting efforts/documentation is needed? This concept does not supercede protocols and will not require a protocol change.

59. 59 Concepts for RMS vote Customer Canceling Move-Ins with Move-Outs. (MIMO will take to RMS November 14 th ) If a TDSP receives a backdated Move-Out with the same effective date as an already completed Move-In, and the Move-Out CR is the same as the Move-in CR, the TDSP will de-energize the premise and send a final and initial with the same read and read dates and the final would have zero consumption. (Except for IDR meters) If the Move-Out is not the same CR as the Move-In, the TDSP will reject the Move-Out for not REP of Record. If a CR needs to cancel a pending Move-In, they should use the 814_08 transaction providing there is enough time for the 814_08 to effectuate at all parties. If the CR needs to cancel a Move-In at the last minute, the TDSPs do have the ability to cancel the Move-In very late in the process and the CRs should call them. If the TDSP IS able to cancel the Move-In, the CR MUST follow up with an 814_08 cancel to ERCOT. The use of a back-dated Move-Out with the same date as the Move-in should be used only if the Move-In is complete and can’t be cancelled at the TDSP and only with the approval of the TDSP in accordance with the RMS vote that “Back office clean up efforts coordinated with ERCOT and TDSP” are one of two “Only situations that CRs may back date Move-Ins and Move-Outs”. A customer's cancellation of a move in transaction must be verified and documented using the same standards and methods outlined in the PUC customer protection rules Sec. 25.474(e) and (f).

60. 60 Concepts for RMS vote Customer Canceling Move-Ins with Move-Outs. (Continued) 1.Does this concept require a coordinated implementation? No, cleaning up back-office issues requires coordination, but implementation of this concept does not. 2.What parties are affected by the implementation of this concept? CRs and TDSPs 3.What is the follow-up plan to ensure the concept is implemented? Require e-mail from TDSPs that this is how they are doing it and from CRs that they understand the method. 4.What enforcement or accountability will we use to ensure the concept is implemented? Self-enforced. CRs and TDSPs will be able to ‘police’ each other and use escalation procedures when necessary.

61. 61 Concepts for RMS vote Handling Switch after 650 Disconnect (MIMO will take to RMS November 14 th ) Off-Cycle Switches: TDSP will use the off-cycle switch to re-energize an ESI ID if the ESI ID was de-energized with a 650 disconnect and no Move-Out has been received. For on-cycle Switches TDSPs will effectuate the switch, but will not energize the ESI ID. The CR must follow up with a Service Order re-connect. It is the recommendation that TX SET does not attempt to create a notification to the submitting CR of the disconnected status. 1.Does this concept require a coordinated implementation? Yes 2.What parties are affected by the implementation of this concept? CRs and TDSPs 3.What is the follow-up plan to ensure the concept is implemented? TTPT – Version 1.5 test flight 4.What enforcement or accountability will we use to ensure the concept is implemented? Test Flight (TTPT) 5.What supporting efforts/documentation is needed? Change to How to Use guide

62. 62 Next Steps MIMO Taskforce meetings as needed –Discussions on concepts for resolving existing issues –Discussions around concepts for handling stacking Recommendations to RMS at future RMS meetings –Additional Concepts Follow-through on execution of approved concepts Release of implementation timelines Coordinating test flights with TTPT as appropriate Development of Texas Set Change Controls, Protocol Revision Requests, and RFP (If necessary) Deployment of Solutions Re-Evaluation of Move-In/Move-Out processes

63. 63 Thank-you

64. 64 Quick Recovery Team Update

65. 65 Pursuing responses from CRs and TDSPs ~10,682 ESI Ids are awaiting more information or acknowledgment of receipt from CR ~37,077 have been sent to TDSPs for investigation and are waiting for a transaction All “New” issues have been addressed 3,303 “In Analysis” issues are planned to be addressed by 11/25 QRE project will be transitioned back to ERCOT by 12/20/02. Consultant contracts will not be extended beyond year’s end. Transition activities are currently under way. Quick Recovery Effort

66. 66 Quick Recovery Effort QRE is transitioning processes and procedures to ERCOT Data Management and Registration teams. QRE is providing documentation for all QRE business processes to ERCOT QRE is hosting brown bag and individual training sessions with Data Management and Registration teams QRE has provided CBT training modules to ERCOT for new hires. Modules have been reviewed and modified per ERCOT comments. QRE will provide a week of “shadowing” ERCOT employees taking over responsibilities

67. 67 Transition Transition tasks have been identified and checklist created. Market notification of transition and survey was sent to Market on 11/12/02. –Survey feedback will be used to assist ERCOT in identifying the proper owner –Survey comments will be used to determine what processes worked and what needs to be improved –Market Participant Surveys need to be returned by 11/18 in order for comments to be considered QRE will provide two documents to ERCOT by 12/20 – “Lessons Learned” –“Recommendations”

68. 68 EntityQuantity TDSP37077 QRE Team2932 CR10682 Total50691 Current StatusQuantity New32 In Analysis3303 In Progress50691 Resolved108100 Total162126 ESI Ids Reported to QRE (as of November 12, 2002) Point of FailureQuantity Cause Not Reported19581 Unexecutable20 CR38962 ERCOT EAI4966 ERCOT FTP694 ERCOT Manual Process (814_08) 3442 ERCOT Out of Protocol20 ERCOT PaperFree8215 ERCOT Siebel1513 ERCOT TCH6933 TDSP23754 Total108100

69. 69 Market Synchronization Activities

70. 70 Objective –Address market issues resulting in an out of sync “Rep of Record” between ERCOT, TDSP, and CR systems for all ESI IDs resulting from market startup/processing issues as well as subsequent workarounds Completed –ERCOT identified “Perfect Sync” and “1 Day Perfect” – sent lists to MPs –ERCOT identified out-of-synch categories at Sept 10 th design meeting –Task Force identified additional ESI IDs considered “In Sync” – sent lists to MPs –Task Force prioritized 8 categories based upon potential customer impact –ERCOT has sent priority 1 through 6 out-of-sync files to TDSPs and CRs –November 11 th face-to-face meeting to resolve “how to fix” set principles to correct out-of-sync conditions In Progress –ERCOT compiling and analyzing MP responses to out-of-sync files –TDSPs and CRs completing analysis and response to priority 2-6 files –MPs making corrections per 11-11-02 decisions. Market Synchronization Retailer Synchronization Project

71. 71 Next Steps –November 19 th, December 3 rd, 10 th, 17 th  Follow-up conference calls –Propose process to complete and close out this project  Establish timeline  Establish reporting mechanism Market Synchronization Retailer Synchronization (cont.)

72. 72 Market Synchronization “TDSP as LSE” Clean-up Objective –Ensure that all ESI ID are converted from the “TDSP as LSE” by the time True-Up Settlement of February 2002 begins; which is currently scheduled for 12-07-02 Completed –ERCOT sent TDSPs list of ESI ID affiliated with “TDSP as LSE” any time after Feb 01, 2002 –All TDSPs have responded to ERCOT original list with suggested corrective action In Progress –ERCOT is reconciling response lists from TDSPs and confirming suggested corrective action can be taken –TDSPs should expect there to be a subset of these ESI IDs which will require multiple discussions prior to ERCOT performing corrective actions

73. 73 Objective –Make necessary corrections to ensure that >1MW Customers were switched on the correct date in January 2002 Completed Items –Per RMS direction, ERCOT sent lists to each MP for reconciliation: 1,134 ESI Ids (>1 MW) identified by CRs (meeting the April 30 deadline) –CR and TDSP have reached agreement of Service Instance Date for all ESI IDs –1,035 (91%) ESI IDs are corrected – 82 (7%) ESI IDs were agreed not to fix by TDSP and CR In Progress –17 (2%) ESI IDs with action required to complete agreement 13 – CR agreed to TDSP date (after TDSP submit usage, ERCOT will correct) 4 – ESI ID retired (TDSP needs to submit 814_20 retire transaction) Next Steps –ERCOT will provide full list with agreement dates by 11/13/02 COB Market Synchronization Non Price to Beat

74. 74 Resettlement of True-up Status Update Sept Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 December 7, 2002 True-Up Settlement of February 01, 2002 The date all ESI IDs should no longer be with the “TDSP as LSE”. November 1, 2002 True-Up Settlement of November 20, 2001 The date we move from the ERCOT Board resolution to the Protocols IDR Data Threshold April 1, 2003 Date we expect to be back to six month after the trade day True-Up Settlements November 14, 2003 True-Up Settlement of December 17, 2001 Drop dead date for correction of Non-PTB ESID Backdating November 12 132 re-settlements performed to date (Operating Day 12/11/01)

75. 75 Consumption Data Loading Reports

76. 76 IDR Data Loaded into Lodestar October 11 th Report 95% or better expected for 60 days ago 93%

77. 77 IDR Data Loaded into Lodestar November 12 th Report 95% or better expected for 60 days ago 94%

78. 78 IDR Data Status Report 99% Data Available per MRE

79. 79 Non-IDR Data Status Report October 14, 2002

80. 80 Non-IDR Data Status Report November 12, 2002