Allow a DTM ( date time reference) segment to be added to the 814_13 that will allow the TDSP to respond to a date change request with a different date than the requested date. The 814_13 will flow from the TDSP to ERCOT and ERCOT will forward the information to the CR.

ERCOT will forward 814_04 ASI U (reject status) to the CR in the 814_05 ASI U (reject status)

ERCOT will stop creating the 814_27 response. The TDSP will create the 814_27 response and forward to ERCOT and ERCOT will forward to the CR.

ERCOT system to recognize an 814_28 notification from the TDSP that a permit is require. If the switch is still pending 20 days later, then use the 814_08 to cancel the move-in. Use the permit not removed notification segment in the 814_08. Track the cancellations for this reason separate from switches that are timed out.

Enhance the ERCOT Web Portal to include the viewing of pending move-in and move-out transactions and the future effective dates.

Modify the use of the "Not First In" reject reason on the move-in transactions. Not First In should only be valid on a Move In that is requested earlier than the pending Move In date. If the Requested Move In date is requested for LATER than the pending Move In date, the Move In should be allowed to pass and schedule.

This change allows for sequential stacking of Move Ins.

ERCOT will forward 814_25 ASI U (reject status) to the CR in the 814_25 ASI U (reject status). The ASI is a segment in the EDI transaction. The ASI segment identifies if the transaction is an accept â??WQâ?? or a reject â??Uâ??.

The problem and resolution follows the same logic and methodology as SCR 701. 701 deals with Move Ins, this SCR deals with Move Outs, but has the same functionality.

Basically, there is no way to communicate to the CR if the TDSP rejects the Move Out request (814_24) from ERCOT.

This SCR would require ERCOT to pass a DTM~649 on an 867_03.

Add GISB EDM (version 1.6) functionality to the existing Message Broker system implemented during phase 1 of the FTP Replacement project.

New screen on the ERCOT Portal with actual real-time flow, flow limits, and MVARs for all ERCOT-monitored Interzonal elements that comprise the four CSCs and their respective CREs. Further, the screen is to be dynamic so as to allow the ERCOT Operators to indicate the specific element(s) (CSC, CRE, or other) to which the ERCOT Operators are currently constraining. The screen should be updated as often as necessary to provide market participants with relevant data regarding lack of, imminent or actual Interzonal congestion. The data could presumably be culled from the â??Real-Time Transmission Constraints Limits Screenâ?? currently used by ERCOT Operators. All CSCs and their related CREs should be constantly displayed on the new screen, with the element to which ERCOT is constraining identified by a different color. No local congestion data is to be communicated to market participants via the proposed screen.

Add scheduled beginning and ending times to posted proposed and approved transmission clearances. The present postings include only the beginning and ending dates. Clearances are posted at the following two addresses: http://mospublic.ercot.com/ercot/jsp/transmission_outages.jsphttp://mospublic.ercot.com/ercot/jsp/trans_outages_received.jsp

• Forecasted Net Zonal Energy - information will be available for each 15-minute interval of the upcoming Operating Period, one hour prior to the start of each Operating Period (or on whatever timeline ERCOT runs its short-term load forecasting routine to update its forecasted load). The information should be based on ERCOTâ??s Forecasted Zonal Aggregate Load and ERCOTâ??s trend of aggregate zonal generation. Separately, the Working Group is also requesting that ERCOT make available a written description of the methodology, including distribution factors, used in converting from Load Areas to Zones.
• Actual Zonal Generation - This information will be available in real-time on the same timeline as other information regarding frequency control that is already being provided by ERCOT (i.e., every few seconds). This information will be based on SCADA data.

• CSC Shadow Price â?? ERCOT to make available via XML notification (push) at the same time ERCOT determines to deploy zonal balancing energy to mitigate zonal congestion. If more than one CSC is constrained in a 15-minute interval, the shadow price for each constrained CSC will be provided. Currently available on portal and accessible day or so later via spreadsheet download.
• CSC Zonal Limit (OC1) - This value, for each CSC, will also be available via XML query in real-time, every 15-minutes, for the relevant interval (currently the interval ending 45 minutes later) whether or not the CSC is constrained. This value may not be the same as the CSC Monitored Limit. Currently available on portal and accessible day or so later via spreadsheet download.
• Forecasted CSC Loading (Sched Impacts) - This information will be available via XML query in real-time, every 15 minutes, for the relevant future interval (currently the interval ending 45 minutes later), whether or not there is, or is forecasted to be, zonal congestion. ERCOT labels this information as â??MW loadingâ??. Actually, the information is better described as â??MW Scheduled Impactsâ?? since it does not reflect the forecasted or actual CSC loading. ERCOT may re-label this item accordingly. Currently available on portal and accessible day or so later via spreadsheet download.
• Zonal Portfolio BES Deployment Quantities (Both Step 1 and Category 1 Deployments) - Both of these items will be available via XML query in real-time, every 15 minutes, for the relevant future interval (currently the interval ending 45 minutes later), whether or not there is, or forecasted to be, zonal congestion. The Step 1 quantities will correspond to the zonal MCPEs that are currently provided by ERCOT in each 15-minute interval.
• Scheduled Zonal Generation - Day-Ahead scheduled generation aggregated by zone, and made available at approximately 11am the day prior to the Operating Day and updated hourly throughout the Adjustment Period. This information will be available via XML query.
• Total System Incremental (up) Regulation Deployments - The 15-minute integral of this information will be available via XML query immediately following each 15-minute interval.
• Total System Decremental (down) Regulation Deployments - The 15-minute integral of this information will be available via XML query immediately following each 15-minute interval.
• Forecasted and Historical Load by Load Areas - This information will be available via XML query for each 15-minute interval of the upcoming Operating Period, one hour prior to the start of each Operating Period (or on whatever timeline ERCOT runs its short-term load forecasting routine to update its forecasted load). The forecasted information should be based on ERCOT's own forecast of aggregate zonal loads, irrespective of QSE schedules. This is information in addition to the â??Short Term Load Forecastâ??, by zone.
• Forecasted Net Zonal Energy â?? This information will be available via XML query for each 15-minute interval of the upcoming Operating Period, one hour prior to the start of each Operating Period (or on whatever timeline ERCOT runs its short-term load forecasting routine to update its forecasted load). The information should be based on ERCOTâ??s Forecasted Zonal Aggregate Load and ERCOTâ??s trend of actual aggregate zonal generation. The Working Group is also requesting that ERCOT make available the methodology, including distribution factors, used in converting from Load Areas to Zones.
• Actual Zonal Generation - This information will be available via XML query in real-time on the same timeline as other information regarding frequency control that is already being provided by ERCOT (i.e., every few seconds). This information will be based on SCADA data.
• Zonally Aggregated BES Bid Curves â?? For those 15-minute settlement intervals in which ERCOT is managing CSC congestion (i.e., intervals in which there is at least one non-zero CSC shadow price due to CSC congestion management), ERCOT will make available, via XML query within 15 days after the operating day, zonal aggregates of up balancing energy service (UBES) bid prices and quantities for each settlement interval and zonal aggregates of down balancing energy service (DBES) bid prices and quantities for each settlement interval.

• Aggregate Zonal Unit-Specific Incremental (up) Deployments by Category, including zonal aggregate OOM deployments. This information will be available in real-time via portal posting and XML query, every 15 minutes, for the relevant future interval (currently the interval ending 35 minutes later), whether or not there is, or forecasted to be, zonal or local congestion.
• Aggregate Zonal Unit-Specific Decremental (down) Deployments by Category, including zonal aggregate OOM deployments. This information will be provided in real-time via portal posting and XML query, every 15 minutes, for the relevant future interval (currently the interval ending 35 minutes later), whether or not there is, or forecasted to be, zonal or local congestion.

Add hardware, software, and required license to enable Transmission Operators to access the ERCOT network analysis software remotely through the ERCOT WAN. Implement secure access to the network applications that will insure that only authorized Transmission Operators will have access.

Modify the existing Affiliate REP (AREP) process to meet the needs of the â??LEFT-IN-HOTâ?? process.

1. TDSP submits a CSV file to ERCOT.
2. ERCOT performs validation against data in Siebel/Lodestar
3. Rejections are returned to the TDSP with specific error remarks
4. Valid submissions change the ESI ID to active with the Affiliate REP

With each Settlement Statement, ERCOT must provide information regarding the Load estimation required because of missing metered volumes. Information for ERCOT-wide estimation, represented REPs estimation, and their specific QSEs estimation.

Modify Mismatch Notification XML message and â??Query for Schedule Mismatch Messagesâ?? to include three additional fields:

• Resource / Obligation (flag to represent type)
• Zone
• MW

Service History Extract
Within a REPs ESI ID Service History Extract, ERCOT would provide information regarding all the ESI IDs assigned to that REP, their service history with the current REP, their Load Profile and other characteristics necessary for the REP to be able to estimate load for settlement. This extract would also allow the TDSPs to validate the EDI documentation previously sent to ERCOT. The following is an example of the data elements that are required:

ESI-ID INFORMATION (IDR & Non-IDR customers)
CUSTOMER_ID
ELECTRIC_SERVICE_IDENTIFIER
START_TIME
STOP_TIME
TRANSACTION_DATE

ESIID_SERVICE_HISTORY (IDR & Non-IDR customers)

CUSTOMER__ID	DISPATCHFL
SERVICECODE	METER_READER_CODE
START_TIME	T_AND_D_PROVIDER_CODE
STOP_TIME	REGIONCODE
RETAIL_PROVIDER_CODE	DISPATCHASSETCODE
STATION_CODE	STATUS
PROFILE_CLASS_CODE	ZIP
LOSS_CODE	POWER_GENERATOR_CODE
TRANSACTION_DATE	DISPATCH_TYPE

Usage Extracts
ERCOT will make available ESI ID Usage Extracts to provide REPs and TDSPs information to validate the actual usage ERCOT has received from TDSPs and uses for settlement. Within an Initial ESI-ID Usage Extract for a REP, ERCOT must provide all usage information loaded into ERCOTâ??s Settlement system for ESI IDs assigned to the REP from the date of the request through the earliest Trade Date requiring True-Up Settlement. A daily REP ESI ID Usage Extract would provide the usage information received by ERCOT and loaded into its Settlement system for a day. This extract would be used by the REP or TDSP to append to the REP Initial Usage Extract in order to compile a complete record of usage data existing in ERCOTâ??s Settlement system. The following is an example of the data elements that are required:

ESIID_USAGE (Non-IDR Meter Information)

CUSTOMER_ID	TOTAL
START_TIME	ON_PEAK
STOP_TIME	OFF_PEAK
BILLING_MONTH	MDPK
METER_READ_STATUS	SPK
USAGE_DAILY_AVERAGE	GLOBPROCID
TRANSACTION_DATE	TIMESTAMP
METER_TYPE

IDR_USAGE_HEADER (IDR Meter Information)

INTERVAL_DATA_ID	DSTPARTICIPANT
CUSTOMER_ID	ORIGIN (Indicates Meter or Profiled)
RECORDER	ACCEPTREJECTSTATUS
MARKET_INTERVAL	DESCRIPTOR
START_TIME	TIMESTAMP
STOP_TIME	COUNT
SECONDS_PER_INTERVAL	TRANSACTION_DATE
MEASUREMENT_UNITS_CODE

IDR_USAGE_DATA (IDR Meter Information)
INTERVAL_DATA_ID
TRANSACTION_DATE
TRADE_DATE
15 MINUTE INTERVAL READ VALUE
(Meter Read value would show estimated and actual values)

Display ERCOT Total Aggregated Balancing Energy Deployment, Total Aggregated Responsive Deployment, Total Aggregated Non-Spin Deployment, ERCOT SCE and ERCOT Responsive Reserve on the ERCOT Real-Time public web.

New screen should be made available on the ERCOT Portal, which indicates current and projected unit generation information. This should include Economic generation, as well as Out Of Merit (OOM) and any other non-economic generation, scheduled for the current and next dayâ??s operations. In addition, this information should also be made available in ASCII format for downloading into transmission application study programs.

The Market Operations Test Environment will enable interface and business testing for the market. This system change will allow both ERCOT and Market Participants to run simulations concurrently.

Automate the process for adjusting the Market Clearing Price of Energy as directed in Section 6.9.5.1, Balancing Energy Clearing Price, item (2) and subject the adjusted clearing price to the same requirements as any unadjusted clearing price (i.e. post the adjusted price pursuant to Section 4.6, Operating Period Process, item (5) and Section 6.7.1.1, Creation of the Balancing Energy Bid Stack, item (5))

FasTrak is the retail transaction issue resolution tool. However, the system currently in place does not include the capability to track issues by variables such as ESI ID or TDSP, and does not allow determination of issue aging. In addition, the tool cannot be queried and interfacing with the tool is somewhat cumbersome. The FasTrak tool needs to be made more user friendly and enhanced with features that will allow issues to be better tracked and manipulated by Market Participants for purposes of better managing the retail transaction issue resolution process.

1. Modify ERCOTâ??s Settlements and Billing Extract to keep the integrity of a QSEâ??s Real Time operational data such as deployments to the QSE from ERCOT.
2. Include bill determinants that are used in calculating offline adjustments.

Allow CRâ??s the ability to request an extract of CSA information for their DUNS. Output the following fields:

• ESI ID
• CR DUNS Number
• TDSP DUNS Number
• Relationship Type (CSA)
• Status
• Service Begin Date
• Service End Date
• Created
• Last Updated
• Comments

Incorporate the following attributes:

• Ability to request on-demand from the Portal
• Limit output to the DUNS of the requestor (as defined by their digital certificate)
• Post output file in CSV format to market participant folder in Report Explorer

Require requestor to input the following parameters:

• Start and Stop dates
• â??Activeâ??, â??Inactiveâ?? or all Status values

The ERCOT market clearing engine, which performs Resource Plan Validation and the Hour-Ahead Study, and clears the Real Time Balancing Energy Market, should be modified to allocate Responsive Reserve Service according to the ERCOT Operating Guides to hydro units operating in synchronous condenser mode.

Append a data Flag of â??Pâ?? to the Transaction Type number to indicate when a displayed transaction was generated and transmitted through the Texas Market Link portal by Market Participants, rather than being generated by Market Participantâ??s system and transmitted in the Market via GISB.

Create a calendar month, summary report to be presented at RMS that will provide Market Participants with estimated meter reading information broken-down by TDSP territory and indicating customer class. This report will also indicate the degree to which meter reads occur consecutively across two or more months and the degree to which estimates may straddle Move-Ins and Move-In/Forced Outs.

This report will be run on the first day of each month and will include the following summary level detail:

• TDSP Duns
• Premise Type (Residential, Small Non-Residential)
• Load Profile
• Number of Consecutive Months â?? Interval of 3 or more and 6 or more months
• By Business Process Type (All MVIs and MVI/Forced Outs)
• Count Total per Business Process Type
• Summarized Total for All

Italicized items above are secondary requirements and could be removed if too costly.

FasTrak is the retail transaction issue resolution tool. However, the system currently in place does not include the capability to track issues by variables such as ESI ID or TDSP, and does not allow determination of issue aging. In addition, the tool cannot be queried and interfacing with the tool is somewhat cumbersome. The FasTrak tool needs to be made more user friendly and enhanced with features that will allow issues to be better tracked and manipulated by Market Participants for purposes of better managing the retail transaction issue resolution process.

Output the following fields:

• ESI ID
• CR DUNS Number
• TDSP DUNS Number
• Status Reason
• Service Period End Date

Incorporate the following attributes:

• Limit output to the DUNS of the losing CR (where the gaining CR is not the losing CR)
• Post output file in CSV format to market participant folder in Report Explorer

Suggested modifications include, but are not limited to:

• Providing usage to CRs for backdated LSE Relationship Changes
• Including a file name or number in order to identify the order in which SCR727 files should be loaded by the MP
• Auditing capabilities to allow MPs the function to confirm the accuracy of their extracts
• Ability to link a dB change back to the source of the change (i.e. FasTrak issue, batch processing)

The essence of the request is for ERCOT to set up a data repository that can receive balanced schedules for future operating days for which a market has not yet been opened. As ERCOT opens markets each day the relevant data from the repository would be pulled into ERCOT’s EMMS system.

Basic requirements:

• Allow submission of balanced schedules up to 7 days prior to operating day
• Clearing should remain limited to the next operating day (as we do currently), unless ERCOT needs to clear a two Day Ahead market for reliability reasons.
• The expectation is that this data is not validated until it is pulled from the repository into the EMMS system.

A list of functional requirements has been developed by the Texas Test Plan Team (TTPT) for tools that support the market in testing retail transactions in an automated fashion. These requirements have been broken into 3 functional groups.

• Transaction Validation
• File Transfer Protocol Requirements
• Transaction Samples

1. Dispute ID
2. Trade Date
3. Statement ID (Stmt ID 1 â?? 12)
4. Transaction Date & Time Stamp (Published Date of Extract)
5. QSE Name
6. QSE Contact Name
7. QSE Submission Date (Transaction Date, Time Stamp)
8. Dispute Status (Not Started, Open, Closed, Withdrawn, Rejected)
9. Dispute Status Assignment Date
10. Dispute Resolution (Granted, Granted w/ Exceptions, Denied)
11. Dispute Resolution Assignment Date
12. Dispute Type
13. Dispute Sub Type
14. Dispute Charge Type
15. Start Interval
16. End Interval
17. Dispute Amount
18. Resolution Amount
19. Short Description
20. Long Description
21. Attachment Submitted (Y/N)
22. ERCOT Resolution Comment

Add view only access functionality to authority options for the User Security Administrator (USA)

In an effort to promote system reliability for the Retail Market by significantly reducing ERCOT System Outages, a technical resolution is needed. To ensure the technical recommendations in this SCR sufficiently accomplish the intention, ERCOT IT should produced a full evaluation of ERCOT systems, and a full evaluation of internal processes associated with those systems such that Retail Market Participants will be able to select the best cost-based solution able to reduce and/or eliminate ERCOT system outages.

Provide transmission element dynamic rating data used by ERCOT to the TSP of the facility through the ICCP link.

Eliminate violation on Commercially Significant Constraints (CSCs) as a trigger for Price Administration in the Real Time Balancing Market Clearing Engine (also known as Scheduling, Pricing and Dispatching (SPD)). Instead of triggering Price Administration when a CSC is violated, SPD should allow the Shadow Price to be equal to the Penalty Factor for OC1 congestion, currently $2,500.

The MarkeTrak tool is a web based database application used to track, manage, and store data utilized by ERCOT and the Market Participants (MPs). This tool is the supported method to track ERCOT Retail market issue management and data discrepancies in the market. 

To add functionality on the MarkeTrak Issue Resolution Tool for:

o       Increased usability

o       Improved workflow of MarkeTrak Issues

o       Increased reporting functionality

In accordance with Protocol Section 4.4.15, QSE Resource Plans, ERCOT shall produce renewable production potential forecasts for Wind-powered Generation Resources (WGRs) to be used as the planned operating level in the Resource Plan during Replacement Reserve Service (RPRS) procurements.

Upon approval of PRR763, Use of WGRPP as Planned Operating Level in Day-Ahead Resource Plan for WGRs, ERCOT implemented the WGR Production Potential (WGRPP) forecast without delay by having the WGRPP forecasting service email forecasts directly to each WGR Qualified Scheduling Entity (QSE).  The email process proved to cause unacceptable delivery delays and errors for QSEs.

This System Change Request (SCR) proposes to provide a secure and programmatic means to supply the WGR QSEs with their forecasts by:

o       Provide WGR QSEs their forecasts through the zonal Extensible Markup Language (XML) Market User Interface (MUI).

o       A WGR QSE can obtain its current forecasts by submitting a query through the zonal XML MUI. 

o       This will be through a query as specified in the "ERCOT Participant Interface:  XML" document.

o       Past forecasts will not be available after each hour.

o       ERCOT may restrict the frequency of these queries to protect system availability.

The MarkeTrak tool is a web based database application used to track and manage issues identified by Market Participants and ERCOT.  This tool is the supported method to resolve retail transaction problems and data discrepancies.

This System Change Request (SCR) will add functionality to the MarkeTrak Issue Resolution Tool to:

• Improve and standardize Market Participant administration functions;
• Implement ERCOT validations requested by the MarkeTrak Task Force (MTTF); and
• Redesign the workflows to leverage potential vendor upgrades to the MarkeTrak application.

This System Change Request (SCR) requires ERCOT to:

• Provide Application Programmatic Interface (API) notification of all republished corrected prices; and
• Always publish all price corrections in Extensible Markup Language (XML) format using the same XML Schema Definition (XSD) that it is using for the regular price publication.

This System Change Request (SCR) proposes system changes to allow public access to a graphical view of non-confidential system conditions and pricing information for the following MIS Dashboards:

• Load Forecast vs. Actual
• LMP Contour Map
• SCED Up/Down

This SCR proposes the development of a new wind aggregated dashboard available to the public that displays the following on both the system-wide and regional level in graphical form:  

• Aggregate Wind-powered Generation Resource (WGR) Power Output
• Aggregate Short-term Wind Power Forecast (STWPF), from both the current and Day-Ahead
• Aggregate Wind-powered Generation Resource Production Potential (WGRPP), from both the current and Day-Ahead
•  Aggregate Current Operating Plan (COP) High Sustained Limits (HSLs) for On-line WGRs, from both the current and Day-Ahead

System-wide and regional WGR output data would also be displayed on the dashboard.  These values will update with each Security-Constrained Economic Dispatch (SCED) run and represent a current snapshot of the aggregate WGR output.

This System Change Request (SCR) allows the price data to be transferred to the Energy Management System (EMS) for distribution over Inter-Control Center Communications Protocol (ICCP) links, as soon as the five-minute Load Zone and Hub prices are calculated in Real-Time.

This System Change Request (SCR) will provide the capability to a read only role in addition to the read and write role for Congestion Revenue Right (CRR) Account Holders.  Currently Digital Certificates for CRR Account Holders provides read and write capabilities to the certificate holder.  Austin Energy (AE) request that ERCOT create a read only role in addition to the read and write role.