MPUD v6 5 (Clean)

EirGrid & SONI SEM Establishment Programme – MPUD v6.5.
doc
SEM Establishment Programme
Title Market Participant Update Document

Version 6.5
Date 17th April 2009
Document History
Version Date Author Comment
0.6 23/11/2006 SEM Implementation Team Initial Draft for Participant Representative
Consultation
1.0 5/12/2006 SEM Implementation Team First release of the document
2.0 29/03/2007 SEM Implementation Team Updates after Factory Test, mostly schema
changes. Include Report Definition Document
v1.0 and latest updates to report details.
Settlement Reports – updated segment details
that were TBD in Report Defn. Doc. SMO
Website (SMOW) references removed from
this document
3.0 27/04/2007 SEM Implementation Team Updates to include corrections on reports and
further information on Reports and functional
topics. Aligning explanatory text to that of
the Agreed Procedures where appropriate.
Incorporating responses to participants
queries. Carrying out formatting corrections
4.0 10/08/2007 SEM Implementation Team Updates to include changes on reports and
further information on related functional
topics.
4.1 30/08/2007 SEM Implementation Team Updates to include clarification following
Market Participants queries (MPI &
Settlements) and changes on reports
following the release note (SEM_R1.1.0)
4.2 07/09/2007 SEM Implementation Team Update following the Pre-Go-live Release
Structure and Options with the Regulator
Authorities and Market Participants held on
4th September 2007
4.3 13/09/2007 SEM Implementation Team Updates relating to fields in the Settlement
Reports – Variable Type Reference table for
NDLFESU, VMOP and FMOP, MO ND and
MO NDLFESU variable types and an update
to the Daily Initial Ex-Post Market Schedule
Summary report.
Added MARKET – MISCELLANEOUS and
© EirGrid & SONI 2009. Commercial in Confidence. Page 1
PDF created with pdfFactory Pro trial version www.pdffactory.com

EirGrid & SONI SEM Establishment Programme – MPUD v6.5.doc

MARKET – METERING report query
combinations.
4.4 27/09/2007 SEM Implementation Team Corrected the Daily Dispatch Instructions
report field 26.6
‘INSTRUCTION_COMBINATION_CODE’
Addition a new informative table to define the
combination of Report Type and Report Sub-
type per report listed in this document.
Addition of the True_up_based_on field to
the Job records of the Invoice
5.0 19/10/2007 SEM Implementation Team Update in advance of the MI system release
due for mid-December 2007
Also deletion of Appendix A following MP
query
5.1 15/11/2007 SEM Implementation Team Addition of the General Public Settlement
Publications section
5.2 26/11/2007 SEM Implementation Team Addition of the Type 3 process for the
General Public Settlement Capacity
Publications
5.3 03/12/2007 SEM Implementation Team Update of the Monthly Standard report from
.zip to .xml following decision made on
30/11/2007
5.4 01/02/2008 SEM Implementation Team Update following the Release Note
SEM_R1.3.0 sent to Market Participants on
31/01/2008


6.0 12/05/2008 SEM Implementation Team Day 1+ Project Updates:
- Change to the latest version of the Code
(4.2).
- Footnote added to Table 11: Settlement
Reallocation Validations to reflect the
change of format against the Monetary
Value field.
- Update of section 5.3.1 to add the Code
Participant Name field to the Application
submission.
- Update of Table 29: Invoice – Element
Fields.
- Addition of section 6.2.4 Credit Cover
Report.
- Update of Table 42: Publication List –
Variables Reference and Table 43:
Settlement Publications – Variables
Reference.
- Update of Table 1: Report Type and
Report Sub-Type Combination.
- Addition of four new General Public
Reports in section 7.4.
6.1 13/06/2008 SEM Implementation Team Final Draft
6.2 12/08/2008 SEM Implementation Team Update following:
- Change Request for the introduction of
JESU_D15
- Typo corrections in the Settlement
Sections
6.3 17/10/2008 SEM Implementation Team Details of the Credit Cover Report included
in Section 6.2 Member Private Settlement
Reports.
Removal of MG / MGIU / MGEU from
Table 44 Settlement Publications – Variables
Reference as not applicable for CA Market.


6.4 16/12/2008 SEM Implementation Team 1. Code Participant Format
Changed all references of the Code

Participant data format from CPT_nnnn to
CP_nnnn which will align with the format
that will apply for Day 1+.
This affected the following sections:
• Table 27 – Credit Cover Report –
Header Records
Summary Records
Detail Records for Generator Unit
and Supplier Unit
2. Change to reflect change request

increasing ASU Trading Site limit from
20 to 100. (page 84)
6.5 17/04/2009 SEMO Section 7.4:

1. Item 4.6: This element name changed to
LOAD_FORECAST (as opposed to
FORECAST_MW).
2. Item 4.6: Updated element description.
6. Item 89: Gate time changed to 16:30 (as
opposed to 09:30).

Table of Contents
Disclaimer and Content Information........................................................................................................... 11
Disclaimer and Content Information........................................................................................................... 11
1. Introduction .......................................................................................................................................... 12
2. Interfaces Architecture Overview........................................................................................................ 13
2.1. Physical Overview .......................................................................................................................... 13

2.2. Logical Overview............................................................................................................................ 14
2.3. Type 2 vs. Type 3 Communication Channels ................................................................................... 15
2.4. Security .......................................................................................................................................... 16
2.4.1. Users .......................................................................................................................................... 16
2.4.2. Functional Areas and Access Levels ........................................................................................... 16
2.4.2.1. Sample Scenarios .................................................................................................................... 17
2.4.3. User Types.................................................................................................................................. 17
2.4.4. Digital Certificates ..................................................................................................................... 18
2.4.5. Miscellaneous ............................................................................................................................. 18
3. Messaging Overview (Type 3 Interfaces only)..................................................................................... 19
3.1. Prerequisites................................................................................................................................... 19
3.2. Data Format ................................................................................................................................... 19
3.3. Web Service build........................................................................................................................... 21
3.4. Data Validation .............................................................................................................................. 21
3.5. Transaction Identification............................................................................................................... 22
3.5.1. SEM Transaction ID ................................................................................................................... 22
3.5.2. External ID................................................................................................................................. 22
3.6. Protocol for Interfacing .................................................................................................................. 22
3.7. Interfacing overview....................................................................................................................... 24
3.8. Non-Repudiation ............................................................................................................................ 25
3.8.1. Client Side .................................................................................................................................. 25
3.8.2. Contesting................................................................................................................................... 26
3.9. Other .............................................................................................................................................. 26
3.10. Transaction Types....................................................................................................................... 27
4. Market Interface .................................................................................................................................. 28
4.1. Description..................................................................................................................................... 28
4.2. Type-Specific Data Entry Procedure............................................................................................... 28
4.2.1. Default Data ............................................................................................................................... 29

4.2.2. Settlement Reallocation .............................................................................................................. 32

4.3. Message Validation and Sample XML............................................................................................. 32
4.3.1. Common Element (applies to all Market Interface submit/query Transactions) ........................... 32
4.3.2. Description of Hours and Intervals Elements .............................................................................. 33
4.3.3. Settlement Reallocation .............................................................................................................. 33
4.3.4. Single Request in Transaction – XML samples ............................................................................ 33
4.3.5. Generator Offers......................................................................................................................... 33
4.3.6. Multiple Requests in Transaction – XML sample......................................................................... 33
4.3.7. Load Bid Submission................................................................................................................... 33
4.3.8. Interconnector Offer Submission................................................................................................. 33
5. Registration .......................................................................................................................................... 33
5.1. Description..................................................................................................................................... 33
5.2.1. Automated Processing................................................................................................................. 33
5.2.2. Manual Processing ..................................................................................................................... 33
5.3. Messages and Validation ................................................................................................................ 33
5.3.1. Application Element Data: Submission ....................................................................................... 33
5.3.2. Contact Element Data: Submission ............................................................................................. 33
5.3.3. User Element Data: Submission.................................................................................................. 33
5.3.4. Bank Element Data: Submission ................................................................................................. 33
5.3.5. Generator Parameters Element Data: Submission....................................................................... 33
5.3.6. Load Parameters Element Data: Submission............................................................................... 33
5.3.7. Netting Generator Parameters Element Data: Submission .......................................................... 33
5.3.8. Facility Transfer Parameters Element Data: Submission ............................................................ 33
5.3.9. Important additional submission requirements ............................................................................ 33
5.3.10. Registration Query.................................................................................................................. 33
6. Settlement Reports ............................................................................................................................... 33
6.1. Common Data Entry Procedure - Settlement Directory Listing ....................................................... 33

6.2. Member Private Settlement Reports................................................................................................ 33
6.2.1. Description ................................................................................................................................. 33
6.2.2. Type-Specific Data Entry Procedure ........................................................................................... 33
6.2.2.1. Statement ................................................................................................................................ 33
6.2.2.2. Participant Information Report (PIR)...................................................................................... 33
6.2.2.3. Credit Cover Report................................................................................................................ 33
6.2.2.4. Reallocation Agreement Report............................................................................................... 33
6.2.2.5. Invoice .................................................................................................................................... 33
6.2.2.6. Reference Tables used by Settlement Reports .......................................................................... 33

6.2.3. Settlement Report (successful and unsuccessful) Request samples ............................................... 33

6.2.3.1. Case 1: Directory Listing ........................................................................................................ 33
6.2.3.2. Case 2a: Specific File ............................................................................................................. 33
6.2.3.3. Case 2b: Specific File – File Not Found.................................................................................. 33
6.2.3.4. Case 3a: Invoice Request ........................................................................................................ 33
6.2.3.5. Case 3b: Invoice Request – File Not Found............................................................................. 33
6.2.3.6. Case 4a: Report Request ......................................................................................................... 33
6.2.3.7. Case 4b: Report Request – File Not Found ............................................................................. 33
6.2.3.8. Case 5a: Statement Request .................................................................................................... 33
6.2.3.9. Case 5b: Statement Request – File Not Found......................................................................... 33
6.3. General Public Settlement Publications.......................................................................................... 33
6.3.1. Description ................................................................................................................................. 33
6.3.2. Publication Timing ..................................................................................................................... 33
6.3.3. Settlement Publications vs. Variables.......................................................................................... 33
6.3.4. Reference Tables used by the Settlement Publications................................................................. 33
6.3.5. File layout .................................................................................................................................. 33
6.3.6. Type-Specific Data Entry Procedure ........................................................................................... 33
6.3.6.1. Energy Market Financial Publication ..................................................................................... 33
6.3.6.2. Energy Market Information Publication .................................................................................. 33
6.3.6.3. Meter Generation Information Publication.............................................................................. 33
6.3.6.4. Capacity Market Financial Publication................................................................................... 33
6.3.6.5. Capacity Market Information Publication ............................................................................... 33
7. Other Standard Reports....................................................................................................................... 33
7.1. Description..................................................................................................................................... 33
7.3. Message Validation and Sample XML............................................................................................. 33
7.3.1. Report and List Reports Requests................................................................................................ 33
7.3.2. Report Type / Report Sub-Type per Report.................................................................................. 33
7.3.3. Sample XML ............................................................................................................................... 33
7.3.4. Case 1a: List Reports.................................................................................................................. 33
7.3.5. Case 1b: List Reports – None Available ...................................................................................... 33
7.3.6. Case 2a: Report Request............................................................................................................. 33
7.3.7. Case 2b: Report Request – No File Available ............................................................................. 33
7.3.8. Guide to Market System Report Definitions................................................................................. 33
7.4. Report and Content Details ............................................................................................................ 33
7.5. Market Reports Translation ............................................................................................................ 33
7.5.1. XML Output Structure................................................................................................................. 33

Appendix A. Trading Hour/Interval Specification...................................................................................... 33

Table of Figures
Figure 1: Messaging Architecture – Physical Overview.................................................................................. 13
Figure 2: Messaging Architecture - Logical Overview.................................................................................... 14
Figure 3: Some Transactions may contain multiple Requests.......................................................................... 19
Figure 4: Digital Signature Generation Process .............................................................................................. 25
Figure 5: Data Transfer Process ..................................................................................................................... 26
Figure 6: Non-Repudiation Process ................................................................................................................ 26
Figure 7: Market Interface Data Processing Overview.................................................................................... 28
Figure 8: Registration Data Processing Overview........................................................................................... 33
Figure 9: Registration Data – Status Updates ................................................................................................. 33
Figure 10: Market Report Request Data Processing Overview ........................................................................ 33
Table of Tables
- Update of Table 1: Report Type and Report Sub-Type Combination. ........................................................ 3
Table 2: Functional Areas and Access Levels ................................................................................................. 16
Table 3: User Types to Functional Area/Access Level mappings .................................................................... 17
Table 4: Processing Statistics Data Fields....................................................................................................... 20
Table 5: Overview of Interface System ........................................................................................................... 24
Table 6: Market Interface – Market Windows ................................................................................................ 29
Table 7: Common Elements ........................................................................................................................... 33
Table 8: Sample of Hours and Intervals (applicable to Forecast)..................................................................... 33
Table 9: Validation rules applicable for Start / End Hour / Interval ......................................................... 33
Table 10: Validation rules for Hours and Interval applicable per message type............................................... 33
Table 11: Settlement Reallocation Elements................................................................................................... 33
Table 12: Settlement Reallocation Validations ............................................................................................... 33
Table 13: Generator Offer Elements............................................................................................................... 33
Table 14: Generator Offer Validations ........................................................................................................... 33
Table 15: Load Bid Elements ......................................................................................................................... 33
Table 16: Load Bid Offer Validations............................................................................................................. 33
Table 17: Interconnector Offer Elements........................................................................................................ 33
Table 18: Interconnector Offer Elements........................................................................................................ 33
Table 19: Statement – Header Record............................................................................................................. 33
Table 20: Statement – Summary Record......................................................................................................... 33
Table 21: Statement – Detail Records............................................................................................................. 33
Table 22: Statement – Trailer Record............................................................................................................. 33
Table 23: Participant Information Report – Header Record ............................................................................ 33
Table 24: Participant Information Report – Summary Record......................................................................... 33
Table 25: Participant Information Report – Detail Records............................................................................. 33
Table 26: Participant Information Report – Trailer Record............................................................................. 33
Table 27 - Credit Cover Report – Header Records .......................................................................................... 33
Table 28 - Credit Cover Report – Summary Records ...................................................................................... 33
Table 29 - Credit Cover Report – Detail Records for Generator Unit and Supplier Unit.................................. 33
Table 30 - Credit Cover Report – Detail Records for Market Participant ........................................................ 33
Table 31 - Credit Cover Report – Detail Records for Market .......................................................................... 33
Table 32: Reallocation Agreement Report – Header Record ........................................................................... 33
Table 33: Reallocation Agreement Report – Detail Records............................................................................ 33
Table 34: Reallocation Agreement Report – Trailer Record............................................................................ 33
Table 35: Invoice – Element Fields ................................................................................................................ 33
Table 36: Invoice – Body records ................................................................................................................... 33
Table 37: Invoice –Job records ....................................................................................................................... 33
Table 38: Settlement Reports – Market Segment Reference............................................................................ 33
Table 39: Settlement Reports – Product (Charge ID) Reference...................................................................... 33
Table 40: Settlement Reports – Variable Type Reference................................................................................ 33
Table 41: Settlement Reports – Variable Type Reference................................................................................ 33
Table 42: Publication Timing – File Type – Frequency .................................................................................. 33

Table 43: Publication List – Variables Reference............................................................................................ 33

Table 44: Settlement Publications – Variables Reference................................................................................ 33
Table 45: General Public Settlement Publications – Header Record................................................................ 33
Table 46: General Public Settlement Publications – Details Records............................................................... 33
Table 47: General Public Settlement Publications – Trailer Record ................................................................ 33
Table 48: Validation rules.............................................................................................................................. 33
Table 49: Report Type and Report Sub-Type Combination ............................................................................. 33
Table 50: Market Reports – Format Types...................................................................................................... 33
Table 51: Market Reports – Confidentiality Definitions.................................................................................. 33
Table 52: Example Market Report Definition – Market Prices Averages ........................................................ 33
Table 53: Market Report Definitions .............................................................................................................. 33
Table 54: Trading Hour/Interval – Standard Day ........................................................................................... 33
Table 55: Trading Hour/Interval – Long Day ................................................................................................. 33
Table 56: Trading Hour/Interval – Short Day................................................................................................. 33
Table of XML Samples

Sample XML 1: Settlement Reallocation “Submit” XML sample with no error – Submit ............................... 33
Sample XML 2: Settlement Reallocation “Submit” XML sample with no error – Response............................ 33
Sample XML 3: Settlement Reallocation “Submit” XML sample with error – Submit .................................... 33
Sample XML 4: Settlement Reallocation “Submit” XML sample with error – Response................................. 33
Sample XML 5: Settlement Reallocation “Query” XML sample with no error – Query .................................. 33
Sample XML 6: Settlement Reallocation “Query” XML sample with no error – Response ............................. 33
Sample XML 7: Settlement Reallocation “Query” XML sample with two errors – Query ............................... 33
Sample XML 8: Settlement Reallocation “Query” XML sample with two errors – Response .......................... 33
Sample XML 9: Multiple Bid/Offer “Submit” Requests in one Transaction – Submit..................................... 33
Sample XML 10: Multiple Bid/Offer “Submit” Requests in one Transaction – Response Part 1 ..................... 33
Sample XML 11: Multiple Bid/Offer “Submit” Requests in one Transaction – Response Part 2 ..................... 33
Sample XML 12: Settlements Directory Listing – Request ............................................................................. 33
Sample XML 13: Settlements Directory Listing – Response........................................................................... 33
Sample XML 14: Statement – Request ........................................................................................................... 33
Sample XML 15: Settlements report file request ............................................................................................ 33
Sample XML 16: DIRL – Request.................................................................................................................. 33
Sample XML 17: Directory Listing (DIRL) – Successful response.................................................................. 33
Sample XML 18: Directory Listing (DIRL) – Empty Directory ...................................................................... 33
Sample XML 19: Specific Settlement File (FILE) – Request .......................................................................... 33
Sample 20: Specific Settlement File (FILE) – Successful Response ................................................................ 33
Sample XML 21: Specific Settlement File (FILE) – Request .......................................................................... 33
Sample 22: Specific Settlement File (FILE) – File not found .......................................................................... 33
Sample XML 23: Invoice (INVC) – Request .................................................................................................. 33
Sample XML 24: Invoice (INVC) – Successful response ................................................................................ 33
Sample XML 25: Invoice (INVC) – Request .................................................................................................. 33
Sample 26: Invoice (INVC) – File not found .................................................................................................. 33
Sample XML 27: Report (RPT) – Request...................................................................................................... 33
Sample 28: Report (RPT) – Successful response............................................................................................. 33
Sample XML 29: Report (RPT) – Request...................................................................................................... 33
Sample 30: Report (RPT) – File not found ..................................................................................................... 33
Sample XML 31: Statement (STMT) – Request ............................................................................................. 33
Sample 32: Statement (STMT) – Successful response .................................................................................... 33
Sample XML 33: Statement (STMT) – Request ............................................................................................. 33
Sample 34: Statement (STMT) – File not found ............................................................................................. 33
Sample XML 35: Market Reports – Market Prices Averages ................................................................... 33

Disclaimer and Content Information

This document has been prepared to provide Market Participants with sufficient
information in order to develop their own systems to interface with the SEM.
The following disclaimers relate to the content of this document and any use by Market
Participants of the information provided therein.
1. The SEM Programme accepts no responsibility for decisions made or actions
taken by Market Participants as a result of the information presented in this
document or associated documents. Furthermore, the SEM does not indemnify
any commercial or organisational decisions made by Market Participants in
relation to the information herein.
2. This document represents the most up-to-date information on the SEM Central
Market Systems as they have been developed. With this in mind, it is not
appropriate simply to compare the document against an issued version of the
Trading and Settlement Code. Instead, it is a combination of Version 4.3 of the
Trading and Settlement Code and subsequently agreed Change Requests and
those to be considered by the Modifications Committee.
3. The information provided in this document is based entirely on documentation
and information provided by the software vendor. Although, the SEM
Programme has made all reasonable efforts to ensure that the information
presented is correct, it cannot guarantee the information provided.
4. The Trading and Settlement Code references presented in this document are
intended to guide Market Participants to relevant sections of the market rules. It
is not a one-to-one mapping, as this would be impossible due to the inherent
differences between market rules and the requirements of trading systems.
5. Further changes to the processes described or schema elements presented
may result as new information comes to light during future phases of the market
development. To mitigate the impact of such changes, the SEM will be issuing
planned updates to this document and associated documents (where
appropriate). Updates to this document will be consistent with the Agreed
Procedure 11.

1. Introduction
• The document is to assist Market Participants in building their systems to interface with the
SEM Central Market Systems.
• The focus of this document is on the Type 3 Communication Channel, i.e. submission and
retrieval of SEM Data Transactions via Web Services. In addition, some of the introductory
sections also refer to the Type 2 Communication Channel (i.e. data submission and retrieval
using the Market Participant Interface).

2. Interfaces Architecture Overview

2.1. Physical Overview
Internet
mktcert.allislandmarket.com
market.allislandmarket.com
External FW External FW
Market Participant
Production Production Market Participant
Certification Web
Web Interface Web Interface Qualification Web Interface
Interface
Internal FW Internal FW
Internal Systems Internal Systems Test Systems
BELFAST DUBLIN
Figure 1: Messaging Architecture – Physical Overview
• Figure 1 above presents the physical connections in place to the SEM Central Market Systems
• From the internet, the market web interfaces can be accessed via:
o https://market.allislandmarket.com/MIWebService/ws for WebService access or
o https://market.allislandmarket.com/mi_webapps/ for Internet access
§ An external service will continuously monitor both production web interfaces
and redirect traffic to the alternate site should there be a problem with one of
the web interfaces
§ Market Participants should not make any assumptions on which site they are
connecting to as it will vary according to the Market Operator’s operational
decisions
• The Market Participant Qualification Environment, for Communication Channel Qualification,
is similarly accessed via:
o https://mktcert.allislandmarket.com/MIWebService/ws for WebService access or
o https://mktcert.allislandmarket.com/mi_webapps/ for Internet access.
• 10 Mbps links will be in place at both Belfast and Dublin SEM sites.
• Security measures for the solutions, such as firewalls and anti-virus, are detailed in Agreed
Procedure 5 (Data Storage and IT Security) – section 3.

2.2. Logical Overview
Market
Web
Participant
Interface
Interface
Settlements
TYPE 2
Request Market
Web Service
Participant
(Participant)
Interface
Response
Web Service Request Meter Data

(Meter Data
Interface
Provider)
Response
TYPE 3
Figure 2: Messaging Architecture - Logical Overview
• Figure 2 above is an overview of both the Type 2 and Type 3 Communication Channels.
• All connections are initiated external to the SEM Central Market Systems – i.e. by Market
Participants, Meter Data Providers, etc. – and operate in a synchronous request-response mode.
• With Type 2, the Market Participant user connects to the Market Participant Interface and is
authorised by selecting the appropriate Digital Certificate. From here, they can select one of the
following options: Trading; Registration; Reports; File Exchange; or Settlements. In the case of
Settlements, this is actually handled by a different web server component.
• The technology behind the Market Participant Interface is Java based, while the Settlements and
Meter Data Interface are developed on Microsoft’s .NET platform.
• All data submitted to SEM is required to be in XML format.
• The majority of data published will be formatted in either XML or HTML (as selected by the
Market Participant).
• The exception to this is settlement reports, the list of reports for which is broken down as
follows:
o Settlement Statements – .csv
o Participant Information Report (PIR) – .csv
o Invoices – .xml
o Settlement Reallocation – .csv
o Energy Market Financial Publication (MFR) – .csv

o Energy Market Information Publication (MIR) – .csv

o Capacity Market Financial Publication (MFR) – .csv
o Capacity Market Information Publication (MIR) – .csv
o Metered Generation Information Publication (MGR) – .csv
o Credit Cover Report (CCR) - .csv
• The settlements reports above can be accessed via the Type 3 channel and Type 2. Where the
data is in CSV format, this must be requested using the SubmitAttachment method rather than
SubmitBody1.
2.3. Type 2 vs. Type 3 Communication Channels
• Type 3 Communications use web services to provide an automated, computer-to-computer

interface.
• The Type 2 Communication Channel is screen based, to provide a human-to-computer interface.
These requests, other than Settlement Reports, are processed by the same web service as is used
for the Type 3 Channel.
• In certain cases, the Type 2 Channel (screens) may have additional configuration to
appropriately present the information returned by the Web Service.
• Some additional information is available via the Type 2 Channel that is not available on Type 3:
o On accessing the Market Participant Interface from an internet browser session,
three separate windows/screens are presented.
§ The First is the functional screen which provides identical operations and
information to the Type 3 channel.
§ Another window presents a list of Market Submission Windows, which are
open, relative to Market Interface Transactions. This is only available on the
Type 2 Channel.
§ Lastly, a Market Messages window is displayed. This is used by the Market
Operator to provide information to Market Participant users and includes an
entry each time a report event occurs (i.e. report available). These messages
may be Market Public – visible by all Market Participants, or Participant
Private – only visible by a specific Market Participant’s users. This is only
available on the Type 2 Channel.
1
Details on SubmitBody and SubmitAttachment are available in the Market Participant Web Services Client
Toolkit

2.4. Security
2.4.1. Users
• Each Market Participant defines the access roles and rights of its Users.
• An initial limited set of users are created during the manual registration process.
• User maintenance is managed by the Market Operator on request for changes from Market
Participants.
• The Market Participant is responsible for designating the read and write privileges for its Users
to each of the Functional Areas of the Market Participant Interface.
• Each User is assigned a Digital Certificate which provides their credentials to the SEM Central
Market Systems (see Digital Certificates section of this document).
• A Market Participant may have multiple Users, but a single User is associated only with a
single Market Participant.
• The above does not preclude a person, e.g. working for a Data Processing Entity, to act as a
User for more than one Market Participant. However, the Data Processing Entity must have a
Digital Certificate for each relevant Market Participant.
• VeriSign Digital Certificates are to be used for interactions with the SEM Central Market
Systems. These certificates will be supplied by VeriSign to Market Participants, on behalf of
SEM/SMO. Agreed Procedure 3 contains further details on this process.
• The Username is determined from the Digital Certificate used to establish the SSL connection.
• The Username in the Digital Certificate has the format user_name@participant_name.
• This Username must match the user_name/participant_name in the request XML when using
mint_sem.xsd (Market Interface) or mi_file_exchange_sem.xsd (Non-Settlement Reports). The
fields in mpr-all.xsd for ActAsMarketParticipant are only for Market Operator use.
• In a Digital Certificate, the Certificate Name (CN) will have the user_name@participant_name
in each certificate issued by VeriSign, on behalf of SEM/SMO. The Digital Certificates are
x509 compliant.
• There is no Digital Signing of details returned by the Market Operator to Market Participants.
2.4.2. Functional Areas and Access Levels
The following table illustrates the functional areas to which access can be given, and the access
levels within that Functional Area if applicable:
Access Level
Functional Area Read-Only Read-Write
Trading - Yes
Registration Yes Yes
Settlements Yes -
Table 2: Functional Areas and Access Levels

2.4.2.1. Sample Scenarios
1. A user who only looks at invoices would need access to the Settlements functional area only,
which is always Read-Only access only.
2. A Full Access user, who can administer and view all details for a Market Participant, would
have: Read-Write access to Trading; Read-Write access to Registration (including the ability to
administer users; and Read-Only access to Settlements).
3. A User who needs to be restricted to Browse access could be given Read-Only access to both
Registration and Settlements, but not Trading as only Read-Write access is available.
2.4.3. User Types
Users are maintained via the Registration system, through which requests for changes are made.
There are then actioned by Market Operator personnel, in this case to set-up Users with the correct
privileges and initiate the Digital Certificate issuance process.
The Market Operator uses the User Type and Comment fields when creating a User via the MPI, or
the "user_type" and "comments" elements of the “User” type if using web services, to determine the
correct access levels for each User.
The User Types available are:

• Main Organisation User – this is the first user set-up for the Market Participant and has Full
Access User status.
• Full Access User – This user had access to all functional areas.
• Trading User – This user only has access to the Trading system (at a Read-Write level).
• Invoicing User – Access to the Settlements area (at a Read-Only level).
• Settlement Statements User – Access to both the Settlements area (at a Read-Only level) and
the Trading system (at a Read-Write level).
• Registration User – This user has Read-Write access to the Registration area.
• Other User Type – This is used in conjunction with the Comments field for any other functional
area/access level combination.
Functional Area
User Type Registration Trading Settlements
Full Access Read-Write Read-Write Read-Only
Registration Read-Write - -
Trading - Read-Write -
Invoicing - - Read-Only
Settlement Statements - Read-Write Read-Only
Other Any combination, based on the Comment element
Table 3: User Types to Functional Area/Access Level mappings

For the sample scenarios above, the user types specified would be:
1. A user who only looks at invoices would need assess to the Settlements functional area only,
which is Read-Only by default – Invoicing User.
2. A Full Access user, who can administer and view all details for a Market Participant, would
have: Read-Write access to Trading; Read-Write access to Registration (including the ability to
administer users; and Read-Only access to Settlements – Full Access User.
3. A User who needs to be restricted to Browse access could be given Read-Only access to both
Registration and Settlements, but not Trading as only Read-Write access is available – Other
User Type, with comments detailing the exact access to be granted.
2.4.4. Digital Certificates
• Each User identifies themselves to the SEM Central Market Systems using a Digital
Certificate.
• This includes screen-based Users accessing the Market Participant Interface and automated
Users via Web Services.
• The Digital Certificate is obtained as per the procedure in Agreed Procedure 3:
Communication Channel Qualification.
• Users are associated uniquely with a single Market Participant. Each User with access to a
particular Functional Area will be able to view or enter information for the entire Functional
Area. For example, a User with access to the Trading Functional Area will be able to trade for
all Units registered to the Market Participant.
• The above does not preclude a person, e.g. working for a Data Processing Entity, acting as a
User for two Market Participants but that person must have a Digital Certificate for each
User/Market Participant.
2.4.5. Miscellaneous
• If a User has Read-Only access to a system, they may be able to edit data on a Market
Participant Interface web page, but will not be able to submit as the SUBMIT button will be
disabled.

3. Messaging Overview (Type 3 Interfaces only)
• The information in this section provide an overview of interfacing using the Type 3 Channel.
• The detail behind this is extracted from the Market Participant Interfaces User Guide and the
Market Participant Web Services Client Toolkit.
• Details in further sections – on data formats and validation – are based on the relevant XML
Schema (mint_sem and mpr_all schema).
3.1. Prerequisites
• The prerequisites for, and standards used in, accessing the system are in the Market Participant
User Interface Guide2.
3.2. Data Format
• Data can only be submitted in XML format and the entire XML data stream will be considered
as one Transaction.
• A Transaction may contain a number of processing Requests – details on which Transactions
support multiple requests are specified on a Transaction Type or specific Transaction level
later in this document.
Transaction
Request
Request
Request
Figure 3: Some Transactions may contain multiple Requests
The following rules are associated with the XML data streams:
• An XML data stream is a simple text file containing ASCII characters only. Each data field in
the data stream begins with a pre-defined XML begin tag and ends with a pre-defined XML
end tag. No hidden formatting information is allowed. The XML data streams submitted must
adhere to the corresponding MI (Market Interface), MPR (Registration), MI File Exchange
(Standard Reports), and Invoice (single report in Settlements) XML Schemas3.
• Blank lines are permitted in the data streams and are ignored by the XML parser. White space
in the number data field is also ignored.
2
Market Participant User Interface Guide (section 2)
3
These Schemas are supplied as part of the Market Participant User Interface Guide (Appendix A.3)

• Comment lines must begin with “”. Any text between these two tags
will be interpreted as a comment and will be ignored.
• All data information in a given data stream must be included in exactly the same order as listed
in the defined XML schema. Any additional information or omissions will be considered as an
error and the relevant Transaction will be rejected.
• For the Market Interface XML schemas, an optional field can have a value of null. If a value
has been entered, it will take precedence over the default value.
• All mandatory fields must have values entered.
Each Transaction submitted receives a Response, which consists of:
• Processing Statistics.
• Messages.
• Original Data Submitted by the Market Participant.
The following describes the processing statistics data fields:

Data Field Description
Valid The number of valid Requests
Invalid The number of invalid Requests
Received The number of received Requests
time_ms The time spent in processing the data in milliseconds.
time_stamp Received time (string format as below)
XML_time_stamp Received datetime in XML format
transaction_id Transaction ID is a unique 10-character code generated
during processing (see section 3.5.1)
Table 4: Processing Statistics Data Fields
Note: Further details on the XML, Schema, and Web Services are available in the Market
Participant User Interface Guide document.
The time_stamp field is not designed for automated consumption – the XML_time_stamp field is
recommended for this.
The time_stamp field is a string of the following form:
dow mon dd hh:mm:ss zzz yyyy
Where:
• dow is the day of the week (Sun, Mon, Tue, Wed, Thu, Fri, Sat);
• mon is the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec);
• dd is the day of the month (01 through 31), as two decimal digits;
• hh is the hour of the day (00 through 23), as two decimal digits;
• mm is the minute within the hour (00 through 59), as two decimal digits;
• ss is the second within the minute (00 through 59), as two decimal digits;

• zzz is the time zone (and may reflect daylight saving time). Standard time zone
abbreviations include those recognized by the method parse. If time zone information is not
available, then zzz is empty – that is, it consists of no characters at all;
• yyyy is the year, as four decimal digits.
3.3. Web Service build
Please review the detail in the Market Participant Web Service Client Toolkit. This gives details of
the SOAP Envelope, SubmitBody and SubmitAttachment methods, and explains the WSDL.
3.4. Data Validation
When Market Participants submit data Requests, the following processing is performed in the order
below:
• The submitted data is first validated to ensure it is valid XML and complies with the Schema.
• For Market Interface requests: Market Window validation is next performed. Submit data
Requests require the appropriate market window to be open. Query data Requests are only
valid for 7 days after a market window has been closed. See section 4.2 for Market Window
details.
• The security permission for the combination of Market Participant and Participant User is
checked – including some checks against Registration data, e.g. resource name is valid, the
Market Participant owns the resource.
• Validation related to submitted data is performed. There are two kinds of validation:
o Validation related to the submitted data that does not require any external data –
i.e. data external to the Transaction/Request – is performed. Examples of these
include checking that Price-Quantity Pairs are monotonically increasing; ending
hour and interval are greater than starting hour and interval; etc.
o Validating offers against parameter data – e.g. validating bids and offers against
Market Price Cap and Market Price Floor.
• Successfully validated and processed data is indicated to the Market Participant through
information messages, whereas the failure is indicated by error messages.
• If any validation fails, then all subsequent validations are also performed to the extent possible
so that all errors are reported to the Market Participant. However, there are some critical
validations like “market not open” or “invalid resource”, which will stop further validation.
• Validation Rules specific to individual Requests are detailed in the relevant sections of this
document. The Market Participant User Interface Guide has a generic list of these Return
Codes for both the Market Interface and Registration submissions.

3.5. Transaction Identification
3.5.1. SEM Transaction ID
• The SEM Central Market Systems will assign a Transaction ID, which is a unique 10-
character code which will be received in the Response message.
• There is one Transaction ID per XML stream, regardless of how many Requests form part of
that stream.
3.5.2. External ID
• Market Participants have the option of submitting an External ID as part of a Market Interface
or Registration submit Transaction. These (External IDs) are optional items at a Request level,
so a submit Transaction made up of five Requests could have External IDs provided for none,
or up to all five, of those Requests.
• The External ID is not used by SEM Central Market Systems in processing and is treated as a
pass-through field. The last External ID (if applicable) used to submit Market Interface and
Registration Data is also returned when a Query is run against that data.
• The External ID is returned as part of the Transaction response, at a Request level, and may be
used by Market Participants for their own tracking purposes.
3.6. Protocol for Interfacing
• All Transactions to SEM Central Market Systems are Synchronous and will typically take
under two seconds per Request. However, there are a number of factors that will affect the
total time taken:
o The number of Requests that are part of the Transaction;
o The volume of data to be downloaded (mostly in the case of reports);
o The Market Participant’s internet connection speed;
o The Market Participant’s Web Service implementation and choice of
SubmitAttachment or SubmitBody operation.
• Transactions received by the SEM Central Market Systems are generally processed on a first
come first served basis. However, to facilitate throughput, various levels of parallelism and
pooling are implemented which could result in certain scenarios under which this sequencing
cannot be guaranteed. Also, as a Transaction may be serviced by either of the Web Interface
systems, at either SEM IT site, sequencing may also be affected.
o The solution architecture for SEM is cognisant of the fact that there are multiple
users on multiple channels that may be submitting updates to the same data.
o As such, any specific requirement around sequencing which a Market Participant
identifies will need to have appropriate business and system processes
implemented by the Market Participant to match the implementation required by
them.

o For example, a Market Participant who chooses to only use the Type 3 Channel
from a single user with a single login could configure their application such that
each transaction is submitted in sequence and a subsequent transaction is not
submitted until a response has been received.
o Other implementations may need to recognise that not all submissions may need to
be sequenced, e.g. Market Interfaces vs. Registration, but that there may be
submission by multiple users on multiple channels.
• Users may initiate multiple sessions using the same Digital Certificate. (As per the Market
Participant Interfaces User Guide, the exception is for Settlement access on the Type 2 channel
but this is not relevant to Type 3, which is being covered here.) Sessions will be timed-out at
the Firewall after 15 minutes of inactivity.
• Specific details relating to specific Transaction Types are addressed in this document.
• There are some circumstances beyond the control of the SEM Central Market Systems,
whereby a user may not see or receive a response (e.g. PC froze before response seen). As per
the Trading and Settlement Code, these are treated as valid Data Transactions if they pass the
relevant validations applied by in the SEM Central Market Systems.
Recommendations
• SubmitAttachment is the recommended method for SOAP requests, as it offers full
compatibility with all Data Transactions and has better performance for large data streams.
• Transactions should be kept to under 1MB in size.
• If Market Participants are unsure whether a Data Transaction was successfully submitted, we
recommend they query their data and ensure that their transaction came through and was
successfully validated.
• The ResponseInfo.ResStatus in the SOAP body will indicate the success or failure of a request
at the wsdl level. Valid values are “SUCCESS” and “FAIL”.
• The ResStatus will be set to “FAIL” if any problems are encountered in validating digital
signatures and if any low level web service code exceptions are raised.
• Also, when requesting a standard Report or Settlement Report, the ResponseInfo.ResFileName
in the SOAP body will indicate the filename of the returned file. In the event of an error, the
ResponseInfo.ResFileName in the SOAP will be blank4. The error message will be written to
the specified response file – e.g. to output.html if that was the name given – but adhering to the
mi_file_exchange_sem.xsd and including embedded messages relating to the error.
4
"ResponseInfo.ResFileName" is a mandatory field, so blank here would mean
<ResFileName></ResFileName> or <ResFileName/>

3.7. Interfacing overview
System Request Channel* DigSig Request Response – Response – Invalid

Reqd. Valid
Market Interface Submit SFW Y mint_sem.xsd mint_sem.xsd

(incl. Processing Statistics and embedded messages)
Market Interface Query SFW - mint_sem.xsd mint_sem.xsd
Registration Submit SFW Y mpr-all.xsd mpr-all.xsd
Registration Query SFW - mpr-all.xsd mpr-all.xsd (incl. embedded messages)
Report – MI List Reports SW - mi_file_exchange_sem.xsd mi_file_exchange_sem.xsd (incl. embedded messages)
Report – MI Report SW - mi_file_exchange_sem.xsd Report mi_file_exchange_sem.xsd
(incl. embedded messages)
Report – Settlement List Reports SW - wsdl – DIRL File List (~xml) Empty List (xml)
Report – Settlement Report SW - wsdl – FILE File (.csv) Requested file not found – {0}
wsdl – RPT File (.csv) Invalid filename - {0}
wsdl – STMT File (.csv) XML request is not well-formed
wsdl – INVC InvoiceSet.xsd There was an error processing the request
Invalid request type, must be one of STMT,

INVC, RPT, DIRL or FILE
(Note: the error messages above could be
returned for any of the four requests)
Channels supported S = Screen, F = File Exchange, W = Web Services
Table 5: Overview of Interface System

3.8. Non-Repudiation
• Non repudiation of submitted data is handled through the use of Digital Signatures. The Digital
Signature can be used at a subsequent date to support Non-Repudiation of submitted data.
• The SEM Central Market Systems require Digital Signatures for data submitted by Market
Participants as follows:
o Market Interface data submit Transactions;
o Registration data submit Transactions;
o Meter Data submitted by Meter Data Providers (via the Meter Data Interface);
o Any Market Interface data submitted through the Type 2 channel will be Digitally
Signed by the application automatically.
Note 1: The ReqDigSig element in the SOAP message is optional as not all Transactions (such as
downloading reports) require Digital Signatures. However, the server-side code ensures that the
Digital Signatures are mandatory for any data submit Transactions. If a Market Participant does not
provide a Digital Signature for these Transactions, the following error message will be issued:
<error> Digital signature is mandatory and not provided for this transaction </error>.
Note 2: XML references for Digital Signatures are not included in the remainder of this document.
Please refer to the Market Participant Interfaces User Guide and the Market Participant Web
Services Client Toolkit for details.
3.8.1. Client Side
• A Market Interface Client (Browser for Type 2 or a Web Service client for Type 3) creates the
Digital Signature for the XML data being submitted to the Market Interface Web Service. The
Digital Signature is created as the RSA encrypted SHA1 digest of the canonicalised XML data.
The steps an Market Interface Web Service client needs to follow to create the Digital
Signature are:
1. Create a DOM representation of the XML data;

2. Create a canonicalised representation of the DOM data. The canonicalised representation
should follow the form described in http://www.w3.org/TR/2001/REC-xml-c14n-
20010315#WithComments;
3. Create the signature RSA encryption of the SHA1 digest of the canonicalised representation.
The signature is encrypted using the Market Participant’s private key;
4. Encode the binary signature into a base64-encoded string
5. Place the Signature string in the SOAP message “ReqDigSig” element;
6. Store the XML data as it may be needed later to support Non-Repudiation of the submitted
XML data.
Figure 4: Digital Signature Generation Process

Figure 5: Data Transfer Process
• In the above and below figures the yellow boxes represent the steps on the Market Participant
side and the salmon boxes represent the steps happening on the Market Operator side.
• The XML data along with the Digital Signature is then encrypted using the Market Operator
public key. This encrypted data is sent within an SSL tunnel to the Market Operator web
server.
Figure 6: Non-Repudiation Process
3.8.2. Contesting
The contesting party should send the “original” xml file to an agreed third party. Using a dedicated
off line application agreed third party would generate the SHA1 hash code for the file being
contested and compare it with the hash code obtained by using the Market Participant Public Key to
decrypt the Digital Signature which was stored against the original Transaction.
• In the case of multiple Requests in the same Transaction a single Digital Signature is created
relating to all data submitted.
3.9. Other
• Timestamp: Market Time will be maintained by the Market Operator and appropriate systems
and processes will be implemented to ensure a consistent Gate Closure etc. Timestamps
submitted by Market Participants will not affect decisions on Market Windows (see section
4.2).

3.10. Transaction Types
There are four Transaction types, which are detailed in the following sections:
• Market Interface;
• Registration;
• Settlement Reports;
• Other Standard Reports (including Ad-hoc reports).
Note: There can only be one Transaction type included in any Transaction.

4. Market Interface
4.1. Description
The Transactions covered in this area are:

• Settlement Reallocation;
• Trading Data:
o Generator Offer;
o Load Bid
o Interconnector Offer.
4.2. Type-Specific Data Entry Procedure
Market Interface XML Submission
- Processing Statistics
Market Participant
- Original Data Submitted

- Submission or - Queried Data (Query Only)
- Query - Error and/or Information Messages
1 2 4
XML Submission XML Response
Prepare XML Data [Local XSD validation]
3
Market Operator
Check Validation
Update SEM
and Rules
Systems
Adherance
- XML Format
- Market Window Open
- Security
- Content
- Quality
Figure 7: Market Interface Data Processing Overview
• Stage 1: Market Participants prepare the XML Data. (Details on how this needs to be
packaged, in terms of SOAP, WSDL, etc. are covered in the Market Participant Interfaces User
Guide and the Market Participant Web Services Client Toolkit);
• Stage 2: Data in this category can either be submitted (updated) or queried and will typically be
validated on the client (Market Participant) system to ensure compliance with the XML Schema
rules;

• Stage 3: The Transaction is received by the SEM Central Market Systems and validation
checks, including business rules, are applied – see section 4.3 for details of the validations and
sample XML;
• Stage 4: If the Stage 3 tests are passed then the SEM Central Market Systems are updated as
appropriate and an XML response is issued to the Market Participant. If the tests are
unsuccessful, a response is issued detailing the errors.
• There can be multiple Requests in a single Transaction. An example of this is provided in
section 4.3.5.
• The processing Market Windows during which Transactions can be submitted are outlined in
the table below:
Market Windows
Transactions Start End Time Comments
Time
Submit Trading 06:00 AM 10:00 AM The data submission window opens at 06:00 AM
Day5 Data on TD-29 on TD-1 28 days before Gate Closure (GC), and closes on
(GC-28) Trading Day (TD) - 1 at 10:00 AM
For the submission of Technical Offer Data,
there is currently an extra process as outlined by
Sections 7.48 through 7.53 of the Trading &
Settlement Code.
Query Data as 23:59 PM Data may be Queried according to the Submit
submitted available on TD+7 timeline, with this functionality being available
for an additional 7 days after the Trading Day
(TD)
Submit Settlement 06:00 AM 10:00 AM The Settlement Re-allocation data submission
Re-allocation on TD-29 on Invoice window opens as above and closes one day
(GC-28) Day - 1 before the issue of the invoice on which the
reallocation is to be included (Billing
Period/Capacity Period plus 4 working days)6
Submit Standing N/A N/A The submission of standing data window is
Data7 always open – albeit only to be used for Market
Submission Windows to be opened in the future
Table 6: Market Interface – Market Windows
4.2.1. Default Data
The following details outline how Default Data, as defined in the Trading and Settlement Code, is
supported in the SEM Central Market Systems through a combination of functionality called
Standing Data and Trading Day Data.
Standing Data and Trading Day Data apply to Trading Data.
Standing Data
o Standing Data can be created at any time.
5
Standing data is defined in section 4.2.1
6
From Agreed Procedure 10: Settlement Reallocation
7
Trading Day Data is defined in section 4.2.1

o It is automatically used to create Trading Day Data immediately after the opening
of the appropriate market submission window (28 days in advance of Gate
Closure).
o As part of Unit Registration, one set of data is manually submitted and is entered
by the Market Operator onto the system with a parameter of “ALL” (valid for all
days). There is no expiry for this, as Default Data (see below) is always required
for use by the Central Market Systems.
o After Communication Channel Qualification – i.e. once access to the system is
granted – Market Participants may update the Standing Data (type “ALL”).
o Market Participants may also submit Standing Data for specific day types (SUN,
MON, ..., SAT). These may optionally have an expiration date.
o If an expiration date is used, the data will be used daily and automatically not
applicable after the expiration date.
o If no expiration date is given, the data will be used indefinitely, or until the
participant supersedes the specific day type data.
o The effective date must be greater than the date for which the specific day type
Standing Data will be processed by Standing Data conversion module. At a
minimum, the Standing Data conversion start date is Current Day + 29, or 29 days
into the future (corresponds to 28 days for open Market Windows + 1 for the next
Window to open).
o At Market Submission Window opening, if for a given trade date there is Standing
Data for both specific day type and "ALL", the system will only use the specific
day type.
Trading Day Data

o As Standing Data will be converted to Trading Day Data at Market Submission
Window opening, submissions of Trading Day Data will always be an update.
o The use of Trading Day Data, pre-populated by Standing Data, ensures that there is
always valid (or Default) data available for a unit.
o This may be updated with revised Trading Day Data while the window is open.
o The latest Data available is used at Gate Closure.
o Trading Day Data submissions will be validated and processed upon receipt, and
the Market Participant will be informed of the results of validation and processing.
o The communication mechanism during data submission is synchronous, that is the
participant submits the data and waits for the response from the Web Server.
o Participants have the ability to revise Trading Day Data as many times as
necessary within the appropriate Market Submission Window (28 days).
o Once Market Participants have successfully completed Communication Channel
Qualification, and thus be granted access to the SEM Central Market Systems, they
will be able to modify both their Standing and Trading Day Data.

o There are some circumstances whereby it is possible that Data Conversion –

changing Standing Data to Trading Day Data at Market Submission Window
opening – could fail. In this case the Market Operator will contact the Market
Participant to add Trading Day Data and update Standing Data if appropriate.
Although there are 28 days before this data will be used, it is expected that the
situation should be resolved within 5 working days8.
8
There will be a Business Process to identify and resolve failed Data Conversion – Standing to Trading Day

4.2.2. Settlement Reallocation
• Only one Request allowed per Transaction.

• Cancellation is a Business Process.
4.3. Message Validation and Sample XML
In the sections below, the validation applicable to each message type and the messages received are
presented. Also included are some sample XML files of Submit and Query Requests and Responses.
• Once Market Participants have successfully completed Communication Channel Qualification,
they will then have the ability to access the Market Systems.
Note 1: The reference number below (e.g. CE-n for Common Elements) provides a link to the data
mapping details in Appendix A.
Note 2: In the Message column, variables to be included in the message are represented by {0}, {1},
{2}, etc.
Note 3: The last two columns indicate whether the field is relevant for a Submit or Query, and if
relevant whether the field is mandatory or optional.
4.3.1. Common Element (applies to all Market Interface submit/query

Transactions)
No Name Validation Message Submit / Query /
Mandatory Mandatory
or Optional or Optional
• Specific application
CE-1 APPLICATION_TYPE request type. Y/M Y/M
• Must be “DAM”.
• YYYY-MM-DD
• There are different
validation rules based on
CE-2 TRADING_DATE the message type, which Y/M Y/M
are detailed in each
individual message
section below.
• Indicates if the bid request
is for a normal or for a
standing bid.
• Must be TRUE or
FALSE
CE-3 STANDING_FLAG • There are different Y/M Y/M
validation rules based on
the message type, which
are detailed in each
individual message
section below.
• Must be STRING.
Invalid combination of
• Must be valid
participant_name {0} and
combination with
user_name {1} for trading_date
USER_NAME.
CE-4 PARTICIPANT_NAME {2}. Y/M Y/M
The user_name {0} for
• Must have system participant_name {1} does not
privileges to allow have system access privileges to
Market Trading. participate in Market Trading
for trading_date {2}.
CE-5 USER_NAME • Must be STRING Y/M Y/M

No Name Validation Message Submit / Query /

Mandatory Mandatory
Invalid combination of
• Must be valid
participant_name {0} and
combination with
user_name {1} for trading_date
PARTICIPANT_NAME.
{2}
The user_name {0} for
• Must have system participant_name {1} does not
privileges to allow have system access privileges to
Market Trading. participate in Market Trading
for trading_date {2}.
• The current version of the
CE-6 VERSION_NO template. Y/M Y/M
• Must be “1.0”.
CE-7 MODE • Must be NORMAL. Y/M Y/M
Table 7: Common Elements
4.3.2. Description of Hours and Intervals Elements
The SEM Central Market Systems are designed to be able to receive data on a Trading Period basis,
allowing Market Participants to enter data such as Nomination Profile. For each submission that
relates to a specific Trading Period, the Market Participant must specific an hour (START_HR and
END_HR) and interval (START_INT and END_INT) to which the data relates. Within various
elements submitted as part of submissions, data with corresponding Trading Period information
must be provided, including:
• Forecast Element for Generator Unit (Generator Offer) and Demand Side Unit (Load Bid);
• Price Quantity Pairs for Interconnector Units;
• Settlement Reallocation;
• Energy Limit definition.
The remainder of this section describes how Trading Period data can be submitted correctly to the
SEM Central Market Systems for submission and query and interpreted in reports.
Here is an example of the Forecast element:

Name Validation
FORECAST_START_HR: Start trading hour will be an integer between 1 and 25.
FORECAST_START_INT: Start trading interval will be an integer 1 or 2.
FORECAST_END_HR: End trading hour will be an integer between 1 and 25.
FORECAST_END_INT: End trading interval will be an integer 1 or 2.
FORECAST_START_HR, Start hour must be less than or equal to End hour.

FORECAST_END_HR:
FORECAST_START_INT, Start interval must be less than or equal to End interval, if the Start
FORECAST_END_INT: hour equal to the End hour.
Hours and Interval in all the elements: Range of hours and intervals in all elements present must match.
Table 8: Sample of Hours and Intervals (applicable to Forecast)

As above, when submitting and covering periods of more than 1 hour the start hour (START_HR)
must be less than the end hour (END_HR). This means that:
• 1:1 to 24:2 is valid in order to cover an entire Trading Day but
• 7:1 to 6:2 is not allowed as 7 is bigger than 6, even though 7:1 to 6:2 would be chronological as
it is covering a Calendar day 1 and then Calendar Day 2.
In this instance, the Market Participant submits 7:1 to 24:2 (Calendar Day 1) and then 1:1 to 6:2
(Calendar Day 2).
For a normal Trading Day, the Market Participant could submit 1 element covering all 48 elements
as follows:
• 1:1 to 24:2; or
• Up to 48 different elements covering all 48 periods independently, e.g. 1:1 to 1:1; 1:2 to 1:2;
2.1 to 2.1;…; 24:2 to 24:2.
Submission of Standing bids of type “ALL” must include all trading periods – including those
extra periods for the long day (hour 25 intervals 1 & 2).
This can be submitted in any number of ways provided the start hour is always less than the end
hour:
1. Normal bid submission for the Long day.

<?xml version="1.0" encoding="UTF-8"?>
Valid – all 50 trading periods covered <forecast start_hr="1" start_int="1" end_hr="25" end_int="2"
maximum_mw="100" minimum_mw="40" minimum_output_mw="0"/>
Invalid – start hour greater than end hour <forecast start_hr="7" start_int="1" end_hr="6" end_int="2" maximum_mw="100"
minimum_mw="40" minimum_output_mw="0"/>
<forecast start_hr="7" start_int="1" end_hr="25" end_int="2"
Valid – two forecast elements present – all 50 maximum_mw="150" minimum_mw="40" minimum_output_mw="0"/>
trading periods covered <?xml version="1.0" encoding="UTF-8"?>
<forecast start_hr="1" start_int="1" end_hr="6" end_int="2" maximum_mw="100"
2. Normal bids for the short day
It is not currently possible to submit just one forecast element, as this would include hour 2 intervals
1 and 2, which do not exist on the short day:
Invalid – 48 periods covered <forecast start_hr="1" start_int="1" end_hr="24" end_int="2"
Valid – only 46 periods covered <forecast start_hr="1" start_int="1" end_hr="1" end_int="2" maximum_mw="100"
<forecast start_hr="3" start_int="1" end_hr="6" end_int="2" maximum_mw="100"

3. Normal bid submission for the normal day
It is possible to submit just one forecast element covering the entire trading day:
Valid – covers all 48 periods <forecast start_hr="1" start_int="1" end_hr="24" end_int="2"
Valid –multiple forecast element submission covers
all 48 periods

The tables below outline the validation rules and associated message(s) for Hours and Intervals in all the elements per Market Interface:
Settlement Reallocation Generator Offer Load Bid Offer Interconnector Offer
Applicable Applicable Applicable Applicable Applicable Applicable Applicable Applicable
Name Validation Message
for Submit for Query for Submit for Query for Submit for Query for Submit for Query
Start trading hour. Y Y Y Y Y Y Y Y
START_HR It will be an integer between 1 and
Y Y Y Y Y Y Y Y
25.
Start trading interval. Y Y Y Y Y Y Y Y
START_INT
It will be an integer 1 or 2. Y Y Y Y Y Y Y Y
End trading hour. Y Y Y Y Y Y Y Y
END_HR It will be an integer between 1 and
Y Y Y Y Y Y Y Y
25.
End trading interval. Y Y Y Y Y Y Y Y
END_INT
It will be an integer 1 or 2. Y Y Y Y Y Y Y Y
START_HR, END_HR The hours and intervals must The hours and intervals must cover
N Y N Y N Y N Y
START_INT, END_INT cover the entire trading day. the entire Trading Day
N
Different
The start_hr of {0} must be less message -
Start hour must be less than or
START_HR, END_HR than or equal to the end_hr of {1} Refer to N Y N Y N Y N
equal to End hour.
in {2} element Settlement
Reallocation
section.
N
Different
Start Interval must be less than or The start_int of {0} must be less message -
START_INT, END_INT equal to End Interval, if the start than or equal to the end_int of {1} Refer to N Y N Y N Y N
hour is equal to the end hour. in {2} element Settlement
Reallocation
section.
Table 9: Validation rules applicable for Start / End Hour / Interval

Settlement Reallocation Generator Offer Load Bid Offer Interconnector Offer

Validation Message Submit / Query / Submit / Query / Submit / Query / Submit / Query /
Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory Mandatory
or Optional or Optional or Optional or Optional or Optional or Optional or Optional or Optional
Hours and Intervals in all above Missing hour {0} and interval {1} in
elements must cover the entire trading {2} element, submission must cover the N/NA N/NA Y/M Y/O Y/M Y/O Y/M Y/O
day. entire Trading Day
For normal bid, if it is normal day or

short day, hours in all above elements Y/M Y/O Y/M Y/O Y/M Y/O Y/M Y/O
cannot submit hour 25. Could not submit hour {0} and interval
For normal bid, if it is short day, hours {1} in {2} element for {3} {4}
in all above elements must skip hour Y/M Y/O Y/M Y/O Y/M Y/O Y/M Y/O
2.
The hours or intervals for the same The hours and intervals are overlapping
N/NA N/NA Y/M Y/O Y/M Y/O Y/M Y/O
element cannot overlapping. for {0} in following {1}
Missing hour {0} and interval {1} in

{2} element. In standing bid
For standing bid with day type as submission: the hours must be from 1 to
"ALL", hours in all above elements 25 with day type as ALL, the hour 25 is N/NA N/NA Y/M Y/O Y/M Y/O Y/M Y/O
submitted must be from 1 to 25. optional in other day types. The
submission must cover the entire
Trading Day
Missing hour {0} and interval {1} in

{2} element. In standing bid
The standing bid with day type as submission: the hours must be from 1 to
SUN, MON, TUE, WED, THU, FRI, 25 with day type as ALL, the hour 25 is N/NA N/NA Y/M Y/O Y/M Y/O Y/M Y/O
or SAT, hours in all above elements optional in other day types. The
submitted may from 1 to 24 or 1 to 25. submission must cover the entire
The hours and intervals in all elements Trading Day
must match.
The following Hours and Intervals did
not match between the {0} element and N/NA N/NA Y/M Y/O Y/M Y/O Y/M Y/O
the {1} element: {2}
Table 10: Validation rules for Hours and Interval applicable per message type
Note: In reference to a long day, all of the information below applies but the Market Participant must ensure that they also cover 25:1 and 25:2 - which
represents the repeat of 1AM to 2AM.

4.3.3. Settlement Reallocation
Market Interface: Settlement Reallocation

Element Requirement
“SemSttlReallocSubmit” Mandatory if submit request.
“SemSttlReallocQuery” Mandatory if query request.
“identifier” [external_id] Optional
“reallocation_detail” Mandatory if submit request.
Table 11: Settlement Reallocation Elements
The table above gives details of the XML elements of the transactions, and specifies whether they
are mandatory or optional.

No Name Validation Message Submit /Mandatory Query/Mandatory

SemSttlReallocSubmit / SemSttlReallocQuery Element (mandatory, depending on transaction)
• The Trading Date is valid as long as the date
is less than or equal to 40 days in the past and
Invalid trading_date {0}. The trading_date must be
less than or equal to 29 days in the future.
between {1} and {2} for Settlement Reallocation Y/M N/NA
Submission.
CE-2 TRADING_DATE System Date - 40<= Trading Date <= System Date
+ 29.
• When the standing_flag is false, the trading
The trading_date {0} is invalid. It must fall within
date must be for past 7 days, current date and N/NA Y/M
the past {1} days and future {2} days
future 28 days.
Could not {0} a standing bid for settlement
reallocation.
• Must be “FALSE”.
The Standing Element could not be presented in
CE-3 STANDING_FLAG Y/M Y/M
settlement reallocation {0}.
• Only one this element is allowed in per
Only one {0} element is allowed per submission
submission.
• Must be STRING
Invalid participant_name {0} in
• Must be valid Participant..
sem_settlement_reallocation element
SR-1 CREDITED_PARTICIPANT_NAME • Only one this element is allowed per Y/M Y/M
submission.
The participant_name {0} in {1} element can not be
• The participant name cannot use the same
the same as the participant_name in market_submit
name with credited participant name.
element
• Must be ENERGY_PAYMENTS or
CAPACITY_PAYMENTS.
SR-2 REALLOCATION_TYPE Y/M Y/M
• Only one of this element is allowed per
submission.
Identifier Element (optional)
• Must be STRING.
SR-3 EXTERNAL_ID • Only one this element is allowed per Y/O N/NA
submission.
Reallocation_Detail Element (mandatory)
Refer to section 4.3.2 Hours and Interval for the common validation rules and messages.
The start_hr of {0} must be equal to the end_hr of
Y/M N/NA
SR-4 START_HR {1} in {2} element
• Start hour must equal to End hour.
The start_hr of {0} must be less than or equal to the
N/NA Y/O
end_hr of {1} in {2} element
Refer to section 4.3.2 Hours and Interval for the common validation rules and messages Y/M Y/M
The start_hr of {0} must be equal to the end_hr of
Y/M N/NA
SR-5 END_HR {1} in {2} element
• Start hour must equal to End hour.
The start_hr of {0} must be less than or equal to the
N/NA Y/O
end_hr of {1} in {2} element

No Name Validation Message Submit /Mandatory Query/Mandatory

The start_int of {0} must be equal to the end_int of
Y/M N/NA
SR-6 START_INT {1} in {2} element
• Start interval must equal to End interval.
The start_int of {0} must be less than or equal to the
N/NA Y/O
end_int of {1} in {2} element
The start_int of {0} must be equal to the end_int of
Y/M N/NA
SR-7 END_INT {1} in {2} element
• Start interval must equal to End interval.
The start_int of {0} must be less than or equal to the
N/NA Y/O
end_int of {1} in {2} element
• Only one this element is allowed per
SR-8 AGREEMENT_NAME Only one {0} element is allowed per submission Y/M N/NA
submission.
The {0} value of {1} must be greater than 0 from
SR-9 MONETARY_VALUE9 • Must be > 0. start_hr {2}, start_int {3} to end_hr {4}, end_int Y/M N/NA
{5}
Table 12: Settlement Reallocation Validations
9
The format of the MONETORY_VALUE field has been increased to NUMBER(12,2).

4.3.4. Single Request in Transaction – XML samples
This section has examples of single Market Interface Submit and Query Request Transactions, and
Response messages, for both valid and invalid Requests.
• For multiple bids/offers, the success flag on each request can be interpreted such that
success=“true” indicates Success and success=“false” indicates Failure.
• The attributes at each <sem_gen_offer> element level are described below:
o valid: This attribute indicates if the XML Offer passed validation or not. “true”
indicates it is successfully passed validation.
o success: This attribute indicates if the XML Offer is successfully written to the
database or not after the successful validation. “true” indicates it is successfully
written to the database, in which case valid=“true” would also apply. If
valid=“false”, the success attribute will always be “false” as well.
o process: This is only used for SEM internal processing, so Market Participants
should ignore this field.
• Regarding the <messages> sections embedded in a response, the <information> message is
presented at the request root but <error> messages are embedded as close to the data causing
the error as applicable.
1. Settlement Reallocation “Submit” XML samples
Sample XML 1: Settlement Reallocation “Submit” XML sample with no error – Submit

Sample XML 2: Settlement Reallocation “Submit” XML sample with no error – Response
• In this example it can be seen that there are no invalid data sets and that there was one valid
data set was received.
• It was submitted on Monday November 6th 2006 at 16:38:12 PST, took 22604 milliseconds to
process.
• The unique transaction_id is “KQA6Gbn0” and the external_id supplied with the Request was
“EXT_ID1” which is also returned in the Response.
• Within the main body of the response it can be seen that there is an information message which
specifies that the Settlement Reallocation Transaction which had been submitted was
successfully processed.
• Also, the data which formed the original submit Transaction is contained in the main body of
the response.

2. Settlement Reallocation “Submit” samples with error
Sample XML 3: Settlement Reallocation “Submit” XML sample with error – Submit
Sample XML 4: Settlement Reallocation “Submit” XML sample with error – Response
• In this example it can be seen that there was one data set received which is invalid.
• The Transaction was received on Tuesday October 10th 2006 at 16:32:19 PDT and it took 78
milliseconds to process.
• The unique transaction_id is “KQ9AGWI0” and an external_id was not supplied with the
Request.
• Within the main body of the response there is an error message present which states that only
one sem_settlement_reallocation element is allowed per submission.
• The main body of the response also includes the data from the original submission.

3. Settlement Reallocation “Query” samples with no error
Sample XML 5: Settlement Reallocation “Query” XML sample with no error – Query
Sample XML 6: Settlement Reallocation “Query” XML sample with no error – Response
• In the above example it can be seen that the query which was submitted resulted in a successful
retrieval of a particular settlement reallocation.
• In the response, it can be seen that the query was submitted on Monday November 6th 2006 at
16:29:00 PST, that one valid data set was received and that it took 47 milliseconds to process.
• The original data from the query is contained in the main body of the response.
• The reallocation details retrieved are the agreement name and the monetary value of the
reallocation.
• If the query is successful in retrieving detail, the response will include the external_id from the
settlement reallocation submission.
4. Settlement Reallocation “Query” samples with two errors

Sample XML 7: Settlement Reallocation “Query” XML sample with two errors – Query
Sample XML 8: Settlement Reallocation “Query” XML sample with two errors – Response
• In the above example, it can be seen that the query was submitted on Tuesday October 10th
2006 at 17:43:53 PDT and that it took 31 milliseconds to process.
• It can also be seen that it failed to retrieve the reallocation details, there was one invalid dataset
submitted as part of the query.
• There are two errors returned which indicate invalid hour and interval combinations for this
transaction.

4.3.5. Generator Offers
Market Interface: Generator Offers

Element Requirement
“SemGenOfferSubmit” Mandatory if submit request.
“SemGenOfferQuery” Mandatory if query request.
“standing” Mandatory, if standing_flag=true.
“forecast” Mandatory, non-autonomous units.
“pump_storage_detail” Mandatory, for pumped storage units.
“energy_limit_detail” Mandatory, for energy limited units.
“price_maker_detail” Mandatory, for PPMG* or VPMG* unit, excluding
demand side units and units Under Test.
“price_taker_detail” Mandatory if PPTG*, VPTG* or PPMG*/VPMG*
Under Test.
Table 13: Generator Offer Elements

(* Terms defined below)
• The table above gives details of the XML elements of the transactions, and specifies the
conditions under which they’re mandatory or optional.
• Notes on the terms in the table above:
o PPMG – Predictable Price Maker Generator;
o VPMG – Variable Price Maker Generator;
o PPTG – Predictable Price Taker Generator;
o VPTG – Variable Price Taker Generator.
• The Trading and Settlement Code definitions of Predictable, Variable, Price Taker and Price
Maker are provided below:
o Predictable Generator Units are Generator Units which are Dispatchable or
Controllable and which are not otherwise required to be classified as Variable in
accordance with paragraph 5.7.
o A Generator Unit shall be classified as a Variable Generator Unit if:
§ The short-term availability of the Generator Unit is unpredictable as a result of
its fuel source; and
§ The Generator Unit is a Wind Power Unit or a Run-of-River Hydro Unit; and
§ The Generator Unit is Dispatchable or Controllable.
o Price Maker Generator Unit - A Generator Unit that is Dispatchable and bid into the
market with the intention of actively influencing the market price.
o Price Taker Generator Unit - A Generator Unit that enters the market without
attempting to influence the market price on the understanding that it will take whatever
price is fixed by the market.

Submit/Mandatory Query /
No Name Validation Message or Optional Mandatory
or Optional
SemGenOfferSubmit / SemGenOfferQuery Element (mandatory, depending on transaction)
• When the standing flag is false, the Market Market Window for normal bid is not open for
Y/M Y/M
Window must be open. trading_date {0} and application_type {1}
• When the standing flag is false, the status of the An error occurred when fetching data from the
Y/M N/NA
trading_date must be set to “Open”. cm_market table for trading_date {0}
• When the standing_flag is false, the trading date
The trading_date {0} is invalid. It must fall within the
must be for past 7 days, current date and future N/NA Y/M
past {1} days and future {2} days
28 days.
• When the standing flag is true and day type is
SUN, MON, TUE, WED, THU, FRI or SAT, the Invalid trading_date {0}. The trading_date must be
valid trade_date must be greater than or equal to greater than or equal to {1} for standing bid with day Y/M N/NA
TRADING_DATE, the max(market_date with current state as type as {2}
CE-2
STANDING_FLAG “OPEN”) + 1 day.
• When the standing flag is true and day type is No record in cm_market table
ALL: Invalid trading_date {0}. The trading_date must be
• For an existing standing bid, the valid equal to {1} for an existing standing bid with day type
trade_date must be equal to the max as ALL. Please contact a Market Operator for
(market_date with current state as clarification and assistance
Y/M N/NA
“OPEN”) + 1 day.
• For a new standing bid, the valid Invalid trading_date {0}. The trading_date must be
trade_date must be greater than or equal to greater than or equal to {1} for an new standing bid
max(market_date with current state as with day type as ALL
• If the Standing Flag is equal to true, Standing Standing Element must be present when standing_flag
Y/M N/NA
must exist. is set to true
CE-3 STANDING_FLAG, STANDING
• If the standing element is present, the standing The standing_flag must be set to true when Standing
Y/M Y/M
flag must be true. Element is present
• Must be STRING.
GO-1 RESOURCE_NAME • Must be valid Resource and belong to the Y/M Y/O
The resource name {0} is invalid
Participant.
• Must be one of the following Invalid facility_type {0} given for facility_name {1},
PRED_PR_MAKER_GEN; it must be PRED_PR_MAKER_GEN,
PRED_PR_TAKER_GEN; PRED_PR_TAKER_GEN,
GO-2 RESOURCE_TYPE VAR_PR_MAKER_GEN; or VAR_PR_MAKER_GEN, or Y/M N/NA
VAR_PR_TAKER_GEN. VAR_PR_TAKER_GEN
The submitted resource_type value {0} does not
• Must match the stored Resource Type.
match the value {2} registered for the resource {1}

or Optional
Standing Element (mandatory if standing_flag=true)
• YYYY-MM-DD
• Must be in the future. The expiry_date {0} must be in the future
• Must be greater than or equal to the Trading The expiry_date {0} must be greater than or equal to Y/O
Date. trading_date {1}
GO-3 EXPIRY_DATE N/NA
• Optional if the day type is SUN, MON, TUE,
WED, THU, FRI or SAT.
The expiry_date attribute must not present when day
• Not required when DAY_TYPE is “ALL”. N/NA
type is ALL
• If STANDING_FLAG is TRUE then must be
MON, TUE, WED, THU, FRI, SAT, SUN or
ALL.
• If a standing bid in place and Submitted Standing Data with type {0} conflicts with
GO-4 DAY_TYPE DAY_TYPE=ALL, then no other DAY_TYPE existing Standing Data with type {1} for trading_date Y/O Y/O
bids can be submitted. {2}
• If standing bid with DAY_TYPE not ALL
accepted, then no bid with DAY_TYPE=ALL
can be submitted.
GO-5 EXTERNAL_ID • Must be STRING. Y/O N/NA
Forecast Parameters (mandatory if not autonomous unit)
Forecast Element • Must be present. The forecast element must be presented Y/M N/NA
Forecast Element:
GO-6 Refer to section 4.3.2 Hours and Interval for the common validation rules and messages.
START_HR
Forecast Element:
START_INT
Forecast Element:
END_HR
Forecast Element:
END_INT
GO-10 MAXIMUM_MW • Must be >=0. Y/M N/NA
start_hr {2}, start_int {3} to end_hr {4}, end_int {5}

or Optional
The maximum_mw value of {0} must be greater than
• MAXIMUM_MW>=MINIMUM_MW. or equal to the minimum_mw value of {1} from
• Must be >=0.
GO-11 MINIMUM_MW The maximum_mw value of {0} must be greater than Y/M N/NA
• MAXIMUM_MW>=MINIMUM_MW. or equal to the minimum_mw value of {1} from
• Standing flag is true with day type: ALL.
The {0} value of {1} MWh must be negative or equal
• Must be = 0 if not pump storage unit. to 0 for standing bid with day type ALL from start_hr
{2}, start_int {3} to end_hr {4}, end_int {5}
• Must be <=0 if pump storage unit.
• Standing flag is set to false or standing flag is set
to true with day type: SUN, MON, TUE, WED, The {0} value of {1} MWh must be equal to 0 for non
GO-12 MINIMUM_OUTPUT_MW THU, FRI or SAT. pumps from start_hr {2}, start_int {3} to end_hr {4}, Y/M N/NA
end_int {5}
• Must be = 0 if not pump storage unit.
• Standing flag is set to false or standing flag is set
to true with day type: SUN, MON, TUE, WED, The {0} value of {1} MWh must be negative for
THU, FRI or SAT. Pumps from start_hr {2}, start_int {3} to end_hr {4},
end_int {5}
• Must be <=0 if pump storage unit.
Pumped Storage Parameters (mandatory if pumped storage unit)
• When standing flag is set to false or standing
flag is set to true with day type: SUN, MON,
TUE, WED, THU, FRI, SAT and the unit can The pump_storage_detail element must be present
operate as a pump, this element must be present. when pump_storage_flag is set to Y
GO-13 PUMP_STORAGE_DETAIL Y/M N/NA
• Units with PUMP_STORAGE_FLG value is set
to “Y”.
• Units with PUMP_STORAGE_FLG value is set The pump_storage_detail element can not be submitted
to “N”. when pump_storage_flag is set to N
• Target Reservoir Level at end of Current
Trading Day (06:00 on D+1).
TARGET_RESERVOIR_LEVEL_MW • When standing flag is set to false or standing
GO-14 flag is set to true with day type: SUN, MON, The target_reservoir_level_mwh value of {0} must not Y/M N/NA
H
TUE, WED, THU, FRI, SAT, the reservoir exceed the Maximum Reservoir storage capacity value
capacity should not exceed Maximum storage of {1}
capacity (MAX_RESERVOIR_CAP).

or Optional
• Only the standing flag is set to false or standing
flag is set to true with day type: SUN, MON,
The target_reservoir_level_mwh value of {0} must not
TUE, WED, THU, FRI, or SAT (except day
fall below the Minimum Reservoir storage capacity
type: ALL), the reservoir capacity does not fall
value of {1}
below Minimum Reservoir storage capacity
(MIN_RESERVOIR_CAP).
TARGET_RESERVOIR_LEVEL_PER • Target Reservoir Level at end of Current

GO-15 Y/O N/NA
CENT Trading Day (06:00 on D+1).
PRIOR_DAY_END_RESERVOIR_LE
GO-16 • End Reservoir Level prior Trading Day. Y/O N/NA
VEL_MWH
The operational_reservoir_capacity_limit_mwh value

• Must be <= MAX_RESERVOIR_CAP. of {0} must not exceed the Maximum Reservoir
OPERATIONAL_RESERVOIR_CAPA storage capacity value of {1}
GO-17 Y/O N/NA
CITY_LIMIT_MWH The operational_reservoir_capacity_limit_mwh value
• Must be >= MIN_RESERVOIR_CAP. of {0} must not fall below the Minimum Reservoir
storage capacity value of {1}
GO-18 SPIN_GENERATION_COST • Cost of moving from Spinning to Generator. Y/O N/NA
GO-19 SPIN_PUMP_COST • Cost of moving from Spinning to Pumping. Y/O N/NA
• Cost of operating unit at minimum generation
GO-20 MINIMUM_GENERATION_COST Y/O N/NA
level.
Energy Limit Parameters (mandatory if Energy Limited)
• Must be present when The energy_limit_detail element must be present when
ENERGY_LIMIT_FLAG=”Y”. energy_limit_flag is set to Y
GO-21 ENERGY_LIMIT_DETAIL Y/M N/NA
• Must not be present when The energy_limit_detail element can not be submitted
ENERGY_LIMIT_FLAG=”N”. when energy_limit_flag is set to N
GO-22 LIMIT_MWH • Must be between 999999.99 and -999999.99. Y/O N/NA
GO-23 LIMIT_FACTOR • Must be between 0 and 1. Y/O N/NA

Energy Limit Period Element:
START_HR
START_INT
END_HR

or Optional
END_INT
Price Maker Element (mandatory if Predictable Price Maker or Variable Price Maker, excluding demand side units and Units under Test)
The price_maker_detail element must be present when
resource_type is "PRED_PR_MAKER_GEN" or
• Must be a Price Maker Element or Price Taker "VAR_PR_MAKER_GEN"
Price Maker Element Y/M N/NA
element submitted, but not both.
Only one price_maker_detail or price_taker_detail
elements is allowed per Gen Offer
The Prices in the PQ Curve are not monotonically
• Must be monotonically increasing.
increasing between points {0} and {1}
The price value of {0} in the pq_curve element must
• Not exceed Price Cap.
not exceed the Market Price Cap value of {1} ({2})
• Not fall below Price Floor. be not lower than the Market Price Floor value of {1}
({2})
GO-29 PQ_CURVE_PRICE Y/M N/NA
• Must be present if resource type is The price_maker_detail element must be present when
PRED_PR_MAKER_GEN or resource_type is "PRED_PR_MAKER_GEN" or
VAR_PR_MAKER_GEN if not Under Test. "VAR_PR_MAKER_GEN"
• The prices must be equal to 0 if the unit is a The price and quantity in the PQ Curve must be equal
pumped storage unit. to 0 when the unit is pumped storage.
• Must be no more than 10 PQ pairs per Trading
Day.
The MW Quantities in the PQ Curve are not
monotonically increasing between points {0} and {1}
GO-30 PQ_CURVE_QUANTITY VAR_PR_MAKER_GEN if not Under Test. "VAR_PR_MAKER_GEN" Y/M N/NA
• The prices must be equal to 0 if the unit is a The price and quantity in the PQ Curve must be equal
pumped storage unit. to 0 when the unit is pumped storage.
Day.
STARTUP_COST_HOT, • Start-up costs for cold, warm or hot states.
STARTUP_COST_WARM, • At least one (1) and up to three (3) values must Start-up costs for cold, warm or hot states. At least one
STARTUP_COST_COLD be provided. and up to three values must be provided
• If these values are provided, they must be The {0} value of {1} {2} must be greater than or
positive. equal to 0 {3}

or Optional
• If these values are provided,
STARTUP_COST_COLD >= The {0} start-up costs must be greater than or equal to
STARTUP_COST_WARM >= {1} start-up costs
STARTUP_COST_HOT
Start-up costs for cold, warm or hot states. At least one
• At least one and up to three values.
and up to three values must be provided
The {0} value of {1} MWh must be greater than or
• All>=0.
equal to 0 MWh
The {0} start-up costs must be greater than or equal to
• COLD>=WARM>=HOT.
{1} start-up costs
• The value for hot, warm and cold start up costs
The hot startup_cost value of {0} {1} must be equal to
must be equal to 0 of the unit is a pumped
0 when the unit is pumped storage
storage unit.
GO-31 STARTUP_COST_HOT • This element must not be present in Y/O N/NA

price_taker_datail when the resource type is:
"VAR_PR_TAKER_GEN"; or
• Unit is under test for the following
resource_types:
"VAR_PR_MAKER_GEN";
"VAR_PR_TAKER_GEN"; The startup_cost element can not be submitted in
"PRED_PR_TAKER_GEN"; price_taker_detail element when resource type is {0}
“PRED_PR_MAKER_GEN".
• Unit under test information is obtained from
mf_generator_parameters table Only When
standing flag is set to false or standing flag is set
to true with day type: SUN, MON, TUE, WED,
THU, FRI, or SAT (except day type: ALL)
check unit is under test.
GO-32 STARTUP_COST_WARM • At least one and up to three values. Y/O N/NA
• All>=0.
equal to 0 MWh
{1} start-up costs

or Optional
The warm startup_cost value of {0} {1} must be equal
to 0 when the unit is pumped storage
storage unit.
• This element must not be present in
resource_types:
"VAR_PR_MAKER_GEN";
GO-33 STARTUP_COST_COLD • At least one and up to three values. Y/M N/NA
• All>=0.
equal to 0 MWh
{1} start-up costs
The cold startup_cost value of {0} {1} must be equal
storage unit.

or Optional
resource_types:
"VAR_PR_MAKER_GEN";
The {0} value of {1} {2} must be greater than or
• Must be >=0.
equal to 0 {3}
• The value for no load cost must be equal to 0 of The no_load_cost value of {0} {1} must be equal to 0
GO-34 NO_LOAD_COST the unit is a pumped storage unit. when the unit is pumped storage Y/M N/NA
Price Taker Parameters (mandatory for Price Takers, excluding wind units and autonomous units or Units Under Test)
The price_taker_detail element must be present when
• Must be a Price Maker Element or Price Taker
Price Taker Element resource_type is "PRED_PR_TAKER_GEN", Y/M N/NA
element submitted, but not both.
"VAR_PR_TAKER_GEN or Under Test is true
PQ Pairs Y/M N/NA
Day.
GO-35 PQ_CURVE_PRICE • Must be monotonically increasing. Y/M N/NA
• Not fall below Price Floor. be not lower than the Market Price Floor value of {1}
({2})

or Optional
• This element must be present in The pq_curve element must be presented in
price_taker_detail when the resource is price_taker_detail element when resource type is
“PRED_PR_TAKER_GEN” and the unit is not PRED_PR_TAKER_GEN
under test.
price_taker_detail when the resource is the
following:
• VAR_PR_TAKER_GEN; or
The pq_curve element can not be submitted in
• Unit under test. price_taker_detail element when resource type is {0}
• Only when standing flag is set to false or
standing flag is set to true with day type SUN,
MON, TUE, WED, THU, FRI or SAT check
unit is under test.

Day.
monotonically increasing between points {0} and {1}
• This element must be present in
The pq_curve element must be presented in
price_taker_detail when the resource is
price_taker_detail element when resource type is
“PRED_PR_TAKER_GEN” and the unit is not
PRED_PR_TAKER_GEN
under test.
price_taker_detail when the resource is the
following:
GO-36 PQ_CURVE_QUANTITY Y/M N/NA
• VAR_PR_TAKER_GEN; or
• Unit under test. price_taker_detail element when resource type is {0}
• Only when standing flag is set to false or
standing flag is set to true with day type SUN,
MON, TUE, WED, THU, FRI or SAT check
unit is under test.
Day.
STARTUP_COST_HOT, • Start-up costs for cold, warm or hot states.
STARTUP_COST_WARM, • At least one (1) and up to three (3) values must Start-up costs for cold, warm or hot states. At least one
STARTUP_COST_COLD be provided. and up to three values must be provided
• If these values are provided, they must be The {0} value of {1} {2} must be greater than or
positive. equal to 0 {3}

or Optional
• If these values are provided,
STARTUP_COST_COLD >= The {0} start-up costs must be greater than or equal to
STARTUP_COST_WARM >= {1} start-up costs
STARTUP_COST_HOT.
The startup_cost element must be presented in
• Must be present. price_taker_detail element when resource type is
PRED_PR_TAKER_GEN
• All>=0.
equal to 0 MWh
{1} start-up costs
GO-37 STARTUP_COST_HOT storage unit. Y/O N/NA
• Must be present if resource type is The price_taker_detail element must be present when
PRED_PR_TAKER_GEN or resource_type is "PRED_PR_TAKER_GEN",
VAR_PR_TAKER_GEN if Unit is Under Test. "VAR_PR_TAKER_GEN or Under Test is true
• Must not be present if resource type is
VAR_PR_TAKER_GEN or
price_taker_detail element when resource type is {0}
VAR_PR_MAKER_GEN when Under test.
• All>=0.
equal to 0 MWh
{1} start-up costs
The warm startup_cost value of {0} {1} must be equal
GO-38 STARTUP_COST_WARM storage unit. Y/O N/NA
VAR_PR_TAKER_GEN or
GO-39 STARTUP_COST_COLD • All>=0. Y/M N/NA
equal to 0 MWh
{1} start-up costs

or Optional
storage unit.
VAR_PR_TAKER_GEN or
VAR_PR_MAKER_GEN when under test.
• Must be >=0.
equal to 0 MWh
• The value for no load cost must be equal to 0 of The no_load_cost value of {0} {1} must be equal to 0
the unit is a pumped storage unit. when the unit is pumped storage
• Must be present if resource type is
GO-40 NO_LOAD_COST The no_load_cost element must be presented in Y/M N/NA
PRED_PR_TAKER_GEN or
price_taker_detail element when resource type is
PRED_PR_MAKER_GEN if Unit is Under
PRED_PR_TAKER_GEN
Test.
The no_load_cost element can not be submitted in
VAR_PR_TAKER_GEN or
Nomination Profile Price Element: • Must be present if resource type is
GO-41 The nomination_profile element must be present when
START_HR PRED_PR_TAKER_GEN or
resource_type is "PRED_PR_TAKER_GEN" , Y/M N/NA
VAR_PR_TAKER_GEN or if a Unit is Under
"VAR_PR_TAKER_GEN" or unit under test
Test.
END_HR PRED_PR_TAKER_GEN or
Test.
START_INT PRED_PR_TAKER_GEN or
Test.
GO-44 Nomination Profile Price Element: Refer to section 4.3.2 Hours and Interval for the common validation rules and messages.

or Optional
END_INT • Must be present if resource type is
The nomination_profile element must be present when
Test.
• Non-price sensitive generation offer which is a
GO-45 NOMINATION_PROFILE_VALUE declaration of intended output level for each Y/M N/NA
Trading Period.
Decremental Price Element: • Must be present if resource type is
START_HR PRED_PR_TAKER_GEN or
Test.
END_HR PRED_PR_TAKER_GEN or
Test.
START_INT PRED_PR_TAKER_GEN or
Test.
END_INT PRED_PR_TAKER_GEN or
Test.
• Decremental Price for Predictable Price Taker
Generator Unit u, Variable Price Taker
Generator Unit u or Generator Unit Under Test
u in Trading Period h.
The {0} value of {1} must be equal to 0 from start_hr
GO-50 DECREMENTAL_PRICE_VALUE • Submitted decremental price must be zero.. Y/M N/NA
• Must be present if resource type is
The decremental_price element must be present when
resource_type is PRED_PR_TAKER_GEN,
VAR_PR_TAKER_GEN or unit under test
Test.
Table 14: Generator Offer Validations

Notes on Generator Offers:

• Price Makers will usually submit only the price_maker_detail element.
• The exception is if the Unit is Under Test, in which case Price Makers will submit the price_taker_detail element.
• Price Takers (non-autonomous) will only submit the price_taker_detail element.

4.3.6. Multiple Requests in Transaction – XML sample

This section has examples of multiple Market Interface Submit and Query Request Transactions,
and Response messages, for both valid and invalid Requests.
Sample XML 9: Multiple Bid/Offer “Submit” Requests in one Transaction – Submit

Sample XML 10: Multiple Bid/Offer “Submit” Requests in one Transaction – Response Part 1
• The response data has been split into two parts for ease of presentation.
• The Transaction was submitted on Monday November 13th 2006 at 14:40:24 PST, took 796
milliseconds to process and was assigned a transaction_id of “KQADEeO0”.
• The Transaction contained four Requests (received=”4”), of which three were valid and one
was invalid.
• Sequentially, the first Request had a Market Participant supplied external_id of “EXT_ID1”
and a Success information message is supplied with the Request (“Successfully processed the
SEM Generator Offer”). It is for a Variable Price Maker Unit.
• The second Request is similar, albeit for a different type of unit (resource_type) – Variable
Price Taker – and a different external_id is supplied (“EXT_ID2”).

Sample XML 11: Multiple Bid/Offer “Submit” Requests in one Transaction – Response Part 2
• This is a continuation of the response data (Sample XML 10), covering the third and fourth
Requests in the Transaction.
• The third Request is for a Predictable Price Maker. The Market Participant supplied
external_id was “EXT_ID3” and a Success information message is supplied with the Request
(“Successfully processed the SEM Generator Offer”).
• The final Request was the invalid one and has the error message – “The cold start-up costs
must be greater than or equal to warm start-up costs”. The Market Participant has supplied the
optional external_id with the Request (“EXT_ID4”).
• Note: In the sample above that there is price_taker_detail for a Predictable Price Maker
Generator. This is because the unit is under test.

4.3.7. Load Bid Submission
Market Interface: Load Bids

Element Requirement
“SemDemandOfferSubmit” Mandatory
“standing” Mandatory, if standing_flag=true
“forecast” Mandatory
“price_maker_detail” Mandatory, if demand side unit is not Under
Test
“price_taker_detail” Mandatory, if demand side unit is Under Test
Table 15: Load Bid Elements
The table above gives details of the XML elements of the Transactions, and specifies whether they

Submit /Mandatory Query/Mandatory

No Name Validation Message
SemDemandOfferSubmit / SemDemandOfferQuery Element (mandatory, depending on transaction)
Y/M Y/M
• When the standing flag is false, the status of An error occurred when fetching data from the
Y/M N/NA
the trading_date must be set to “Open”. cm_market table for trading_date {0}
date must be for past 7 days, current date N/NA Y/M
and future 28 days.
• When the standing flag is true and day type
is SUN, MON, TUE, WED, THU, FRI or Invalid trading_date {0}. The trading_date must
SAT, the valid trade_date must be greater be greater than or equal to {1} for standing bid Y/M N/NA
TRADING_DATE, than or equal to the max(market_date with with day type as {2}
CE-2
STANDING_FLAG current state as “OPEN”) + 1 day.
• When the standing flag is true and day type No record in cm_market table
is ALL: Invalid trading_date {0}. The trading_date must
• For an existing standing bid, the valid be equal to {1} for an existing standing bid with
trade_date must be equal to the day type as ALL. Please contact a Market
max(market_date with current state as Operator for clarification and assistance
Y/M N/NA
• For a new standing bid, the valid Invalid trading_date {0}. The trading_date must
trade_date must be greater than or be greater than or equal to {1} for an new
equal to max(market_date with standing bid with day type as ALL
current state as “OPEN”) + 1 day.
• If the Standing Flag is equal to true, Standing Element must be present when
Y/M N/NA
Standing must exist. standing_flag is set to true
• If the standing element is present, the The standing_flag must be set to true when
Y/M Y/M
standing flag must be true. Standing Element is present
• Must be STRING.
LB-1 RESOURCE_NAME • Must be valid Resource and belong to the Y/M Y/O
The resource name {0} is invalid
Participant and User.
Invalid facility_type {0} given for facility_name
• Must be PR_MAKER_DEMAND_UNIT.
{1}, it must be PR_MAKER_DEMAND_UNIT
LB-2 RESOURCE_TYPE Y/M N/NA
• Must match the stored Resource Type. The submitted resource_type value {0} does not
LB-3 EXPIRY_DATE • YYYY-MM-DD Y/O N/NA
• Must be greater than or equal to the Trading The expiry_date {0} must be greater than or equal to


type is ALL
ALL.
• If a standing bid in place and Submitted Standing Data with type {0} conflicts
LB-4 DAY_TYPE DAY_TYPE=ALL, then no other with existing Standing Data with type {1} for Y/M Y/M
DAY_TYPE bids can be submitted. trading_date {2}
accepted, then no bid with
DAY_TYPE=ALL can be submitted.
LB-5 EXTERNAL_ID • Must be STRING. Y/O N/NA
Forecast Element (mandatory)
Forecast Element • Must be present. The forecast element must be presented Y/M N/NA
Forecast Element:
LB-6 Refer to section 4.3.2 Hours and Interval for the common validation rules and messages.
START_HR
Forecast Element:
START_INT
Forecast Element:
END_HR
Forecast Element:
LB-9 Refer to section 4.3.2 Hours and Interval for the common validation rules and messages
END_INT
• Must be >=0. equal to 0 MWh from start_hr {2}, start_int {3} to
end_hr {4}, end_int {5}
LB-10 MAXIMUM_MW The maximum_mw value of {0} must be greater Y/M N/NA
than or equal to the minimum_mw value of {1} from
• Must be >=MINIMUM_MW.
start_hr {2}, start_int {3} to end_hr {4}, end_int
{5}
• Must be >=0. equal to 0 MWh from start_hr {2}, start_int {3} to
LB-11 MINIMUM_MW The maximum_mw value of {0} must be greater Y/M N/NA
than or equal to the minimum_mw value of {1} from
• Must be <=MAXIMUM_MW.
start_hr {2}, start_int {3} to end_hr {4}, end_int
{5}


The {0} value of {1} MWh must be less than or
LB-12 MINIMUM_OUTPUT_MW • Must be <=0. equal to 0 MWh from start_hr {2}, start_int {3} to Y/M N/NA
Price Maker Element (mandatory if demand side unit is not Under Test)
The price_maker_detail element must be present
• Must be present if the Unit is not Under Test.
when the unit is not under test
Price Maker Element • Must be either PRICE TAKER or PRICE Y/M N/NA
MAKER element in the submission, but not
element is allowed per Demand Offer
both.
LB-13 PQ_CURVE_PRICE The price value of {0} in the pq_curve element must Y/M N/NA
• Not fall below Price Floor. be not lower than the Market Price Floor value of
{1} ({2})
• Must be no more than 10 PQ pairs per
Trading Day.
• Must be monotonically increasing. monotonically increasing between points {0} and
LB-14 PQ_CURVE_QUANTITY {1} Y/M N/NA
• Must be no more than 10 PQ pairs per
Trading Day.
• Cost associated with Shut Down of a Demand
LB-15 SHUTDOWN_COST Y/M N/NA
Side Unit.
Price Taker Element (mandatory only if demand side unit is Under Test)
The price_taker_detail element must be present when
• Must be present if the Unit is Under Test.
the unit is under test
Price Taker Element • Must be either PRICE TAKER or PRICE Y/M N/NA
MAKER element in the submission, but not
element is allowed per Demand Offer
both.
Nomination Profile Element:
START_HR
START_INT
END_HR
END_INT


• A Nomination Profile for a Generator Unit u
shall comprise Nominated Quantities (NQuh)
LB-20 NOMINATION_PROFILE_VALUE Y/M N/NA
in respect of each Trading Period h during the
Trading Day.
Decremental Price Element:
START_HR
START_INT
END_HR
LB-24 Refer to section 4.3.2 Hours and Interval for the common validation rules and messages
END_INT
• Decremental Price for Predictable Price
Taker Generator Unit u, Variable Price
Taker Generator Unit u or Generator Unit
Under Test u in Trading Period h.
LB-25 DECREMENTAL_PRICE_VALUE Y/M N/NA
The {0} value of {1} must be equal to 0 from
• Submitted decremental price must be zero. start_hr {2}, start_int {3} to end_hr {4}, end_int
{5}
Table 16: Load Bid Offer Validations

4.3.8. Interconnector Offer Submission
Market Interface: Interconnector Offers

Element Requirement
“SemIntconOfferSubmit” Mandatory
“standing” Mandatory, if standing_flag=true
“interconnector_capacity” Mandatory
“pq_curve” Mandatory
Table 17: Interconnector Offer Elements
The table above gives details of the XML elements of the Transactions, and specifies whether they

EirGrid & SONI SEM Establishment Programme – MPUD
v6.5.doc

SemIntconOfferSubmit / SemIntconOfferQuery Element (mandatory, depending on transaction)
Y/M Y/M
• When the standing flag is false, the status of An error occurred when fetching data from the
Y/M N/NA
the trading_date must be set to “Open”. cm_market table for trading_date {0}
date must be for past 7 days, current date N/NA Y/M
and future 28 days.
• When the standing flag is true and day type
is SUN, MON, TUE, WED, THU, FRI or Invalid trading_date {0}. The trading_date must
SAT, the valid trading_date must be greater be greater than or equal to {1} for standing bid Y/M N/NA
TRADING_DATE, than or equal to the max(market_date with with day type as {2}
CE-2
STANDING_FLAG current state as “OPEN”) + 1 day.
• When the standing flag is true and day type No record in cm_market table
is ALL: Invalid trading_date {0}. The trading_date must
• For an existing standing bid, the valid be equal to {1} for an existing standing bid with
trading_date must be equal to the day type as ALL. Please contact a Market
max(market_date with current state as Operator for clarification and assistance
Y/M N/NA
• For a new standing bid, the valid Invalid trading_date {0}. The trading_date must
trading_date must be greater than or be greater than or equal to {1} for an new
equal to max(market_date with standing bid with day type as ALL
current state as “OPEN”) + 1 day.
• If the Standing Flag is equal to true, Standing Element must be present when
Y/M N/NA
Standing must exist. standing_flag is set to true
• If the standing element is present, the The standing_flag must be set to true when
Y/M Y/M
standing flag must be true. Standing Element is present
• Must be a valid Participant Name, the Invalid -- participant_name {0} is not registered as a
CE-4 PARTICIPANT_NAME INTCON_FLAG must be set to 'Y' in Interconnector user in Market Participant Y/M Y/M
MF_PARTICIPANT_USERS table. Registration
• Must be STRING.
IO-1 RESOURCE_NAME Y/M Y/M
• Must be valid Resource. The resource name {0} is invalid
Invalid facility_type {0} given for facility_name
• Must be INTERCONNNECTOR.
{1}, it must be INTERCONNECTOR
IO-2 RESOURCE_TYPE Y/M N/NA
The submitted resource_type value {0} does not
• Must match the stored Resource Name.

v6.5.doc

• YYYY-MM-DD
• Must be greater than or equal to the Trading The expiry_date {0} must be greater than or equal to Y/O
IO-3 EXPIRY_DATE N/NA
type is ALL
ALL.
• If a standing bid in place and Submitted Standing Data with type {0} conflicts
IO-4 DAY_TYPE DAY_TYPE=ALL, then no other with existing Standing Data with type {1} for Y/O N/NA
DAY_TYPE bids can be submitted. trading_date {2}
accepted, then no bid with DAY_TYPE=ALL
can be submitted.
IO-5 EXTERNAL_ID • Must be STRING Y/O N
Interconnector_Capacity Element (mandatory)
Interconnector Capacity Element:
IO-6 Refer to section 4.3.2 Hours and Interval for the common validation rules and messages.
START_HR
START_INT
END_HR
END_INT
The maximum_import value of {0} must not exceed
MAXIMUM_IMPORT_CAPACITY_M • Must be <= Maximum Import Capacity
IO-10 the Maximum Interconnector Import Capacity value Y/M N/NA
W Holding.
of {1}
The absolute maximum_export value of {0} must
• Must be <= Maximum Export Capacity
not exceed the absolute Maximum Interconnector
MAXIMUM_EXPORT_CAPACITY_M Holding.
IO-11 Export Capacity value of {1} Y/M N/NA
W
• It must be less than or equal to zero for all The maximum_export value of {0} must be less than
offers. or equal to zero

v6.5.doc

PQ_Curve Element (mandatory)
PQ Curve Element:
START_HR
PQ Curve Element:
START_INT
PQ Curve Element:
END_HR
PQ Curve Element:
END_INT
from start_hr {3}, start_int {4} to end_hr {5},
IO-16 PQ_CURVE_PRICE end_int {6} Y/M N/NA
• Not fall below Price Floor. be not lower than the Market Price Floor value of
{1} ({2})
• No more than 10 PQ pairs per Trading
Period.
• Must be monotonically increasing. increasing between points {0} and {1} from start_hr
• If the last quantity is positive, it must be less The quantity value of {0} must not exceed the
than or equal to the Maximum Import maximum_import_capacity_mw value of {1} for
Capacity. hour {2} and interval {3}
IO-17 PQ_CURVE_QUANTITY Y/M N/NA
• If the first quantity is negative, the absolute
The absolute quantity value of {0} must not exceed
value must be less than or equal to the
the absolute maximum_export_capacity_mw value
absolute value of the Maximum Export
of {1} for hour {2} and interval {3}
Capacity.
• No more than 10 PQ pairs per Trading
Period.
Table 18: Interconnector Offer Elements

5. Registration
5.1. Description
• The Transactions covered in this area are:

o Submit Transactions:
§ Application;
§ Contacts Data;
§ Users Data;
§ Bank Details;
§ Generator Parameters;
§ Load Parameters.
o Registration Query.
5.2.1. Automated Processing
Registration XML Submission
Market Participant
- Original Data Submitted

- Submission or - Queried Data (Query Only)
- Query - Error and/or Information Messages
1 2 4
3
Market Operator
Check Validation Update SEM

and Rules Systems
Adherance (Status = Received)
- XML Format
- Security
- Content
- Quality
Figure 8: Registration Data Processing Overview

packaged, in terms of SOAP, WSDL, etc. are covered in the Market Participant Interfaces
User Guide and the Market Participant Web Services Client Toolkit ).
• Stage 2: Data in this category can either be submitted (updated) or queried and will typically
be validated on the client (Market Participant) system to ensure compliance with the XML
Schema rules.
checks, including business rules, are applied – see section 5.3 for details of the specific
validations and sample XML for each transaction. At a generic level the following apply:
o The user must have access to the Registration system, with read-only access limited
to Query data, which read-write users can Submit, Query, or Cancel data.
o Generally, all submissions to be included for a Trading Day should be submitted
two working days before the Trading Day. This will allow time for appropriate
review of the details and contact with the relevant other Parties (e.g. System
Operators) who may need to agree to the change.
o However, once manually notified, submissions may be made up to five minutes
before Gate Closure. In these scenarios, the Market Operator will use best
endeavours to ensure that the data is approved in time for Gate Closure.
o Gate Closure for data to be used on the Trading Day, is 10am on the previous
Calendar Day prior that Trading Day.
• Stage 4: If the Stage 3 tests are passed then the SEM Central Market Systems are updated as
appropriate (with a status of Received) and an XML response is issued to the Market
Participant. If the tests are unsuccessful, a response is issued detailing the errors.
• For queries, the latest data set that qualifies for the range of Market Participant provided dates
will be returned to the Market Participant User. This will include the Status of the data (see
5.2.2 – Manual Processing section below).

5.2.2. Manual Processing
Note: The details below are provided for reference only.
Received
Market
Accepted
Operator
Incomplete
In Progress
Deny
Figure 9: Registration Data – Status Updates
• The Market Operator reviews all changes received through the Registration system. Other
applicable Parties will be contacted by the Market Operator if necessary (e.g. System
Operator).
• Based on the review, the Market Operator can update the status to Accepted, Incomplete, In
Progress or Deny. The Market Operator may also change the status to Cancel (from Accepted
and Received).
• Market Participants may update any data, subject to acceptance by the Market Operator and if
submitted within the applicable timescale.

5.3. Messages and Validation
In the sections below, the validation applicable to each message type is presented.
Note: The reference number below (e.g. AD-n for Application Data) provides a link to the data
mapping details in Appendix A.
5.3.1. Application Element Data: Submission
No. Name Validation Mandatory / Optional
AD-1 NAME • Must be a STRING (<=50 Characters). Mandatory
AD-2 SHORT_NAME • Must be a STRING (<=12 Characters restricted Mandatory

to "[a-zA-Z_0-9 \-]*").
AD-3 BUS_PRESIDENT • Must be a STRING (<=20 Characters). Mandatory
AD-4 EFF_DATE • Must be YYYY-MM-DD. Mandatory
AD-5 EXP_DATE • Must be YYYY-MM-DD. Optional
AD-6 ADDRESS • Must be a STRING (<=128 Characters). Mandatory
AD-7 ADDRESS2 • Must be a STRING (<=128 Characters). Optional
AD-8 CITY • Must be a STRING (<=20 Characters). Mandatory
AD-9 COUNTY • Must be a STRING (<=20 Characters). Mandatory
AD-10 POSTAL_CODE • Must be a STRING (<=15 Characters). Mandatory
AD-11 BILLING_ADDRESS • Must be a STRING (<=128 Characters). Optional
AD-12 BILLING_ADDRESS2 • Must be a STRING (<=128 Characters). Optional
AD-13 BILLING_CITY • Must be a STRING (<=20 Characters). Optional
AD-14 BILLING_COUNTY • Must be a STRING (<=20 Characters). Optional
AD-15 BILLING_POSTAL_CODE • Must be a STRING (<=15 Characters). Optional
AD-16 COUNTRY • Must be a STRING (<=20 Characters). Mandatory
AD-17 PHONE • Must be a STRING (<=20 Characters). Mandatory
AD-18 FAX • Must be a STRING (<=20 Characters). Mandatory
AD-19 EMAIL • Must be a STRING (<=50 Characters). Mandatory
AD-20 URL • Must be a STRING (<=100 Characters). Optional
AD-21 REPRESENT_PARTY • Must be a STRING (<=32 Characters). Optional
AD-22 VAT_JURISDICTION • Must be ROI or NI. Mandatory
AD-23 VAT_NUMBER • Must be a STRING (<=32 Characters). Mandatory
AD-24 VAT_STATUS • Must be “Non-Exempt” or “Exempt”. Mandatory

No. Name Validation Mandatory / Optional
AD-25 NOTIFICATION_COMMENT • Must be a STRING (<=250 Characters). Optional
AD-26 WAS_MP_FLG • Must be “Yes” or “No”. Optional
AD-27 OLD_MP_NAME • Must be a STRING (<=12 Characters). Optional
AD-28 OLD_MP_DATE • Must be YYYY-MM-DD. Optional
AD-29 ACCOUNT_MANAGER • Must be a STRING (<=50 Characters). Mandatory
AD-30 DOC_SIGNATORY_TRACKING • Must be a STRING (<=50 Characters). Mandatory
AD-31 INITIAL_CREDIT_COVER • Must be a decimal (max=999999.99). Optional
AD-32 CREDIT_COVER_TYPE • Must be “Letter of Credit” or “Credit”. Mandatory
AD-33 DATA_XCHG_TEST • Must be “Pass” or “Fail”. Optional but do not use
AD-34 INTCON_FLAG • Must be “Yes” or “No”. Optional
AD-35 CLASS_TYPE • Must be “System Operator”, “Trading Mandatory

Participant”, “Non-Trading Participant”,
“Regulator”, or “Interconnector Administrator”.
AD-36 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
AD-37 CODE_PARTICIPANT_NAME • Must be left blank for submission. Optional
• If submitted by the Market Participant, the

submission will be rejected.
5.3.2. Contact Element Data: Submission
No Name Validation Mandatory / Optional
CD-1 NAME • Must be a STRING (<= 50 Characters Mandatory

restricted to "[a-zA-Z_0-9 \-]*").
CD-2 ADDRESS • Must be a STRING (<= 128 Characters). Mandatory
CD-3 ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
CD-4 CITY • Must be a STRING (<= 20 Characters). Mandatory
CD-5 COUNTY • Must be a STRING (<= 20 Characters). Mandatory
CD-6 POSTAL_CODE • Must be a STRING (<= 15 Characters). Mandatory
CD-7 COUNTRY • Must be a STRING (<= 20 Characters). Mandatory
CD-8 PHONE • Must be a STRING (<= 20 Characters). Mandatory
CD-9 FAX • Must be a STRING (<= 20 Characters). Mandatory
CD-10 EMAIL • Must be a STRING (<= 50 Characters). Mandatory
CD-11 MOBILE • Must be a STRING (<= 20 Characters). Mandatory

CD-12 PAGER • Must be a STRING (<= 20 Characters). Mandatory
CD-13 URL • Must be a STRING (<= 100 Characters). Optional
CD-14 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
CD-15 EFF_DATE • Must be YYYY-MM-DD. Mandatory
CD-16 EXP_DATE • Must be YYYY-MM-DD. Optional
CD-17 POSITION • Must be a STRING (<= 50 Characters). Mandatory
CD-18 CONTACT_TYPE • Must be “Full Access Contact”, “Main Mandatory

Organisation Contact”, “Invoicing and Banking
Contact”, “Settlement Statements Contact”,
“Trading Contact” or “Other”.
CD-19 COMMENTS • Must be a STRING (<= 250 Characters). Optional
CD-20 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
5.3.3. User Element Data: Submission
UD-1 LOGIN_ID • Must be a STRING (<= 12 Characters Mandatory

UD-2 NAME • Must be a STRING (<= 50 Characters Mandatory

UD-3 ADDRESS • Must be a STRING (<= 128 Characters). Mandatory
UD-4 ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
UD-5 CITY • Must be a STRING (<= 20 Characters). Mandatory
UD-6 COUNTY • Must be a STRING (<= 20 Characters). Mandatory
UD-7 POSTAL_CODE • Must be a STRING (<= 15 Characters). Mandatory
UD-8 COUNTRY • Must be a STRING (<= 20 Characters). Mandatory
UD-9 PHONE • Must be a STRING (<= 20 Characters). Mandatory
UD-10 FAX • Must be a STRING (<= 20 Characters). Mandatory
UD-11 EMAIL • Must be a STRING (<= 50 Characters). Mandatory
UD-12 MOBILE • Must be a STRING (<= 20 Characters). Mandatory
UD-13 PAGER • Must be a STRING (<= 20 Characters). Mandatory
UD-14 URL • Must be a STRING (<= 100 Characters). Optional
UD-15 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
UD-16 EFF_DATE • Must be YYYY-MM-DD. Mandatory

UD-17 EXP_DATE • Must be YYYY-MM-DD. Optional
UD-18 POSITION • Must be a STRING (<= 50 Characters). Mandatory
UD-19 USER_TYPE • Must be “Full Access User”, “Trading User”, Mandatory

“Registration User”, “Invoicing User”,
“Settlement Statements User”, “Main
Organisation User”, or “Other User Type”.
UD-20 DATA_XCHG_TEST • Must be “Pass” or “Fail”. Optional but do not use
UD-21 COMMENTS • Must be a STRING (<= 250 Characters). Optional
UD-22 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
5.3.4. Bank Element Data: Submission
BD-1 BANK_NAME • Must be a STRING (<= 20 Characters). Mandatory
BD-2 BANK_NUM • Must be a NUMBER (<= 20 Digits). Mandatory
BD-3 BANK_ACCOUNT_NAME • Must be a STRING (<= 30 Characters). Mandatory
BD-4 BANK_ACCOUNT_NUM • Must be a STRING (<= 30 Characters). Mandatory
BD-5 BANK_ACCOUNT_DESCRIPTION • Must be a STRING (<= 50 Characters). Mandatory
BD-6 BANK_BRANCH_TYPE • Must be a STRING (<= 15 Characters). Mandatory
BD-7 BANK_BRANCH_NAME • Must be a STRING (<= 30 Characters). Mandatory
BD-8 BANK_BRANCH_NUM • Must be a STRING (<= 32 Characters). Mandatory
BD-9 BANK_BRANCH_DESCRIPTION • Must be a STRING (<= 50 Characters). Optional
BD-10 BANK_BRANCH_ADDRESS • Must be a STRING (<= 128 Characters). Optional
BD-11 BANK_BRANCH_ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
BD-12 BANK_BRANCH_CITY • Must be a STRING (<= 20 Characters). Optional
BD-13 BANK_BRANCH_COUNTY • Must be a STRING (<= 20 Characters). Optional
BD-14 BANK_BRANCH_POSTAL_CODE • Must be a STRING (<= 15 Characters). Optional
BD-15 BANK_BRANCH_COUNTRY • Must be a STRING (<= 20 Characters). Optional
BD-16 BANK_BRANCH_PHONE • Must be a STRING (<= 20 Characters). Optional
BD-17 BANK_BRANCH_FAX • Must be a STRING (<= 20 Characters). Optional
BD-18 SWIFT_BIC • Must be a STRING (<= 32 Characters). Mandatory
BD-19 IBAN • Must be a STRING (<= 30 Characters). Mandatory
BD-20 JURISDICTION • Must be ROI or NI. Optional

BD-21 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
BD-22 EFF_DATE • Must be YYYY-MM-DD. Mandatory
BD-23 EXP_DATE • Must be YYYY-MM-DD. Optional
BD-24 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
5.3.5. Generator Parameters Element Data: Submission
GP-1 RES_TYPE • Must be one of the following Mandatory

PRED_PR_MAKER_GEN;
PRED_PR_TAKER_GEN;
VAR_PR_MAKER_GEN;
VAR_PR_TAKER_GEN;
AUTO_PR_TAKER_GEN.
GP-2 RES_NAME • Must be STRING (<= 32 Characters restricted Mandatory

to "[a-zA-Z_0-9 \-]*").
GP-3 IM_RES_NAME • Must be STRING (<= 32 Characters). Optional
GP-4 CONNECTION_POINT • Must be STRING (<= 32 Characters). Optional
GP-5 CONNECTION_TYPE • Must be TRNS or DIST. Optional
• Must be STRING (<= 4 Characters).
GP-6 CONNECTION_AGREEMENT_XREF • Must be STRING (<= 32 Characters). Optional
GP-7 EFF_DATE • Must be YYYY-MM-DD. Mandatory
GP-8 EXP_DATE • Must be YYYY-MM-DD. Optional
GP-9 FUEL_TYPE • Must be “Oil”, “Gas”, “Coal”, “Multiple Fuel”, Mandatory

“Wind”, “Hydro”, “Biomass”, “Combined Heat
and Power”, “Pumped Storage”, “Peat",
"Distillate", "Nuclear", or "Not Applicable”.
GP-10 MIN_STABLE_GEN • Must be a positive NUMBER (max Mandatory

99999.999).
GP-11 MIN_TIME_SYNC_COLD Mandatory, but not used
• Must be a NUMBER (min -999.99 - max

by the SEM Central
999.99).
Market Systems
GP-12 MIN_TIME_SYNC_WARM • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-13 MIN_TIME_SYNC_HOT • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-14 MIN_GEN_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999)..

GP-15 MAX_GEN_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-16 MAX_RAMP_UP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-17 MAX_RAMP_DOWN • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-18 ELAPSE_SYNC_COLD Mandatory, but not used

by the SEM Central
99999.999).
Market Systems
GP-19 ELAPSE_SYNC_WARM Mandatory, but not used

by the SEM Central
99999.999).
Market Systems
GP-20 ELAPSE_SYNC_HOT Mandatory, but not used

by the SEM Central
99999.999).
Market Systems
GP-21 PUMP_STORAGE_FLAG • Must be Yes or No. Mandatory
GP-22 ENERGY_LIMIT_FLAG • Must be Yes or No. Mandatory
GP-23 NETTING_GEN_FLAG • Must be Yes or No. Mandatory
• Only applicable to PPMG; PPTG; VPMG;

VPTG; APTG.
• It is a Y/N/Null field. Null for Supplier,

demand and Interconnector.
GP-24 ST_MAX_CAP_MW • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-25 ST_MAX_CAP_TIME • Must be a INTEGER (max 9999). Mandatory
GP-26 MIN_ON_TIME • Must be a NUMBER (max 99999999.999). Mandatory
GP-27 MAX_ON_TIME • Must be a NUMBER (max 99999999.999). Mandatory
GP-28 MIN_OFF_TIME • Must be a INTEGER (max 99999999.999). Mandatory
GP-29 START_FORBIDDEN_RANGE_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-30 END_FORBIDDEN_RANGE_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-31 START_FORBIDDEN_RANGE_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-32 END_FORBIDDEN_RANGE_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

GP-33 FIXED_UNIT_LOAD • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-34 UNIT_LOAD_SCALAR • Must be between 0 and 1. Mandatory
• 4 decimal places.
GP-35 STARTUP_TIME_COLD • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-36 STARTUP_TIME_WARM • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-37 STARTUP_TIME_HOT • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-38 BLOCK_LOAD_FLAG • Must be Yes or No. Mandatory
GP-39 BLOCK_LOADS_COLD • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-40 BLOCK_LOADS_WARM • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-41 BLOCK_LOADS_HOT • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-42 LOADING_RATE_COLD_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).
GP-45 LOADING_RATE_WARM_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).
GP-48 LOADING_RATE_HOT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).
GP-51 LOADING_UP_BREAK_PT_COLD_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999)
GP-52 LOADING_UP_BREAK_PT_COLD_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-53 LOADING_UP_BREAK_PT_WARM_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

GP-54 LOADING_UP_BREAK_PT_WARM_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-55 LOADING_UP_BREAK_PT_HOT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-56 LOADING_UP_BREAK_PT_HOT_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-57 SOAK_TIME_HOT_1 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-58 SOAK_TIME_HOT_2 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-59 SOAK_TIME_WARM_1 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-60 SOAK_TIME_WARM_2 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-61 SOAK_TIME_COLD_1 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-62 SOAK_TIME_COLD_2 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).
GP-63 TRIGGER_PT_HOT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-64 TRIGGER_PT_HOT_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-65 TRIGGER_PT_WARM_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-66 TRIGGER_PT_WARM_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-67 TRIGGER_PT_COLD_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-68 TRIGGER_PT_COLD_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-69 STARTUP_END_PT • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-70 RAMP_UP_RATE_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999)

99999.999).

99999.999).

GP-75 RAMP_UP_BREAK_PT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).

99999.999).
GP-79 RAMP_DOWN_RATE_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).

99999.999).

99999.999).
GP-84 RAMP_DOWN_BREAK_PT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).

99999.999).

99999.999).
GP-88 DELOADING_RATE_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-89 DELOADING_RATE_2 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-90 DELOAD_BREAK_PT • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-91 DWELL_TIMES_1 • Must be a NUMBER (min -999.99 - max Mandatory

999.99).

999.99).

999.99).
GP-94 DWELL_TIMES_TRIGGER_PT_1 • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).

99999.999).


99999.999).
GP-97 DROOP • Must be a NUMBER (min -99999.999 - max Mandatory

999.9999).
GP-98 NUMBER_OF_STARTS • Must be an INTEGER (max 9999). Mandatory
GP-99 NUMBER_OF_RUN_HRS • Must be an INTEGER (max 9999). Mandatory
GP-100 MIN_RESERVOIR_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-101 MAX_RESERVOIR_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999)
GP-102 PUMPING_LOAD_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-103 PUMP_STORAGE_CYC_EFY • Must be between 0 and 100. Mandatory

9999.9999).
GP-104 MODE_OF_OPERATION • Must be 1, 2, 3 or 4. Mandatory
• Must be INTEGER (max 9).
GP-105 UNIT_LOCATION_ID • Must be a STRING (<= 32 Characters). Mandatory
GP-106 PHYSICAL_LOCATION_ID • Must be a STRING (<= 32 Characters). Mandatory
GP-107 STATION_NAME • Must be a STRING (<= 8 Characters, restricted Mandatory

to "[a-zA-Z_0-9 \-]*").
GP-108 STATION_ID • Must be a STRING (<= 32 Characters). Optional
GP-109 STATION_ADDRESS • Must be a STRING (<= 128 Characters). Optional
GP-110 STATION_ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
GP-111 REGISTERED_FIRM_CAP • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-112 NON_FIRM_ACC_QUANTITY • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-113 TARGET_RESV_LEVEL_PERCENT • Must be a FLOAT (max 200). Mandatory
GP-114 TARGET_RESV_LEVEL_MWH • Must be a NUMBER (min -99999.999 - max Mandatory

99999.999).
GP-115 COMMISSION_TEST_CERT • Must be a STRING (<= 32 Characters). Mandatory
GP-116 OLD_FLAG • Must be Yes or No. Optional
GP-117 OLD_RESNAME • Must be a STRING (<= 32 Characters). Optional
GP-118 OLD_MPNAME • Must be a STRING (<= 12 Characters). Optional
GP-119 PRIORITY_DISPATCH_FLAG • Must be Yes or No. Mandatory

GP-120 UNDER_TEST_START_DATE • Must be YYYY-MM-DD. Optional
GP-121 UNDER_TEST_END_DATE • Must be YYYY-MM-DD. Optional
GP-122 QUALIFIED_COMM_CH • Must be “NOT_QUALIFIED”, “BROWSER”, Optional

“WEBSERVICE”, or
“BROWSER_AND_WEBSERVICE”.
GP-123 JURISDICTION • Must be ROI or NI. Optional
GP-124 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
GP-125 TRADING_SITE_NAME • Must be a STRING (<= 32 Characters Optional

GP-126 METER_REGISTRATION_ID • Must be STRING (<= 32 Characters restricted Mandatory

to "[a-zA-Z_0-9 \-]*").
• MUST equal RES_NAME value.
GP-127 DATA_XCHG_TEST • Must be “Pass” or “Fail”. Optional but do not use
GP-128 EB_LICENSE • Must be a STRING (<= 24 Characters). Optional
GP-129 EB_EFF_DATE • Must be YYYY-MM-DD. Optional
GP-130 EB_EXP_DATE • Must be YYYY-MM-DD. Optional
GP-131 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
GP-132 DEFAULT_DATA_SUBMISSION • Must be Yes or No. Optional
5.3.6. Load Parameters Element Data: Submission
LP-1 RES_TYPE • Must be one of the following Mandatory

"PR_MAKER_DEMAND_UNIT";
"SUPP_UNIT”.
LP-2 RES_NAME • Must be STRING (<= 32 Characters restricted Mandatory

to "[a-zA-Z_0-9 \-]*")
LP-3 IM_RES_NAME • Must be STRING (<= 32 Characters). Optional
LP-4 CONNECTION_POINT • Must be STRING (<= 32 Characters). Optional
LP-5 CONNECTION_TYPE • Must be TRNS or DIST. Optional
LP-6 CONNECTION_AGREEMENT_XREF • Must be STRING (<= 32 Characters). Optional
LP-7 EFF_DATE • Must be YYYY-MM-DD. Mandatory
LP-8 EXP_DATE • Must be YYYY-MM-DD. Optional
LP-9 MAX_RAMP_UP • Must be a NUMBER (min -99999.999 - max Optional

99999.999).

LP-10 MAX_RAMP_DOWN • Must be a NUMBER (min -99999.999 - max Optional

99999.999).
LP-11 DISP_CAPACITY • Must be a NUMBER (min -99999.999 - max Optional

99999.999).
LP-12 NON_DISP_CAPACITY • Must be a NUMBER (min -99999.999 - max Optional

99999.999).
LP-13 MIN_DOWN_TIME • Must be a INTEGER (max 99999999.999). Optional
LP-14 MAX_DOWN_TIME • Must be a INTEGER (max 99999999.999). Optional
LP-15 FUEL_TYPE • Must be “DEM”. Optional
LP-16 TRADINGSITE_SUPPLIER_FLAG • Must be Yes, No, or NULL. Optional
LP-17 TRADING_SITE_NAME • Must be a STRING (<= 32 Characters Mandatory

• Maximum occurrences = 100.
LP-18 METER_REGISTRATION_ID • Must be STRING (<= 32 Characters restricted Optional

to "[a-zA-Z_0-9 \-]*").
LP-19 UNDER_TEST_START_DATE • Must be YYYY-MM-DD. Optional
LP-20 UNDER_TEST_END_DATE • Must be YYYY-MM-DD. Optional
LP-21 OLD_FLAG • Must be Yes or No. Optional
LP-22 OLD_RESNAME • Must be a STRING (<= 32 Characters). Optional
LP-23 OLD_MPNAME • Must be a STRING (<= 12 Characters). Optional
LP-24 QUALIFIED_COMM_CH • Must be ”NOT_QUALIFIED”, “BROWSER”, Optional

“WEBSERVICE”, or
LP-25 JURISDICTION • Must be ROI or NI. Optional
LP-26 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
LP-27 DATA_XCHG_TEST • Must be “Pass” or “Fail”. Optional
LP-28 EB_LICENSE • Must be a STRING (<= 24 Characters). Optional
LP-29 EB_EFF_DATE • Must be YYYY-MM-DD. Optional
LP-30 EB_EXP_DATE • Must be YYYY-MM-DD. Optional
LP-31 STATION_NAME • Must be a STRING (<= 8 Characters, restricted Mandatory

to "[a-zA-Z_0-9 \-]*").
LP-32 STATION_ID • Must be a STRING (<= 32 Characters). Optional
LP-33 STATION_ADDRESS • Must be a STRING (<= 128 Characters). Optional
LP-34 STATION_ADDRESS2 • Must be a STRING (<= 128 Characters). Optional

LP-35 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
LP-37 DEFAULT_DATA_SUBMISSION • Must be Yes or No. Optional
5.3.7. Netting Generator Parameters Element Data: Submission
• Must be one of the following:

NP-1 RES_TYPE Mandatory
“AUTO_PR_TAKER_GEN”.
• Must be STRING (<= 32 Characters restricted

NP-2 RES_NAME Mandatory
to "[a-zA-Z_0-9 \-]*").
NP-3 IM_RES_NAME • Must be STRING (<= 32 Characters). Optional
NP-4 CONNECTION_POINT • Must be STRING (<= 32 Characters). Optional
• Must be TRNS or DIST.

NP-5 CONNECTION_TYPE Optional
NP-6 CONNECTION_AGREEMENT_XREF • Must be STRING (<= 32 Characters). Optional
NP-7 EFF_DATE • Must be YYYY-MM-DD. Mandatory
NP-8 EXP_DATE • Must be YYYY-MM-DD. Optional
NP-9 FUEL_TYPE • Must be “Not Applicable”. Mandatory
NP-10 PUMP_STORAGE_FLAG • Must be “No”. Mandatory
NP-11 ENERGY_LIMIT_FLAG • Must be “No”. Mandatory
NP-12 NETTING_GEN_FLAG • Must be “No”. Mandatory
• Must be a STRING (<= 8 Characters,

NP-13 STATION_NAME Mandatory
NP-14 STATION_ID • Must be a STRING (<= 32 Characters). Optional
NP-15 STATION_ADDRESS • Must be a STRING (<= 32 Characters). Optional
NP-16 STATION_ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
NP-17 OLD_FLAG • Must be Yes or No. Optional
NP-18 OLD_RESNAME • Must be a STRING (<= 12 Characters). Optional
NP-19 OLD_MPNAME • Must be a STRING (<= 12 Characters). Optional
• Must be ”NOT_QUALIFIED”,
NP-20 QUALIFIED_COMM_CH “BROWSER”, “WEBSERVICE”, or Optional
NP-21 JURISDICTION • Must be ROI or NI. Optional

NP-22 NOTIFICATION_COMMENT • Must be a STRING (<= 250 Characters). Optional
• Must be a STRING (<= 32 Characters

NP-23 TRADING_SITE_NAME Mandatory
• Must be a STRING (<= 32 Characters

restricted to "[a-zA-Z_0-9 \-]*".
NP-24 METER_REGISTRATION_ID Optional
NP-25 DATA_XCHG_TEST • Must be “Pass” or “Fail”. Optional
NP-26 EB_LICENSE • Must be a STRING (<= 24 Characters). Optional
NP-27 EB_EFF_DATE • Must be YYYY-MM-DD. Optional
NP-28 EB_EXP_DATE • Must be YYYY-MM-DD. Optional
• Must be a STRING (<= 8 Characters,

NP-29 STATION_NAME Mandatory
NP-30 STATION_ID • Must be a STRING (<= 32 Characters). Optional
NP-31 STATION_ADDRESS • Must be a STRING (<= 128 Characters). Optional
NP-32 STATION_ADDRESS2 • Must be a STRING (<= 128 Characters). Optional
NP-33 EXTERNAL_ID • Must be a STRING (<= 32 Characters). Optional
5.3.8. Facility Transfer Parameters Element Data: Submission
This template is used to allow transfer of Facility between Market Participants.

A De-registration request is to be submitted from the Market Participant transferring the Facility,
while a Facility Transfer request is to be submitted from the Market Participant acquiring the
Facility.
The Effective Date from the Facility Transfer request must be greater than or equal to the De-
registration date for the Unit from the Market Participant transferring the Facility.
FP-1 OLD_RESOURCE_NAME • Must be STRING (<= 32 Characters). Mandatory
FP-2 OLD_MARKET_PARTICIPANT_NAME • Must be STRING (<= 12 Characters). Mandatory
FP-3 EFF_DATE • Must be YYYY-MM-DD. Mandatory

5.3.9. Important additional submission requirements
The SEM Central Market Systems have been built to support the requirements of the Trading and
Settlement Code. However, there are some areas where the data submission requirements are less
stringent than those required by the Code. Market Participants should therefore refer to the
requirements as set out in the Code, which reflects submission requirements that are physically
meaningful and will avoid incorrect results from the SEM Central Market Systems calculations.
Some key areas (this is not an exhaustive list) where such additional Code restrictions apply are:
• All submitted costs (e.g. Warm Start Up Cost) must be greater than or equal to zero.
• All submitted times (e.g. Synchronous Start Up Time Cold, Hot Cooling Boundary Time) must
be greater than or equal to zero.
• All submitted ramp rates (including the Aggregate Interconnector Ramp Rate) must be greater
than zero.
• Pumped Storage Cycle Efficiency must be between 0 and 100.
It is important that Market Participants consider the provisions of the Trading and Settlement Code
and the nature of the values to be submitted when preparing data for submission to the SEM Central
Market Systems.
5.3.10. Registration Query
RQ-1 START_DATE • YYYY-MM-DD Mandatory
• Must be <= END_DATE.
RQ-2 END_DATE • YYYY-MM-DD Mandatory
• Must be >= START_DATE.
RQ-3 APPLICATION • Must be “true” or “false”. Optional
RQ-4 BANK • Must be “true” or “false” (indicates whether the Optional

element data should be returned by the query).
RQ-5 CONTACT • Must be “true” or “false” (indicates whether the Optional

RQ-6 RESOURCE • Must be “true” or “false” (indicates whether the Optional

RQ-7 USER • Must be “true” or “false” (indicates whether the Optional

RQ-8 TRADINGSITE • Must be “true” or “false” (indicates whether the Optional

RQ-9 INTERCONNECTOR Optional, but not for

• Must be “true” or “false” (indicates whether the
Market Participant use
RQ-10 METER_REGISTRATION Optional, but not for

• Must be “true” or “false” (indicates whether the
Market Participant use


6. Settlement Reports
There are two types of Settlement Reports available:

• Member Private Settlement Reports:
o Statements;
o Participant Information Report and Settlement Reallocation;
o Invoices.
o Credit Cover Report (CCR)
• General Public Settlement Publications:
o Energy Market Financial Publication (MFR);
o Energy Market Information Publication (MIR);
o Capacity Market Financial Publication (MFR);
o Capacity Market Information Publication (MIR);
o Metered Generation Information Publication (MGR).
The sections below highlight the major elements.
6.1. Common Data Entry Procedure - Settlement Directory Listing
• In order for the Market Participants to view which files are available to them on any particular
day, they can request a directory listing using the following XML:
<directory date="2007-11-05">
</directory>
Sample XML 12: Settlements Directory Listing – Request
• If successful, this will return a response as follows:
<?xml version=”1.0” encoding=”UTF-8”?>

<directory_file_list>
<file name=”CAPEXG_P_PGEN_2007-11-05.csv”/>
<file name=”CAPEXG_P_PGEN_2007-11-05(1).csv”/>
<file name=”ENGEXG_P_PGEN_2007-11-05.csv”/>
<file name=”ENGIPCC_P_PGEN_2007-11-05.csv”/>
<file name=”CAPIPCC_P_PGEN_2007-11-05.csv”/>
<file name=”ENGEXG_P_PGEN_2007-11-05(1).csv”/>
<file name=”ENGEXG_P_PGEN_2007-11-05 (2).csv”/>
<file name=”MOEXG_P_PGEN_2007-11-05(1).csv”/>
<file name=”MOEXG_P_PGEN_2007-11-05(2).csv”/>
<file name=”FMOEXG_P_PGEN_2007-11-05.csv”/>
<file name=”CA_PIR_PGEN_P_2007-11-05.csv”/>
<file name=”EN_PIR_PGEN_P_2007-11-05.csv”/>
<file name=”INV_1079_PGEN_P_2007-11-05.csv”/>

<file name=”INV_1079_PGEN_P_2007-11-05.csv”/>
<file name=”EN_MFR_P_2007-11-05.csv”/>
<file name=”EN_MIR_P_2007-11-05.csv”/>
<file name=”EN_MGR_P_2007-11-05.csv”/>
<file name=”CA_MFR_P_2007-11-05.csv”/>
<file name=”CA_MIR_P_2007-11-05.csv”/>
Sample XML 13: Settlements Directory Listing – Response
Note: The above response Directory Listing contains Statements, Reports and Publications. It can
return all four Settlement file types (Statements, Reports, Invoices and Publications) if applicable.
With regard to the Statements, Reports and Publications, the Settlement Type code (Run Type) is
indicated in each file name as follows:
• P (representing the Indicative run),
• F (representing the Initial run),
• F (representing the nth revised Initial run).
Note: Revised Initial run is not applicable for General Public Settlement Publications.
6.2. Member Private Settlement Reports
6.2.1. Description
There are three Member Private Settlement file types available:

• Statements – CSV
• Reports– CSV
o Participant Information Report (PIR);
o Settlement Reallocation.
o Credit Cover Report
• Invoices – XML
Sign convention:
• Amounts to be paid to Market Participants are positive values on statements, but are negative
values on invoices.
• Amounts to be paid by Market Participants are negative values on statements, but are positive
on invoices.
• Settlement reallocation amounts that are positive mean a debit to the Market Participant and a
negative amount means a credit to Market Participant.

6.2.2. Type-Specific Data Entry Procedure
6.2.2.1. Statement
1. File Type
The file will be in a CSV format, which will be retrieved through the Type 3 communication channel
using the following XML:

<statement segment="ENGEXG" type="INDICATIVE" date="2006-10-31"/>
Sample XML 14: Statement – Request
Where:
• “Segment“ – segment abbreviation
o ENGEXG – energy payment and charge amount exchanged;
o MOEXG – market operator charges amount exchanged;
o CAPEXG – capacity payment and charge amount exchanged;
o ENGIPCC - currency cost for Energy market;
o CAPIPCC – currency cost for Capacity market;
o FMOEXG – fixed market operator charges amount exchanged.
• “Type” – Settlement Type
o INDICATIVE – indicative run;
o INITIAL – initial run;
o REVISED – revised initial run.
• “Date” – Settlement Date in “YYYY-MM-DD” numeric format.
The above XML returns the latest available file. To request a specific file, the following is used:
<file name="CAPEXG_P_PGEN_2006-10-31.csv" date="2006-10-31">
</file>
Sample XML 15: Settlements report file request

2. File Naming Convention

The file will be named as follows:
1. “segment”_“type”_“participant name”_“date”.CSV; or
2. “segment”_“type”_“participant name”_“date”(“n”).csv (if the “type” is “F” only).
Where:
• “segment” – segment abbreviation (see above);
• “type” - settlement type code ( see 6.2.1);
• “date” – date in “YYYY-MM-DD” numeric format (leading zeros for month and day);
• (“n”) – version number :
e.g.: “ENGEXG_F_MKTPAR_2006-10-20.csv”; or
“ENGEXG_F_MKTPAR_2006-10-20(2).csv”.
3. File Layout
The layout of the file is as follows:
• Header Record;
• Summary Record;
• Detail Record;
• Trailer Record.
a. Header Record
# Field Definition Domain Format Null? Example
1 Record Type Indicates the type of record. ‘H’ Char 1 H

2 File_Version The version number that Char 3 007
defines the file layout. This
version is 007.
3 Entity Settlement Entity that the Char 20 AIP
update is for.
4 Timestamp Date and time the file was YYYY- Date time 2005-05-
created. Military time. MM-DD 15
HH:MM:SS 20:55:45
5 File No Sequence number of the file; Number(8) 2001
unique to each settlement
statement file.
6 Participant The participant unique Char 4 MKTPAR
identifier (short name). (max 100)
7 Statement Settlement statement No, Number(8) 3221
No which is the unique identifier
for the statement. Each
statement is linked to one
settlement job.
8 Type Status type for the data. It ‘P’,’F’ Char 1 P
indicates whether the report is
based on Indicative (P)
Initial/Revised (F).

9 Market Market abbreviation that Char 2 EN

uniquely identifies the market
(Ref: 6.2.6).
10 Segment Segment or product group Char 8 ENGEXG
abbreviation that uniquely
identifies the segment. (Ref:
6.2.6).
11 Job ID Settlement Job No that Number(8) 3321
identified the group of
statement created in a
calculation.
12 Job_Version Version of run or calculation Number(8) 1
job. Every time a segment and
settlement day is calculated the
version increases by one.
13 Timestamp Date and time the settlement YYYY- Date time 2005-05-
job was created. Military time. MM-DD 15
HH:MM:SS 20:55:45
14 Settlement The settlement day for the job. YYYY- Date 2005-05-
Day This is the date the energy was MM-DD 20
delivered and consumed.
Table 19: Statement – Header Record
b. Summary Records
1 Record Type Indicates the type of record ‘S’ Char 1 S
2 Product Product unique identifier (short Char 32 ENPEX
name) – Ref 0
3 Product Product code description Char 1000 Energy
Description (PRODUCTPART.DESCRIPTI Payment
ON)
4 Delivery Date the energy was delivered YYYY- Date 2001-05-
Day and consumed. MM-DD 20
5 Pay/Charge Indicates whether transaction is ‘P’,’C’ Char 1 P
a payment (P) or charge (C).
(P record is populated when
summary records are calculated
as positive amount (0 or
greater); C record is populated
when summary records are
calculated as negative amount)
6 Total Sum of all the billable quantity Number 0.0000
Quantity records for all the hours for the (28.4)
given product ID. Shown with 2
decimals. Minus sign is used if
needed.
The value in this field is not
relevant for the Market
Participant
7 Unit Type of quantity unit. E.g. ‘MWh’ Char 18 MWh
MWh.


8 Total Sum of all the amount records Number 4533.210
Amount for all the hours for the given (28.4) 0
product ID. This could be
payment or charges. Minus sign
is used if needed.
9 Financial The unit for the Total Amount ‘/’ Char 1 /
Unit column and is an indicator that
the Total Amount value
contains a monetary value.
Table 20: Statement – Summary Record
c. Detail Records
1 Record Type Indicates the type of record. ‘D’ Char 1 D
2 Product Product unique identifier (short Char 100 ENPEX
name) – Ref : 6.2.6
For Combined product;
For positive sum add P, for
negative sum add C at the end of
the product name.
3 Order Order unique identifier (number). Number(8) 2225
4 Pay/Charge Indicates whether transaction is a ‘P’,’C’ Char 1 P
payment (P) or charge (C)
(P record is populated when detail
records are calculated as positive
amount (0 or greater); C record is
populated when detail records are
calculated as negative amount).
5 Operation date The date energy is delivered and YYYY-MM- Date 2005-05-20
consumed. DD
6 Hour Operation hour ending. (1-24) Date HH 7
7 Min Operation min starting. (00-59) Date MM 00
8 Resolution Time resolution will give 30-34,40 Number(2) 30
information of length of the
interval.
30 30-minute
31 Hour
32 Day
33 Week
34 Month
40 Undefined
9 PDA Not used Not used Not used √ Not used
10 Comments Reserved for future use. This field Char 32 √
is not populated in this file
version.
11 Resource The unique identifier for the Char 100 √ UNIT1
participant’s resource/unit. This
would be null (blank) when the
settlement line is for a non-
resource.


12 Location The unique identifier for the Char 10 √ Power
location of the resource/unit, e.g. Station
zone or hub. This would be null
(blank) when the settlement line is
for a non-resource.
13 Internal Zone Not used. Not used Not Used √ Not Used
14 Jurisdiction The unique identifier for Char 30 √ NI
jurisdictions. This would be null
when the settlement line is not for
Jurisdiction.
15 Contract The unique identifier for the Char 30 √ 1234
contract or trade. This would be
null (blank) when the settlement
line is for a non-contract.
16 Quantity Billable quantity for the given Number 0.0000
interval. Minus sign is used if (28.4)
needed.
Shown with 2 decimals.
The value in this field is not
relevant for the Market
Participant.
17 Unit Type of quantity unit. E.g. MWh. ‘MWh’ Char 18 MWh
18 Amount Billable amount. Payment or Number 2340.2200
charge. Minus sign is used if (28.4)
needed.
19 Financial Unit The unit for the Total Amount ‘/’ Char 1 /
column and is an indicator that the
Total Amount value contains a
monetary value.
Table 21: Statement – Detail Records
d. Trailer Record

1 Record Type Indicates the type of record. ‘T’ Char 1 T
2 Record Count Number of records contained in Number 32
the file including the header and
trailer records.
Table 22: Statement – Trailer Record

e. Sample CSV:
6.2.2.2. Participant Information Report (PIR)
1. File Type
The file will be in a CSV format, which will be retrieved through the Type 3 communication channel
Where:
• “Market” – Market abbreviation:
o EN – energy market;
o CA – capacity;
o MO – Market Operator Charges Market;
o FMO – Fixed Market Operator Charges Market.
• “Report” – is “PIR”.
• “type” – settlement type:
o INDICATIVE – indicative run;
o INITIAL – initial run.
• “date” – settlement date in “YYYY-MM-DD” numeric format.
Note: The file available for download is the latest produced in the Settlement system. When
downloading a PIR associated with a revised run, then the type would be “INITIAL”.


The file will be named as follows:
1. “Market”_PIR_”Participant”_”Type”_”Settlement Date”.csv.
Where:
• “Market” – Market abbreviation (see above);
• “Type” – Settlement type code (see 6.2.1):
• ”Settlement Date” – date in “YYYY-MM-DD”
e.g.: EN_PIR_MKTPAR_P_2006-10-20.csv.
Note: There is no version number in the file name for the Participant Information Report. The latest
report is available for the Participant to download where there are multiple reports produced for the
same report “Market”, “Type” and “Settlement Date”.
3. File Layout
• Header Record;
• Summary Record;
• Detail Record;
• Trailer Record.
a. Header Record

1 Record Indicates the type of record. {‘H’} Char 1 H
Type
2 Version The version number that Char 3 001
version is 001.
3 Entity This refers to the Market Char 20 AIP
Operator.
4 Timestam Date and time the file was YYYY-MM- Date time 2005-05-15
p created. Military time. DD 20:55:45
HH:MM:SS
5 File No Sequence number of the file; Number 2001
unique to each PIR file. (8)
identifier (short name).
7 Type Status type for the data. It ‘P’,’F’ Char 1 P
based on Indicative (P)
Initial/Revised (F).
8 Settlement The settlement day for the YYYY-MM- Date 2005-05-20
Day report. That is the main date DD
the energy was delivered and
consumed.

Table 23: Participant Information Report – Header Record
b. Summary Record

1 Record Indicates the type of record. {‘S’} Char 1 S
Type
2 Market Market abbreviation that Char 2 EN
uniquely identifies the
market.
3 Segment Segment or product group Char 8 ENGEX
abbreviation that uniquely
identifies the segment. (Ref:
6.2.6).
4 Job ID Settlement job No that Number(8 3321
identified the group of )
statement created in a
calculation.
5 Job_Version Version of run or calculation Number(8 1
job. Every time a segment )
and settlement day is
calculated the version
increases with one.
6 Type Status type for the job. ‘P’,’F’ Char 1 P
7 Timestamp Date and time the settlement YYYY-MM- Date time 2005-05-15
job was created. Military DD HH:MM:SS 20:55:45
time.
Table 24: Participant Information Report – Summary Record
c. Detail Records

1 Record Indicates the type of record. ‘D’ Char 1 D
Type
2 Delivery Date the energy was delivered YYYY-MM-DD Date 2005-05-20
Day and consumed.
3 Delivery Hour the energy was delivered HH24 Number(2 7 or 13
Hour and consumed. If an hour does )
not have any values there will
be no record for this hour.
4 Resolution Time resolution will give 30-34,40 Number(2 30
information of length of the )
interval.
30 30-minute
31 Hour
32 Day
33 Week
34 Month
40 Undefined
5 PDA Not used Not used Not used √ Not used
6 Variable The short name of the variable Char 24 MG
type type code that is reported. (Ref:
6.2.6).


7 Variable A name uniquely identifying Char 156 MG_UNIT1
name the values.
8 Resource The unique identifier for the Char 100 √ UNIT1
participant’s resource/unit. This
variable type is for a non-
resource.
9 Location The unique identifier for the Char 100 √ Power Station
location zone or hub. This
variable type is for a non-
resource.
Zone field in database.
10 Contract The unique identifier for the Char 100 √ 1234
contract or trade. This would be
null (blank) when the variable
type is for a non-contract.
11 Unit Unit for the variable type. E.g. {‘MWh’ Char 18 MWh
MWh. ,’MW’}
12 Value1 Variable value for the first Positive and Number 65.00
interval for the hour in field 3. negative (28.8)
Minus sign is used if needed. numbers
All values shown with decimals
as imported into the system.
13 Value2 Variable value for the second Positive and Number 65.00
interval for the hour in field 3. negative (28.8)
numbers
Table 25: Participant Information Report – Detail Records
d. Trailer Record

1 Record Type Indicates the type of record. {‘T’} Char 1 T
2 Record Count Number of records contained Number 20
in the file including the header
and trailer records.
Table 26: Participant Information Report – Trailer Record

e. Sample CSV:
6.2.2.3. Credit Cover Report
1. File name
The filename will be as follows;
“ReportName”_“PT_ID”_“Date”(“n”).csv where:
• “ReportName” is the abbreviated report name CCR
• “PT_ID” is the applicable Participant ID
“Date” is of the form YYYY-MM-DD (with leading zeros for month and day) and is the date that the report is
generated for:
• (“n”) is the version number (where required.)
• e.g. CCR_PT_11111_2008-01-01.csv; or
• CCR_PT_11111_2008-01-01(2).csv
Note: The Credit Cover Report can be retrieved via Type 3 communications using the File Name and Directory
Listing download processes.
2. File format
Header
1 Record Type Indicates the type of {‘H’} Char 1 H
record.

defines the file layout.
This version is 003.
3 Entity This is a reference to the Char 20
Market Operator.
4 Timestamp Date and time the file was YYYY-MM- Date time 2008-05-02
created. DD 10:05:54
HH:MM:SS


5 Code Represents the unique Char 100 CP_400020
Participant ID grouping of Generator
and/or Supplier Units to
the entity defined as a
“Participant” in the
Trading and Settlement
Code.
6 Day The date the credit risk YYYY-MM- Date 2008-05-02
calculations and the DD
credit risk report were
processed.
Table 27 - Credit Cover Report – Header Records
Summary
1 Record Type Indicates the type of {‘S’} Char 1 S
record
2 Code Participant Represents the Char 100 CP_400020
ID unique grouping of
Generator and/or
Supplier Units to the
entity defined as a
Trading and
Settlement Code.
3 Currency Denotes the currency Char 3 EUR, GBP
that the values are
included in.
4 Required Credit The result of the Number 12345.67
Cover Credit Risk (22,2)
Assessment for the
Code Participant.
5 Posted Credit The total value of Number 76543.21
Cover collateral posted for (22,2)
the Code Participant.
6 Warning Limit A value of collateral. Number 76543.21
The participant (22,2)
requires notification
when the Required
Credit Cover exceeds
the Warning Limit.
7 Warning Limit A comparison of the Char 3 YES, NO
reached? Required Credit
Cover and the
Warning Limit for
the Code Participant.
This field is
populated with
“YES” or “NO”.

8 Breach Amount The value by which Number 76543.21

the Required Credit (22,2)
Cover is greater than
the Posted Credit
Cover for the Code
Participant.
Table 28 - Credit Cover Report – Summary Records
Detail – Generator Unit and Supplier Unit

1 Record Type Indicates the type of {‘D0’} Char 2 D0
record
2 Code Participant Represents the Char 100 CP_400020

ID unique grouping of
Generator and/or
Supplier Units to the
entity defined as a
Trading and
Settlement Code.
3 Type Abbreviation that Char 3 GEN, SUP
uniquely identifies
the type of units, i.e.
Generator Units or
Supplier Units
4 Currency Denotes the currency Char 3 EUR, GBP
that the values are
included in.
5 Required Credit The result of the Number 12345.67
Cover Credit Risk (22,2)
Assessment for the
Code Participant for
the specified "Type".
6 Invoices Not Paid The value of all Number 76543.21
Invoices issued for (22,2)
the Participant
Accounts for the
named Type that are
unpaid (including
VAT).
7 Settlement Not The sum of all Number 76543.21
Invoiced Settlement (22,2)
Statements issued for
the Participant
Accounts for the
named Type that
have not yet been
included in an
Invoice (including
VAT).


8 Undefined The sum of all Number 76543.21
Exposure calculated exposures (22,2)
for the Participant
Accounts for the
named Type in
respect of the
Undefined Exposure
Period(s) (including
VAT).
9 Reallocations The sum of all Number 76543.21
pending Settlement (22,2)
Reallocation
Agreements lodged
for the Market
Participants for the
named Type.
10 Fixed Credit Cover The sum of all Fixed Number 76543.21
Credit Requirements (22,2)
in respect of the
the named "Type"
11 Adjustment The sum of all Number 76543.21
Amount Adjustment Amounts (22,2)
in respect of the
the named "Type".
Table 29 - Credit Cover Report – Detail Records for Generator Unit and Supplier Unit
Detail – Market Participant

record
2 Participant ID The Market Char 100 PT_400022

Participant ID:
Represents a unique
grouping of
Generator Units or a
unique grouping of
Supplier Units. A
Code Participant
may have multiple
Market Participant
accounts registered
in the Central
Market Systems.
3 Type Abbreviation that Char 3 GEN, SUP
uniquely identifies
the type of account
i.e. Generator Units
or Supplier Units

4 Status Denotes whether the Char1 N,

Participant is classed A,
as New, Adjusted or S
Standard for
calculation of
Undefined Exposure
5 Currency Denotes the currency Char 3 EUR,
that the values are GBP
included in.
6 Market Market abbreviation Char 50 EN,
that uniquely CA
identifies the market.
(NB – Calculations
under EN also
include Credit Cover
Requirements in
respect of the
Variable Market
Operator Charges)
7 Invoices Not Paid The value of all Number 76543.21
Invoices issued for (22,2)
the Participant
Accounts for the
named Market that
are unpaid
(including VAT)
8 Settlement Not The sum of all Number 76543.21
Invoiced Settlement (22,2)
Statements issued for
the Market
Participant for the
named Market that
have not yet been
included in an
Invoice (including
VAT)
9 Undefined The sum of all Number 76543.21
Exposure calculated exposures (22,2)
for the Market
Participant for the
named Market in
respect of the
Undefined Exposure
Period(s) (including
VAT)
10 Reallocations The sum of all Number 76543.21
pending Settlement (22,2)
Reallocation
Agreements lodged
for the Market
Participant.
Table 30 - Credit Cover Report – Detail Records for Market Participant

Detail – Market
record
2 Market Market abbreviation Char 50 EN,
that uniquely CA
identifies the market.
(NB – Calculations
under EN also
include Credit Cover
Requirements in
respect of the
Variable Market
Operator Charges)
3 Undefined Denotes the number Number (8) 15
Exposure Period of days in the
Undefined Exposure
Period for this
Market used in the
calculation of RCC.
4 Analysis Percentile The value of Number 95
Parameter Analysis Percentile (10,2)
Parameter used in
the calculation of
RCC.
5 Historical The number of days Number (8) 45
Assessment Period in the Historical
Assessment Period
for this Market used
in the calculation of
RCC.
6 Credit Assessment The Credit Number 92.636
Price Assessment Price (23,3)
that is used in
calculations of
Undefined Exposure
for New and
Adjusted Participants
used in the
calculation of RCC.
Table 31 - Credit Cover Report – Detail Records for Market

6.2.2.4. Reallocation Agreement Report
1. File Type
The File will be a CSV, which will be retrieved through the Type 3 communication channel.

• The file will be named as follows:
“Market”_RAR_”Participant”_”Type”_”Date”.csv
Where:
• “Market” – Market abbreviation:
o EN – energy market;
o CA – capacity market;
• “Type” – Run type:
o P – indicative,
o F – initial.
• “Date” – date in “YYYY-MM-DD”
E.g. EN_RAR_MKTPAR_P_2006-10-20.csv.
3. File Layout
• Header Record;
• Detail Record;
• Trailer Record.
a. Header Record

1 Record Type Indicates the type of record. {‘H’} Char 1 H
version is 001.
3 Entity This refers to Market Operator. Char 20 AIP
created. A 24 hour clock is DD 20:55:45
used. HH:MM:SS
identifier (short name).
6 Type Status type for the data. It {‘P’,’F'} Char 1 P
based on preliminary (P) or
final (F) jobs.


7 Billing period The first date of the billing YYYY-MM- Date 2006-09-24
start date period for which the report is DD
created.
8 Billing period The last date of the billing YYYY-MM- Date 2006-09-30
end date period for which the report is DD
created.
Table 32: Reallocation Agreement Report – Header Record
b. Detail Records
1 Record Type Indicates the type of record. ‘D’ Char 1 D
2 Reallocation The name for the Char 32 My Reallocation
name reallocation agreement, agreement
entered by the submitting
participant.
3 Trading The start time of the trading YYYY-MM- Date 2006-09-28
interval interval against which the DD Time 21:30:00
reallocation agreement is HH:MM:SS
launched.
4 DST Flag This is 1 if the Trading (0,1) Number 0
interval is during the extra (1)
hour for the day of DST
ending.
5 Counterpart The unique identifier (short Char 100 PGEN
Participant name) of that participant
which is the counterpart to
the Settlement Reallocation
Agreement.
6 Unit Currency for the amount. EUR, GBP Char 3 EUR
7 Amount The reallocation agreement Number -
amount. This is a positive (28, 8) 32344.0000000
value for the debited 0
participant and a negative
value for the credited
participant.
7 Validity Y for valid reallocation (‘N’, ‘Y’) Char 1 Y
agreements, N for invalid
agreements.
8 Reason For invalid reallocation Char 500 √ Total invoice
agreements this gives the amount
reason for rejecting the exceeded
agreement.
Table 33: Reallocation Agreement Report – Detail Records

c. Trailer Record

1 Record Type Indicates the type of record. {‘T’} Char 1 T
2 Record Count Number of records contained Number 32
in the file including the
header and trailer records.
Table 34: Reallocation Agreement Report – Trailer Record
d. Sample CSV
6.2.2.5. Invoice
• An invoice is requested using the following XML:

<invoice number="1079" date="2007-13-03">
</invoice>
• The invoice is returned as XML with the following naming convention:
INV_”Invoice Number”_”Participant”_”Invoice Date”.xml.
• Where Invoice date is in the format YYYY-MM-DD. e.g. INV_1_MKTPAR_2006-09-26.xml.
• The invoice XML is structure according to the following element hierarchy:
v InvoiceSet
Ø InvoiceElement
§ Body
§ Job
• There is only one InvoiceSet in an invoice XML file. Although the schema allows for it, there is
normally not more than one InvoiceElement for the InvoiceSet.
• There are generally multiple Body records for an InvoiceElement. The body records each
represent an invoice line item.
• There are generally multiple Job records for an InvoiceElement. The Job records each identify a
Settlement job that was used to generate the invoice.
• Further details can be obtained from the InvoiceSet xsd.
• Before requesting a specific invoice, one must first request a Directory Listing. From this one
can either:
o Request the Invoice file directly by doing a FILE request.

o Determine the Invoice Number from the details in the Directory Listing, and do an
Invoice (INVC) request.
1. Invoice Element fields
Field Definition Format Example

Invoice_number Invoice number String (10) 1433
Sender_addr1 Line 1 of sender's address String (256)
Sender_addr2 Line 2 of sender's address String (102)
Sender_tel Sender's telephone number String (20)
Sender_fax Sender's fax number String (20)
Sender_taxid Sender's VAT Registration
details
Receiver_name Recipient’s name String (100) MKTPAR
Receiver_addr1 Line 1 of Recipient’s billing String (256) 321 East St.
address
Receiver_addr2 Line 2 of Recipient’s billing String (102) Offaly
address
Receiver_gl_number Receiver's VAT Registration String (20) 111111
details
Invoice_type 1=regular invoice String(1) 1
2 = Credit note
Due_date Due date YYYY-MM-DD 2006-06-22
Inv_heading Invoice header (always String (200) Final invoice for
named “final invoice”, even Week 24 2006
for revised invoice)
Inv_comment Invoice comment String (160) Energy Invoice for
week 24 2006
Signature1 Invoice signature String (120) John Doe
Unit Currency unit String (18) EUR
Invoice_date Invoice date YYYY-MM-DD 2006-06-19
Invoice_calendar_id N/A String (8) 2
Invoice_amount Invoice amount Double 37581.12
Market_name Name of Market for which String (120) Energy
the invoice is issued (Ref:
6.2.6 Table 22)
Bill_period_name Name of billing period String (255) Week 24 2006
Receiver_id Participant code String (120) MKTPAR
First_amount Invoice amount of initial Double 37581.12
invoice of billing period
Table 35: Invoice – Element Fields

2. Body Records

Invoice_number Invoice number String (10) 1433
Bill_heading Billing period header String (119) Charges for period
Week 24 2006
Charge_description Invoice line description String (120) Energy Market
Settlement Amount
Charge_id Ref: 6.2.6 String (24) ENCEX
Quantity Quantity (where applicable) Double 34.224
Qty_unit Quantity unit (where String (18) MWh
applicable)
Amount Invoice line amount (ex Double 33212.23
VAT)
Amount_unit Currency unit String (18) EUR
Bill_order N/A String (32)
Charge_type 2 - Invoice line amount Integer (1) 2
3 - VAT amount
4 - Interest amount
Tax_amount N/A Double
Tax_vartype_code N/A String (24)
Tax_vartype_name Name of the VAT code String (120) VAT Rate of
ENCEX Product
Prev_amount Amount on previous invoice Double 32322.53
(only applicable for revised
invoices)
Prev_tax_amount N/A Double
Table 36: Invoice – Body records
3. Job Records

Job_id N/A String (8)
Job_name Settlement segment name String (100) Energy Settlement
Settlement_day Settlement day YYYY-MM-DD 2006-06-08
Job_number Job number Integer (16) 193
Job_version Job version String (8) 1
Job_state N/A String (6) SAD
Job_status Job completion code String (6) F
True_up_based_on N/A String (8) 100
Optional field for the
revised invoice
Statement_id Settlement statement Integer (8) 1494
number
Global_participant_n Participant Short name String (100) MKTPAR
o
Table 37: Invoice –Job records
Note for the Revised Invoice:

For each Settlement run and each segment there will be set of Job Records, which uniquely identify that
Settlement run.
Where a Settlement Day is included on the Revised Invoice, and that Settlement Day has not been
reprocessed, the Job Records will be the same for new job processing and the previous job processing
except for the “True_up_based_on” field.

4. Sample Invoice XML

6.2.2.6. Reference Tables used by Settlement Reports
1. Segment
A Segment is a group of calculations that are able to be run at the same time. The following
Segments are configured in the Market Operator Settlements System.
Market Segment Segment Description

Energy payment and charge amount exchanged. All currencies are
EN ENGEXG
subject to Market Participant jurisdiction.
EN ENGIPCC Currency cost calculations for Energy Market.
Capacity payment and charge amount exchanged. All currencies
CA CAPEXG
are subject to Market Participant jurisdiction.
CA CAPIPCC Currency cost calculations for Capacity Market.
MO MOEXG Market Operator charges amount exchanged.
FMO FMOEXG Fixed Market Operator charges amount exchanged.
Table 38: Settlement Reports – Market Segment Reference
Note: This field refers to the Segment field in the Header section of the Settlement Statement, the
Summary section of the Participant Information Report (PIR), and the Detail section of the
Participant Summary Report (PSR).

2. Product (Charge ID)

A Product is pushed out on statement files and they represent an amount in the Market Participants’
native currencies. The following products are configured in the Market Operator Settlements
System.
Product (Charge
Market Product Description
IDs)
Capacity Payment for Generator Units
CA CPEX
(exchanged to Market Participant currency).
Capacity Payment for Interconnector Users
CA CPIUEX
Capacity Payments for Interconnector Error
CA CPIEUEX Units (exchanged to Market Participant
currency).
Capacity Charge for Supplier Units
CA CCEX
Capacity Charges for Error Supplier Unit
CA CCJEX
CA REALLOC Reallocation amount.
Currency Costs for Capacity Market for each
CA CC_PCPEX Market Participant for the Capacity Period
CA CCCAALOC Currency Costs Reallocation – Capacity.
Energy Payment for Generator Units
EN ENPEX
Energy Payment to Interconnector Users
EN ENPIUEX
Constraint Payment for Generator Units
EN CONPEX
Constraint Payment to Interconnector Users
EN CONPIUEX
Uninstructed Imbalance Payment for
EN UNIMPEX Generator Units (exchanged to Market
Participant currency).
Make Whole Payment for Generator Units
EN MWPEX
Make Whole Payment to Interconnector Users
EN MWPIUEX
(exchanged to Market Participant currency)
Energy Charge for Supplier Units (exchanged
EN ENCEX
to Market Participant currency).
Energy Charge to for Error Supplier Unit
EN ENCJEX
Imperfection Charge for Supplier Units
EN IMPCEX
Imperfection Charge for Error Supplier Unit
EN IMPCJEX
Testing charge (exchanged to Market
EN TCHAREX
EN REALLOC Reallocation amount.
Uninstructed Imbalance Payment for
EN UNIMPIEUEX Interconnector Error Units (exchanged to
Market Participant currency).
Currency cost for Energy Market for each
EN CC_PENEX Market Participant for the Billing Period

Product (Charge
Market Product Description
IDs)
EN CCENALOC Currency Costs Reallocation – Energy.
Fixed Market Operator Charge (exchanged to
FMO FMOC_EX
Market Participant currency)..
Fixed Market Operator Charge for
FMO FMOCIU_EX Interconnector Units (exchanged to Market
Variable Market Operator Charge (exchanged
MO VMOC_EX
to Market Participant currency).
Variable Market Operator Charge for Error
MO VMOCJ_EX Supplier Unit (exchanged to Market
EN INTEREST Interest
EN INT_XMPT Interest Exempt
Table 39: Settlement Reports – Product (Charge ID) Reference
Note: The Product (Charge ID) refers to the Product field in the Summary and Detail sections of the
Settlement Statement.
3. Variable Type
Total market values are captured as Variable Types. The following Variable Types are configured
in the Market Operator Settlements System.
Variable Used in reference to:

Market Description
Types
EN MG Metered Generation Generator Units
Metered Generation for Interconnector Units
EN MGIU
Interconnector Unit
Metered Generation for Interconnector Error Units
EN MGEU
Interconnector Error Unit
Supplier Units (not Jurisdictional
EN MD Metered Demand
Error Supplier Unit - JESU)
EN NDLF Loss Adjusted Net Demand
Loss-Adjusted Net Demand for Jurisdictional Error Supplier Unit
EN NDLFESU
Jurisdictional Error Supplier Unit JESU
Market Schedule Quantity used Generator Units
EN MSQ
in Settlement Calculations
Market Schedule Quantity for Generator Units
EN MSQIU Interconnector Unit used in
Settlement Calculations
Dispatched Quantity used in Generator Units
EN DQ
Settlement Calculations
Dispatch Quantity for Generator Units
EN DQIU
Interconnector Unit
EN SMP System Marginal Price Participant
EN NIJ Net Inter-jurisdictional Import Participant
CA EA Eligible Availability Generator Units
CA NDLF Loss Adjusted Net Demand
Loss- Adjusted Net Demand for Jurisdictional Error Supplier Unit
CA NDLFESU
Jurisdictional Error Supplier Unit – JESU

Variable Used in reference to:

Market Description
Types
Ex-Post Capacity Payment Participant
CA VCPWF
Weighting Factor
Fixed Capacity Payment Participant
CA FCPWF
Weighting Factor
Ex-Ante Variable Capacity Participant
CA EAVWF
Payment Weighting Factor
CA ALLP Ex-Ante Loss of Load Probability Participant
CA LLP Ex-Post Loss of Load Probability Participant
CA CPDP Capacity Payment Demand Price Participant
CA Capacity Payment Generation Participant
CPGP
Price
CA Ex-Ante Payment Generation Participant
ECPGP
Price
CA FCGP Fixed Payment Generation Price Participant
CA Ex-Post Payment Generation Participant
VCPGP
Price
FMO FMOP Fixed Market Operator Price Participant
MO VMOP Variable Market Operator Price Participant
MO NDLF Loss Adjusted Net Demand
Loss-Adjusted Net Demand for Jurisdictional Error Supplier Unit
MO NDLFESU
Jurisdictional Error Supplier Unit - JESU
Table 40: Settlement Reports – Variable Type Reference
Note: This field refers to the Variable Type field in the Detail section of the Participant Information
Report (PIR).
4. Market Name for Invoice

This table provides a list of the different values that could be recorded in the “Market_name” field in
the invoice.
Market name Description

Energy Market Energy settlement
Capacity Market Capacity settlement
Variable Market Operator Variable Market Operator charge
Charge settlement
Fixed Market Operator charge
Fixed Market Operator Charge
settlement
Table 41: Settlement Reports – Variable Type Reference

6.2.3. Settlement Report (successful and unsuccessful) Request samples
• When a Market Participant requests a settlements file (Statement, Report, or Invoice), they will
receive back a single response from the SEM Central Market Systems. This result message that
can be either:
o The file itself, returned in the specified response file.
o An “error” message when the request is invalid, returned in the specified response
file. The error message will be one of:
§ Requested file not found - {0}.
§ Invalid filename - {0}.
§ XML request is not well-formed.
§ There was an error processing the request.
§ Invalid request type, must be one of STMT, INVC, RPT, DIRL or FILE
where {0} indicates the appropriate file name, typically ending in csv or xml.
• By default the Sample Market Participant Client Toolkit will also return a Digital Signature
xml file generated locally.
• In the following pages result messages are provided based on different cases covering both
successful and unsuccessful examples.
6.2.3.1. Case 1: Directory Listing
A Market Participant requests a Directory Listing (DIRL) (which provides a listing of the files
available for access for a given date) and receives the Directory Listing as the response.
Request message:

<directory date="2007-11-01">
</directory>
Sample XML 16: DIRL – Request

Result message:
<?xml version=”1.0” encoding=”UTF-8”?>

<file name=”CAPEXG_F_MKTPAR_2006-10-31.csv”/>
<file name=”CAPEXG_F_MKTPAR_2006-10-31(1).csv”/>
<file name=”ENGEXG_P_MKTPAR_2006-10-31.csv”/>
<file name=”ENGEXG_P_MKTPAR_2006-10-31(1).csv”/>
<file name=”MOEXG_P_MKTPAR_2006-10-31(1).csv”/>
<file name=”MOEXG_P_MKTPAR_2006-10-31(2).csv”/>
<file name=”FMOEXG_P_MKTPAR_2006-10-31.csv”/>
<file name=”CA_PIR_MKTPAR_P_2006-10-31.csv”/>
<file name=”EN_PIR_MKTPAR_P_2006-10-31.csv”/>
<file name=”INV_1079_MKTPAR_P_2006-10-31.csv”/>
<file name=”INV_1080_MKTPAR_P_2006-10-31.csv”/>
<file name=”EN_MFR_P_2007-11-01.csv”/>
<file name=”EN_MIR_P_2007-11-01.csv”/>
<file name=”EN_MGR_P_2007-11-01.csv”/>
<file name=”CA_MFR_P_2007-11-01.csv”/>
<file name=”CA_MIR_P_2007-11-01.csv”/><directory_file_list>
Sample XML 17: Directory Listing (DIRL) – Successful response
Note 1: The three settlement file types are included above:

• Invoices – prefixed by INV_
• Statements – prefixed by Market Segment abbreviation (ENGEXG_ for Energy, CAPEXG_
for Capacity, MOEXG_ for Market Operator Charges, or FMOEXG_ for Fixed Market
Operator Charges)
• Reports – prefixed by Market abbreviation (EN_ for Energy or CA_ for Capacity)
Note 2: Invoices are available by Invoice Date, Statements and Reports by Settlement Day.
For an empty directory, the response would be:

</directory_file_list>
Sample XML 18: Directory Listing (DIRL) – Empty Directory

6.2.3.2. Case 2a: Specific File
A Market Participant requests a specific Settlements File (FILE) by filename and receives the
specified file as the response. (The Market Participant would obtain the exact filename using the
DIRL request as above in Case 1.)
Request message:

<file name="EN_PIR_MKTPAR_P_2006-10-31.csv" date="2006-10-31">
</file>
Sample XML 19: Specific Settlement File (FILE) – Request
Result message:
H,001,AIP,2007-03-16 08:44:53,287,MKTPAR,P,2006-10-31
S,EN,INTP1,100,1,P,2007-03-02 16:08:42
S,EN,INTP2,101,1,P,2007-03-05 10:18:29
S,EN,INTP3,104,3,P,2007-03-05 11:57:45
S,EN,FMOC,119,2,P,2007-03-09 13:57:12
D,2006-10-
31,10,30,,MG,MG_SampleGen1,SampleGen1,Location1,,MWh,9.6,9.6
D,2006-10-
D,2006-10-31,10,30,,MG,MG_SampleGen2,SampleGen2,,,MWh,33.25,33.25
D,2006-10-
31,10,30,,MSQ,MSQ_SampleGen1,SampleGen1,Location1,,MW,18,18
D,2006-10-
D,2006-10-31,10,30,,MSQ,MSQ_SampleGen2,SampleGen2,,,MW,70,70
D,2006-10-31,10,30,,DQ,DQ_SampleGen1,SampleGen1,Location1,,MW,20,20
D,2006-10-31,10,30,,DQ,DQ_SampleGen2,SampleGen2,,,MW,70,70
…
Sample 20: Specific Settlement File (FILE) – Successful Response
The actual file is returned as the response, but only the start of the file is included above for
illustration.
Note: When requesting a Report file the response file specified in build.xml should specify .csv in
the filename. The same file extension should be used when requesting a Statement, whereas .xml
should be used when requesting an Invoice.

6.2.3.3. Case 2b: Specific File – File Not Found
A Market Participant requests a specific Settlements File (FILE) by filename and receives a
response indicating that no settlements files match the filename specified.
Request message:
<file name="EN_PIR_MKTPAR_P_2006-12-31.csv" date="2006-10-31">
</file>
Sample XML 21: Specific Settlement File (FILE) – Request
Result message:
Requested file not found - EN_PIR_MKTPAR_P_2006-12-31.csv
Sample 22: Specific Settlement File (FILE) – File not found
6.2.3.4. Case 3a: Invoice Request
A Market Participant requests an Invoice (INVC) and receives the Invoice file as the response.
Request message:

</invoice>
Sample XML 23: Invoice (INVC) – Request

Result message:
<?xml version="1.0" encoding="utf-8"?>

<InvoiceSet xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://tempuri.org/InvoiceSet.xsd">
<InvoiceElement>
<Invoice_number>1079</Invoice_number>
<Sender_addr1>DUBLIN</Sender_addr1>
<Sender_addr2>DUBLIN, DUBLIN</Sender_addr2>
<Sender_tel>+35 111 1111</Sender_tel>
<Sender_taxid>AIPSEM</Sender_taxid>
<Receiver_name>MKTPAR</Receiver_name>
<Receiver_addr1>DUBLIN</Receiver_addr1>
<Receiver_addr2>DUBLIN, DUBLIN</Receiver_addr2>
<Receiver_gl_number>MKTPAR</Receiver_gl_number>
<Invoice_type>2</Invoice_type>
<Due_date>2007-03-16</Due_date>
<Inv_heading>Final invoice for Oct 2006</Inv_heading>
<Signature1>appstl</Signature1>
<Unit>EUR</Unit>
<Invoice_date>2007-03-13</Invoice_date>
<Invoice_calendar_id>233</Invoice_calendar_id>
<Invoice_amount>5025994.46</Invoice_amount>
<Market_name>Capacity Market</Market_name>
<Bill_period_name>Oct 2006</Bill_period_name>
<Receiver_id>MKTPAR</Receiver_id>
<First_amount>-5025994.46</First_amount>
<Body>
<Invoice_number>1079</Invoice_number>
<Bill_heading>Charges for period Oct 2006</Bill_heading>
…
Sample XML 24: Invoice (INVC) – Successful response
illustration.
Note: The invoice number will need to be determined by doing a DIRL request.

6.2.3.5. Case 3b: Invoice Request – File Not Found
A Market Participant requests an Invoice (INVC) and receives a response indicating that no
Invoices match the request.
Request message:

</invoice>
Sample XML 25: Invoice (INVC) – Request
Result message:
Requested file not found - INV_1079_MKTPAR_2007-03-14.xml
Sample 26: Invoice (INVC) – File not found
6.2.3.6. Case 4a: Report Request
A Market Participant requests a Report (RPT) and receives the Report file as the response.
Request message:

<report market="EN" report="PIR" type="INDICATIVE" date="2006-10-
31">
</report>
Sample XML 27: Report (RPT) – Request

Result message:
H,001,AIP,2007-03-16 08:44:53,287,MKTPAR,P,2006-10-31
S,EN,INTP1,100,1,P,2007-03-02 16:08:42
S,EN,INTP2,101,1,P,2007-03-05 10:18:29
S,EN,INTP3,104,3,P,2007-03-05 11:57:45
S,EN,FMOC,119,2,P,2007-03-09 13:57:12
D,2006-10-
D,2006-10-
D,2006-10-
D,2006-10-
…
Sample 28: Report (RPT) – Successful response
illustration.
6.2.3.7. Case 4b: Report Request – File Not Found
A Market Participant requests a Report (RPT) and receives a response indicating that no Reports
match the request.
Request message:

<report market="EN" report="PIR" type="INITIAL" date="2006-10-31">
</report>
Sample XML 29: Report (RPT) – Request
Result message:
Requested file not found - EN_PIR_MKTPAR_F_2006-10-31.csv
Sample 30: Report (RPT) – File not found

6.2.3.8. Case 5a: Statement Request
A Market Participant requests a Statement (STMT) and receives the Statement file as the response.
Request message:
<statement segment="ENGEXG" type="INDICATIVE" date="2006-10-31"/>
Sample XML 31: Statement (STMT) – Request
Result message:
H,007,AIP,2007-03-09 15:58:57,112,MKTPAR,178,P,EN,ENGEXG108,2,2007-03-06
11:12:14,2006-10-31
S,ENPEX,Energy Payment ,2006-10-31,P,0.0000,MWh,12191.2000,/
S,TCHAREX,Testing Charge for Generator Unit Exchanged ,2006-10-
31,P,0.0000,MWh,0.0000,/
S,UNIMarket ParticipantEX,Uninstructed Imbalance Payment Exchanged,2006-10-
31,C,0.0000,MWh,-1577.7600,/
S,CONPEX,Constraint Payments Exchanged,2006-10-31,P,0.0000,MWh,365.4000,/
D,ENPEX,176,P,2006-10-31,10,00,30,,,SampleGen1,Location1,,,,00000,MWh,639.4500,/
D,TCHAREX,177,P,2006-10-31,10,00,30,,,SampleGen1,Location1,,,,00000,MWh,0.0000,/
D,UNIMarket ParticipantEX,207,C,2006-10-
31,10,00,30,,,SampleGen1,Location1,,,,00000,MWh,-179.4321,/
D,CONPEX,216,P,2006-10-31,0,00,30,,,SampleGen1,Location1,,,,00000,MWh,0.0000,/
…
Sample 32: Statement (STMT) – Successful response
illustration.
6.2.3.9. Case 5b: Statement Request – File Not Found
A Market Participant requests a Statement (STMT) and receives a response indicating that no
Statements match the request.
Request message:

<statement segment="ENGEXG" type="INITIAL" date="2006-10-31"/>
Sample XML 33: Statement (STMT) – Request

Result message:
Requested file not found - ENGEXG_F_MKTPAR_2006-10-31.csv
Sample 34: Statement (STMT) – File not found
6.3. General Public Settlement Publications
6.3.1. Description
There are 5 General Public Settlement Publication file types available:
• Energy Market Financial Publication (MFR);

• Energy Market Information Publication (MIR);
• Capacity Market Financial Publication (MFR);
• Capacity Market Information Publication (MIR);
• Metered Generation Information Publication (MGR).
Each of these Publications is available for both Indicative and Initial settlement runs (i.e. 10 separate
files are available).
6.3.2. Publication Timing
The following table details the publication time, file type and frequency for each of the publication.
Publication Name Publication Time File Type Frequency

Energy Market Financial
Settlement Day + Two working day by 17:00 .csv Daily
Publication – Indicative
Energy Market Financial Settlement Day + Five Working days, as
.csv Daily
Publication – Initial updated, at 17:00 the day of recalculation
Energy Market Information Settlement Day + Two Working Day by .csv Daily
Publication - Indicative 17:00
Energy Market Information Settlement Day + Five Working Days by .csv Daily
Publication - Initial 17:00
Meter Generation Information Settlement Day + Two Working Day by .csv Daily
Publication - Indicative 17:00
Meter Generation Information Settlement Day + Five Working Days by .csv Daily
Publication - Initial 17:00
Capacity Market Financial Capacity Period + Three Working days at Collection Monthly
Publication - Indicative 17:00 of daily
.csv

Publication Name Publication Time File Type Frequency

Capacity Market Financial Capacity Period + Seven Working days at Collection Monthly
Publication - Initial 12:00 of daily
.csv
Capacity Market Information Capacity Period + Three Working days at Collection Monthly
Publication - Indicative 17:00 of daily
.csv
Capacity Market Information Capacity Period + Seven Working days at Collection Monthly
Publication - Initial 12:00 of daily
.csv
Table 42: Publication Timing – File Type – Frequency
6.3.3. Settlement Publications vs. Variables
The File Layout is to take two general formats, as set out in the File Layout section (6.3.4). Within
each of the general file types (Indicative and Initial), the Market determines the Variables (fully defined
in the Reference Table used by the Settlement Publications section (6.3.5)) that are included in that
Settlement Publication. A summary of the different Variables included in each Settlement Publication is
listed in the table below.
Publication Name Variable Variable description

Indicative Energy Market Financial Publication ENPEX Energy Payment for Generator
Units (exchanged to Market
Initial Energy Market Financial Publication Participant currency)
ENPIUEX Energy Payment to Interconnector
Participant currency)
CONPEX Constraint Payment for Generator
CONPIUEX Constraint Payment to
Interconnector Units (exchanged to
Market Participant currency)
Indicative Energy Market Information Publication TOLOGLF Loss-Adjusted Tolerance for Over
Generation
Initial Energy Market Information Publication TOLUGLF Loss-Adjusted Tolerance for Under
Generation
DOPEX Dispatch Offer Price for Generator
DOPIUEX Dispatch Offer Price for
DOP_UEX Dispatch Offer Price for Price
Taker Generator Units for the
Uninstructed Imbalance Payments
(exchanged to Market Participant
currency)
Indicative Meter Generation Information MG Metered Generation for Generator
Publication Units
MGIU Metered Generation for
Initial Meter Generation Information Publication Interconnector Units

Publication Name Variable Variable description

MGEU Metered Generation for
Interconnector Error Units
NIJ Net Inter-Jurisdictional Import
Aggregate Jurisdictional Metered
JMGLF Generation, Loss Adjusted, for
Generator Units
Aggregate Jurisdictional Metered
JMDLF Demand, Loss Adjusted, for
Supplier Units.
Indicative Capacity Market Financial Publication CPEX Capacity Payment for Generator
Initial Capacity Market Financial Publication Participant currency)
CPIUEX Capacity Payment for
CPEIUEX Capacity Payments for
(exchanged to Market Participant
currency)
Indicative Capacity Market Information Publication EAVWF Ex-ante Variable Capacity
Payments Weighting Factor
Initial Capacity Market Information Publication VCPWF Ex-post Variable Capacity
Payments Weighting Factor
MARGIN Ex-Post Margin
LLP Ex-Post Loss of Load Probability
(Φh)
EA Eligible Availability for Generator
Units
EAIU Eligible Availability for
Interconnector Units
Eligible Availability for
EAEU
Aggregate Loss-Adjusted Net
TNDLF
Demand for all Supplier Units
Table 43: Publication List – Variables Reference
6.3.4. Reference Tables used by the Settlement Publications
The Variables refer to the Variable field in the Detail Records of the Settlement Publications.
Unit of
Market Variable Variable Description
Measurement
Capacity Payment for Generator Units EUR or GBP
CA CPEX
Capacity Payment for Interconnector Units EUR or GBP
CA CPIUEX
Capacity Payments for Interconnector Error EUR or GBP
CA CPIEUEX Units (exchanged to Market Participant
currency)
CA EA Eligible Availability MW
CA EAIU Eligible Availability for Interconnector Units MW
Eligible Availability for Interconnector Error MW
CA EAEU
Units
CA MARGIN Ex-Post Margin MW

Unit of
Market Variable Variable Description
Measurement
Ex-ante Variable Capacity Payments Weighting Decimal
CA EAVWF
Factor
Ex-post Variable Capacity Payments Weighting Decimal
CA VCPWF
Factor
CA LLP Ex-Post Loss of Load Probability (Φh) Decimal
Aggregate Loss-Adjusted Net Demand for all MWh
CA TNDLF
Supplier Units
Energy Payment for Generator Units EUR or GBP
EN ENPEX
Energy Payment to Interconnector Units EUR or GBP
EN ENPIUEX
Constraint Payment for Generator Units EUR or GBP
EN CONPEX
Constraint Payment to Interconnector Units EUR or GBP
EN CONPIUEX
Dispatch Offer Price for Generator Units EUR/MWh or
EN DOPEX
(exchanged to Market Participant currency) GBP/MWh
Dispatch Offer Price for Interconnector Units EUR/MWh or
EN DOPIUEX
(exchanged to Market Participant currency) GBP/MWh
Dispatch Offer Price for Price Taker Generator EUR/MWh or
EN DOP_UEX Units for the Uninstructed Imbalance Payments GBP/MWh
EN MG Metered Generation for Generator Units MWh
EN MGIU Metered Generation for Interconnector Units MWh
Metered Generation for Interconnector Error MWh
EN MGEU
Units
EN NIJ Net Inter-Jurisdictional Import MWh
EN TOLOGLF Loss-Adjusted Tolerance for Over Generation MW
EN TOLUGLF Loss-Adjusted Tolerance for Under Generation MW
Aggregate Jurisdictional Metered Generation, MWh
EN JMGLF
Loss Adjusted, for Generator Units
Aggregate Jurisdictional Metered Demand, Loss MWh
EN JMDLF
Adjusted, for Supplier Units.
Table 44: Settlement Publications – Variables Reference
6.3.5. File layout
The file layout is generic across the five Settlement Publication file types.
It is as follows:
• Header Record;
• Detail Records;
• Trailer Record.
a. Header Record

1 Record Type Indicates the type of record. {‘H’} Char(1) H


2 Version The version number that Char(3) 001
defines the file layout
This version is 001.
created. Military time. DD 21:05:14
HH:MM:SS
4 Type Status Type for the data. It ‘P’. ‘F’ Char(1) P
indicates whether the
Publication is based on
Indicative (P) or Initial (F).
5 Settlement Day The Settlement Day for the YYYY-MM- Date 2007-10-18
Publication DD
That is the main date the
energy was delivered and
consumed.
Table 45: General Public Settlement Publications – Header Record
b. Detail Records

1 Record Type Indicates the type of record. ‘D’ Char(1) D
2 Delivery Day Date the energy was YYY-MM- Date 2007-10-18
delivered and consumed. DD
3 Delivery Hour Hour the energy was HH24 Number(2) 13
delivered and consumed
If an hour does not have any
values there will be no record
for this hour.
4 Resolution Time resolution gives 30 Number(2) 30
information on the length of
the interval (30 minutes).
5 Variable type The short name of the Char(24) MG
variable type code that is
reported.
6 Variable name A name uniquely identifying Char(156) MG_UNIT1

the values.
7 Resource The unique identifier for the Char(100) √ UNIT1
Market Participant’s
resource/unit
The would be null (blank)
when the variable type is for
a non-resource.
8 Jurisdiction The unique identifier for the ‘ROI’ , ‘NI’ Char(100) √ ROI
jurisdiction
The would be null (blank)
when the variable type is for
a non-resource.
9 Unit of Unit for the variable type. ‘MWh’, Char(18) MWh
Measurement ‘MW’


10 Value1 Variable value for the first Positive and Number(28,8 65.00
interval for the hour in Field negative )
3 numbers
Minus sign us used in if
needed.
11 Value2 Variable value for the second Positive and Number(28,8 65.00
interval for the hour in Field negative )
3. numbers
Table 46: General Public Settlement Publications – Details Records
c. Trailer Record

1 Record Type Indicates the type of record. ‘T’ Char(1) T
2 Record count Number of records contained Number 20
in the file including the
header and trailer records.
Table 47: General Public Settlement Publications – Trailer Record
6.3.6. Type-Specific Data Entry Procedure
6.3.6.1. Energy Market Financial Publication
1. File Type
The File will be a .csv, which can be retrieved through the Type 3 communication channel using the
following XML:

<file name="EN_MFR_P_2007-11-01.csv" date="2007-11-01">
</file>

The file is named as follows:
“Market”_MFR_”Type”_”Settlement Date”.csv
Where:
• “Market” – Market abbreviation
• “Type” – Settlement type code
e.g.: EN_MFR_P_2007-11-01.csv
6.3.6.2. Energy Market Information Publication

1. File Type
following XML:

<file name="EN_MIR_P_2007-11-01.csv" date="2007-11-01">
</file>

“Market”_MIR_”Type”_”Settlement Date”.csv
Where:
e.g.: EN_MIR_P_2007-11-01.csv
6.3.6.3. Meter Generation Information Publication
1. File Type
The file will be in a .csv format, which can be retrieved through the Type 3 communication channel

<file name="EN_MGR_P_2007-11-01.csv" date="2007-11-01">
</file>

“Market”_MGR_”Type”_”Settlement Date”.csv
Where:
e.g.: EN_MGR_P_2007-11-01.csv
6.3.6.4. Capacity Market Financial Publication
1. File Type
following XML:


<file name="CA_MFR_P_2007-11-01.csv" date="2007-11-01">
</file>

“Market”_MFR_”Type”_”Settlement Date”.csv
Where:
e.g.: CA_MFR_P_2007-11-01.csv
6.3.6.5. Capacity Market Information Publication
1. File Type
following XML:

<file name="CA_MIR_P_2007-11-01.csv" date="2007-11-01">
</file>

“Market”_MIR_”Type”_”Settlement Date”.csv
Where:
e.g.: CA_MIR_P_2007-11-01.csv

7. Other Standard Reports

7.1. Description
This list includes the timing of the publication, the periodicity, the name and header information, and
the detailed content of the report.
Also covered in this section are Ad-hoc reports – from a Report List or Report request perspective
only.
Report Request XML Submission

Market Participant
- Report List or Report Data
- List Reports or
- Error and/or Information Messages
- Report
1 2 4
3
Market Operator
Check Validation
and Rules
Adherance
- XML Format
- Security
- Content
- Quality
Figure 10: Market Report Request Data Processing Overview
packaged, in terms of SOAP, WSDL, etc. are covered in the Market Participant Interfaces
User Guide and the Market Participant Web Services Client Toolkit ).
• Stage 2: A Report or a List of Reports can be requested and will typically be validated on the
client (Market Participant) system to ensure compliance with the XML Schema rules.
checks, including business rules, are applied – see section 7.3.
• Stage 4: If the Stage 3 tests are passed then the Report or List of Reports is issued to the
Market Participant as an XML response. If the request is unsuccessful, a response is issued
detailing the errors.
• Market Participant Users may choose to get a List of Reports first, and then request a specific
report.

• If sufficient parameters are used as part of a List Report request, a single report can be
searched for. This may be used by Market Participants to determine if a report is available.
• Report data can be returned in either XML or HTML format.
• Note: Annual Reports are downloadable in .zip file. Only a single report or list report Request
can be contained in a Transaction.
7.3. Message Validation and Sample XML
In the sections below, the validations applicable to each message type and some sample XML are
detailed.
Note: The reference number below (e.g. RP-n) provides a link to the data mapping details in
Appendix A.
7.3.1. Report and List Reports Requests

Mandatory /
No Name Validation
Optional
Generic Parameters
RP-1 APPLICATION_TYPE Mandatory • Must be “MARKET_REPORT”.
• Must be STRING.
RP-2 PARTICIPANT_NAME Mandatory • Must be validation combination with USER_NAME.
• Must have system privileges to allow Market Trading.
• Must be STRING.
RP-3 USER_NAME Mandatory • Must be validation combination with PARTICIPANT_NAME.
• User must have system privileges for Market Trading.
RP-4 MODE Mandatory • Must be NORMAL.
List Report/Report Parameters
RP-5 REQUEST_TYPE Mandatory • “LIST REPORTS” or “REPORT”.
RP-6 ACTION Mandatory • Must be “DOWNLOAD”.
• Valid REPORT_TYPE (mandatory) and REPORT_SUB_TYPE
RP-7 REPORT_TYPE Mandatory combinations:
APPLICATION – ADHOC
APPLICATION – NOTIFICATIONS
MARKET – ADHOC*
MARKET – DAY_AHEAD
MARKET – DAY_AHEAD_STANDING_OPEN
MARKET – DAY_AHEAD_STANDING_CLOSE
Mandatory for MARKET – MISCELLANEOUS
request_type MARKET - METERING
"REPORT" REGISTRATION – ADHOC*
RP-8 REPORT_SUB_TYPE REGISTRATION – MP_ACTIVITY
Optional for TRANS_SYSTEM – ADHOC*
request_type TRANS_SYSTEM –FORECASTS
"LIST_REPORTS" TRANS_SYSTEM – INTERCONNECTOR
TRANS_SYSTEM – MISCELLANEOUS
TRANS_SYSTEM – METERING
TRANS_SYSTEM – OUTAGES
• * see periodicity below

Valid PERIODICITY:
• DAILY
• MONTHLY
RP-9 PERIODICITY Mandatory • YEARLY
• ADHOC*
If report_sub_type = "ADHOC", then periodicity should also be
"ADHOC".
• MP (MP Specific reports);
RP-10 ACCESS_CLASS Optional • ALLMP (All MP specific reports);
• PUB (Public reports).
RP-11 VERSION_NO Mandatory • Must be “1.0”.
RP-12 TRADE_DATE Optional • YYYY-MM-DD

Mandatory /
No Name Validation
Optional
• For Daily market reports, the entire date is used. For monthly and
yearly, month and year are extracted from the trade date,
respectively.
Report Specific Parameters (Mandatory for Reports)
RP-13 FILE_TYPE Mandatory • “XML” or “HTML” – The format of the report to be downloaded.
RP-14 REPORT_NAME Mandatory • Must be STRING.
RP-15 FILE_NAME Mandatory • Must be STRING.
RP-16 MULTIPLE_MESSAGES Mandatory • Must be "false".
Table 48: Validation rules
7.3.2. Report Type / Report Sub-Type per Report

MPUD
Report Report Name Periodicity Report Type Report Sub-Type
No
List of Active Market Participants
1 Daily REGISTRATION MP_ACTIVITY
(PUBLIC)
List of Suspended/Terminated Market
Participants (PUBLIC)
4 Annual Load Forecast Annual TRANS_SYSTEM FORECASTS
Monthly Load Forecast and Assumptions
11 Monthly TRANS_SYSTEM FORECASTS
(PUBLIC)
Monthly Updates to Settlement Classes
13 Monthly REGISTRATION MP_ACTIVITY
(PUBLIC)
Monthly Loss of Load Probability Forecast
14 Monthly TRANS_SYSTEM FORECASTS
(PUBLIC)
16 Daily Interconnector ATC Data (PUBLIC) Daily TRANS_SYSTEM INTERCONNECTOR
Daily Trading Day Exchange Rate
17 Daily MARKET MISCELLANEOUS
(PUBLIC)
Daily Four Day Rolling Load Forecast and
18 Daily TRANS_SYSTEM FORECASTS
Assumptions (PUBLIC)
19 Daily Load Forecast Summary (PUBLIC) Daily TRANS_SYSTEM FORECASTS
Daily Rolling Wind Forecast and
Assumptions (PUBLIC)
Daily Ex-Ante Market Schedule Summary
23 Daily MARKET DAY_AHEAD
(D-1) (PUBLIC)
Daily Ex-Ante Market Schedule Detail (D-
1) (MP)
Daily Dispatch Instructions (D+1)
(PUBLIC)
Daily Indicative Ex-Post Market Schedule
Summary (D+1) (PUBLIC)
Detail (D+1) (MP)
Daily Initial Ex-Post Market Schedule
Summary (D+4) (PUBLIC)
Details (D+4) (MP)
Daily Market Prices Averages (SMP)
(PUBLIC)
Daily Indicative Ex-Post Market Prices
(PUBLIC)
Daily Initial Ex-Post Market Prices
(PUBLIC)
Daily Meter Data Summary (D+1)
35 Daily MARKET METERING
(PUBLIC)
36 Daily Meter Data Detail (D+1) (MP) Daily MARKET METERING
Daily Meter Data Summary (D+3)
(PUBLIC)
38 Daily Meter Data Detail (D+3) (MP) Daily MARKET METERING
Daily Market Operations Notifications
40 Daily APPLICATION NOTIFICATIONS
(PUBLIC)
41 Daily Actual Load Summary (PUBLIC) Daily MARKET DAY_AHEAD
Daily Ex-Ante Interconnector Nominations
46 Daily TRANS_SYSTEM INTERCONNECTOR
(D-1) (MP)
Daily Ex-Post Indicative Interconnector
Nominations (D+1) (MP)
48 Daily Ex-Post Initial Interconnector Daily TRANS_SYSTEM INTERCONNECTOR

MPUD
Report Report Name Periodicity Report Type Report Sub-Type
No
Nominations (D+4) (MP)
Daily Interconnector Modified
Nominations (MP)
Daily Revised Interconnector Modified
Nominations (MP)
List of Active Market Participants and
Units (PUBLIC)
Daily Interconnector Capacity Active
Holdings
Daily Revised Interconnector ATC Data
(PUBLIC)
59 Daily SO System Frequency (PUBLIC) Daily TRANS_SYSTEM MISCELLANEOUS
Indicative Interconnector Flows and
Residual Capacity (PUBLIC)
Initial Interconnector Flows and Residual
Capacity (PUBLIC)
63 List of Active Units (PUBLIC) Daily REGISTRATION MP_ACTIVITY
64 Daily Indicative Actual Schedules (MP) Daily MARKET DAY_AHEAD
65 Monthly Aggregated Load Forecast Monthly TRANS_SYSTEM FORECASTS
Daily Aggregated Four Day Rolling Load
Forecast
Two Day Aggregated Rolling Wind Power
Forecast
Daily Revised Interconnector Modified
Nominations (D+4)
69 Daily Within Day Actual Schedules Daily MARKET DAY_AHEAD
Daily Technical Offer Data – Standard
Units
Daily technical Offer Data – Demand Side
Units
Daily Technical Offer Data – Forecast
Data
Daily Commercial Offer Data – Standard
Generator Unit
Daily Commercial Offer Data – Standard
Demand Side Unit
Daily Commercial Offer Data –
Interconnector Unit
Daily Commercial Data – Generator Unit
Nomination Profiles
Daily Commercial Data – Demand Side
Unit Nomination Profiles
78 Daily Demand Control Data Transaction Daily MARKET DAY_AHEAD
Daily revised Modified Interconnector Unit
Nominations
80 Ex-Ante Indicative Market Schedule Daily MARKET DAY_AHEAD
81 Ex-Ante Indicative Operations Schedule Daily MARKET DAY_AHEAD
Daily Generator Unit Technical
Characteristics Data Transaction
Daily Energy Limited Generator Unit
Technical Characteristics Data Transaction
84 Daily SO Interconnector Trades Daily TRANS_SYSTEM INTERCONNECTOR
85 Price-affecting Metered Data Daily MARKET METERING
Quantity
Quantity
Daily Interconnector Capacity Active
Holdings (PUBLIC)
89 Forecast Ex-Post Loss Of Load Probability Daily TRANS_SYSTEM FORECASTS
90 Ex-Ante Indicative Shadow Prices Daily MARKET DAY_AHEAD
91 Ex-Post Indicative Shadow Prices Daily MARKET DAY_AHEAD
92 Ex-Post Initial Shadow Prices Daily MARKET DAY_AHEAD
Daily Jurisdiction Error Supply MW
(D15)
Table 49: Report Type and Report Sub-Type Combination

7.3.3. Sample XML
• When a Market Participant requests a report, they will receive a single response from the SEM
Central Market Systems. This result message that can be either:
o the report itself; or
o an xml “error” message when the request is invalid.
• Processing statistics details are not applicable for reports, however it is possible to request a
report that contains processing statistics (refer to case 2a).
• By default, the Sample Market Participant Client Toolkit will also return a Digital Signature
xml file generated locally.
• Two examples are presented below – one each for List Reports and retrieval of an individual
Report, with samples for both successful and unsuccessful requests.
7.3.4. Case 1a: List Reports
• A Market Participant requests the list of reports available and receives back the name and type
of the reports available (in this case two).
Request message:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <file_exchange
xsi:noNamespaceSchemaLocation="mi_file_exchange_sem.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <market_report application_type="MARKET_REPORT"
participant_name="MKTPAR" user_name="MKTPAR01" mode="NORMAL">
<report_request action="DOWNLOAD" request_type="LIST_REPORTS"
report_type="MARKET" report_sub_type="DAY_AHEAD_STANDING_OPEN"
periodicity="DAILY" trade_date="2007-04-03"
multiple_messages="false" version_no="1.0" />
</market_report>
</file_exchange>

Result message:

- <file_exchange
username="MKTPAR01@MKTPAR">
<messages />
- <market_report application_type="MARKET_REPORT" mode="NORMAL"
participant_name="MKTPAR" user_name="MKTPAR01">
- <messages>
<information>Successfully processed:
application_type=MARKET_REPORT.</information>
</messages>
- <report_request periodicity="DAILY"
report_sub_type="DAY_AHEAD_STANDING_OPEN" report_type="MARKET"
trade_date="2007-04-03" action="DOWNLOAD"
multiple_messages="false" request_type="LIST_REPORTS"
valid="true" version_no="1.0">
- <messages>
<information>Successfully processed: action=DOWNLOAD and
request_type=LIST_REPORTS.</information>
<information>Number of files which matched the request:
2.</information>
</messages>
- <report_response>
<report_item access_class="MP" file_name="Market
Participant_D_StndConv_GENOFF_all.xml" file_type="XML"
periodicity="DAILY" report_name="Market Participant_D_StndConv"
trade_date="2007-04-03" binary_file="false" description="Daily
Standing conversion Results at Market Open" expiry_date="2007-
07-02" file_size="44348" />
<report_item access_class="MP" file_name="Market
Participant_D_StndConv_TRDSITEDATA_all.xml" file_type="XML"
trade_date="2007-04-03" binary_file="false" description="Daily
Standing conversion Results at Market Open" expiry_date="2007-
07-02" file_size="1904" />
</report_response>
</report_request>
</market_report>
</file_exchange>

7.3.5. Case 1b: List Reports – None Available
A Market Participant requests the list of reports available and receives back a message that there is
no report available.
Request message:
- <file_exchange
<report_request action="DOWNLOAD" request_type="LIST_REPORTS"
report_type="REGISTRATION" report_sub_type="ADHOC"
periodicity="ADHOC" trade_date="2007-03-05"
multiple_messages="false" version_no="1.0" />
</market_report>
</file_exchange>
Result message:
- <file_exchange
<messages />
- <messages>
<warning>No files matched the request:
application_type=MARKET_REPORT.</warning>
</messages>
- <report_request periodicity="ADHOC" report_sub_type="ADHOC"
report_type="REGISTRATION" trade_date="2007-03-05"
action="DOWNLOAD" multiple_messages="false"
request_type="LIST_REPORTS" valid="true" version_no="1.0">
- <messages>
<warning>No files matched the request: action=DOWNLOAD and
request_type=LIST_REPORTS.</warning>
<warning>Number of files which matched the request: 0.</warning>
</messages>
<report_response />
</report_request>
</market_report>
</file_exchange>

7.3.6. Case 2a: Report Request
A Market Participant requests a specific xml report and receives back the associated report.
Request message:
- <file_exchange
<report_request request_type="REPORT" action="DOWNLOAD"
access_class="MP" file_type="XML" periodicity="DAILY"
report_name="Market Participant_D_StndConv" file_name="Market
Participant_D_StndConv_TRDSITEDATA_all.xml" report_type="MARKET"
trade_date="2007-04-03" multiple_messages="false"
version_no="1.0" />
</market_report>
</file_exchange>

Result message:

- <bids_offers username="MKTPAR01@MKTPAR" valid="true"
xsi:noNamespaceSchemaLocation="mint_sem.xsd"
<processing_statistics invalid="2" received="3" successful="1"
time_ms="141" time_stamp="Mon Mar 05 09:35:15 GMT 2007"
transaction_id="KR259ZE3" unsuccessful="2" valid="1"
xml_time_stamp="2007-03-05T09:35:15.097+00:00" />
- <market_submit application_type="DAM" delivery_date="2007-04-03"
mode="NORMAL" participant_name="MKTPAR" process="true"
trading_date="2007-04-03" user_name="MKTPAR01" valid="true"
standing_conversion="true">
- <sem_trading_site_data standing_flag="false" success="true"
valid="true" version_no="1.0"
trading_site_name="SampleTradingSite1">
- <messages>
<information>Successfully processed the SEM Trading Site
Data.</information>
</messages>
<shared_energy_limit_detail active_flag="true" limit_factor="0.25"
limit_mwh="20.2" />
</sem_trading_site_data>
- <sem_trading_site_data standing_flag="false" success="false"
valid="false" version_no="1.0"
trading_site_name="SampleTradingSite1111">
- <messages>
<error>Invalid trading_site_name SampleTradingSite1111</error>
</messages>
limit_mwh="20.2" />
- <sem_trading_site_data standing_flag="false" success="false"
valid="false" version_no="1.0" trading_site_name="
SampleTradingSite2222">
- <messages>
<error>Invalid trading_site_name SampleTradingSite2222</error>
</messages>
<identifier external_id="TESTING ALL" />
limit_mwh="160.0" />
</market_submit>
</bids_offers>
Note: This is a report of a failed standing bid conversion. The processing statistics information is
from that conversion, not the report request. The report is flagging that three trading sites are found
for the relevant Market Participant, but the trading site name is invalid for the other two.

7.3.7. Case 2b: Report Request – No File Available
A Market Participant requests a specific xml report and receives back that the report requested is
not available.
Request message:

- <file_exchange
<report_request request_type="REPORT" action="DOWNLOAD"
access_class="MP" file_type="XML" periodicity="DAILY"
report_name="Market Participant_D_StndConv"
file_name="Non_Existing_Report.xml" report_type="MARKET"
trade_date="2007-04-03" multiple_messages="false"
version_no="1.0" />
</market_report>
</file_exchange>
Result message:

- <file_exchange
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
<messages />
- <messages>
<warning>No files matched the request:
application_type=MARKET_REPORT.</warning>
</messages>
- <report_request access_class="MP"
file_name="Non_Existing_Report.xml" file_type="XML"
report_type="MARKET" trade_date="2007-04-03" action="DOWNLOAD"
multiple_messages="false" request_type="REPORT" valid="true"
version_no="1.0">
- <messages>
<warning>No files matched the request: action=DOWNLOAD and
request_type=REPORT.</warning>
<warning>Number of files which matched the request: 0.</warning>
</messages>
<report_response />
</report_request>
</market_report>
</file_exchange>

7.3.8. Guide to Market System Report Definitions
Each Market System Report Definition contains the following detail:

• No: Reference Number;
• Name: Report Name;
• Format;
o The format types referenced in this document are as follows:
Format Description Example
CHAR(x) Character field of maximum length x. CHAR(4) = ‘ROI’ or ‘NI’

Number field:
• x : number of values to the left of the decimal.
• y : number of values to the right of the decimal.
Where no values to the right of the decimal point exist, NUMBER(8,3) = ‘99999999.999’
NUMBER(x, y) there will be no y value in the format definition. When
Note: This is not the standard Oracle definition
there is no values available for the field in the MO
database, the reports will populate the field with '-'. As
such, this is not a NUMBER value in the true database
sense, and interfaces to handle report downloads should be
written to cater for this.
Date, format defined in parenthesis.
When there is no values available for the DATE field in the

DATE
MO database, the reports will populate the field with '-'. As 31/01/2007
(DD/MM/YYYY)
such, this is not a DATE value in the true database sense,
and interfaces to handle report downloads should be written
to cater for this.
Date and Time, format utilising a 24-hour clock.
DATE When there is no values available for the DATE field in the
(DD/MM/YYYY MO database, the reports will populate the field with '-'. As 31/01/2007 19:59:50
HH:MM:SS) such, this is not a DATE value in the true database sense,
and interfaces to handle report downloads should be written
to cater for this.
Table 50: Market Reports – Format Types
• Period;
• Timing;
• Confidentiality.
Confidentiality Description
A Public Market System Report is defined to be accessible to all
Market Participants on the Market Participant Interface. Note that
General Public
the REPORT_NAME in each REPORT_HEADER will start with
the prefix PUB.
Member Private is defined to be confidential and accessible only on
Member Private
an individual Market Participant basis.
Table 51: Market Reports – Confidentiality Definitions
• A row containing the elements nested within the HEADROW element of the XML Output. The
element REPORT_NAME nested within the HEADROW element of the XML Output is used
when retrieving the file in a Web Services request. The filename will have the extension .xml or
.html, as required by the Market Participant.
• Subsequent rows containing the elements nested within the DATAROW element of the XML
Output. Data formats and descriptions are provided each of these elements accordingly.

32 Daily Market Prices Averages (SMP) XML/HTML Daily On Demand General Public
<REPORT_NAME>PUB_D_MarketPricesAverages</REPORT_NAME>
<TITLE>Daily Market Prices Averages (SMP) (PUBLIC)</TITLE>
<RPT_DATE>DD/MM/YYYY HH:MM:SS</RPT_DATE>
<TRADE_DATE>YYYYMMDD</TRADE_DATE>
A 24-hour period containing forty eight 30-minute trading
periods, except on the clock change days in spring and
DATE
32.1 TRADE_DATE autumn when the Trading Day will last for 23 and 25 hours
(DD/MM/YYYY)
respectively. The first trading period of the trading day
commences at 06:00hrs
DATE Calendar Day (referred to "Day" in the Trading and
32.2 DELIVERY_DATE
(DD/MM/YYYY) Settlement Code).
Run Type:
• EA - Ex-Ante;
32.3 RUN_TYPE CHAR(4) • EP1 - Ex-Post Run1;
• EP2 - Ex-Post Run2.
32.4 SMP_AVERAGE NUMBER(8,2) Average SMP for the day.
32.5 CURRENCY_FLAG CHAR(1) Euro (E) or Sterling Pound (P).
Table 52: Example Market Report Definition – Market Prices Averages

7.4. Report and Content Details
The information below covers details of the reports being produced and the contents of those reports.
“Note: The use of the term 'General Public' in the reports listing below relates reports that are made available via the MPI for the 'Member Public', i.e.
Market Participants as distinct from those reports that would be classified as ‘General Public’ and made available on the SMO Website.”
No Name (or Report Field Name) Format Period Timing Confidentiality

As updated (within two days of a
1 List of Active Market Participants XML/HTML As required
successful application)
General Public
<REPORT_NAME>PUB_ActiveMPs</REPORT_NAME>
<TITLE>List of Active Market Participants (PUBLIC)</TITLE>
Participant Short Name, which represents the name of Market Participant, as registered in the SEM
1.1 PARTICIPANT_NAME CHAR(12)
Central Market Systems.
1.2 ORGANISATION_NAME CHAR(50) Organisation Name.
1.3 START_DATE DATE (DD/MM/YYYY) Start date for activity of participant.
1.4 END_DATE DATE (DD/MM/YYYY) End date for activity of participant.
As updated (at least within two days

3 List of Suspended/Terminated Market Participants XML/HTML As required
of issue)
General Public
<REPORT_NAME>PUB_SupsTermMPs</REPORT_NAME>
<TITLE>List of Suspended/Terminated Market Participants (PUBLIC)</TITLE>

Request Type Values:
3.3 REQUEST_TYPE CHAR(10) • TERMINATED;
• SUSPENDED.
3.4 EFF_DATE DATE (DD/MM/YYYY) Effective date.


XML/HTML
4 Annual Load Forecast (.zip file when request for Annual Four Months before Start of Year General Public
XML report)
<REPORT_NAME>PUB_A_LoadFcst</REPORT_NAME>
<TITLE>Annual Load Forecast (PUBLIC)</TITLE>
A 24-hour period containing forty eight 30-minute trading periods, except on the clock change days
4.1 TRADE_DATE DATE (DD/MM/YYYY) in spring and autumn when the Trading Day will last for 23 and 25 hours respectively
The first trading period of the trading day commences at 06:00hrs.
4.2 JURISDICTION CHAR(4) Republic of Ireland (ROI) or Northern Ireland (NI) as appropriate.
4.3 DELIVERY_DATE DATE (DD/MM/YYYY) Calendar Day (referred to "Day" in the Trading and Settlement Code).
4.4 DELIVERY_HOUR NUMBER(2) The hour of the day, based on the end of hour convention.
Will be 1 or 2, to split an hour into two equal Trading Periods (i.e. 1 denotes the first half-hour and 2
4.5 DELIVERY_INTERVAL NUMBER(2)
denotes the second half-hour).
4.6 LOAD_FORECAST NUMBER(8,3) Load Forecast value per Jurisdiction, as generated by the TSO.
4.7 ASSUMPTIONS CHAR(128) Assumptions behind the creation of those forecasts..
XML/HTML At least one working day before start

11 Monthly Load Forecast & Assumptions Monthly
of Month – By 10:00
General Public
<REPORT_NAME>PUB_M_LoadFcstAssumptions</REPORT_NAME>
<TITLE>Monthly Load Forecast and Assumptions (PUBLIC)</TITLE>
Will be 1 or 2, to split an hour into two equal Trading Periods (i.e. 1 denotes the first half-hour the
first half-hour and 2 denotes the second half-hour).
11.6 FORECAST_MW NUMBER(8,3) Load Forecast value per Jurisdiction, as generated by the TSO.

11.7 ASSUMPTIONS CHAR(128) Assumptions behind the creation of those forecasts.
XML/HTML At least one Working Day before

13 Monthly Updates to Settlement Class Monthly
start of Month – At 10:00
General Public
<REPORT_NAME>PUB_M_SttlClassesUpdates</REPORT_NAME>
<TITLE>Monthly Updates to Settlement Classes (PUBLIC)</TITLE>
The name of the resource in question (e.g. the name of the Generating Unit, Supplier Unit, Demand
13.2 RESOURCE_NAME CHAR(32)
Side Unit, Interconnector Unit or Interconnector for which data is being reported).
Indicates the type of resource for which data is being submitted - for example, this will indicate if a
13.3 RESOURCE_TYPE CHAR(4) resource is predictable or variable and whether it is a price taker or price maker. Permitted values
are: PPMG, PPTG, VPMG, VPTG, APTG, DU, SU and I.
13.4 EFFECTIVE_DATE DATE (DD/MM/YYYY) Effective Settlement Class change date.
13.5 EXPIRATION_DATE DATE (DD/MM/YYYY) Expiration of Settlement Class date.


XML/HTML At least five Working Days before
14 Monthly Loss of Load Probability Forecast Monthly
start of Month – By 10:00
General Public
<REPORT_NAME>PUB_M_LossLoadProbabilityFcst</REPORT_NAME>
<TITLE>Monthly Loss of Load Probability Forecast (PUBLIC)</TITLE>
14.5 LOSS_OF_LOAD_PROBABILITY NUMBER(6,5) Forecast of Loss of Load Probability for each Trading Period in the forthcoming 31 Trading Days.
16 Daily Interconnector ATC XML/HTML Daily Day prior to Gate Closure - By 10:00 General Public
<REPORT_NAME>PUB_D_IntconnATCData</REPORT_NAME>
<TITLE>Daily Interconnector ATC Data (PUBLIC)</TITLE>
16.3 DELIVERY_DATE DATE (DD/MM/YYYY) Calendar Day (referred to "Day" in the Trading and Settlement Code)
16.6 MAXIMUM_IMPORT_MW NUMBER(8,3) Maximum Interconnector Import MW.
16.7 MAXIMUM_EXPORT_MW NUMBER(8,3) Maximum Interconnector Export MW.


Day prior Trading Day - Prior Gate
17 Daily Trading Day Exchange Rate XML/HTML Daily
Closure - By 08:00
General Public
<REPORT_NAME>PUB_D_ExchangeRate</REPORT_NAME>
<TITLE>Daily Trading Day Exchange Rate (PUBLIC)</TITLE>
The currency to which the Exchange Rate will be applied to calculate the monetary value in another
currency:
17.2 FROM_CURRENCY CHAR(1)
• E – Euro;
• P – Pound.
The currency in which the Exchange Rate calculation will generate a monetary value:
17.3 TO_CURRENCY CHAR(1) • E – Euro;
• P – Pound.
The Trading Day Exchange Rate is the exchange rate between the FROM_CURRENCY and the
17.4 EXCHANGE_RATE NUMBER(4,4)
TO_CURRENCY. For the SEM, the only available currencies are Sterling (P) and Euro (E).
18 Daily Four Day Rolling Load Forecast and Assumptions XML/HTML Daily
Closure - By 09:30
General Public
<REPORT_NAME>PUB_D_LoadFcstAssumptions</REPORT_NAME>
<TITLE>Daily Four Day Rolling Load Forecast and Assumptions (PUBLIC)</TITLE>
18.6 FORECAST_MW NUMBER(8,3) Load Forecast value per Jurisdiction, as generated by the TSO.


19 Daily Load Forecast Summary XML/HTML Daily
Closure – By 09:30
General Public
<REPORT_NAME>PUB_D_LoadFcstSummary</REPORT_NAME>
<TITLE>Daily Load Forecast Summary (PUBLIC)</TITLE>
19.6 FORECAST_MW NUMBER(8,3) Load Forecast value, as generated by the TSO.
19.8 NET_LOAD_FORECAST NUMBER(8,3) Forecast value of the load excluding the amount served by wind units.
In advance of Gate Closure, as

21 Rolling Wind Forecast and Assumptions (Two-Day) XML/HTML Daily
Available, every 6 hours
General Public
<REPORT_NAME>PUB_D_RollingWindFcstAssumptions</REPORT_NAME>
<TITLE> Daily Rolling Wind Forecast and Assumptions (PUBLIC)</TITLE>


21.8 FORECAST_MW NUMBER(8,3) Load Forecast value, as generated by the TSO
Post Gate Closure - prior Trading

23 Ex-Ante Market Schedule Summary XML/HTML Daily
Day - At 13:00
General Public
<REPORT_NAME>PUB_D_ExAnteMktSchSummary</REPORT_NAME>
<TITLE>Daily Ex-Ante Market Schedule Summary (D-1) (PUBLIC)</TITLE>
23.5 AGGREGATED_MSQ NUMBER(8,3) Aggregate Market Schedule Quantity
23.6 SMP NUMBER(8,2) System Marginal Price.
Post Gate Closure - Prior Trading

24 Ex-Ante Market Schedule by Market Participant XML/HTML Daily
Day - At 13:00
Member Private
<REPORT_NAME>MP_D_ExAnteMktSchDetail</REPORT_NAME>
<TITLE>Daily Ex-Ante Market Schedule Detail (D-1) (MP)</TITLE>
<PARTICIPANT_NAME>PARTNAME</PARTICIPANT_NAME>
Side Unit, Interconnector for which data is being reported).
include: PPMG, PPTG, VPMG, VPTG, APTG, DU, SU and I.

24.7 MSQ NUMBER(8,3) Aggregate Market Schedule Quantity.
24.8 SMP NUMBER(8,2) Aggregate System Marginal Price.
27 Daily Dispatch Instructions XML/HTML Daily Day after Trading Day - By 16:00 General Public
<REPORT_NAME>PUB_D_DispatchInstructions</REPORT_NAME>
<TITLE>Daily Dispatch Instructions (D+1) (PUBLIC)</TITLE>
DATE (DD/MM/YYYY
27.1 INSTRUCTION_TIMESTAMP Dispatch Instruction effective time stamp.
HH24:MI:SS)
An instruction (MW) given by the System Operator to the Generator or the Generator's approved
27.4 DISPATCH_INSTRUCTION NUMBER(8,3) representative for the scheduling of a generating unit or for changes to the output manner of
operation of a Generation Unit in accordance with the Grid Code.
Instruction Code, denoting instructions such as MWOF and SYNC given to Generating Units and
27.5 INSTRUCTION_CODE CHAR(4)
Demand Side Units.
27.6 INSTRUCTION_COMBINATION_CODE CHAR(4) Instruction Combination Code.
DATE (DD/MM/YYYY
27.7 INSTRUCTION_ISSUE_TIME Instruction Issue Time (the time at which the instruction was issued).
HH24:MI:SS)
27.8 RAMP_UP_RATE NUMBER(8,3) Ramp Up Rate (used in NI only to limit ramping for operational reasons)
27.9 RAMP_DOWN_RATE NUMBER(8,3) Ramp Down Rate (used in NI only to limit ramping for operational reasons).

28 Daily Indicative Ex-Post Market Schedule Summary XML/HTML Daily Day after Trading Day - By 16:00 General Public
<REPORT_NAME>PUB_D_ExPostMktSchSummary</REPORT_NAME>
<TITLE>Daily Indicative Ex-Post Market Schedule Summary (D+1) (PUBLIC)</TITLE>
28.5 AGGREGATED_MSQ NUMBER(8,3) Aggregate Market Schedule Quantity.
Daily Indicative Ex-Post Market Schedule by Market

29 XML/HTML Daily Day after Trading Day - By 16:00 Member Private
Participant
<REPORT_NAME>MP_D_ExPostMktSchDetail</REPORT_NAME>
<TITLE>Daily Indicative Ex-Post Market Schedule Detail (D+1) (MP)</TITLE>

29.7 SCHEDULE_QUANTITY NUMBER(8,3) Market Schedule Quantity.
29.10 MAXIMUM_AVAILABILITY NUMBER(11,3) Maximum Availability MW.
29.11 MINIMUM_GENERATION NUMBER(11,3) Minimum Generation MW.
29.12 MINIMUM_OUTPUT NUMBER(11,3) Minimum Output.
29.13 ACTUAL_AVAILABILITY NUMBER(11,3) Actual Availability MW.
Four Days after Trading Day - By

30 Daily Initial Ex-Post Market Schedule Summary XML/HTML Daily
16:00
General Public
<REPORT_NAME>PUB_D_InitialExPostMktSchSummary</REPORT_NAME>
<TITLE>Daily Initial Ex-Post Market Schedule Summary (D+4) (PUBLIC)</TITLE>
30.5 AGGREGATED_MSQ NUMBER(8,3) Aggregate Market Schedule Quantity.
30.6 INITIAL_SMP NUMBER(8,2) Aggregate System Marginal Price.


31 Daily Initial Ex-Post Market Schedule by Market Participant XML/HTML Daily
16:00
Member Private
<REPORT_NAME>MP_D_InitialExPostMktSchDetail</REPORT_NAME>
<TITLE>Daily Initial Ex-Post Market Schedule Details (D+4) (MP)</TITLE>
31.3 RESOURCE_TYPE CHAR(4) resource is predictable or variable and whether it is a price taker or price maker Permitted values
31.8 INITIAL_SMP NUMBER(8,2) System Marginal Price.
31.13 ACTUAL_AVAILABILITY NUMBER(8,3) Actual Availability MW.

32 Daily Market Prices Averages (SMP) XML/HTML Daily Day after Trading Day - By 16:00 General Public
32.2 SMP_AVERAGE NUMBER(8,2) Average SMP for the day.

Run Type:
• EA - Ex-Ante;
Daily Post Trading

33 Daily Indicative Ex-Post Market Prices XML/HTML
Day
Day after Trading Day - By 16:00 General Public
<REPORT_NAME>PUB_D_IndicativeMarketPrices</REPORT_NAME>
<TITLE>Daily Indicative Ex-Post Market Prices (PUBLIC)</TITLE>


34 Daily Initial Ex-Post Market Prices XML/HTML Daily
16:00
General Public
<REPORT_NAME>PUB_D_InitialMarketPrices</REPORT_NAME>
<TITLE>Daily Initial Ex-Post Market Prices (PUBLIC)</TITLE>
35 Daily Meter Data Summary D+1 (Price Effecting) XML/HTML Daily Day after Trading Day - By 15:00 General Public
<REPORT_NAME>PUB_D_MeterDataSummaryD1</REPORT_NAME>
<TITLE>Daily Meter Data Summary (D+1) (PUBLIC)</TITLE>
35.4 TOTAL_GENERATION NUMBER(8,3) Total Generation for Price Effecting Generation.
35.5 TOTAL_LOAD NUMBER(8,3) Total Demand for Price Effecting Demand.

36 Daily Meter Data Detail D+1 (Price Effecting) XML/HTML Daily Day after Trading Day - By 17:00 Member Private
<REPORT_NAME>MP_D_MeterDataDetailD1</REPORT_NAME>
<TITLE>Daily Meter Data Detail (D+1) (MP)</TITLE>
include: PPMG, PPTG, VPMG, VPTG, DU, SU and I.
Metered MW represents the total generation when the resource type is PPMG, PPTG, VPMG, and
36.8 METERED_MW NUMBER(8,3)
APTG. Metered MW represents the total load when the resource type is DU and SU.
Transmission Type:
• PED – Price Effecting Demand;
• PEG – Price Effecting Generation;
36.9 METER_TRANSMISSION_TYPE CHAR(4)
• NPED – Non-Price Effecting Demand;
• NPEG – Non-Price Effecting Generation.
CJF – Cross-Jurisdictional Power Flow.


Three Days after Trading Day - By
37 Daily Meter Data Summary D+3 (Price Effecting) XML/HTML Daily
17:00
General Public
<REPORT_NAME>PUB_D_MeterDataSummaryD3</REPORT_NAME>
<TITLE>Daily Meter Data Summary (D+3) (PUBLIC)</TITLE>
<RPT_DATE>DD/MM/YY HH:MM:SS</RPT_DATE>
37.5 TOTAL_GENERATION NUMBER(8,3) Total Generation for Price Effecting Generation.
37.6 TOTAL_LOAD NUMBER(8,3) Total Demand for Price Effecting Demand.
Three Days after Trading Day - By

38 Daily Meter Data Detail D+3 (Price Effecting) XML/HTML Daily
17:00
Member Private
<REPORT_NAME>MP_D_MeterDataDetailD3</REPORT_NAME>
<TITLE>Daily Meter Data Detail (D+3) (MP)</TITLE>
include: PPMG, PPTG, VPMG, VPTG, DU, SU and I.


38.8 METERED_MW NUMBER(8,3)
APTG. Metered MW represents the total load when the resource type is DU and SU.
Transmission Type:
• NPEG – Non-Price Effecting Generation;
• CJF – Cross-Jurisdictional Power Flow.
40 Daily Market Operations Notifications XML/HTML Daily Daily, within day and ad-hoc General Public
<REPORT_NAME>PUB_D_AdvInfo</REPORT_NAME>
<TITLE>Daily Market Operations Notifications (PUBLIC)</TITLE>
DATE (DD/MM/YYYY
40.1 ISSUE_DATE Notification Issue time stamp.
HH24:MI:SS)
Central Market Systems. (Always “ALL”.)
40.3 SEVERITY CHAR(1) Issue priority.
40.4 MESSAGE CHAR(252) Issue content.
41 Daily Actual Load Summary XML/HTML Daily Day after Trading Day - By 17:00, General Public
<REPORT_NAME>PUB_D_ActualLoadSummary</REPORT_NAME>
<TITLE>Daily Actual Load Summary (PUBLIC)</TITLE>
Run Type:

41.7 ACTUAL_LOAD_MW NUMBER(8,3) Actual Load in MW.

46 Daily Ex-Ante Interconnector Nominations XML/HTML Daily
Day - By 11:00
Member Private
<REPORT_NAME>MP_D_ExAnteIntconnNominations</REPORT_NAME>
<TITLE>Daily Ex-Ante Interconnector Nominations (D-1) (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit as calculated by the Ex-Ante
46.6 UNIT_NOMINATION NUMBER(8,3)
Market Schedule.
47 Daily Ex-Post Indicative Interconnector Nominations XML/HTML Daily Day after Trading Day - By 16:00 Member Private
<REPORT_NAME>MP_D_ExPostIndIntconnNominations</REPORT_NAME>
<TITLE>Daily Ex-Post Indicative Interconnector Nominations (D+1) (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit as calculated by the Indicative
Ex-Post Market Schedule.


48 Daily Ex-Post Initial Interconnector Nominations XML/HTML Daily
16:00
Member Private
<REPORT_NAME>MP_D_ExPostInitIntconnNominations</REPORT_NAME>
<TITLE>Daily Ex-Post Initial Interconnector Nominations (D+4) (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit as calculated by the Initial Ex-
Post Market Schedule.
49 Daily Interconnector Modified Nominations XML/HTML Daily
Day - By 12;00,
Member Private
<REPORT_NAME>MP_D_IntconnModNominations</REPORT_NAME>
<TITLE>Daily Interconnector Modified Nominations (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit as provided by the
Interconnector Administrator (IA).


Day after Trading Day - By 16:00
50 Daily Revised Interconnector Modified Nominations XML/HTML Daily
(Updated as available)
Member Private
<REPORT_NAME>MP_D_RevIntconnModNominations</REPORT_NAME>
<TITLE>Daily Revised Interconnector Modified Nominations (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit, after output from Indicative
Market Schedule is verified against capacity allocations on the Interconnector.
As updated (within two days of a
53 List of Active Market Participants and Units XML/HTML As required
successful application)
General Public
<REPORT_NAME>PUB_ActiveMPUnits</REPORT_NAME>
<TITLE>List of Active Market Participants and Units (PUBLIC)</TITLE>
53.1 PARTICIPANT_NAME CHAR(12) Central Market Systems.
Resource Type Values:
• PPMG – Predictable Price Maker Generator Unit;
• PPTG – Predictable Price Taker Generator Unit;
• VPMG – Variable Price Maker Generator Unit;
53.5 RESOURCE_TYPE CHAR(4) • VPTG – Variable Price Taker Generator Unit;
• APTG – Autonomous Price Taker Generator Unit;
• SU – Supplier Unit;
• I – Interconnector;
• DU – Demand Unit.
53.6 EFFECTIVE_DATE DATE (DD/MM/YYYY) Effective date.

53.7 EXPIRATION_DATE DATE (DD/MM/YYYY) Expiration date.
Day prior Trading Day – Post Gate

54 Daily Interconnector Capacity Active Holdings XML/HTML Daily
Member Private
<REPORT_NAME>MP_D_IntconnCapActHoldResults</REPORT_NAME>
<TITLE>Daily Interconnector Capacity Active Holdings (MP)</TITLE>
Maximum Interconnector Export Capacity offered on the Interconnector Unit in each Trading Period
54.6 INTERCONNECTOR_EXPORT_CAPACITY NUMBER(8,3)
in the optimisation time horizon of the Indicative Market Schedule.
Maximum Interconnector Import Capacity offered on the Interconnector Unit in each Trading Period
54.7 INTERCONNECTOR_IMPORT_CAPACITY NUMBER(8,3)
58 Daily Revised Interconnector ATC Data XML/HTML Daily Day after Trading Day – By 15:00 General Public
<REPORT_NAME>PUB_D_RevIntconnATCData</REPORT_NAME>
<TITLE>Daily Revised Interconnector ATC Data (PUBLIC)</TITLE>

58.6 MAXIMUM_IMPORT_MW NUMBER(8,3) Maximum Interconnector Import MW.
58.7 MAXIMUM_EXPORT_MW NUMBER(8,3) Maximum Interconnector Export MW.
One Working Day after Trading Day

59 Daily SO System Frequency XML/HTML Trading Day
- By 17:00
General Public
<REPORT_NAME>PUB_D_SystemFrequency</REPORT_NAME>
<TITLE>Daily SO System Frequency (PUBLIC)</TITLE>
59.2 PARTICIPANT_NAME CHAR(12) Participant Short Name.
Nominal Frequency values in Hz per Trading Period utilised in the calculation of the tolerance bands
59.6 NORMAL_FREQUENCY NUMBER(8,3) for Over or Under Generation.
Published TD+1 at 14:00 hrs.
Average Frequency values in Hz per Trading Period utilised in the calculation of the tolerance bands
59.7 AVERAGE_FREQUENCY NUMBER(8,3) for Over or Under Generation.
Published TD+1 at 14:00 hrs.
60 Indicative Interconnector Flows and Residual Capacity XML/HTML Daily Day after Trading Day - By 16:00 General Public
<REPORT_NAME>PUB_IndicativeInterconnFlows</REPORT_NAME>
<TITLE>Indicative Interconnector Flows and Residual Capacity (PUBLIC)</TITLE>


60.6 NET_FLOW NUMBER(8,3) Metered MW for the Interconnector.
60.7 RESIDUAL_CAPACITY NUMBER(8,3) Difference between Scheduled and Actual Interconnector Flow.

61 Initial Interconnector Flows and Residual Capacity XML/HTML Daily
16:00
General Public
<REPORT_NAME>PUB_InitialInterconnFlows</REPORT_NAME>
<TITLE>Initial Interconnector Flows and Residual Capacity (PUBLIC)</TITLE>
61.6 NET_FLOW NUMBER(8,3) Metered MW for the Interconnector.
61.7 RESIDUAL_CAPACITY NUMBER(8,3) Difference between Scheduled and Actual Interconnector Flow.
63 List of Active Units XML/HTML As required As updated General Public
<REPORT_NAME>PUB_ActiveUnits</REPORT_NAME>
<TITLE>List of Active Units (PUBLIC)</TITLE>
63.4 EFFECTIVE _DATE DATE (DD/MM/YYYY) Effective date.

63.5 EXPIRATION_DATE DATE (DD/MM/YYYY) Expiration date.
Post Gate Closure – Prior Trading Day

64 Daily Indicative Actual Schedules (MP) XML/HTML Daily
– By 16:00 and 01:00
Member Private
<REPORT_NAME>MP_D_IndicativeActualSchedules</REPORT_NAME>
<TITLE>Daily Indicative Actual Schedules (MP) </TITLE>
64.6 DELIVERY_HOUR NUMBER(2) Trading hour (between 1 and 25).
64.7 DELIVERY_INTERVAL NUMBER(2) Trading interval (1 or 2).
64.8 SCHEDULE_MW NUMBER(8,3) Operation Schedule Quantity (MW values).
DATE (DD/MM/YYYY,
64.9 POST_TIME Time at which RCUC has generated the current Operation Schedule.
HH24:MI:SS)

XML/HTML One Working Day prior the beginning

65 Monthly Aggregated Load Forecast Monthly General Public
of the Month – By 10:00
<REPORT_NAME>PUB_M_AggLoadFcst</REPORT_NAME>
<TITLE>Monthly Aggregated Load Forecast (PUBLIC)</TITLE>
<RPT_DATE> DD/MM/YYYY HH:MM:SS </RPT_DATE>
65.5 FORECAST_MW NUMBER(8,3) Load Forecast value.

66 Daily Aggregated Four Day Rolling Load Forecast XML/HTML Daily General Public
<REPORT_NAME>PUB_D_AggLoadFcst</REPORT_NAME>
<TITLE>Daily Aggregated Four Day Rolling Load Forecast (PUBLIC)</TITLE>
<RPT_DATE>DD/MM/YYYY HH:MM:SS </RPT_DATE>
66.5 FORECAST_MW NUMBER(8,3) Load Forecast value.


67 Two Day Rolling Wind Forecast and Assumptions Per Jurisdiction XML/HTML Daily General Public
Closure – Every 6 hours
<REPORT_NAME>PUB_D_RollingWindFcstAssumptionsJurisdiction</REPORT_NAME>
<TITLE>Daily Rolling Wind Forecast and Assumptions Aggregated Per Jurisdiction (PUBLIC)</TITLE>
The demand forecast per Jurisdiction for each Trading Period in the next four Trading Days as
67.6 FORECAST_MW NUMBER(8,3)
forecast by the System Operators.


68 Daily Revised Interconnector Modified Nominations (D+4) XML/HTML Daily Member Private
16:00
<REPORT_NAME>MP_D_RevIntconnModNominationsD4</REPORT_NAME>
<TITLE>Daily Revised Interconnector Modified Nominations (D+4) (MP)</TITLE>
Quantity nominated for import or export for an Interconnector Unit as calculated by the Ex-Ante
Market Schedule.
Trading Day – Every 4 hours, from

69 Daily Within Day Actual Schedules XML/HTML Daily Member Private
08:00
<REPORT_NAME>MP_D_WithinDayActualSchedules</REPORT_NAME>
<TITLE>Daily Within Day Actual Schedules (MP)</TITLE>


Resource Type Values:
• PPMG – Predictable Price Maker Generator Unit;
• PPTG – Predictable Price Taker Generator Unit;
• VPMG – Variable Price Maker Generator Unit;
69.3 RESOURCE_TYPE CHAR(4) • VPTG – Variable Price Taker Generator Unit;
• APTG – Autonomous Price Taker Generator Unit;
• SU – Supplier Unit;
• I – Interconnector;
• DU – Demand Unit.
DATE (DD/MM/YYYY,
69.9 POST_TIME Time at which RCUC has generated the current Operation Schedule.
HH24:MI:SS)
70 Daily Technical Offer Data – Standard Units XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_TODStandardUnits</REPORT_NAME>
<TITLE> Daily Technical Offer Data – Standard Units (PUBLIC)</TITLE>
The name of the resource in question (e.g. the name of the Generating Unit for which data is being
reported).


Indicates the type of resource for which data is being submitted.
Values include: PPMG, PPTG, VPMG and VPTG.
PPMG = Predictable Price Maker Generator Unit (excluding DU);
PPTG = Predictable Price Taker Generator Unit;
70.3 RESOURCE_TYPE CHAR(4)
VPMG = Variable Price Maker Generator Unit;
VPTG = Variable Price Taker Generator Unit.
The report will exclude APTG = Autonomous Price Taker Generator Unit types as these types of
unit do not submit any Technical Offer Data as per the TSC v4.2 section C.14.
Value Description
OIL Oil
GAS Gas
COAL Coal
MULTI Multi Fuel
WIND Wind
70.5 FUEL_TYPE CHAR(5) HYDRO Hydro
BIO Biomass
CHP Combined Heat and Power
PUMP Pumped Storage
PEAT Peat
DISTL Distillage
NUCLR Nuclear
NA Not Applicable
70.6 PRIORITY_DISPATCH_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit has priority dispatch status.
70.7 PUMP_STORAGE_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit is a Pumped Storage Unit.
70.8 ENERGY_LIMIT_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit is an Energy Limited Unit.
‘Y’ for YES or ‘N’ for NO value generated based on whether the trading day in question is within
70.9 UNDER_TEST_YN CHAR(1)
the ‘UNDER_TEST_START_DATE’ and ‘UNDER_TEST_END_DATE’.
Firm Access Quantity for Site s in Trading Period h, represents lower bound on MSP Availability
70.10 FIRM_ACCESS_QUANTITY NUMBER(5,3) (the Capacity in MW, net of unit load, for Unit u, that has firm access (deep connection) to the
Transmission Network, as agreed between the Registrant and the System Operator.
Non-firm capacity for a Trading Site in MW, i.e. part of a Generator Unit's Availability that does not
70.11 NON_FIRM_ACC_QUANTITY NUMBER(5,3)
have Firm Access.
Capacity above MAXGEN that can be sustained for a finite period of time (MW). This represents
the ‘ST_MAX_CAP_MW’ value that is submitted.
70.12 SHORT_TERM_MAXIMISATION_CAP NUMBER(8,3)
Although the ‘ST_MAX_CAP_TIME’ is also available it is not required as a data value in this
publication.
Minimum Output of Generator Unit.
70.13 MINIMUM_GENERATION NUMBER(15,3)
The lowest value to which a unit can be scheduled.
70.14 MAXIMUM_GENERATION NUMBER(15,3) Registered Maximum Availability level in MW.
The minimum time that must elapse from the time a Generation Unit is instructed to Start-Up before
70.15 MINIMUM_ON_TIME NUMBER(15,3)
it can be instructed to Shut-Down.

The minimum time that a Generation Unit must remain producing no Active Power or Reactive
70.16 MINIMUM_OFF_TIME NUMBER(15,3)
Power commencing at the time when it first stops producing no Active Power or Reactive Power.
The maximum time that can elapse from the time a Generation Unit is instructed to Start-Up before
70.17 MAXIMUM_ON_TIME NUMBER(15,3)
it can be instructed to Shut-Down.
70.18 HOT_COOLING_BOUNDARY NUMBER(5,2) The duration in hours off load that indicates the standby status change of the unit from Hot to Warm.
The duration in hours off load that indicates the standby status change of the unit from Warm to
70.19 WARM_COOLING_BOUNDARY NUMBER(5,2)
Cold.
70.20 SYNCHRONOUS_START_UP_TIME_HOT NUMBER(5,2) Notification/Start-up times in hours for a unit considered to be in a hot state.
70.21 SYNCHRONOUS_START_UP_TIME_WARM NUMBER(5,2) Notification/Start-up times in hours for a unit considered to be in a warm state.
70.22 SYNCHRONOUS_START_UP_TIME_COLD NUMBER(5,2) Notification/Start-up times in hours for a unit considered to be in a cold state.
The case where a Generation Unit, when starting to generate energy onto the Transmission System,
produces a certain amount of output with no need to ramp up to that output during a Cold Start and
70.23 BLOCK_LOAD_COLD NUMBER(15,3)
which represents the amount that generators instantaneously put onto the system when Synchronised
during a Cold Start.
produces a certain amount of output with no need to ramp up to that output during a Hot Start and
70.24 BLOCK_LOAD_HOT NUMBER(15,3)
during a Hot Start.
produces a certain amount of output with no need to ramp up to that output during a Warm Start and
70.25 BLOCK_LOAD_WARM NUMBER(15,3)
during a Warm Start.
Loading Up Rate in MW/min when a Unit is in a cold state that applies until
LOADING_UP_BREAK_PT_COLD_1.
70.26 LOADING_RATE_COLD_1 NUMBER(15,3)
(One of the rates at which a Generation Unit increases Generation Unit Output from zero to
Minimum Generation when it is instructed to Cold Start).
Loading Up Rate in MW/min when a Unit is in a cold state that applies from
LOADING_UP_BREAK_PT_COLD_1 to LOADING_UP_BREAK_PT_COLD_2.
Loading Up Rate in MW/min when a Unit is in a cold state that applies above
LOADING_UP_BREAK_PT_COLD_2.
MW level from which the cold loading up rate will change from Loading Rate 1 to Loading Rate 2.
The break point which defines the shared MW boundary between two Loading Rates Cold.
The first Loading Rate Cold applies from 0 MW to the Load Up Break Point Cold 1, the second
70.29 LOAD_UP_BREAK_POINT_COLD_1 NUMBER(15,3)
Loading Rate Cold applies from the Load Up Break Point Cold 1 to the Load Up Break Point Cold 2
or it that is not provided, directly to the end point of the start-up period, which should be set equal to
the Minimum Generation.
MW level from which the cold loading up rate will change from Loading Rate 2 to Loading Rate 3.
The break point which defines the shared MW boundary between two Loading Rates Cold.
70.30 LOAD_UP_BREAK_POINT_COLD_2 NUMBER(15,3) The Loading Rate Cold 2 applies from the Load Up Break Point Cold 1 to the Load Up Break Point
Cold 2, and the Loading Rate Cold 3 applies from the Load Up Break Point Cold 2 to the end point
of the start-up period, which should be set equal to Minimum Generation.


Loading Up Rate in MW/min when a Unit is in a hot state that applies until
LOADING_UP_BREAK_PT_HOT_1.
70.31 LOADING_RATE_HOT_1 NUMBER(15,3)
Minimum Generation when it is instructed to Hot Start).
Loading Up Rate in MW/min when a Unit is in a hot state that applies from
LOADING_UP_BREAK_PT_HOT_1 to LOADING_UP_BREAK_PT_HOT_2.
Loading Up Rate in MW/min when a Unit is in a hot state that applies above
LOADING_UP_BREAK_PT_HOT_2.
MW level from which the hot loading up rate will change from Loading Rate 1 to Loading Rate 2.
The break point which defines the shared MW boundary between two Loading Rates Hot.
The first Loading Rate Hot applies from 0 MW to the Load Up Break Point Hot 1, the second
70.34 LOAD_UP_BREAK_POINT_HOT_1 NUMBER(15,3)
Loading Rate Hot applies from the Load Up Break Point Hot 1 to the Load Up Break Point Hot 2 or
it that is not provided, directly to the end point of the start-up period, which should be set equal to the
Minimum Generation.
MW level from which the hot loading up rate will change from Loading Rate 2 to Loading Rate 3.
The break point which defines the shared MW boundary between two Loading Rates Hot.
70.35 LOAD_UP_BREAK_POINT_HOT_2 NUMBER(15,3) The Loading Rate Hot 2 applies from the Load Up Break Point Hot 1 to the Load Up Break Point
Hot 2, and the Loading Rate Hot 3 applies from the Load Up Break Point Hot 2 to the end point of
the start-up period, which should be set equal to Minimum Generation.
Loading Up Rate in MW/min when a Unit is in a warm state that applies until
LOADING_UP_BREAK_PT_WARM_1.
70.36 LOADING_RATE_WARM_1 NUMBER(15,3)
Minimum Generation when it is instructed to Warm Start).
Loading Up Rate in MW/min when a Unit is in a warm state that applies from
LOADING_UP_BREAK_PT_WARM_1 to LOADING_UP_BREAK_PT_WARM_2.
Loading Up Rate in MW/min when a Unit is in a warm state that applies above
LOADING_UP_BREAK_PT_WARM_2.
MW level from which the warm loading up rate will change from Loading Rate 1 to Loading Rate 2.
The break point which defines the shared MW boundary between two Loading Rates Warm. The
first Loading Rate Warm applies from 0 MW to the Load Up Break Point Warm 1, the second
70.39 LOAD_UP_BREAK_POINT_WARM_1 NUMBER(15,3)
Loading Rate Warm applies from the Load Up Break Point Warm 1 to the Load Up Break Point
Warm 2 or it that is not provided, directly to the end point of the start-up period, which should be set
equal to the Minimum Generation.
MW level from which the warm loading up rate will change from Loading Rate 2 to Loading Rate 3.
The break point which defines the shared MW boundary between two Loading Rates Warm
70.40 LOAD_UP_BREAK_POINT_WARM_2 NUMBER(15,3) The Loading Rate Warm 2 applies from the Load Up Break Point Warm 1 to the Load Up Break
Point Warm 2, and the Loading Rate Warm 3 applies from the Load Up Break Point Warm 2 to the
end point of the start-up period, which should be set equal to Minimum Generation.
For each Soak Time Trigger Point Cold, Soak Time Cold is the duration at which the Generator
70.41 SOAK_TIME_COLD_1 NUMBER(5,2)
Unit must remain at that Soak Time Trigger Point Cold during a Cold Start.

70.42 SOAK_TIME_COLD_2 NUMBER(5,2)
70.43 SOAK_TIME_TRIGGER_POINT_COLD_1 NUMBER(15,3)
70.44 SOAK_TIME_TRIGGER_POINT_COLD_2 NUMBER(15,3)
For each Soak Time Trigger Point Hot, Soak Time Hot is the duration at which the Generator Unit
70.45 SOAK_TIME_HOT_1 NUMBER(5,2)
must remain at that Soak Time Trigger Point Hot during a Hot Start.
70.46 SOAK_TIME_HOT_2 NUMBER(5,2)
70.47 SOAK_TIME_TRIGGER_POINT_HOT_1 NUMBER(15,3)
70.48 SOAK_TIME_TRIGGER_POINT_HOT_2 NUMBER(15,3)
70.49 SOAK_TIME_WARM_1 NUMBER(5,2)
70.50 SOAK_TIME_WARM_2 NUMBER(5,2)
For each Soak Time Trigger Point Warm, Soak Time Warm is the duration at which the Generator
70.51 SOAK_TIME_TRIGGER_POINT_WARM_1 NUMBER(15,3)
Unit must remain at that Soak Time Trigger Point Warm during a Warm Start.
For each Soak Time Trigger Point Warm, Soak Time Warm is the duration at which the Generator
70.52 SOAK_TIME_TRIGGER_POINT_WARM_2 NUMBER(15,3)
Unit must remain at that Soak Time Trigger Point Warm during a Warm Start.
The Market Operator approval process will ensure that this is set to the registered Minimum Stable
70.53 END_POINT_OF_START_UP_PERIOD NUMBER(15,3)
Generation.
Ramp Up Rate in MW/min that applies until RAMP_UP_BREAK_PT_1

70.54 RAMP_UP_RATE_1 NUMBER(15,3)
The rate of increase in Active Power produced by a Generating Unit.
Ramp Up Rate in MW/min that applies from RAMP_UP_BREAK_PT_1 until

RAMP_UP_BREAK_PT_2.


RAMP_UP_BREAK_PT_3.

RAMP_UP_BREAK_PT_4.
70.58 RAMP_UP_RATE_5 NUMBER(15,3) Ramp Up Rate in MW/min that applies from RAMP_UP_BREAK_PT_4.
70.59 RAMP_UP_BREAK_POINT_1 NUMBER(15,3) MW level from which the ramp rate will change from Ramp Up Rate 1 to Ramp Up Rate 2.
Time (in minutes) above Minimum Stable Generation for which a Unit remains at a constant MW
level before continuing to increase or decrease output.
70.63 DWELL_TIME_1 NUMBER(5,2)
For each Dwell Time Trigger Point, Dwell Time is the duration at which the Generation Unit must
remain at that Dwell Time Trigger Point.
A constant MW level at which a Generation Unit must remain while ramping up or down between
70.66 DWELL_TIME_TRIGGER_POINT_1 NUMBER(15,3)
Minimum Generation and Maximum Generation.

70.69 RAMP_DOWN_RATE_1 NUMBER(15,3) Ramp Down Rate in MW/min that applies until RAMP_DOWN_BREAK_PT_1.
Ramp Down Rate in MW/min that applies from RAMP_DOWN_BREAK_PT_1 until

70.70 RAMP_DOWN_RATE_2 NUMBER(15,3)
RAMP_DOWN_BREAK_PT_2.


70.73 RAMP_DOWN_RATE_5 NUMBER(15,3) Ramp Down Rate in MW/min that applies from RAMP_DOWN_BREAK_PT_4.
70.74 RAMP_DOWN_BREAK_POINT_1 NUMBER(15,3) MW level from which the ramp rate will change from Ramp Down Rate 1 to Ramp Down Rate 2.
Deloading Rate in MW/min that applies for a Unit below Minimum Stable Generation until
70.78 DELOADING_RATE_1 NUMBER(15,3)
DELOAD_BREAK_PT.
Deloading Rate in MW/min that applies for a Unit below Minimum Stable Generation beyond
70.79 DELOADING_RATE_2 NUMBER(15,3)
DELOAD_BREAK_PT.
MW level from which the deloading rate will change from DELOADING_RATE_1 to
70.80 DELOAD_BREAK_POINT NUMBER(15,3)
DELOADING_RATE_2.
For Pumped Storage Units.

70.81 MAXIMUM_STORAGE_CAPACITY NUMBER(15,3)
Expressed in terms of generation (MWh) for each Pumped Storage Unit within the Trading Day.

70.82 MINIMUM_STORAGE_CAPACITY NUMBER(15,3)
Expressed in terms of generation (MWh) for each Pumped Storage Unit within the Trading Day.


70.83 PUMPING_LOAD_CAP NUMBER(15,3) The Pumping Capacity - Registered value, representing notional load consumed by unit during
pumping phase (MW).
The daily submitted value is called ‘TARGET_RESERVOIR_LEVEL_PERCENT’
70.84 TARGET_RESERVOIR_LEVEL_PERCENT NUMBER(5,2)
The value that should be provided in this publication is the value that is submitted on a daily basis by
participants.
For Energy Limited Units.
The daily submitted value is called ‘LIMIT_MWH’.
70.85 ENERGY_LIMIT_MWH NUMBER(8,3)
participants.
The maximum limit for the accumulated energy output for an Energy Limited Generator Unit u in
Trading Day t.
For Energy Limited Units.
The daily submitted value is called ‘LIMIT_FACTOR’.
The value for the ENERGY_LIMIT_FACTOR must be 0.25 in the systems as per the TSC v1.3
section 5.86C.
70.86 ENERGY_LIMIT_FACTOR NUMBER(4,3)
participants.
A factor between zero and one which will determine the amount of energy that can be generated
during the last six hours of the Optimisation Horizon.
70.87 FIXED_UNIT_LOAD NUMBER(15,3) Fixed linear factor used to calculate net output from a Generator Unit.
70.88 UNIT_LOAD_SCALAR NUMBER(5,4) Scalar quantity which approximates physical losses associated with a Generator Unit Transformer.
71 Daily Technical Offer Data – Demand Side Units XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_TODDemandSideUnits</REPORT_NAME>
<TITLE>Daily Technical Offer Data – Demand Side Units (PUBLIC)</TITLE>
The name of the resource in question (e.g. the name of the Demand Side Unit for which data is being
reported).

Value must be DU = Demand Side Unit (also a Predictable Price Maker Generator Unit).

71.5 FUEL_TYPE CHAR(3) Must be ‘DEM’ for Demand.
Ramp Up Rate in MW/min that applies for the Demand Side Unit.
71.7 MAXIMUM_RAMP_UP_RATE NUMBER(15,3)
The rate of increase in Active Power produced by a Demand Side Unit.
Ramp Down Rate in MW/min that applies for the Demand Side Unit.
71.8 MAXIMUM_RAMP_DOWN_RATE NUMBER(15,3)
The rate of increase in Active Power produced by a Demand Side Unit.
The minimum time that must elapse from the time a Demand Side Unit is instructed to reduce load
71.9 MINIMUM_DOWN_TIME NUMBER(15,3)
or Shut-Down before it must end it’s period of demand reduction.
The maximum time that can elapse from the time a Demand Side Unit is instructed to reduce load or
71.10 MAXIMUM_DOWN_TIME NUMBER(15,3)
Shut-Down before it must end it’s period of demand reduction.
72 Daily Technical Offer Data – Forecast Data XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_TODForecastData</REPORT_NAME>
<TITLE>Daily Technical Offer Data – Forecast Data (PUBLIC)</TITLE>
reported).
Values include: PPMG, PPTG, VPMG, VPTG and DU.
VPTG = Variable Price Taker Generator Unit;
DU = Demand Side Unit (also a Predictable Price Maker Generator Unit).
The publication will exclude APTG = Autonomous Price Taker Generator Unit types as these types
of unit do not submit any Technical Offer Data as per the T&SC v4.2 section C.14.

Forecast Availability Profile means the forecast of Availability in MW of Unit u in Trading Period h.
72.9 FORECAST_AVAILABILITY NUMBER(8,3) Forecast Availability for each Trading Period in the Optimisation Time Horizon.
This is used to set the upper output limit for Generating or Demand Side Units.
Forecast Minimum Stable Generation Profile means the forecast of Minimum Generation in MW of
Unit u in Trading Period h.
72.10 FORECAST_MINIMUM_STABLE_GEN NUMBER(8,3)
Forecast Minimum Stable Generation for each Trading Period in the Optimisation Time Horizon.
This is used to set the lower output limit for Generating or Demand Side Units.
Forecast Minimum Output Profile means the forecast of Minimum Output in MW of Unit u in
Trading Period h.
72.11 FORECAST_MINIMUM_OUTPUT NUMBER(8,3)
Forecast Minimum Output for each Trading Period in the Optimisation Time Horizon.
This is used to set the lower output limit for Pumped Storage Units.
73 Daily Commercial Offer Data – Standard Generator Unit XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_CODStandardGenUnits</REPORT_NAME>
<TITLE>Daily Commercial Offer Data – Standard Generator Units (PUBLIC)</TITLE>
The name of the resource in question (e.g. the name of the Generating Unit or Demand Side Unit for
which data is being reported).


APTG = Autonomous Price Taker Generator Unit;
of unit do not submit any Commercial Offer Data as per the T&SC v4.2 section C.5
Maybe
Value Description
OIL Oil
GAS Gas
COAL Coal
MULTI Multi Fuel
WIND Wind
73.5 FUEL_TYPE CHAR(5) HYDRO Hydro
BIO Biomass
CHP Combined Heat and Power
PUMP Pumped Storage
PEAT Peat
DISTL Distillage
NUCLR Nuclear
NA Not Applicable
73.6 PRIORITY_DISPATCH_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit has priority dispatch status.
73.7 PUMP_STORAGE_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit is a Pumped Storage Unit.
73.8 ENERGY_LIMIT_YN CHAR(1) ‘Y’ for YES or ‘N’ for NO value generated based on whether the unit is an Energy Limited Unit.
Price which is used to schedule units to meet the Generation Requirement in the market systems,
73.10 PRICE_1 NUMBER(8,2)
both in Ex-Ante and Ex-Post.
Quantity in MW to which the associated price will apply when considered by the SEM Central
73.11 QUANTITY_1 NUMBER(8,3)
Market Systems.
73.12 PRICE_2 NUMBER(8,2) both in Ex-Ante and Ex-Post.
This Price value is optional as PRICE_1 is the only mandatory value.
73.13 QUANTITY_2 NUMBER(8,3) Market Systems.
This Quantity value is optional as QUANTITY_1 is the only mandatory value.
73.14 PRICE_3 NUMBER(8,2) As PRICE_2.
73.15 QUANTITY_3 NUMBER(8,3) As QUANTITY_2.


Cost to start-up when in hot warmth state.
The cost of bringing a Generator Unit to a Synchronised state, from a Cold, Warm or Hot (non-
73.30 STARTUP_COST_HOT NUMBER(8,2)
synchronised) state.
Start Up Cost for Unit u for Trading Period h.
Cost to start-up when in warm warmth state.
73.31 STARTUP_COST_WARM NUMBER(8,2)
Start Up Cost for Unit u for Trading Period h.
Cost to start-up when in cold warmth state.
73.32 STARTUP_COST_COLD NUMBER(8,2)
Start Up Cost for Unit u for Trading Period h..
The element of Operating Cost, expressed in €/hour or £/hour, submitted as part of Commercial
73.33 NO_LOAD_COST NUMBER(8,2) Offer Data, that is invariant with the level of unit output and incurred at all times when the level of
output is greater than zero.
73.34 TARGET_RESV_LEVEL_MWH NUMBER(5,3)
Minimum Reservoir Level required at the end of the Trading Day.
The ratio between the gross electrical energy consumed to pump a given quantity of water from the
73.35 PUMP_STORAGE_CYC_EFY NUMBER(7,4)
lower reservoir to the upper reservoir and the net electrical energy sent out through the release of that
quantity of water from the upper reservoir to the lower reservoir through the turbine-generators.
74 Daily Commercial Offer Data – Standard Demand Side Unit XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_CODStandardDemUnits</REPORT_NAME>
<TITLE>Daily Commercial Offer Data – Standard Demand Side Units (PUBLIC)</TITLE>


74.3 RESOURCE_TYPE CHAR(4) VPTG = Variable Price Taker Generator Unit;
APTG = Autonomous Price Taker Generator Unit;
of unit do not submit any Commercial Offer Data as per the T&SC v4.2 section C.5
74.5 FUEL_TYPE CHAR(5) Must be ‘DEM’ for Demand.
Market Systems.
Market Systems.
Submitted for Demand Side Units only - this represents the cost for the Unit to reduce load as
74.27 SHUTDOWN_COST NUMBER(8,2) requested by the System Operator.
This can be thought of in the same way as a single start-up cost for Generating Units.

75 Daily Commercial Offer Data – Interconnector Units XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_CODInterconnectorUnits</REPORT_NAME>
<TITLE>Daily Commercial Offer Data – Interconnector Units (PUBLIC)</TITLE>
Value must be PPMG = Predictable Price Maker Generator Unit.
For clarity, Interconnector Units are not equal to Interconnectors.
Interconnector Units are owned by a participant and are considered to be price makers in the market.
Market Systems.
75.12 QUANTITY_2 NUMBER(8,3) Market Systems.
This Quantity value is optional as QUANTITY_1 is the only mandatory value.


Maximum import capacity submitted for an Interconnector Unit per Trading Period
75.29 MAXIMUM_IU_IMPORT_CAPACITY_MW NUMBER(8,3)
This is used to calculate the upper output limit for Interconnector Units.
Maximum export capacity submitted for an Interconnector Unit per Trading Period
75.30 MAXIMUM_IU_EXPORT_CAPACITY_MW NUMBER(8,3)
This is used to calculate the lower output limit for Interconnector Units.
76 Daily Commercial Data Generator Unit Nomination Profiles XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_CommercialOfferDataGenNomProfiles</REPORT_NAME>
<TITLE>Daily Commercial Data Generator Unit Nomination Profiles (PUBLIC)</TITLE>
reported).
of unit do not submit any Technical Offer Data as per the T&SC v4.2 section C.14
76.9 NOMINATED_QUANTITY NUMBER(8,3) Nomination Profile means the nominated profile in MW of Unit u in Trading Period h.
Submitted by MPs that are being treated as Price Takers, to account in settlements for the situation
76.10 DECREMENTAL_PRICE NUMBER(8,2)
where they are constrained down.

77 Daily Commercial Data Demand Side Unit Nomination Profiles XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_CommercialOfferDataDemNomProfiles</REPORT_NAME>
<TITLE>Daily Commercial Data Demand Side Unit Nomination Profiles (PUBLIC)</TITLE>
77.1 TRADE_DATE DATE (DD/MM/YYYY) in spring and autumn when the Trading Day will last for 23 and 25 hours respectively. The first
trading period of the trading day commences at 06:00hrs.
reported).
77.3 RESOURCE_TYPE CHAR(4) VPMG = Variable Price Maker Generator Unit;
DU = Demand Side Unit (also a Predictable Price Maker Generator Unit);
of unit do not submit any Technical Offer Data as per the T&SC v4.2 section C.14
77.9 NOMINATED_QUANTITY NUMBER(8,3) Nomination Profile means the nominated profile in MW of Unit u in Trading Period h.
Submitted by MPs that are being treated as Price Takers, to account in settlements for the situation
77.10 DECREMENTAL_PRICE NUMBER(8,2)
where they are constrained down.
78 Daily Demand Control Data Transaction XML/HTML Daily Day after Trading Day – By 14:00 General Public
<REPORT_NAME>PUB_D_DemandControlData</REPORT_NAME>
<TITLE>Daily Demand Control Data Transaction (PUBLIC)</TITLE>
78.4 DELIVERY_INTERVAL NUMBER(2) Will be 1 or 2, to split an hour into two equal Trading Periods (i.e. 1 denotes the first half-hour and 2


78.5 ESTIMATE_DEMAND_REDUCTION_MW NUMBER(8,3) Estimate of any reduction in demand as a consequence of Demand Control, i.e. Load Shedding.
79 Daily Revised Modified Interconnector Unit Nominations XML/HTML Daily Day after Trading Day – By 15:00 General Public
<REPORT_NAME>PUB_D_RevIntconnModNominations</REPORT_NAME>
<TITLE>Daily Revised Interconnector Modified Nominations (PUBLIC)</TITLE>
79.3 RESOURCE_NAME CHAR(32) Resource Name.
Quantity nominated for import or export for an Interconnector Unit, after output from Indicative
Market Schedule is verified against capacity allocations on the Interconnector.
80 Ex-Ante Indicative Market Schedule XML/HTML Daily Day after Trading Day – By 15:00 General Public
<REPORT_NAME>PUB_D_ExAnteMktSchDetail</REPORT_NAME>
<TITLE>Daily Ex-Ante Market Schedule Detail (PUBLIC)</TITLE>
Indicates the type of resource for which data is being submitted - for example this will indicate if a
80.4 RESOURCE_TYPE CHAR(4) resource is predictable or variable and whether it is a price taker or price maker
Permitted values include: PPMG, PPTG, VPMG, VPTG, APTG, DU, SU and I.
80.8 MSQ NUMBER(8,3) Market Schedule Quantity.

81 Ex-Ante Indicative Operations Schedule XML/HTML Daily Day after Trading Day – By 16:00 General Public
<REPORT_NAME>PUB_D_ExAnteIndicativeOpsScheduleDetails</REPORT_NAME>
<TITLE>Daily Ex-Ante Indicative Operations Schedule Detail (PUBLIC)</TITLE>
81.6 DELIVERY_HOUR NUMBER(2) Trading hour (between 1 and 25).
81.7 DELIVERY_INTERVAL NUMBER(2) Trading interval (1 or 2).
DATE (DD/MM/YYYY,
81.9 POST_TIME Time at which the current Operation Schedule was generated.
HH24:MI:SS)
82 Daily Generator Unit Technical Characteristics Data Transaction XML/HTML Daily Day after Trading Day – By 16:00 General Public
<REPORT_NAME>PUB_D_GenUnitTechChars</REPORT_NAME>
<TITLE>Daily Generator Unit Technical Characteristics Data (PUBLIC)</TITLE>
Permitted values include: PPMG, PPTG, VPMG, VPTG.
82.5 GMT_OFFSET NUMBER(1) GMT offset (0 or 1).
DATE (DD/MM/YYYY
82.6 EFF_TIME Effective time stamp.
HH24:MI:SS)
DATE (DD/MM/YYYY
82.7 ISSUE_TIME Issue time stamp.
HH24:MI:SS)
82.8 OUTTURN_AVAILABILITY NUMBER(8,3) Outturn Availability, spot values, by Unit Id.
82.9 OUTTURN_MINIMUM_STABLE_GEN NUMBER(8,3) Outturn Minimum Stable Generation, spot values, by Unit Id.


82.10 OUTTURN_MINIMUM_OUTPUT NUMBER(8,3) Outturn Minimum Output, spot values, by Unit Id.
Daily Energy Limited Generator Unit Technical Characteristics Data
83 XML/HTML Daily Day after Trading Day – By 16:00 General Public
Transaction
<REPORT_NAME>PUB_D_EnergyLimitedGenUnitTechChars</REPORT_NAME>
<TITLE>Daily Energy Limited Generator Unit Technical Characteristics Data (PUBLIC)</TITLE>
Permitted values include: PPMG, PPTG, VPMG, VPTG.
83.5 REDECLARED_ENERGY_LIMIT NUMBER(8,3) Re-Declared Values of Energy Limit, SELut.
84 Daily SO Interconnector Trades XML/HTML Daily Day after Trading Day – By 16:00 General Public
<REPORT_NAME>PUB_D_InterconnectorTrades</REPORT_NAME>
<TITLE>Daily Interconnector Trades (PUBLIC)</TITLE>
The name of the resource in question (e.g. the name of the Interconnector Unit for which data is
being reported).
84.6 SO_INTERCON_IMP_PRICE NUMBER(8,2) Equates to the SIIP for TSO trades on the Interconnector.
84.7 SO_INTERCON_IMP_QUANTITY NUMBER(8,3) Equates to the SIIQ for TSO trades on the Interconnector.
84.8 SO_INTERCON_EXP_PRICE NUMBER(8,2) Equates to the SIEP for TSO trades on the Interconnector.
84.9 SO_INTERCON_EXP_QUANTITY NUMBER(8,3) Equates to the SIEQ for TSO trades on the Interconnector.
Price-affecting Metered Data, excluding Trading Site Supplier Units for Day after Trading Day – By 15:00, as
85 XML/HTML Daily General Public
Trading Sites with Non-firm Access updated


<REPORT_NAME>PUB_D_PriceAffectingMeterData</REPORT_NAME>
<TITLE>Daily Price Affecting Meter Data (PUBLIC)</TITLE>
Permitted values include: PPMG, PPTG, VPMG, VPTG, DU, SU and I.
85.9 METERED_MW NUMBER(8,3) APTG.
Metered MW represents the total load when the resource type is DU and SU.
Transmission Type: (PEG for this report)
• NPEG – Non-Price Effecting Generation.
CJF – Cross-Jurisdictional Power Flow.
Day after Trading Day – By 15:00, as
86 Daily Indicative Ex-Post Market Schedule Quantity XML/HTML Daily General Public
updated
<REPORT_NAME>PUB_D_ExPostMktSchDetail</REPORT_NAME>
<TITLE>Daily Indicative Ex-Post MSQ Detail (PUBLIC)</TITLE>


86.10 MINIMUM_OUTPUT NUMBER(8,3) Minimum Output
Actual Availability as calculated as the outcome values from the firm/non-firm calculations as per
86.11 ACTUAL_AVAILABILITY NUMBER(8,3)
the Physical Market Specification.
Four Days after Trading Day – By

87 Daily Initial Ex-Post Market Schedule Quantity XML/HTML Daily General Public
17:00
<REPORT_NAME>PUB_D_InitialExPostMktSchDetail</REPORT_NAME>
<TITLE>Daily Initial Ex-Post MSQ Detail (PUBLIC)</TITLE>
Actual Availability as calculated as the outcome values from the firm/non-firm calculations as per
87.11 ACTUAL_AVAILABILITY NUMBER(8,3)
the Physical Market Specification.
One Working Day after Trading Day,
88 Daily Interconnector Capacity Active Holdings XML/HTML Daily General Public
by 15:00, and as updated


<REPORT_NAME>PUB_D_IntconnCapActHoldResults </REPORT_NAME>
<TITLE>Daily Interconnector Capacity Active Holdings (PUBLIC)</TITLE>
Maximum Interconnector Export Capacity offered on the Interconnector Unit in each Trading Period
88.6 INTERCONNECTOR_EXPORT_CAPACITY NUMBER(11.3)
Maximum Interconnector Import Capacity offered on the Interconnector Unit in each Trading Period
88.7 INTERCONNECTOR_IMPORT_CAPACITY NUMBER(11.3)
One Day prior to Trading Day, by
89 Forecast Ex-Post Loss Of Load Probability XML/HTML Daily General Public
16:30
<REPORT_NAME>PUB_D_EPLossOfLoadProbability</REPORT_NAME>
<TITLE>Daily Forecast Ex-Post Loss Of Load Probability (PUBLIC)</TITLE>
Number denoting the hour of the Trading Day applicable taking into account Daylight Savings
89.3 DELIVERY_HOUR NUMBER(2)
Conditions. Range: {1…25}.
89.4 DELIVERY_INTERVAL NUMBER(1) Number denoting the trading interval applicable. Range: {1, 2}.
Numeric value, between zero and one, denoting the Forecast Ex-Post Loss of Load Probability for
89.5 EP_LOSS_OF_LOAD_PROBABILITY NUMBER(13,12)
the relevant Trading Period.
One Day prior to Trading Day, post
90 Ex-Ante Indicative Shadow Prices XML/HTML Daily General Public
Gate Closure, by 13:00
<REPORT_NAME>PUB_D_EAShadowPrices</REPORT_NAME>
<TITLE>Daily Ex Ante Indicative Shadow Prices(PUBLIC)</TITLE>


Values:
90.5 CURRENCY_FLAG CHAR(1) E for Euro
P for Sterling
The additional cost of delivering an additional MW of energy in addition to the value of Schedule
90.6 SHADOW_PRICE NUMBER(8,2)
Demand. This is generally the price for the marginal Generating Unit.
91 Ex-Post Indicative Shadow Prices XML/HTML Daily Day after Trading Day - By 16:00 General Public
<REPORT_NAME>PUB_D_EPIndShadowPrices</REPORT_NAME>
<TITLE>Daily Ex Post Indicative Shadow Prices(PUBLIC)</TITLE>
Values:
91.5 CURRENCY_FLAG CHAR(1) E for Euro
P for Sterling
92 Ex-Post Initial Shadow Prices XML/HTML Daily General Public
17:00
<REPORT_NAME>PUB_D_EPInitShadowPrices</REPORT_NAME>
<TITLE>Daily Ex Post Initial Shadow Prices(PUBLIC)</TITLE>
Values:
92.5 CURRENCY_FLAG CHAR(1)
E for Euro


P for Sterling
Fifteen Days after Trading Day – By
93 Daily Jurisdiction Error Supply MW (D+15) XML/HTML Daily
17:00
General Public
<REPORT_NAME>PUB_D_JurisdictionErrorSupplyD15</REPORT_NAME>
<TITLE>Daily Jurisdiction Error Supply MW (D+15) (Public)</TITLE>
93.6 JESU_MW NUMBER(8,3) Metered data in MW for Jurisdictional Error Supply Unit.
Table 53: Market Report Definitions

7.5. Market Reports Translation
Market System Reports will be made available to Market Participants through the Market
Participant Interface as XML or HTML formats. To further assist in the understanding of each
report definition, included in this section is an explanation of the XML output structure and
instructions detailing how the fields in a report definition map to the XML output structure. This
includes a worked example.
This section is taken from the Report Definitions Document v1.0, and track changes are from that
document.
7.5.1. XML Output Structure
• Each System Report will be structured consistent with the following hierarchy:
<?xml version="1.0" ?>
<!DOCTYPE REPORT (View Source for full doctype...)>
<REPORT>
<REPORT_HEADER>
<HEADROW num="1">
<RPT_DATE>15/03/2007 11:13:57</RPT_DATE>
<TRADE_DATE>20070228</TRADE_DATE>
</HEADROW>
</REPORT_HEADER>
<REPORT_BODY>
<PAGE>
<DATAROW num="1">
<TRADE_DATE>28/02/2007</TRADE_DATE>
<SMP_AVERAGE>93.67</SMP_AVERAGE>
<CURRENCY_FLAG>E</CURRENCY_FLAG>
</DATAROW>
<DATAROW num="2">
<TRADE_DATE>28/02/2007</TRADE_DATE>
<SMP_AVERAGE>63.29</SMP_AVERAGE>
<CURRENCY_FLAG>P</CURRENCY_FLAG>
</DATAROW>
</PAGE>
</REPORT_BODY>
</REPORT>
Sample XML 35: Market Reports – Market Prices Averages
• The REPORT element will contain two nested elements REPORT_HEADER and
REPORT_BODY.
• Each REPORT_HEADER will contain a nested element called HEADROW. The contents of
HEADROW are described in each report definition.
• Each REPORT_BODY will contain a nested element called PAGE. Each PAGE contains 25
DATAROW elements and the contents of DATAROW are described in each report definition.

Appendix A. Trading Hour/Interval Specification

• When communicating with the SEM Central Market Systems, a Trading Period is represented
by a combination of two data items – Trade Hour and Trade Interval.
• Trade Hour is the actual hour of the day to which the time applies, based on ‘end of
hour’ notation.
• Trade Interval denotes the 30 minute trading period within the Hour In Day (1 or 2).
• Examples:
• The Trading Period 06:00 – 06:30 (albeit ending just before 06:30) is represented by:
§ Hour in Day: 7 (based on ‘End-Of-Hour’ notation).
§ Trade Interval: 1.
• Trading Period 06:30 – 07:00 is represented by:
§ Hour in Day: 7.
§ Trade Interval: 2.
• A Standard Day has 48 Trading Periods:
Trading Period Date Time Hour In Trade Interval

Day
(Start of Period)
27-June-2006 06:00 7 1
27-June-2006 06:30 7 2
27-June-2006 07:00 8 1
… … …
27-June-2006 23:30 24 2
28-June-2006 00:00 1 1
… … …
28-June-2006 05:00 6 1
28-June-2006 05:30 6 2
Table 54: Trading Hour/Interval – Standard Day

• A Long Day has 50 Trading Periods.

• Due to the clock change, the hour between 01:00 and 02:00 is repeated.
• This extra hour is denoted by Hour In Day: 25.

Day
(Start of Period)
28-Oct-2006 06:00 7 1
28-Oct-2006 06:30 7 2
… … …
29-Oct-2006 01:00 2 1
29-Oct-2006 01:30 2 2
29-Oct-2006 01:00 25 1
29-Oct-2006 01:30 25 2
29-Oct-2006 02:00 3 1
29-Oct-2006 02:30 3 2
… … …
29-Oct-2006 05:30 6 2
Table 55: Trading Hour/Interval – Long Day
• A Short Day has 46 Trading Periods

• Due to clock change there are no Trading Period entries for 01:00 and 01:30 so
therefore there are no entries for Hour In Day of 2.

Day
(Start of Period)
24-Mar-2007 06:00 7 1
24-Mar-2007 06:30 7 2
… … …
25-Mar-2007 00:00 1 1
25-Mar-2007 00:30 1 2
25-Mar-2007 02:00 3 1
25-Mar-2007 02:30 3 2
… … …
25-Mar-2007 05:00 6 1
25-Mar-2007 05:30 6 2
Table 56: Trading Hour/Interval – Short Day

MPUD v6 5 (Clean)

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MPUD v6 5 (Clean)

Caricato da

Copyright:

Formati disponibili

EirGrid & SONI SEM Establishment Programme – MPUD v6.5.

SEM Establishment Programme

Title Market Participant Update Document

© EirGrid & SONI 2009. Commercial in Confidence. Page 1

PDF created with pdfFactory Pro trial version www.pdffactory.com

Version Date Author Comment

© EirGrid & SONI 2009. Commercial in Confidence. Page 2

PDF created with pdfFactory Pro trial version www.pdffactory.com

Version Date Author Comment

© EirGrid & SONI 2009. Commercial in Confidence. Page 3

PDF created with pdfFactory Pro trial version www.pdffactory.com

Version Date Author Comment

Changed all references of the Code

2. Change to reflect change request

6.5 17/04/2009 SEMO Section 7.4:

© EirGrid & SONI 2009. Commercial in Confidence. Page 4

PDF created with pdfFactory Pro trial version www.pdffactory.com

Disclaimer and Content Information........................................................................................................... 11

Disclaimer and Content Information........................................................................................................... 11

2. Interfaces Architecture Overview........................................................................................................ 13

2.1. Physical Overview .......................................................................................................................... 13

3. Messaging Overview (Type 3 Interfaces only)..................................................................................... 19

4. Market Interface .................................................................................................................................. 28

© EirGrid & SONI 2009. Commercial in Confidence. Page 5

PDF created with pdfFactory Pro trial version www.pdffactory.com

4.2.2. Settlement Reallocation .............................................................................................................. 32

6. Settlement Reports ............................................................................................................................... 33

6.1. Common Data Entry Procedure - Settlement Directory Listing ....................................................... 33

© EirGrid & SONI 2009. Commercial in Confidence. Page 6

PDF created with pdfFactory Pro trial version www.pdffactory.com

6.2.3. Settlement Report (successful and unsuccessful) Request samples ............................................... 33

7. Other Standard Reports....................................................................................................................... 33

© EirGrid & SONI 2009. Commercial in Confidence. Page 7

PDF created with pdfFactory Pro trial version www.pdffactory.com

Appendix A. Trading Hour/Interval Specification...................................................................................... 33

© EirGrid & SONI 2009. Commercial in Confidence. Page 8

PDF created with pdfFactory Pro trial version www.pdffactory.com

© EirGrid & SONI 2009. Commercial in Confidence. Page 9

PDF created with pdfFactory Pro trial version www.pdffactory.com

Table 43: Publication List – Variables Reference............................................................................................ 33

Table of XML Samples

© EirGrid & SONI 2009. Commercial in Confidence. Page 10

PDF created with pdfFactory Pro trial version www.pdffactory.com

Disclaimer and Content Information

© EirGrid & SONI 2009. Commercial in Confidence. Page 11

PDF created with pdfFactory Pro trial version www.pdffactory.com

© EirGrid & SONI 2009. Commercial in Confidence. Page 12

PDF created with pdfFactory Pro trial version www.pdffactory.com

2. Interfaces Architecture Overview

Internal Systems Internal Systems Test Systems

Figure 1: Messaging Architecture – Physical Overview

© EirGrid & SONI 2009. Commercial in Confidence. Page 13

PDF created with pdfFactory Pro trial version www.pdffactory.com

2.2. Logical Overview

Web Service Request Meter Data

Figure 2: Messaging Architecture - Logical Overview

© EirGrid & SONI 2009. Commercial in Confidence. Page 14

PDF created with pdfFactory Pro trial version www.pdffactory.com

o Energy Market Information Publication (MIR) – .csv

2.3. Type 2 vs. Type 3 Communication Channels

• Type 3 Communications use web services to provide an automated, computer-to-computer

© EirGrid & SONI 2009. Commercial in Confidence. Page 15

PDF created with pdfFactory Pro trial version www.pdffactory.com