Post on 26-Dec-2015
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?
– Protocol compliance
– 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
– 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
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
35
36
37
38
39
40
41
42
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
Concepts for RMS vote
• 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
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
Concepts for RMS vote
• 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
Concepts for RMS vote
• 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
Concepts for RMS vote
• 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
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
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
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
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
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.
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
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
Concepts for RMS vote
• 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
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
Concepts for RMS vote
• 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