ERCOT POPULATING SMT PORTAL WITH LOADED & ESTIMATED DATA VIA FILE TRANSFER

DISCLAIMER

The concepts included in this documentare not to be considered requirements. They were prepared to communicate to the market the general understanding ERCOT has with regards to ERCOT populating the SMT portal in lieu of the TDSPs. ERCOT has not fully vetted these concepts internally nor have we consulted with SMT staff.

ASSUMPTIONS

  1. Beginning on Day X, ERCOT will begin delivering LSE files to SMT via NAESB.
  1. Beginning on Day X, SMT will only accept LSE files from ERCOT.
  1. Submission of files to SMT will occur after each hourly loading process completes provided that data was loaded in that hour with the exception being the timeframe when wholesale batch is running (4 pm - ≈10 pm).
  1. The LSE file format specification as listed on ERCOT.com will be used(with the possible exception being indicators for ERCOT created data.) *may need to update that documentation currently on ERCOT.com
  1. ERCOT will deliver each file to SMT drop off point only. Any further dissemination of the files will be performed by SMT.
  1. Files will follow the 50K transaction count maximum per file and be sorted by ROR DUNS#
  1. File will be acknowledged by SMT via NAESB.
  1. Files from ERCOT to SMT could be delivered out of synch. There will be a unique way of identifying the file order. SMT is responsible for processing files in order.
  1. For each data loading process, ERCOT will create a summary file that includes a file count and a count of transactions per file and deliver to SMT. SMT should use the summary data to support real time monitoring.
  1. ERCOT would only deliver those AMS transactions that loaded into ERCOT systems. Any further validations performed once SMT receives the data could cause SMT and ERCOT to be out-of-synch. If any transactions are rejected by SMT, there would need to be a process created by which those transactions would be researched and corrected.
  1. Estimates produced by ERCOT (OD+4,OD+53,OD+177,Resettlement) will be delivered to SMT after Data Aggregation routines have completed (≈10 pm each night) and this file should be acknowledged by SMT prior to ERCOT resuming the data loading process of files received from the TDSPs.
  1. ERCOT estimation process is not the same as the TDSPs estimation process.
  2. Estimated data produced by ERCOT would have to be marked differently to indicate the transactions were created by ERCOT’s estimation process and SMT would need to be able to consume the estimation data.
  3. TDSP data origins: Header ‘M’, Interval ‘A’ or ‘E’
  4. ERCOT data origins: Header ‘C’, Interval ‘C’ - ???
  5. Any current SLA for delivery of AMS data to SMT will need to be revisited/revised given ERCOT’s new role and considerations for its processing timelines.
  1. Any delays in Wholesale batch completion would impact delivery time of ERCOT’s AMS data to SMT. (potential impacts to any SLA’s if established.)
  1. ERCOT planned maintenance outages which include NAESB would prevent ERCOT from delivering AMS data to SMT for the duration of the outage. At the point of re-opening to the market, there would need to be a mechanism in place to properly process the outbound AMS files.
  1. A dedicated primary and backup NAESB system is not required for this implementation.
  1. Creation and submission of the ISync and FSync files would remain the responsibility of the TDSPs.
  1. ERCOT would not be responsible for addressing questions from a customer, third party, or REP of Record regarding data provisioned through SMT.

UNKNOWN IMPACTS

  1. Impact to processing speeds of data loading if another process was tied to the AMSInterval table. (I.e. building of files to pass to SMT).
  1. Impact to processing speeds of data loading due to keeping 30 days’ worth of data in the AMSIntervalStage table instead of purging the table at the end of a loading run.
  1. Impact of SMT processing ISync and FSyncfiles (i.e. ESIID adds, deletes) now that the interval data is coming from ERCOT instead of the TDSPs.