1 / 25

Pre-TX Set 1.5 Data Clean Up

Pre-TX Set 1.5 Data Clean Up. 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 – 0 TDSP 2 – 0 TDSP 3 – 6 TDSP 4 – 6

sondra
Télécharger la présentation

Pre-TX Set 1.5 Data Clean Up

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. 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 – 0 TDSP 2 – 0 TDSP 3 – 6 TDSP 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,953 TDSP 2– 1,215 TDSP 3 – 991 TDSP 4 – 994 • Action Item: ERCOT request missing transaction from the TDSPs or confirmation to cancel

  3. Pre-TX SET 1.5 Data Clean-up Process 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 31 TDSP 2-ERCOT working to complete 694 TDSP 3-ERCOT working to complete 624 TDSP 4 no response • Action Requested: TDSP give OK to remain cancelled or coordinate transaction submittal to ERCOT

  4. Pre-TX SET 1.5 Data Clean-up Process 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. Pre-TX SET 1.5 Data Clean-up Process 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) • Of the 248Service 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) 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 • 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? • 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 • 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, 2003 Time: 10:00 am – 4:00 pm Central Time Location: 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

  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. Canceling Drop to AREP, Cntd. • 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. Cancel DTA Scenarios, Cntd. • 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. Cancel DTA Scenarios, Cntd. • 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. Canceling Drop to AREP, Cntd. • 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 Market Sync Response Files File Count 16 TDSPs 29 CRs 4 ERCOT ESI ID Count 2,854 TDSPs 13,300 CRs 2,966 ERCOT 15,931 Distinct ESI IDs 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 Compile List of ESI IDs not completed Removed List from Market Sync DEV List Completed 7-8-2003

More Related