ESI IDs Retired in Error!

RMS – August 10, 2005 Discussion 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 ImpactsNew 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.