550 likes | 688 Views
Update from ERCOT Retail Market Services to RMS December 11, 2003. Texas Market Link (PRP Phase 1) IT Update. IT Update – Texas Market Link (Portal Replacement Project Phase 1).
E N D
Update from ERCOT Retail Market Services to RMS December 11, 2003
IT Update – Texas Market Link(Portal Replacement Project Phase 1) • Portal was re-launched as planned on December 3 after successful completion of market testing and stress/load testing, however, issues were encountered and the old Portal was reinstated during the early hours of the next morning. • TML was online for 10 hours from Dec 3 7:20pm through Dec 4 5:15am the next morning. • Users were able to access the new TML system during that time • During the brief operation, TML experienced web service issues that created technical issues in the background, but did not impact Market Operations. • An IT decision to revert back to the old Portal was made and executed at 5:15am to minimize operational risk. • Market notified by Client Relations that morning. • Post-mortem analysis is underway to identify the issues and to assess the next re-launch approach. • Any tml.ercot.com requests are being redirected to portal.ercot.com.
IT Update(API Issue and Redevelopment Efforts) • API became corrupt/unrecoverable on October 3 • ERCOT Development team has developed new API program to replace old functionality • Planned Release Steps: • Download of Report Functions- released November 11 (this week) • Delivery was on schedule • Some issues with unzipping files (2 companies using a Java program) • Find ESI Id and Find Transactions- target December 5 • Find Market Participant Data- target December 12 • Continue providing Weekly Updates on Retail Conference Call • Reminder that the website URL for the API changed: • https://pi.ercot.com/servlet/piController • (old address was pi.ercot.com)
FasTrak Issue Status • Day-to-Day • Data Extract Variances (DEV) • ERCOT Initiated Issues
FasTrak 2003 “Day to Day”Issue Stats (as of 12-04-03) • Of the 350 In Progress, 119 are resolved and awaiting other party resolution check off • Total ESI IDs worked to date since January 1, 2003 = 2,852,895 • ERCOT would like to complete and close out all 2003 issues by January 31, 2004 • Of the 3,381 New and In Progress Non- ERCOT issues, 13 are for the year 2002 • Number of ESI IDs not tracked
FasTrak Data Extract VarianceIssue Stats (as of 12-04-03) • Of the 276 In Progress, 29 are resolved and awaiting other party resolution check off
FasTrak ERCOT Initiated Issues Issue Stats (as of 12-04-03) • These are issue initiated by ERCOT to the TDSP or CR as a result of one of the following projects: • Customer Protection Period and 814.08 • 867 Received on Canceled Service orders
Pre TX Set 1.5 Data Clean Up • RMS Directive • Pre TX SET 1.5 Status Report
Pre-TX Set 1.5 Data Cleanup Background: ERCOT identified “In Review”, “Scheduled” and “Canceled with Exception with Meter Reads” that were not completed from early 2002 to April 11, 2003. RMS Vote, July 17th, 2003: Recommend RMS direct ERCOT to completely clean-up by August 13th, 2003 the Pre-Tx Set 1.5 In Review, Scheduled and Cancel With Exception that have been identified and sent to the market participants which should include cancels with CR approvals. ERCOT will provide at August RMS full statistics involving market participants broken down per issue type. ERCOT is directed that if the TDSP provides file names, ERCOT will locate and re-process if it is a valid transaction. RMS directs the TDSPs and CRs to provide transactions or information necessary to achieve the completion of the data clean-up.
Ongoing Transaction Data Clean Up • Clean-up Process Steps • Completed Items – Next Steps • Status Report
Ongoing Transaction Data Clean-up Clean-up Process Steps: • ERCOT runs the query and defines the Action Items needed • In-Review with Meter Read: Notify TDSP and request 814_04/25 then transaction will complete. (Date Range equals or greater than 07/01/01.) • Scheduled No Meter Read: Notify TDSP and request 867 completing transaction. (Date Range equals or greater then 07/01/01.) • Cancel With Exception (CWE) with Meter Read: Notify CR and TDSP and find out if they thought the transaction had completed. If so – take corrective action. (Date Range is 04/12/03 to 08/31/03.) • Cancelled Permit Not Received with Meter Read: Notify CR and TDSP and find out if they thought the transaction had completed. If so – take corrective action. (Date Range is 04/12/03 to 08/31/03.) • ERCOT distributes the lists to MP who owe the follow-up action. • MP Responds and ERCOT coordinates the clean-up activities. • ERCOT to report Monthly to RMS.
Ongoing Transaction Data Clean-up Completed Items : • October 20, 2003: ERCOT sends out new lists to CRs and TDSPs • October 29, 2003: TDSPs send analysis to CR • November 4, 2003: CRs respond to TDSPs and coordinate final response to ERCOT • ERCOT received responses from all TDSPs except Sharyland by November 7th • RMS approved a target deadline of December 12 for completing this activity Next Steps: • ERCOT to coordinate corrective actions to TDSP • ERCOT will continue to report progress at each RMS meting
Customer Protection and 814_08 Issue • Background and Completed Items • Matrix and Progress Report • Other Status Items and Next Steps
Customer Protection Period and 814.08 Background ERCOT has determined that there was an issue with the 814_08 manual-processing tool related to the cancel by customer objection process. While ERCOT systems were updated appropriately, 972 ESI IDs (spanning the August 2002 through July 2003 time frame) were identified where ERCOT has been unable to confirm that the TDSP was sent the 814_08 cancel. Completed Items • All Scenario 1 instances that could be worked have been worked. ERCOT still has approximately 35 that need further clarification from TDSPs • 41 FasTrak issues: • 20 Resolved (spanning 32 switches) • 20 In Progress (some dialog has occurred) • 3 Not Started (no feedback)
Customer Protection Period and 814.08 December 04, 2003 Status
Customer Protection Period and 814.08 Other Status Items • Matrix of FasTrak issues not yet resolved provided to RMS Chair/Vice Chair on Nov 6th and Dec 4th - included CR names • ERCOT has “processed” all email exchanges related to FT issues as of 12/4/03 • Concern that ERCOT is not being informed of “resolution” in some cases. Next Steps • ERCOT to continue to escalate missing responses • ERCOT to complete manual corrections by related to Scenario 1 • CRs and TDSPs make decisions on outstanding FasTrak issues and provide response to ERCOT
Pro-Active Transaction Resolution Measures 867s Received on Canceled Service Orders
867s received on Canceled Service Orders Situation ERCOT periodically receives 867_03 Finals and 867_04s for service orders that are Canceled in ERCOT systems. The Service Order Statuses that are considered Canceled are: Canceled (manually or concurrent processing), Canceled by Customer Request, Canceled by Customer Objection, Canceled Permit Not Received, Canceled with Exception, Unexecutable and Rejected by TDSP. This can indicate an out-of-sync condition between the TDSP and ERCOT. Volume:
867s received on Canceled Service Orders Proactive Measure: • ERCOT will compile transaction data related to the situation described above and on a weekly basis submit an ERCOT initiated FasTrak issue with the TDSP identified as the Resolving Party. • The TDSP is to provide a response for each FasTrak line item within the issue spreadsheet: • The service orders are Canceled in the TDSPs system - the TDSP should update the FasTrak issue spreadsheet accordingly. No further action is necessary. • The service orders are Complete in the TDSPs system - identifying an out-of-sync condition with ERCOT. The TDSP would then initiate an effort to clear the out-of-sync condition. (see ERCOT proposal for resolving out-of-sync conditions) Timing and Implementation: • ERCOT initiated this process on November 7, 2003 • Each Friday thereafter, ERCOT has provided a list to the TDSPs via FasTrak containing data for 867s received against Canceled Service Orders for the previous seven days • ERCOT is awaiting RMS direction for process completion
867s received on Canceled Service Orders Considerations for clean-up of Out-of-Sync Situations : • CRs receive both completing and cancellation information on service orders and should initiate an inquiry to the TDSP any time they see both on the same service order (they should not wait for this process) • Additionally, CRs who submit an enrollment transaction receive a Service Order extract identifying the ERCOT Siebel status of the transaction • Use of a “modified” Inadvertent issue process has not been a great success in the missing 08 clean-up effort • Precise rules allow for definitive understanding of how each Market Player will respond but does not circumvent the ability for ad-hoc corrections
867s received on Canceled Service Orders ERCOT Proposal for Handling Out-of-Sync Conditions : For: ▪ Canceled • Canceled by Customer Request • Canceled by Customer Objection • Unexecutable • Rejected by the TDSP Process: The TDSP will cancel the service order in their system. For: ▪ Canceled Permit Not Received • Canceled with Exception Process: When TDSP indicates service order should be completed, ERCOT will locate and reprocess transactions identified as sent by the TDSP to complete a service order. (May require TDSP to re-send transaction) NOTE: FasTrak is the mechanism to handle exceptions to the above policy
NAESB EDM v1.6 Background & Progress Background: • NAESB EDM v1.6 • July 08, 2002 RMS votes to approve: • Data transport change from GISB EDM v1.4 to NAESB EDM v1.6 • Target GISB EDM v1.4 Retirement date – Q1, 2004 • TDTWG would create Market Survey necessary for project planning for timing and readiness of project testing and implementation • Testing and migration would be coordinated with Market Test Flights • October 01, 2003 • Market Survey completed and results submitted to Market Participants • Testing and migration timelines finalized and coordinated with Market Test Flights and Move-In/Move-out Stacking Solution efforts • October 16, 2002 RMS votes to approve: • NAESB EDM v1.6 testing approach and migration timeline Progress: • Phase 1: ERCOT and TDSP – in progress • Phase 2: ERCOT and CR – not started • Phase 3: TDSP and CR - not started
NAESB EDM v1.6 ERCOT Testing Status CR cont.
NAESB EDM v1.6 ERCOT Testing Status CR cont.
NAESB EDM v1.6 Issues Issues: • NAESB EDM v1.6 Standards Compliance • MIME content-type in the payload, e.g. “Content-Type:application/EDI-X12”. Is an identifier that follows the recommendation of Internet Standards RFC 1767, for “MIME Encapsulation of EDI Data” . TDTWG made this an optional not used element which in not optional in the NAESB EDM v 1.6 Standard as published by the NAESB organization. • Issue has been sent to TDTWG for discussion and resolution at the December 10th, 2003 meeting.
Market Coordination Team for the Solution to Stacking • Progress • Delivered ERCOT Exception Processing Procedures • New NFI Statistics • Feb 1, 2003 through Oct 31, 2003 • Average 384 / day
Market Coordination Team for the Solution to Stacking • Educational Seminars
Market Coordination Team for the Solution to Stacking • MP Progress Tracking • All Market Participants have been requested to provide a monthly status on their progress with the Stacking effort • Market Participants are being asked to provide their own status, no default to Service Provider status • Large dependency on Business Rules • Back end system modifications • EDI changes relatively small • Progress will be reported through April, 2004
Market Coordination Team for the Solution to Stacking • MP Progress Tracking • **Graph goes here**
Project Overview Summary of Changes: Manage customer expectations by accepting and processing all valid requests. • Business Problem • Existing NFI logic forces an unreasonable amount of dependency on labor intensive workarounds. • Execution of workarounds are causing synchronization issues between market participants. • Lack of synchronization leads to improper billing and mismanagement of customer expectations • Solution • All valid transactions will be accepted and processed based on a set of market rules. • Drop notifications will be sent at a point in time where the proper recipient can be positively identified. • Rule based cancellations are sent on a pre-determined timeline with enough time for the recipient to react. Impact Level Efficiency Competition Communication
Solution to Stacking Production Implementation Timeline Production Implementation Date: 8/1/2004 Testing checkpoints at wks. 5 & 8 Connectivity 10 weeks Test Flight 4/23 2004 4/1 2004 5/3 2004 5/17 2004 7/23 2004 Final of Implementation schedule and plan due Draft of Implementation schedule and plan due Beginning of Test Flight
Market Coordination Team for the Solution to Stacking • Next Steps • Continue working with TTPT to develop test scripts • MCT will review scripts being developed by Script Sub-Team • Continue to Track Market Participant Progress • Educational Seminars as requested • Five currently scheduled • Develop Production Implementation Plan • Develop Transition Plan for Service Orders ‘In Flight’ • Develop Post-Implementation Success Criteria
Load Research Sampling ProjectHigh Level Summary • PUCT Order 25516 purpose: “This rule is necessary to facilitate retail competition in the ERCOT area. Since a large number of customers’ wholesale obligations are settled based on load profiles, it is imperative that the profiles be as accurate as possible.... More accurate profiles will enhance the retail market by providing for more accurate settlements.” • ERCOT will create Load Profiles for each point in the sample matrix (including TDSP, rate type, weather zone, TDSP rate class, voltage type) based on sample points defined by ERCOT and installation by TDSPs • TDSPs will install IDRs on all agreed sample points for the Load Research Sampling project (can be cost based IDRs that are already installed). • ERCOT will make Load Profile data available to REPs and participating Muni/Co-ops (included is customer class, TDU service area, weather zone, and interval usage) • ERCOT/TDSPs will NOT provide any customer identification information (including ESIID, address, etc) to REPs and participating Muni/Co-ops. • ERCOT will work with the market to develop processes and procedures for Load Research Sampling Project (including IDR meter replacements, VEE standards, data transport method, data file types, data frequency)
UPDATED LRS PROJECT TIMELINE October – December 2003 12/05/03 Meeting with CRs & TDSP 10/08/03 Administer TDSP survey 10/23/03 Meeting #1 with TDSPs 11/06/03 Meeting #2 with TDSPs 11/17/03 TDSP IDR format agreement 12/1/03-1/15/2003 TDSP Handshake test for FTP replacement (on-going) 10/16/03 Present timeline to RMS 11/15/03 Administer CR survey January 2004 1/15/04 TDSP validate samples and send installation schedule 1/31/04 Target for finalized sample selection 01/31/04 Install SAS 01/31/04 Install Load Research Software 1/5/04 Design and select TDSP samples 1/31/04 Finalized TDSP IDR installation schedule 1/15/04 TDSPs starts ordering IDRs February 2004 -- Completion 02/04 Start receiving sample IDR data from TDSPs 06/01/04 Start posting IDR data for CRs IDR Installation Complete at TDSPs -6 months after sample set selection 2/1/03-2/28/2003 CR Handshake test (on-going) 04/15/04 Complete Development for LRS solution at ERCOT 05/15/04—05/31/2004 Market test validation for IDR files – TDSP and CR
LRS PROJECT UPDATES • Market Decisions for LRS Project • Incoming IDR files (load profile data) from TDSPs will be in .LS format • Incoming IDR data will be transported by FTP Replacement protocol (TDTWG recommendation) • Completion of IDR installations by TDSPs could take up to 6 months from sample selection decision • ESIID with meter number information will be provided from TDSPs to ERCOT by a .CSV template • A daily Ack/Nack summary report should be generated by ERCOT for all inbound IDR information for each TDSP
LRS PROJECT NOTES AND ISSUES • Target design and select TDSP samples date has slipped from 11/20/2003 to 1/5/2004 (target). Slip due to hardware and software constraints • Time period from initial TDSP design sample to finalized sample selection will be used to review sample selection data, review viability for IDRs in the field, and TDSPs sample selection confirmation • Each TDSP will provide an installation schedule for IDR meters (1/31/2004), and installation shall be an on-going process for 6 months post sample design selection • Target IDR installation complete date based on TDSP IDR installation dependencies and finalized sample design. Additional constraint due to Direct Load Control Project not currently taken into account (project currently on hold pending PUC approval)