ESI IDs Retired in Error! RMS – August 10, 2005 Discussion

Current Issue:  ESI IDs have been found to be ‘Retired’ in ERCOT's system, but are still active and energized in both the Rep of Record (CR) and TDSP’s system. Questions(?):  How could this happen?  Why is the ESI ID Still Active for Some and Not Others?

How Could this Happen?  TDSP could have provided an incorrect ESI ID or Service Address for retirement (example 123 Main Street, when it should be 123 Main Lane).  Manual errors where an ESI ID may have been incorrectly entered into ERCOT’s system.  System failures and/or programming changes where information may have been incorrectly populated into a data field showing ESI ID once active, but now retired.  Conversion problems where data loads were transferred and stored into the production database incorrectly.

Why is ESI ID still Active for Some?  System failure may have only occurred in one entities system.  System and database enhancements and/or upgrades requiring data transfers that may not all post correctly creating an out of synch condition.  No current fail-safes in place to prevent or process developed to correct or recover from such event.  ERCOT’s current validation process checks to see if the ESI ID is ‘Retired’ only after the Monthly Usage (867_03) has been sent to the Rep of Record that is indicated in the TX SET transaction from the TDSP.

Protocol Section 15.4  Electric Service Identifier (ESI ID) Each TDSP Service Delivery Point (SDP) shall have a unique number within Texas. Once this unique number has been created and assigned to a SDP, it shall not be re-issued, even in the event of termination of the associated point-of-service. This unique number shall be referred to as the Electric Service Identifier (ESI ID).

Market Impacts  CR has invoiced their Retail Customer monthly with usage received on the 867_03 on a ‘Retired’ ESI ID.  ERCOT does not load usage/consumption for an ESI ID that indicates retired in their database.  CR is not being Settled on usage/consumption for an ESI ID that is de-energized and ‘Retired’ in ERCOT’s system.  TDSP has invoiced CR monthly with usage/ consumption on the ESI ID that is ‘Retired’, but the ESI ID is not Settled.

Retail Customer Impacts (Retired ESI ID)  In order to correct this problem according to existing Protocol Section 15.4 language and Market interpretation: TDSP would cancel all usage and invoices back to the point where ESI ID was ‘Retired’, which could be months. CR would receive all cancelled usage and invoices from TDSP for ‘Retired’ ESI ID Customer may receive cancelled invoice(s) from CR for multiple months of usage just to change the ESI ID. During the meantime, if the Retire is only at ERCOT this may prevent Customer Choice because ESI ID this is not eligible on ERCOT’s Portal for CR Selection, if Retail Customer’s choice is to Switch from current REP.

Retail Customer Impacts New ESI ID  New ESI ID will be created for same Service Delivery Point that was ‘Retired’: TDSP would re-bill the same usage and invoices from point where new ESI ID was created for same Service Delivery Point (SDP) CR would receive re-billed usage and invoice(s) from TDSP for same SDP and same usage. Customer may receive re-billed invoice(s) from CR for same service periods Retail Customer already paid and maybe current causing customer confusion as to why new bills, explanation we needed to change your account/ESI ID number.

Recommendation  RMS would create a Taskforce to develop Market guidelines, procedures, and process to correct and resolve the existing issue of ESI IDs ‘retired’ in error.  Responsibility of Taskforce would be: Review current Protocol language for clarifications and corrections where needed to support process. Discuss Settlement implications and determine timeline procedures to correct CR Settlement. Where possible, develop mechanisms that will prevent this scenario from re-occurring in the future. Document the process in the appropriate Market Guides or Manuals with the recommended Market solution

CNP Taskforce Suggestion  RMS would consider re-activating the DEV Taskforce to develop the process and procedures to resolve this issue.