Date Posted
Retail Market Guide (RMG) Section(s) Requiring Revision (Include Section No. and Title) / 7.11 Mass Transition
Protocol Section(s) Requiring Revision, if any
Requested Resolution (Normal or Urgent, and justification for Urgent status) / Normal
Revision Description / This Retail Market Guide Revision Request (RMGRR) defines the process for mass transition of ESI IDs from one CR to another CR when transitioning due to an acquisition.
Reason for Revision / Facilitate the large transition of ESI IDs as a result of an acquisition pursuant to Subst. R. 25.493, Acquisition and Transfer of Customers from one Retail Electric Provider to Another.
Overall Market Benefit
Overall Market Impact
Consumer Impact
Quantitative Impacts and Benefits
Assumptions / 1
2
3
4
Market Cost / Impact Area / Monetary Impact
1 / Changes to ERCOT Systems / Unknown
2 / Changes to TDSP Systems / Unknown
3 / Possible changes to CR Systems to accept 814_14 / Unknown
4
Market Benefit / Impact Area / Monetary Impact
1 / Compliance with PUCT Subst Rule 25.493 / Unknown
2 / Ability to expeditiously transfer large volumes of ESI IDs from one CR to another CR / Unknown
3
4
Additional Qualitative Information / 1
2
3
4
Other Comments / 1
2
3
4
Sponsor
Name / Jennifer Frederick on behalf of the Texas Standard Electronic Transaction (Texas SET) Working Group
E-mail Address /
Company / Direct Energy
Phone Number / 512-320-7912
Cell Number / 512-922-1652
Market Segment / Independent Retail Electric Provider (IREP)
Market Rules Staff Contact
Name / Sandra Tindall
E-Mail Address /
Phone Number / 512-248-3867
Proposed Guide Language Revision
7 Market Processes
7.1 Overview and Assumptions
(1) Market Processes provides the processes and guidelines for Market Participants operating in the Texas retail market to resolve issues allowing the market to function in a timely and efficient manner.
(2) In the ERCOT Region, there are Transmission and/or Distribution Service Providers (TDSPs) which are categorized as Municipally Owned Utilities (MOUs) and/or Electric Cooperatives. General information for the TDSPs can be found in Table 1, TDSP General Information.
(3) Differences between the MOU and/or EC TDSP market and the Investor Owned Utility (IOU) TDSP market are identified in their respective tariffs.
(4) For current tariff information, refer to P.U.C. Subst. R. 25, Appendix V, Tariff for Competitive Retailer Access, and subsection (d)(1), Figure: 16 of P.U.C. Subst. R. 25.214, Terms and Conditions of Retail Delivery Service Provided by Investor Owned Transmission and Distribution Utilities, on the Public Utility Commission of Texas (PUCT) website or the TDSP website.
(5) For an overview on the use of the Texas Standard Electronic Transactions (TX SETs), refer to Protocol Section 19, Texas Standard Electronic Transaction.
(6) The Texas Standard Electronic Transaction Implementation Guides located on the ERCOT website provide implementation guidelines for the transactions used in the Texas retail market as well as specific details contained within the transactions.
Table 1. TDSP General Information
TDSP / General Call Center / Website /AEP / 877-373-4858 / http://www.aeptexas.com
CNP / 713-207-2222 (local – Houston)
800-332-7143 (toll free) / http://www.centerpointenergy.com/home
Oncor / 888-313-6934 (CRs only, not for end-use Customer) / www.Oncor.com
SULP / 956-687-5600
After-hours: 956-668-9551 / http://www.sharylandutilities.com/
TNMP / 888-866-7456 / www.tnmp.com
7.2 Market Synchronization
(1) Market synchronization issues may arise as Market Participants submit and process transactions.
(2) In order to maintain synchronization with the Transmission and/or Distribution Service Providers (TDSPs) and Competitive Retailers (CRs), ERCOT provides the following reports on the Market Information System (MIS) Certified Area:
(a) Mapping Status Reject Report – A daily report identifying inbound transactions that ERCOT rejected due to mapping status errors.
(i) Notifies TDSPs and CRs that one or more transactions submitted the previous day were rejected due to failing the Texas Standard Electronic Transaction (TX SET) validation process.
(b) 867RCSO Report – A weekly report identifying service orders in which ERCOT received an 867_03, Monthly or Final Usage, (finals) and/or 867_04, Initial Meter Read Notification, transaction(s) for service orders that are cancelled in the ERCOT systems.
(i) Notifies TDSP(s) that they had one or more 867 RCSO exceptions;
(ii) Reports are posted each Monday for the previous week, Sunday through Saturday, based on the received date of the 867 transaction;
(iii) Assists the TDSPs in identifying a potential out-of-sync condition between the TDSP and ERCOT;
(iv) For completed service orders, the TDSP will create a day-to-day MarkeTrak issue to change the service order status to complete in the ERCOT systems. Completion of cancelled service orders will require the approval of the CR initiating the transaction; and
(v) For cancel by customer objection, the TDSP will honor the cancel in their systems.
(c) 997 Functional Acknowledgement Report – A daily report providing details on 997, Functional Acknowledgements, that were not received by ERCOT within three days of receipt of the transaction.
(i) Notifies TDSPs and CRs that they have not sent the Accept or Reject in the 997 transaction for Electronic Data Interchange (EDI) files they received from ERCOT three days prior; and
(ii) Provides a method for Market Participants and ERCOT to validate receipt and submission of all EDI transactions.
(d) Potential Load Loss Report – A daily report notifying CRs of potential Customer loss based on ERCOT’s receipt of the TDSP’s accepted response to a Switch or Move-In Request.
(i) Notifies CRs that are the current Retail Electric Provider (REP) of record for an Electric Service Identifier (ESI ID) that the ESI ID has a pending Switch or Move-In Request and the scheduling transaction for the pending order has been received outside the two Business Day window; and
(ii) Assists CRs with daily Load forecasting by providing advance notice of the potential loss of a Customer and the associated Load.
(3) ERCOT has developed MarkeTrak, an issue management tool, to help ensure that the various databases are synchronized with each other. The ERCOT MarkeTrak system is a web-based workflow application made available to all active Market Participants with a digital certificate. MarkeTrak is the primary tool used by Competitive Retailers (CRs), Transmission and/or Distribution Service Providers (TDSPs) and ERCOT to resolve retail market transaction issues, request manual service order cancellations, request ERCOT assistance with inadvertent Electric Service Identifier (ESI ID) transfers, and file Data Extract Variance (DEV) issues.
(24) All retail market transaction issues and DEV issues must be logged in the MarkeTrak system before they can be worked by ERCOT.
(35) Market Participants should refer to the MarkeTrak Users Guide located on the ERCOT website for guidelines on issue submission, timing, and issue resolution.
7.2.1 Transmission and/or Distribution Service Provider Cancel
When it is necessary for a TDSP to request a manual cancellation of a service order at ERCOT, the TDSP shall submit the cancellation through the MarkeTrak process. The workflow will allow the CR and TDSP involved with the cancellation to have access to the issue. When ERCOT issues the cancel, it will provide the A13 reject code with explanatory text appropriate for the scenario.
7.2.2 MarkeTrak Day-to-Day
(1) Market Participants use the MarkeTrak Day-to-Day workflow to report an issue to ERCOT and/or the TDSP. By selecting the Day-to-Day MarkeTrak issue and the correct subtype, Market Participants are able to create an issue that involves ERCOT and potentially another Market Participant or a non-ERCOT issue such as a point-to-point transaction between a Market Participant and the TDSP.
(2) Some examples of issues that should be filed to ERCOT through MarkeTrak are Service Order Request cancellations, Retail Electric Provider (REP) of record requests, inadvertent issues, rejected transactions and missing transactions. Some examples of non-ERCOT Day-to-Day issues are billing questions and missing monthly usage.
7.2.3 MarkeTrak Data Extract Variance Processes
(1) In order to ensure that ERCOT systems and Market Participant systems are synchronized, ERCOT created the ESI ID Service History and Usage Data Extract. ESI ID Service History includes ESI ID relationships and ESI ID characteristics. This data extract provides transparency to Market Participants for ESI ID level data that ERCOT utilizes in market Settlement. The DEV process will assist in the expedited resolution of ESI ID level data variances between ERCOT and Market Participant systems. Load Serving Entities (LSEs), Meter Reading Entities (MREs), and TDSPs will receive these incremental changes from ERCOT on a daily basis. See the MarkeTrak Users Guide for business rules concerning filing DEV issues in MarkeTrak.
(2) If a DEV issue, submitted according to the MarkeTrak Users Guide is not resolved prior to the True-Up Settlement, a Market Participant may seek correction of ESI ID service history and usage information and resettlement pursuant to the provisions of Protocol Section 20, Alternative Dispute Resolution Procedure.
7.3 Inadvertent Gain Process
This Section provides guidelines for ensuring that inadvertently gained Electric Service Identifiers (ESI IDs) are returned to the losing Competitive Retailer (CR) in a quick and efficient manner with minimal inconvenience to the Customer as required by P.U.C. Subst. R. 25.495, Unauthorized Change of Retail Electric Provider.
7.3.1 Escalation Process
Each Market Participant is responsible for compliance with the Public Utility Commission of Texas (PUCT) rules and the procedures and timelines in this Section 7.3, Inadvertent Gain Process. Each Market Participant shall provide escalation contacts consistent with the process outlined in the MarkeTrak User Guide, Section 1.7.1, Rolodex, to assist in resolution of delays and disputes regarding the procedures. MarkeTrak will send escalation e-mails to the escalation contact(s) whenever an issue has remained untouched for seven days.
7.3.2 Competitive Retailer’s Inadvertent Gain Process
As soon as a CR discovers or is notified of a potential inadvertent gain, the CR shall investigate the matter immediately. The CR investigation should include reviewing the ESI ID Service History on the Texas Market Link (TML).
7.3.2.1 Buyer’s Remorse
7.3.2.1.1 Rescission Period
(1) An untimely notice of rescission does not constitute and should not be treated as an inadvertent gain or loss. Any CR receiving an untimely notice of rescission from the Customer shall inform the Customer that they have a right to select another CR and may do so by contacting that CR. The CR shall also inform the Customer that they will be responsible for charges from the CR for services provided until they switch to another CR. The right of rescission is not applicable to a Customer requesting a move-in.
(2) CRs that receive anotice of rescission in a timely manner shall first attempt to cancel the order in question by submitting the appropriate Texas Standard Electronic Transaction (TX SET). If this is not possible due to the order having Completed, MarkeTrak shall be utilized to restore the Customer to their previous Retail Electric Provider (REP). The submitting REP for a rescinded switch shall follow the process outlined in the MarkeTrak Users Guide.
7.3.2.1.2 Breach of Contract
The MarkeTrak inadvertent gain process shall not be used to resolve a Customer’s intentional breach of a contract.
7.3.2.2 Prevention of Inadvertent Gains
(1) If the gaining CR determines that a potential inadvertent gain may be avoided by cancelling a pending switch or move-in transaction during the evaluation period (two Retail Business Days prior to a move-in or a switch), the gaining CR shall file a Cancel with Approval MarkeTrak issue in order to prevent the need for an Inadvertent Gain MarkeTrak issue. The gaining CR shall note in the comments field of the Cancel with Approval MarkeTrak issue that this cancellation is being requested in order to prevent an inadvertent gain.
(2) If an Inadvertent Gain MarkeTrak issue has already been created, the Cancel with Approval MarkeTrak issue should be linked to it, and the Gaining CR shall note in the comments field of the Inadvertent Gain MarkeTrak issue that a Cancel with Approval MarkeTrak issue has been created. The Transmission and/or Distribution Service Providers (TDSPs) shall attempt to cancel the pending transaction even if the transaction currently falls within the evaluation period.
(3) Cancellation of a pending switch/move-in that will cause an inadvertent gain shall be addressed as follows:
(a) Before the evaluation period of a transaction, if the submitting CR discovers that the transaction will cause an inadvertent gain, the submitting CR shall cancel the transaction using the 814_08, Cancel Switch/Move-In/Move-Out/Mass Transition Drop Request.
(b) If the ESI ID is discovered to be an inadvertent gain during the evaluation period, and if the TDSP approves the cancellation during the evaluation period, the submitting CR shall follow the MarkeTrak process to request cancellation of the transaction.
7.3.2.3 Resolution of Inadvertent Gains
(1) If the CR determines that the gain was unauthorized or in error, the CR shall promptly submit an Inadvertent Gain issue in MarkeTrak. (See Section 7.2, Market Synchronization, for more information about MarkeTrak).
(2) The gaining CR shall not submit a Move-Out Request or a Disconnect for Non-Pay (DNP) on an ESI ID that was gained in error.
7.3.2.3.1 Reinstatement Date
(1) The losing CR and the gaining CR may work together to negotiate a reinstatement date for the losing CR to take the ESI ID back and note that date in the MarkeTrak issue. However, the losing CR shall ultimately determine the reinstatement date and note that date in the MarkeTrak issue.
(2) The reinstatement date shall be one day beyond the date of loss (date of loss is the date the Customer started with the gaining CR) or any subsequent date chosen by the losing CR for which the losing CR had authorization to serve the Customer but no greater than 15 days past the date the MarkeTrak issue was logged.
(3) The losing CR shall submit an 814_16, Move- In Request, that is backdated by at least one Business Day. The losing CR shall submit a move-in no later than 17 days after the MarkeTrak issue was logged, utilizing the reported reinstatement date.
(4) If the reinstatement process is delayed, the reinstatement date shall not be extended beyond 15 days from the date the MarkeTrak issue was logged.
(5) If the move-in has not been submitted within this required timeline, or the reinstatement date is different than the date noted in the MarkeTrak issue, refer to the escalation process in the MarkeTrak Users Guide.