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

1

Update from ERCOT Retail

Market Services

to RMS

November 14, 2002

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

Master Project Plan Update

4

Master Project Plan

• 2002 Planned Projects– 46 Projects in progress

– 27 Projects completed between August 1st and November 1st

– 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

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

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 6th 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

•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

Timeline10/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

OverallFinancial

RiskStaffing

RiskSchedule

Risk

TechnicalRisk

Bus.Align/Scope RiskPR-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.

Completed In Progress Scheduled

• 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/28 11/1 2/15 3/17 4/1

Migration of Market Participants

8

GISB 1.4 Update

9

GISB 1.4 Update

• 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

Texas Set V.1.5

Presented by: Dave Odle

Thursday, November 14th, 2002

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

• 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

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

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Build

Design

Test

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

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

Next Steps

• Begin Monthly Face to Face Meetings (Dates Set) for project status/issues, testing, and Production Implementation fine tuning.

– Nov 21st (Thursday)– Dec 19th (Thursday)– Jan 23rd (Thursday)– Feb 20th (Thursday)– Mar 20th (Thursday)– April 14th (Monday) – tentative depending on production

implementation schedule

17

ERCOT Data Transparency(ETS)

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

ERCOT Data TransparencyERCOT/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?


– Transaction volumes and status

– View/Research transactions

20

ERCOT Data TransparencyERCOT/Market Requirements

– ERCOT Retail Market Services

• How is ERCOT and the Market performing now and over time?

– Transaction Success


– 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

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

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

ERCOT Data Transparency Stakeholders and Needs

ERCOT IT

ERCOT Retail

CRsTDSPs

PUC

Performance and ThroughputBacklogs

State of Current Environment

View and Research

Transaction StatusTransactionSuccess

Protocol Compliance

24

ERCOT Data TransparencyBusiness and Operational Concerns

Business Environment– Market changes– Regulatory mandates– Transaction Management

Operational Infrastructure– System availability– Component integrity– System capability

Business Activity Business 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 theBusiness Environment andOperations Infrastructure

25

ERCOT Data Transparency Model For Improvement

Retail Transactions

(Issues /Concerns /

Gaps)

Root CauseAnalysis

CorrectiveActions

PerformanceMetrics

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

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

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

Data LogsData Logs

FTPFTP

TCHTCHPaperfreePaperfree

SeebeyondSeebeyond

LodestarLodestar SiebelSiebel

LodestarApp

Server

LodestarDB

Server

Siebel App

Server

Siebel DB

Server

EAITCHPaperfreeFTP

Internet

ERCOTFrame

ERCOT EDI PIPELINE (PRODUCTION)

Portal

Transaction Transparency WarehouseTransaction Transparency WarehouseDataData

EventsEvents LoggingLogging

ReportsReports

ArchiveArchive

29

Queue Depths & E-waysQueue Depths & E-ways

FTPFTP

TCHTCHPaperfreePaperfree

SeebeyondSeebeyond

LodestarLodestar SiebelSiebel

LodestarApp

Server

LodestarDB

Server

Siebel App

Server

Siebel DB

Server

EAITCHPaperfreeFTP

Internet

ERCOTFrame

ERCOT EDI PIPELINE (PRODUCTION)

Portal

Component AvailabilityComponent AvailabilityTransactionsTransactions

RelatedRelated LoggingLogging

ReportsReports

SummarySummary

30

Future

ERCOT Data Transparency Project Deliverables

Q2 - 03

Siebel Report997 ReportMP Report

Siebel Report997 ReportMP ReportTrans FlowTrans SuccessProtocol

Siebel Report997 ReportPortalTrans FlowTrans SuccessProtocolNew ReportsPUC ReportsData ArchiveSummary Rpt- Transactions % Cancelled % Failed % Reprocessed-System Avail-Component Avail-Trans Flow Rates-Volume Trending

CompetitiveMeteringReports?

BillingSummaries?

CR/TDSPSummariesBy Area?

MTD/QTDESIIDUsage

Summaries?

Auto Reprocess

Q1 - 03Nov 02In Place

Siebel Report997 ReportMP ReportTrans FlowTrans SuccessProtocolCapture MMPUC ReportsData Archive

Market Reports

ERCOTVisibility

Market Metrics /Visibility

Scorecard /Dashboard

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

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

5% Reports

10%Take Calls

10%Answer Emails

75%Research/Reprocess Transactions

ERCOT Data Transparency Day in the Life – Pre ETS

Typical day for a Registration Analyst

AdditionalIT & Business

Resources

34

5% Reports

5%Take Calls

5%Answer Emails

25%Research/Reprocess Transactions

60%Available for Other Tasks

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

43

RMS Update on Move-In / Move-Out Task Force

November 14, 2002

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

Approved Concepts

• Questions from RMS1. 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

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

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


• Pending 814_06s (MIMO will take to RMS November 14th)– 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


• Pending 814_06s (continued)1. Does this concept require a coordinated implementation?

• Yes, between all CRs and ERCOT.


• CRs and ERCOT.


• Test Flight for implementation and a published implementation date.


• 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


• Retired ESI Ids (MIMO will take to RMS November 14th)• 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 notification1. Does this concept require a coordinated implementation?

• Yes2. What parties are affected by the implementation of this concept?

• CRs and TDSPs3. 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


• Invalid ESI ID Retry (MIMO will take to RMS November 14th)• 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?

• No2. 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


• Processing Efficiency (MIMO will take to RMS November 14th)– 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


• 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


• 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


• 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


• 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


• 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.

Dec Jan Feb Mar Apr May Jun Jul

10%

20%

30%

40%

50%

60%

70%

80%

90%

First goal of 50% by

January 1, 2003

Implementation 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


• Processing Efficiency (Continued)1. Does this concept require a coordinated implementation?

• No


• CRs, TDSPs, and ERCOT


• MIMO will review metrics as agreed upon


• Metrics reports

5. What supporting efforts/documentation is needed?

• This concept does not supercede protocols and will not require a protocol change.

59


• Customer Canceling Move-Ins with Move-Outs. (MIMO will take to RMS November 14th)

• 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


• 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.


• CRs and TDSPs


• Require e-mail from TDSPs that this is how they are doing it and from CRs that they understand the method.


• Self-enforced. CRs and TDSPs will be able to ‘police’ each other and use escalation procedures when necessary.

61


• Handling Switch after 650 Disconnect (MIMO will take to RMS November 14th)

• 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?

• Yes2. What parties are affected by the implementation of this concept?

• CRs and TDSPs3. What is the follow-up plan to ensure the concept is implemented?

• TTPT – Version 1.5 test flight4. 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

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

Thank-you

64

Quick Recovery Team Update

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

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

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

Entity Quantity

TDSP 37077

QRE Team 2932

CR 10682

Total 50691

Current Status Quantity

New 32

In Analysis 3303

In Progress 50691

Resolved 108100

Total 162126

ESI Ids Reported to QRE (as of November 12, 2002)

Point of Failure Quantity

Cause Not Reported 19581

Unexecutable 20

CR 38962

ERCOT EAI 4966

ERCOT FTP 694

ERCOT Manual Process (814_08)

3442

ERCOT Out of Protocol 20

ERCOT PaperFree 8215

ERCOT Siebel 1513

ERCOT TCH 6933

TDSP 23754

Total 108100

69

Market Synchronization Activities

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 10th 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 11th 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

Next Steps

– November 19th, December 3rd, 10th, 17th

Follow-up conference calls

– Propose process to complete and close out this project

Establish timeline

Establish reporting mechanism

Market Synchronization Retailer Synchronization (cont.)

72

Market Synchronization“TDSP as LSE” Clean-up

October 10, 2002 RelationshipStatus exists after Active as of

Feb 01,2002 10/10/2002CenterPoint 8,350 505ONCOR 18,328 433TNMP 515 71CPL 2,246 793WTU 3,164 314

Market 32,603 2,116

• 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

• 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

Resettlement of True-up Status Update

SeptOct

NovDec

JanFeb

MarApr

MayJun

JulAug

SepOct

NovDec

20032004

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

Consumption Data Loading Reports

76

% of IDR Data Loaded by MRE (as of 10-11-2002)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

10/1 10/15 10/29 11/12 11/26 12/10 12/24 1/7 1/21 2/4 2/18 3/4 3/18 4/1 4/15 4/29 5/13 5/27 6/10 6/24 7/8 7/22 8/5 8/19 9/2 9/16 9/30

CPL

WTU

ONCOR

CenterPt

TNMP

Brazos

LCRA

Rayburn

STEC

System

IDR Data Loaded into LodestarOctober 11th Report

95% or better expected for 60 days ago

93%

77

% of IDR Data Loaded by MRE (as of 11-12-2002)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

12/1 12/15 12/29 1/12 1/26 2/9 2/23 3/9 3/23 4/6 4/20 5/4 5/18 6/1 6/15 6/29 7/13 7/27 8/10 8/24 9/7 9/21 10/5 10/19 11/2

CPL

WTU

ONCOR

CenterPt

TNMP

Brazos

LCRA

Rayburn

STEC

System

IDR Data Loaded into LodestarNovember 12th Report

95% or better expected for 60 days ago

94%

78

IDR Data Status Report 99% Data Available per MRE

As of As ofOctober 11, 2002 November 12, 2002

CPL 01/14/02 01/14/02CenterPoint 12/18/01 02/24/02ONCOR 12/28/01 01/20/02TNMP 01/14/02 12/31/01WTU 01/25/02 01/30/02

Brazos 09/30/02 11/03/02LCRA 10/02/02 10/31/02Rayburn 09/30/02 10/31/02STEC 09/30/02 10/17/0209/30/02Market 01/17/02 01/28/02

Meter Reading Entity(MRE)

79

Non-IDR Data Status Report October 14, 2002

Percent of Actual Non-IDR Datafrom October 14, 2002 Batch Process

38%

42%

36%

44% 45%

0%

41%

97% 98%

80%

91% 93%96%

100% 99% 99% 99%95%

99%

0% NA0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

CenterPoint ONCOR TNMP CPL WTU Sharyland Market

Initial (9-29-02) -16 Days After

Final (8-18-02) - 59 Days After

Re-Settle (10-16-01) - 367 Days After

80

Non-IDR Data Status Report November 12, 2002

Percent of Actual Non-IDR Data from November 12, 2002 Batch Process

38%42%

25%

42% 44%

0%

40%

96% 96%

80%

91% 92%95%

99% 99% 99% 99%95%

99%

71%

NA0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

CenterPoint ONCOR TNMP CPL WTU Sharyland Market

Initial (10/27/2002) - 16 days after

Final (09/15/2002) - 58 days after

TrueUp (12/11/2001) - 336 days after

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

Documents

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