Pre-TX Set 1.5 Data Clean Up

1

Pre-TX Set 1.5 Data Clean Up

2

Pre-TX SET 1.5 Data Clean-up Process

In-Review - currently 12 (Original Quantity = 863)– June RMS, count 207 In-Review with Meter Read present– Update In Progress: 12 In Review with Meter Read waiting on TDSPs

TDSP 1 – 0TDSP 2 – 0TDSP 3 – 6TDSP 4 – 6

– Action Item: ERCOT request missing transaction from the TDSPs

Scheduled – currently 6,153 (Original Quantity =17,676)– June RMS, count 11,038 Scheduled with No Meter Read present– ERCOT provided TDSPs and CRs an updated list of ESI IDs– ERCOT would like to note that since June RMS, ERCOT and the TDSPs have been able

to resolve 4,945 Scheduled ESI IDs– Update In Progress: 6,153 waiting on TDSP response

TDSP 1 – 2,953TDSP 2– 1,215TDSP 3 – 991TDSP 4 – 994

– Action Item: ERCOT request missing transaction from the TDSPs or confirmation to cancel

3


Cancelled with Exception - currently 1,349with Meter Reads present Process:– June RMS, count Cancelled with Exception, 1,618– ERCOT provided TDSPs and CRs an updated list of ESI IDs– Update 7-14-03: (1,349 In Progress waiting response on 269)

TDSP 1-ERCOT working to complete 31TDSP 2-ERCOT working to complete 694TDSP 3-ERCOT working to complete 624TDSP 4 no response

– Action Requested: TDSP give OK to remain cancelled or coordinate transaction submittal to ERCOT

4


Issue: These outstanding pending service orders are causing NFIs and out of sync

conditions.

June 3rd, 2002 thru June 7th, 2002

Total Not First Ins for the week: 3,696

• 17 NFIs - OLD Service order exists for 2001

• 473 NFIs - SO exists for current transaction

• 1,933 NFIs - CR submitted multiple transactions basically at same time/for same data range (same CR)

• 35 NFIs - SO exists for an order that should be COMPLETE but maybe is only 5 days old, 10 etc. (included some that were a month old)

• 1,238 NFIs - OLD service order pending from January thru early May of 2002.

5


Recommend RMS approval to have the TDSPs to respond to ERCOT with the necessary actions requested to resolve the Pre-TX Set 1.5 Data Clean UP initiative by August 29th, 2003

6

ESI ID Data ExtractVariance Process Update

• Stats by Issue Count • Stats by ESI ID Count (for ERCOT LSE Relationship issues)

• Comment on Process• Potential Issues

7

FasTrak 2003 Data Extract VarianceIssue Stats (as of 07-15-2003)

STATUSService History Usage

TotalIssues

Issues% of Total

New 2 0 2 0.28%

In Progress (ERCOT) 194 0 194 27.17%

In Progress (w/TDSP) 45 0 45 6.30%

In Progress (w/CR) 9 0 9 1.26%

Resolved 17 0 17 2.38%

Rejected/Withdrawn 424 23 447 62.61%

Total 691 23 714

Service History Usage

TotalIssues

Issues% of Total

New 3 25 28 2.30%

In Progress 198 382 580 47.58%

Resolved 158 239 397 32.57%

Rejected 67 147 214 17.56%

Total 426 793 1,219

ERCOT

Non-ERCOT (CR to TDSP)

• Of the 248 Service History Issues In Progress with ERCOT, 54 are resolved and awaiting other party resolution check off

• Of the 248 In Progress Issues a 136 of these Issues were received by ERCOT after the resettlement date.

• .

8

FasTrak 2003 Data Extract VarianceESI ID Stats (as of 07-15-2003)

STATUS Service History UsageTotal

ESI IDs

New 10 0 10

In Progress (ERCOT) 32,843 0 32,843

(w/TDSP) 10,685 0 10,685

(w/CR) 303 0 303

Resolved (per Issue) 146 0 146

(no Fix) 410 0 410

Rejected/Withdrawn 199,737 0 199,737

Total 244,134 0 244,134

ERCOT from CR

TDSP from ERCOT

CR From ERCOT

Average Turnaround Response Time (Calandar Days) 29 24 21

ERCOT LSE Relationship Variances

NOTE: Average turn around time is calculated from the time ERCOT sends the spreadsheet to the TDSP, the TDSP responds and when the CR responds if necessary. Response time is not calculated off of “Progress Reports”.

9

Comments for Thought

• ERCOT can not report statistics or the success of Non-ERCOT issue resolution

• CR submitting issues after settlement of trade date– Out of the 720 issues received by ERCOT, 261 have been out side of the

settlement date. 136 of those are currently in the status of “In Progress”

• ERCOT would like to propose that a spreadsheet is NOT Rejected, but instead is sent back to the submitting Market Participant to remove the invalid ESI IDs, correct any spreadsheet issues and then re-upload the corrected spreadsheet with a new file name.

• ERCOT would like to request a monitoring party be added at the time of creation for all ERCOT data extract variance issues

• ERCOT would like to propose a file naming standard for uploaded spreadsheets: “FT#_MPName_TradeDate_DEVType_MonitoringPartyName”

10

Comments for Thought

1. Multiple CR involvement - Record change request that crosses multiple CR records in ERCOT system

• Who owns responsibility for notification and reconciliation with TDSP and CR(s)?

• What happens when one CR or more disagree?

• Acceptability of all CRs involved knowing who each other is?

2. Completion of some CR requests will create de-energized periods in ERCOT systems where usage data exists

• Will Market Participants accept that usage will be UFE?

• What if usage exists and is really large?

• Is anyone responsible for “finding the correct CR” if completing another CR request results in usage during a de-energized period?

• Note- Quantity of the fixes has been very small

3. For bulk of LSE relationship issues, ERCOT and TDSP agree on record. • CR should modify their database (for 2002 issues)

11

“Check Point” Meeting

ERCOT proposes that a “Check Point” meeting take place to discuss the current data extract variance processes, procedures, potential issues and enhancements that have been requested.

Date: Tuesday, August 5th, 2003Time: 10:00 am – 4:00 pm Central TimeLocation: ERCOT Met Center

A market notice will be sent out with all details.

12

FasTrak Day-to-Day and DEV Issues

General Guidelines:• Day-2-Day issue would be confirmed to be related to transaction or

processing issues.

• If an MP submits a Day-2-Day just to change a date because they don’t agree with ERCOT (without transactional reasoning) then we will reject and require a Data Extract Variance be submitted.

13

FasTrak Day-to-DayIssue Status

14

FasTrak 2003 “Day to Day”Issue Stats (as of 07-15-2003)

• Of the ## In Progress with ERCOT, #### are resolved and awaiting other party resolution check off

• ## remaining issues for 2002 are not included in the numbers to the left

– ## is in progress pending a response from the CR

– ## are in progress pending a response from the TDSP

STATUSIssueCount

Issues as a% of Total

New #DIV/0!

In Progress (ERCOT) #DIV/0!

In Progress (w/TDSP) #DIV/0!

In Progress (w/CR) #DIV/0!

Resolved #DIV/0!

Rejected #DIV/0!

Total 0

IssueCount

Issues as a% of Total

New #DIV/0!

In Progress #DIV/0!

Resolved #DIV/0!

Rejected #DIV/0!

Total 0

Non-ERCOT

ERCOT

15

Cancelling Drop To AREP

16

Canceling Drop to AREP

• As a follow-up to discussions at the June RMS meeting, ERCOT met with the PUCT staff and a customer protection agency to review PUC rules and ERCOT protocols and procedures.

ERCOT Protocols Section 15.1.2

• Prior to initiating a Drop, the CR shall comply with all PUCT rules and regulations. This process ensures that the Customer will not experience an interruption of service, will allow the Customer to choose another CR or will switch the Customer to the POLR or Affiliate REP (as defined in PURA 31.002(2)) if the Customer does not choose a new CR or does not choose a new CR within sufficient processing time. A Drop by a CR is binding on the CR and cannot be cancelled or rescinded.

17

Canceling Drop to AREP, Cntd.

Customer Protection ruling Section 25.474 (k)• Customer's switch to POLR. The methods of customer authorization,

customer verification, and rights of cancellation are not applicable when the customer's electric service is "dropped" to the POLR by a REP for non-payment pursuant to §25.482 of this title (relating to Termination of Contract). Nothing in this subsection shall be read to imply that the customer is accepting a contract with the POLR for a specific term.

Customer Protection ruling Section 25.482 (b)• Termination policy. A REP other than a REP that is authorized to disconnect

for nonpayment pursuant to the provisions of §25.483(b) of this title may terminate its contract with a customer for nonpayment of electric service charges and, if no other REP extends service to that customer, service shall be offered by the POLR until September 24, 2002, and thereafter by the affiliated REP. If a customer makes payment or satisfactory payment arrangements prior to the termination date, a REP shall continue serving the customer under the existing terms and conditions that were in effect prior to the issuance of a termination notice. If a REP chooses to terminate its contract with a customer, it shall follow the procedures in this section, or modify them in ways that are more generous to the customer in terms of the cause for termination, the timing of the termination notice, and the period between notice and termination. Nothing in this section shall be interpreted to require a REP to terminate its contract with a customer.

18


• As noted in the market notification on June 17th, 2003, ERCOT has begun to honor all requests from the originating CR, TDSP and/or the gaining AREP that are logged via FasTrak to cancel Drop to AREP transactions that have not yet completed as denoted in the below scenarios.

• This decision comes from interpretations of sections 25.474 (k) which only discusses not allowing the customer to cancel the Drop to AREP transaction and 25.482 (b) which states that REPs have an obligation to take back customers who settle their bill prior to the termination date.

19

Cancel DTA Scenarios

• Scenario 1: Customer settles the bill with the REP and the REP has time to submit a FasTrak issue requesting the cancel prior to the termination date.– REP submits FasTrak asking for DTA be canceled – (No current statistics exist)

• Scenario 2: REP submits a FasTrak issue indicating they sent the Drop to AREP in error.– REP submits FasTrak asking for DTA be canceled– ERCOT manually cancels the DTA and forwards necessary

814.08s– (4 FasTrak Issues; 316 ESI IDs)

20

Cancel DTA Scenarios, Cntd.

• Scenario 3: While a drop to AREP is pending at ERCOT, the TDSP receives a safety net move in. TDSP cancels the drop in their system and allows the move in to process thereby avoiding dropping the new customer to the AREP. TDSP then submits a FasTrak issue asking ERCOT to cancel the Drop to AREP. – TDSP submits FasTrak asking for DTA be canceled– ERCOT manually cancels the DTA and forwards necessary

814.08s– This scenario will not be valid once the solution to stacking is

implemented.– (15 FasTrak Issues; 20 ESI IDs)

21


• Scenario 4: A drop to AREP and switch are both concurrently processing at ERCOT. ERCOT’s system determines that the drop to AREP should win because it is scheduled sooner and cancels the switch. The TDSP completes the switch and cancels the drop. The TDSP requests via FasTrak that ERCOT cancel the drop and complete the switch to match their system.

– TDSP submits FasTrak asking for DTA be canceled

– ERCOT manually cancels the DTA and forwards necessary 814.08s

– This scenario will not be valid once the solution to stacking is implemented.

– (1 FasTrak Issue; 46 ESI IDs canceled)

22


• Scenario 5: TDSP is unable to complete the DTA and request the DTA be canceled. Example, fire occurs at location, no meter existed.– TDSP submits FasTrak asking for DTA be canceled

– ERCOT manually cancels the DTA and forwards necessary 814.08s

– (9 FasTrak Issues; 11 ESI IDs)

• Scenario 6: The gaining AREP is requesting customer information regarding the Drop. The AREP should open a FasTrak and ERCOT will handle the issue the same way as the Inadvertent Switch Process.– AREP submits FasTrak asking for dropped customer information

– ERCOT will facilitate the emails between the AREP and the originating CR

– ERCOT will change the FasTrak from an ERCOT issue to a NON-ERCOT issue

– (1 FasTrak Issue; 1 ESI ID)

23


• ERCOT will cancel Drop to AREP transactions for the above scenarios. These scenarios may or may not be comprehensive. Any requests that do not fit one of these scenarios will be considered as it applies to the customer protection rules. Provided it does not violate any ruling, ERCOT will honor the request.

• Because the ERCOT Protocols (Section 15.1.2) seem to be in contradiction with the customer protection rules (Section 25.482 (b)), this procedure has been implemented concurrently with ERCOT submitting a Protocol Revision Request to the Protocol Revision Subcommittee to make modifications to the protocols to allow for the procedure. This PRR will also include changes necessary to make the cancel EDI initiated.

24

Market SyncClosure

25

Closing Out Market Sync

Compile List of ESI IDs not completed

Compile List of ESI IDs not completed

Removed List from Market Sync

DEV ListCompleted 7-8-2003

Removed List from Market Sync

DEV ListCompleted 7-8-2003

For ESI IDs Not Completed,

Re-send Entire File to TDSP or CR.

(Items not classified as “1” are valid to submit

as DEV issue)Completed 7-7-2003

For ESI IDs Not Completed,

Re-send Entire File to TDSP or CR.

(Items not classified as “1” are valid to submit

as DEV issue)Completed 7-7-2003

Market SyncResponse

Files

File Count16 TDSPs29 CRs 4 ERCOT

ESI ID Count 2,854 TDSPs13,300 CRs 2,966 ERCOT15,931 Distinct ESI IDs

Documents

Pre-TX Set 1.5 Data Clean Up