1 / 78

Update from ERCOT Retail Market Services to RMS February 12, 2004

Update from ERCOT Retail Market Services to RMS February 12, 2004. Agenda / Presenters. MIMO Stacking Solution Update Glen Wingerd Data Variance / SCR 727 Extract Update Betty Day / Troy Anderson Texas Market Link (PRP phase 1) Update Matt Mereness

kali
Download Presentation

Update from ERCOT Retail Market Services to RMS February 12, 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Update from ERCOT Retail Market Services to RMS February 12, 2004

  2. Agenda / Presenters • MIMO Stacking Solution Update • Glen Wingerd • Data Variance / SCR 727 Extract Update • Betty Day / Troy Anderson • Texas Market Link (PRP phase 1) Update • Matt Mereness • Commercial Application Systems Upgrade Project • Dave Odle • EDIM Progress Reports • James Cohea

  3. Supporting Reports • EDIM Progress Reports • Fast Trak Day to Day Issues Progress Report • Fast Trak DEV Issues Progress Report • Pre-Texas SET 1.5 Data Clean Up Progress Report • On-Going Data Clean Up Update • Proactive Reporting • NAESB 1.6 Migration Update • Load Research Project Update • Flight Test Update (0104) • CR Data Extract Variance Reporting

  4. Move-In/Move-Out Market Solution to Stacking (Texas Set V.2.0)

  5. Market Coordination Team for the Solution to Stacking • Agenda • Market Participant Progress Tracking • Educational Seminars • Next Steps • Implementation Plan

  6. 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 • Additional questions were asked to identify known risk • Have you identified any risks that will prevent your company from beginning testing on time (April 26th)? • Please describe any risk(s). • Have you identified any risks that will prevent your company from implementing on time (August 1st)? • Please describe any risk(s). • Response is required, non-responses will be reported to RMS. Non-response to the status will result in a default to the previous month’s status. Non-Response to the questions will indicate that no risks have been identified. • Progress including reporting of identified risks will be reported through April, 2004

  7. Market Coordination Team for the Solution to Stacking • ERCOT/TDSPs/Service Providers

  8. Market Coordination Team for the Solution to Stacking • REPs

  9. Market Coordination Team for the Solution to Stacking • Answers to Status Questions: • 3 of 76 did not provide a status (Calpine, Tenaska, & XERS) • 71 of 76 indicated that no risks had been identified • 2 of 76 reported manageable issues • Yes, we are currently in the process of selecting a new CIS vendor.  However, all of the vendors that we are in discussions with should be ready to begin testing on 4/26.   Contracts are estimated to be signed by 2/27/04.  The two vendors in the early front running both have status that they have reported to you. • 2.0 Changes occurring as we get closer to Flight 0504; Late changes could impact the design and thus causing code and/or design changes

  10. Market Coordination Team for the Solution to Stacking • Educational Seminars • 27 Educational Seminars completed, 2 scheduled • Over 400 participants have attended

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

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

  13. 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 2/19/04 • Continue to Track Market Participant Progress • Finalize details of Production Implementation Plan • Finalize details of Transition Plan for Service Orders ‘In Flight’ • Develop Post-Implementation Success Criteria

  14. Shut Down Etiquette Shut Down • The shutdown times listed will be strictly adhered to. • All MPs should submit transactions well in advance of the shutdown time so that large transaction volumes are not experienced just prior to shutdown • (i.e. if you run batch jobs, schedule them throughout the day)!!! • All MPs shall call-in to each conference call, on-time, during the implementation. • All times listed are Central Prevailing Time

  15. Use of Safety Net Safety Net • Beginning Thursday, July 29 at 0800, the CR will utilize the approved Safety Net process during implementation with a default BGN 02 value to request Move-Ins with requested dates of July 29th through August 2nd. The BGN02 must use the following format: • First 4 spaces= MIMO • Next 3 spaces= Abbreviated CR name • Then followed by a unique number to each CR. • CR's will be required to follow up with the corrected BGN02 immediately after implementation. • The TDSPs will no longer accept default BGN values on Monday Aug 2nd at 0800 or as soon as Version 2.0 transactions begin to flow.

  16. 650 TransactionsShut-down timeline for Disconnects 650 Disconnects for Non-Pay • REPs must stop sending Disconnect for Non-Pay 650’s at 0800 Monday, July 26. • REPs must stop sending Temporary Disconnect 650s at 0800 on Tuesday July 27. • CR's should contact each TDSP via phone or e-mail with any emergency issues. • TDSP's will begin their normal reconnect process, contingent upon resources and volumes, on Monday morning following conversion. • A follow up 650 will not be required for previously received request.

  17. Legend = Conference Calls CRs ERCOT TDSPs Implementation Shutdown Overview Wednesday Midnight Thursday Noon Thursday Midnight Friday Noon Friday Midnight Initiating 814_01, 814_10, 814_16, 814_24 1 am 6 hrs 14 hrs 6 hrs 9 hrs 814_08, 814_12, 814_18, 814_26 9 pm 6 hrs 8 hrs 6 hrs 6 hrs 814_20 9 pm 6 hrs 8 hrs 6 hrs 867 2 pm 8 hrs 7 hrs 650_01 5 pm 1 hr 810, 650_04 5 pm 1 hr 2 pm 4 hrs 814_PC

  18. Conference Call Times Ten Planned Market Conference Calls • Wednesday July 28th 5 p.m. • Thursday July 29th 9 a.m. • Friday July 30th 9 a.m. • Friday July 30th 5 p.m. • Saturday July 31st 9 a.m. • Saturday July 31st 7 p.m. • Sunday August 1st 9 a.m. • Sunday August 1st 3 p.m. • Monday August 2nd 9 a.m. • Tuesday August 3rd 9 a.m.

  19. Start up Etiquette Validation of 2.0 prior to resuming normal transaction volumes • MPs that wish to do this will have to regulate the flow of transactions into and out of their system. • ERCOT will not run special tests with MPs during the migration prior to opening the market with 2.0 functionality. • Any responses that are not sent prior to shut-down will be sent after start-up and will be validated against Version 2.0. All stacking rules will apply.

  20. Conversion Plan • Service Orders ‘In Flight’ • All Transactions that are sent (including re-drops) and received by all market participants after the implementation of Stacking will be processed under the new Stacking rules and will use the Version 2.0 implementation guides • Date Changes and Cancels received after the implementation of stacking on orders that were scheduled prior to implementation will be processed using the new Stacking rules • Stacking rules that are designed to be executed at the beginning of the evaluation period or on the scheduled meter read date will be executed on orders that were scheduled prior to stacking • For Date Changes, it will be required that for any date changes that the REP has not received a response prior to implementation of stacking, they will have to send a new date change request • For Cancels, it will be required that for any cancels that the REP has not received a response prior to implementation of stacking, they will have to send a new cancel request

  21. Conversion Plan • Service Orders ‘In Flight’ • 814_14s and 814_22s that have been sent out prior to the implementation of stacking will not be sent again during their evaluation periods. • For Move-Ins and Move-Outs that are scheduled on the same day for the same ESI ID within 2 business days after the implementation of stacking, ERCOT will cancel the Move-Out and allow the Move-In to complete. • Order information in the form of a spreadsheet and 814_08s for cancelled Move-Outs will be provided to affected TDSPs and REPs • Move-Outs will be cancelled after the implementation of stacking and 814_08s will be sent to all affected parties • Volume is expected to be around 1,000 • Once Stacking has been implemented, backdated MVIs/MVOs that are requesting a date prior to implementation of stacking will be processed using stacking rules.

  22. Conversion Plan • Service Orders ‘In Flight’ • All orders that are in a Cancel Pending state at 11:00 am on Friday will be manually cancelled by ERCOT. • 814_08s will be sent out for these orders after implementation • The TDSPs will not be able to reject them. • This will require a concerted effort to clean up all potential CWEs prior to implementation weekend • Volume is expected to be around 300 • The MCT has reviewed the Option 1 Outages and has determined that implementation will have no affect on it. • For Move-Ins with a status of Permit Pending during migration weekend, ERCOT will re-calculate the PNR expiration to be Requested Meter Read Date +20 Bus. Days. If that calculation yields a date that is less than the first business day after implementation weekend, ERCOT will default to a date that is equal to the first business day after implementation weekend.

  23. When bad things happento a good plan… • At the point that we arrive at conversion weekend, every market participant has: • Provided monthly statuses • Participated in migration conference calls • Passed testing certification. • The inability of a Market Participant to successfully implement would not be a situation where a party failed to build their solution, but rather a situation where there is a technical problem with migrating to their production environment. • Based on this, it is the position of MCT that any issues on conversion weekend will be of the type that cause delays measured in hours not days. • Although it is a fundamental requirement for all MPs that they have a back-out plan, MCT does not envision an issue that would be a showstopper, but does believe there may be a possibility for delay.

  24. When bad things happento a good plan… • If any party cannot implement the stacking solution at any point between July 23rd and August 1st, the potential for delay will be discussed on an emergency conference call. • As determined on the call, the affected parties will develop a plan for resolving the issue(s). • Once Version 2.0 transactions begin to flow, there will be no turning back. • There will not be a reverse migration once Stacking goes live.

  25. Data Variance / SCR 727 Extract Status

  26. Texas Market Link(PRP Phase 1)

  27. IT Update – Texas Market Link(Portal Replacement Project Phase 1) • Status: • The previous launch of TML was unsuccessful due to platform stability issues. • The Vendor has addressed the stability issues with a code fix to the software platform that is being stress tested by ERCOT. • Moving forward: • Feb 17- TML is to be moved into final integration testing (iTest). • March 2- Planned completion date of functional and stress testing. • ERCOT IT may reach out to MP for assistance in technical testing. • March RMS Meeting- ERCOT plans to provide details of next steps for the launch of TML in parallel with the current Portal.

  28. Commercial Application Systems Upgrade Project (CASUP) PR# 30082_02

  29. Since Jan RMS • Business Requirements • On Schedule • Technical Requirements Delivery • On Schedule • Recommendation (Upgrade/Replace) and Vendor Shortlist Delivery • Vendor in house demonstrations completed 2/3 • Currently aggregating data for evaluation • Requirements phase to conclude 3/31/04

  30. By March RMS • Vendor information aggregated and evaluations completed • Shortlist of vendors who could be potential candidates • Cost/Benefit/Risk Analysis • Recommendation(s) given • Requirements • Business detailed requirements ready for review • Technical detailed requirements ready for review

  31. CASUP Market Communication • Would like to solicit input from Market Participants • Arrange a conference call for the last week in February for all interested MPs to voice concerns and provide opportunity to express opinions to ERCOT

  32. Customer Protection and 814_08 Issue(Phase 1 – Potentially Missing 08s) • Background and Completed Items • Matrix and Progress Report • Other Status Items and Next Steps

  33. Customer Protection Period and 814.08(Phase 1 – Potentially Missing 08s) 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 • Scenario 1 instances: ERCOT has completed synching with the TDSPs on all of these. • 41 FasTrak issues: • 33 Resolved (spanning 52 switches) • 8 In Progress (some dialog has occurred) • Matrix of FasTrak issues not yet resolved provided to RMS Chair/Vice Chair on 11/6/03, 12/4/0, 1/6/04 and 1/30/04 - included CR names • ERCOT has “processed” all email exchanges related to FT issues as of 02/04/04 Next Steps • ERCOT to continue to escalate missing responses • CRs and TDSPs make decisions on outstanding FasTrak issues and provide response to ERCOT via FasTrak and Email

  34. Customer Protection Period and 814.08(Phase 1 – Potentially Missing 08s) February 6, 2004 Status

  35. Customer Protection Period and 814.08(Phase 1 – Potentially Missing 08s) February 6, 2004 Status Notes • Of the remaining 52 switches “In Progress”, 36 of these switches are on two FasTrak issues that appear very close to resolution. • Recent activity surge implies many others are moving towards resolution.

  36. Customer Protection and 814_08 Issue(Phase 2 – Potentially Late 08s) • Background and Completed Items • Matrix and Progress Report • Other Status Items and Next Steps

  37. Customer Protection Period and 814.08(Phase 2 – Potentially Late 08s) Background Upon inception of Phase 1 of the ‘Potentially Missing 08s’, MPs requested an analysis of potentially late 08’s on Cancel by Customer Objection (CCO). ERCOT identified 264 instances of 08’s on CCOs that were sent to the TDSP at least two days after the end of the customer objection period where the TDSP rejected the cancel. These switch transactions span the August 2002 through November 2003 time frame. Upon direction from RMS at the December 2003 meeting, ERCOT sent list to each CR and TDSP involved in an attempt to quantify the true scope of out-of-sync conditions.

  38. Customer Protection Period and 814.08(Phase 2 – Potentially Late 08s) Completed Items • Received direction at 01-14-04 RMS meeting: (Excerpt from Minutes) “The RMS discussed the scenario when an 814_08 is late. The RMS agreed, that for Phase 2, that if the customer objects and there is a cancel within the rescission period, the customer’s request should be honored. ERCOT will notify all parties involved, using the Inadvertent Gain Process. It was noted that CRs might need to send a backdated move-in to ERCOT’s System as the same process as an Inadvertent Gain.” • ERCOT created 30 FasTrak issues on 1-30-04 connecting both CRs and notified the TDSP and CRs via email of the RMS directive and the FasTrak issue Next Steps • CRs review the FasTrak issue and ensure they honored the Cancellation by Customer Objection • TDSPs review email notification of the issue and ensure they honored the Cancellation by Customer Objection

  39. Pro-Active Transaction Resolution Measures Summary - Overview

  40. Proactive Measures Summary Excerpt from August 2003 Minutes: • “Cohea was asked to develop a process and timeline for making the Pre-Texas SET 1.5 Data Clean-Up Process an ongoing process.” Activity Timeline: • ERCOT initiated an “Ongoing Transaction Data Clean-up” program similar to the Pre-TX SET Data Clean-up process in October 2003 which was endorsed by RMS • ERCOT announced the development and pending implementation of four proactive measures to meet the August 2003 RMS directive • ERCOT initiated a test implementation of the 867RCSO measure in November 2003 • ERCOT will fully enact all four proactive measures in February 2004

  41. Proactive Measures Summary

  42. Pro-Active Transaction Resolution Measures 867s Received on Canceled Service Orders

  43. 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. Process Timing and Implementation : • Since Friday 11/7/2003 and 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 • TDSPs have been reviewing the data and providing responses back to ERCOT identifying that the transaction was either cancelled (in-sync with ERCOT) or completed (out-of-sync with ERCOT) in the TDSPs system

  44. 867s received on Canceled Service Orders

  45. 867s received on Canceled Service Orders ERCOT and TDSP Proposal for Handling 867 RCSO: Step 1: ERCOT produces 867RCSO data each Friday and submits an ERCOT initiated FasTrak to the TDSP Step 2: The TDSPs review the FasTrak line items and take one of the following actions: a) If the TDSP has cancelled the service order, note cancelled on the line in the FasTrak issue Note: For Cancel by Customer Objection, the TDSP will honor the cancel in their systems b) If the TDSP has completed the service order, they will establish a new day-to-day FasTrak issue and work with ERCOT to get ERCOT systems changed to complete also – in this case the TDSP will note the new FasTrak issue number in the line item of the original ERCOT initiated 867RCSO FasTrak issue Step 3: Once all line items within the ERCOT initiated 867RCSO FasTrak issue have been updated, the TDSP and ERCOT will close that issue.

  46. 867s received on Canceled Service Orders Completed Items • ERCOT continues sending weekly FasTrak issues to TDSPs • ERCOT modified process to omit 867 Cancels from reporting beginning with 2004 • ERCOT met with each TDSP on 2/4/04 and 2/5/04 to determine a consensus direction for clearing out-of-sync ESI IDs Next Steps • Seek RMS approval of TDSPs and ERCOT consensus for going forward • ERCOT to move from a FasTrak Initiated issue to an automated weekly report to the TDSP

  47. Thank You

  48. Supporting Reports Section

  49. FasTrak Issue Status • Day-to-Day • Data Extract Variances (DEV) • ERCOT Initiated Issues

  50. FasTrak 2003 “Day to Day”Issue Stats (as of 02-06-04) • Of the 14 In Progress, 8 are resolved and awaiting other party resolution check off • Total ESI IDs worked on 2003 issues = 324,653 • Of the 3,023 New and In Progress Non- ERCOT issues, 10 are for the year 2002 • Number of ESI IDs not tracked

More Related