Download - MPUD v6 5 (Clean)

8/8/2019 MPUD v6 5 (Clean)

1/199

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

EirGrid & SONI 2009. Commercial in Confidence. Page 1

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

PDF created with pdfFactory Pro trial version www.pdffactory.com
http://www.pdffactory.com/http://www.pdffactory.com/http://www.pdffactory.com/

8/8/2019 MPUD v6 5 (Clean)

2/199




MARKET METERING report query

combinations.

4.4 27/09/2007 SEM Implementation Team Corrected the Daily Dispatch Instructions

report field 26.6INSTRUCTION_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 MPquery

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


8/8/2019 MPUD v6 5 (Clean)

3/199




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: SettlementReallocation Validations to reflect the

change of format against the Monetary

Value field.

- Update of section 5.3.1 to add the CodeParticipant Name field to the Application

submission.

- Update of Table 29: Invoice ElementFields.

- Addition of section 6.2.4 Credit CoverReport.

- Update of Table 42: Publication List Variables Reference and Table 43:

Settlement Publications Variables

Reference.

- Update of Table 1: Report Type andReport Sub-Type Combination.

- Addition of four new General PublicReports 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 ofJESU_D15

- Typo corrections in the SettlementSections

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.


8/8/2019 MPUD v6 5 (Clean)

4/199




6.4 16/12/2008 SEM Implementation Team 1. Code Participant Format

Changed all references of the CodeParticipant data format from CPT_nnnn to

CP_nnnn which will align with the formatthat will apply for Day 1+.This affected the following sections:

Table 27 Credit Cover Report Header Records

Table 28 Credit Cover Report Summary Records

Table 29 Credit Cover Report Detail Records for Generator Unitand Supplier Unit

2. Change to reflect change requestincreasing 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 toFORECAST_MW).

2. Item 4.6: Updated element description.3. Item 11.6: Updated element description.4. Item 65.5: Updated element description.5. Item 66.5: Updated element description.6. Item 89: Gate time changed to 16:30 (as

opposed to 09:30).


8/8/2019 MPUD v6 5 (Clean)

5/199



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............................................................................................... 284.2.1. Default Data................................................................................. .............................................. 29


8/8/2019 MPUD v6 5 (Clean)

6/199



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. Type-Specific Data Entry Procedure............................................................................................... 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 ....................................................... 336.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


8/8/2019 MPUD v6 5 (Clean)

7/199



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 ..................................................................................................................... 336.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...................................................................................336.3.6.5. Capacity Market Information Publication ............................................................................... 33

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

7.1. Description..................................................................................................................................... 33

7.2. Type-Specific Data Entry Procedure............................................................................................... 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


8/8/2019 MPUD v6 5 (Clean)

8/199



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


8/8/2019 MPUD v6 5 (Clean)

9/199



Table of Figures

Figure 1: Messaging Architecture Physical Overview.................................................................................. 13Figure 2: Messaging Architecture - Logical Overview.................................................................................... 14Figure 3: Some Transactions may contain multiple Requests.......................................................................... 19Figure 4: Digital Signature Generation Process........................................... ................................................... 25

Figure 5: Data Transfer Process ..................................................................................................................... 26Figure 6: Non-Repudiation Process ................................................................................................................ 26Figure 7: Market Interface Data Processing Overview.................................................................................... 28Figure 8: Registration Data Processing Overview........................................................................................... 33Figure 9: Registration Data Status Updates ................................................................................................. 33Figure 10: Market Report Request Data Processing Overview........................................................................ 33

Table of Tables

- Update of Table 1: Report Type and Report Sub-Type Combination. ........................................................ 3Table 2: Functional Areas and Access Levels........................................................ ......................................... 16Table 3: User Types to Functional Area/Access Level mappings .................................................................... 17

Table 4: Processing Statistics Data Fields....................................................................................................... 20Table 5: Overview of Interface System........................................................................................................... 24Table 6: Market Interface Market Windows ................................................................................................ 29Table 7: Common Elements ........................................................................................................................... 33Table 8: Sample of Hours and Intervals (applicable to Forecast)..................................................................... 33Table 9: Validation rules applicable for Start / End Hour / Interval .........................................................33 Table 10: Validation rules for Hours and Interval applicable per message type............................................... 33Table 11: Settlement Reallocation Elements................................................................................................... 33Table 12: Settlement Reallocation Validations ............................................................................................... 33Table 13: Generator Offer Elements............................................................................................................... 33Table 14: Generator Offer Validations ........................................................................................................... 33Table 15: Load Bid Elements ......................................................................................................................... 33

Table 16: Load Bid Offer Validations............................................................................................................. 33Table 17: Interconnector Offer Elements........................................................................................................ 33Table 18: Interconnector Offer Elements........................................................................................................ 33Table 19: Statement Header Record............................................................................................................. 33Table 20: Statement Summary Record.........................................................................................................33Table 21: Statement Detail Records.............................................................................................................33Table 22: Statement Trailer Record............................................................................................................. 33Table 23: Participant Information Report Header Record ............................................................................ 33Table 24: Participant Information Report Summary Record......................................................................... 33Table 25: Participant Information Report Detail Records.............................................................................33Table 26: Participant Information Report Trailer Record............................................................................. 33Table 27 - Credit Cover Report Header Records.......................................................................................... 33Table 28 - Credit Cover Report Summary Records ...................................................................................... 33Table 29 - Credit Cover Report Detail Records for Generator Unit and Supplier Unit.................................. 33Table 30 - Credit Cover Report Detail Records for Market Participant ........................................................ 33Table 31 - Credit Cover Report Detail Records for Market .......................................................................... 33Table 32: Reallocation Agreement Report Header Record ........................................................................... 33Table 33: Reallocation Agreement Report Detail Records............................................................................33Table 34: Reallocation Agreement Report Trailer Record............................................................................ 33Table 35: Invoice Element Fields ................................................................................................................ 33Table 36: Invoice Body records ................................................................................................................... 33Table 37: Invoice Job records ....................................................................................................................... 33Table 38: Settlement Reports Market Segment Reference............................................................................ 33Table 39: Settlement Reports Product (Charge ID) Reference...................................................................... 33Table 40: Settlement Reports Variable Type Reference................................................................................ 33

Table 41: Settlement Reports Variable Type Reference................................................................................ 33Table 42: Publication Timing File Type Frequency .................................................................................. 33


8/8/2019 MPUD v6 5 (Clean)

10/199



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

Table of XML Samples

Sample XML 1: Settlement Reallocation Submit XML sample with no error Submit ............................... 33Sample XML 2: Settlement Reallocation Submit XML sample with no error Response............................ 33Sample XML 3: Settlement Reallocation Submit XML sample with error Submit.................................... 33Sample XML 4: Settlement Reallocation Submit XML sample with error Response................................. 33Sample XML 5: Settlement Reallocation Query XML sample with no error Query .................................. 33Sample XML 6: Settlement Reallocation Query XML sample with no error Response ............................. 33Sample XML 7: Settlement Reallocation Query XML sample with two errors Query............................... 33Sample XML 8: Settlement Reallocation Query XML sample with two errors Response .......................... 33Sample XML 9: Multiple Bid/Offer Submit Requests in one Transaction Submit..................................... 33Sample XML 10: Multiple Bid/Offer Submit Requests in one Transaction Response Part 1 ..................... 33Sample XML 11: Multiple Bid/Offer Submit Requests in one Transaction Response Part 2 ..................... 33Sample XML 12: Settlements Directory Listing Request ............................................................................. 33Sample XML 13: Settlements Directory Listing Response........................................................................... 33

Sample XML 14: Statement Request ........................................................................................................... 33Sample XML 15: Settlements report file request ............................................................................................ 33Sample XML 16: DIRL Request.................................................................................................................. 33Sample XML 17: Directory Listing (DIRL) Successful response.................................................................. 33Sample XML 18: Directory Listing (DIRL) Empty Directory.......................... ............................................ 33Sample XML 19: Specific Settlement File (FILE) Request .......................................................................... 33Sample 20: Specific Settlement File (FILE) Successful Response ................................................................ 33Sample XML 21: Specific Settlement File (FILE) Request .......................................................................... 33Sample 22: Specific Settlement File (FILE) File not found .......................................................................... 33Sample XML 23: Invoice (INVC) Request .................................................................................................. 33Sample XML 24: Invoice (INVC) Successful response ................................................................................ 33Sample XML 25: Invoice (INVC) Request .................................................................................................. 33

Sample 26: Invoice (INVC) File not found.................................................................................................. 33Sample XML 27: Report (RPT) Request...................................................................................................... 33Sample 28: Report (RPT) Successful response............................................................................................. 33Sample XML 29: Report (RPT) Request...................................................................................................... 33Sample 30: Report (RPT) File not found ..................................................................................................... 33Sample XML 31: Statement (STMT) Request ............................................................................................. 33Sample 32: Statement (STMT) Successful response .................................................................................... 33Sample XML 33: Statement (STMT) Request ............................................................................................. 33Sample 34: Statement (STMT) File not found ............................................................................................. 33Sample XML 35: Market Reports Market Prices Averages ...................................................................33


8/8/2019 MPUD v6 5 (Clean)

11/199



Disclaimer and Content Information

This document has been prepared to provide Market Participants with sufficientinformation 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 actionstaken by Market Participants as a result of the information presented in thisdocument or associated documents. Furthermore, the SEM does not indemnifyany commercial or organisational decisions made by Market Participants inrelation to the information herein.

2. This document represents the most up-to-date information on the SEM CentralMarket Systems as they have been developed. With this in mind, it is notappropriate simply to compare the document against an issued version of theTrading and Settlement Code. Instead, it is a combination of Version 4.3 of the

Trading and Settlement Code and subsequently agreed Change Requests andthose to be considered by the Modifications Committee.

3. The information provided in this document is based entirely on documentationand information provided by the software vendor. Although, the SEMProgramme has made all reasonable efforts to ensure that the informationpresented is correct, it cannot guarantee the information provided.

4. The Trading and Settlement Code references presented in this document areintended to guide Market Participants to relevant sections of the market rules. Itis not a one-to-one mapping, as this would be impossible due to the inherentdifferences between market rules and the requirements of trading systems.

5. Further changes to the processes described or schema elements presentedmay result as new information comes to light during future phases of the marketdevelopment. To mitigate the impact of such changes, the SEM will be issuingplanned updates to this document and associated documents (whereappropriate). Updates to this document will be consistent with the AgreedProcedure 11.


8/8/2019 MPUD v6 5 (Clean)

12/199



1. Introduction

The document is to assist Market Participants in building their systems to interface with theSEM Central Market Systems.

The focus of this document is on the Type 3 Communication Channel, i.e. submission andretrieval 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).


8/8/2019 MPUD v6 5 (Clean)

13/199



2. Interfaces Architecture Overview

2.1.Physical Overview

BELFAST DUBLIN

ProductionWeb Interface

Market Participant

Certification WebInterface

Internal Systems Internal Systems Test Systems

Internetmktcert.allislandmarket.com

ProductionWeb Interface

External FW

Internal FW Internal FW

External FW

market.allislandmarket.com

Market ParticipantQualification Web Interface

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 interfacesand 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 areconnecting to as it will vary according to the Market Operators operational

decisions

The Market Participant Qualification Environment, for Communication Channel Qualification,is similarly accessed via:

o https://mktcert.allislandmarket.com/MIWebService/wsfor 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 AgreedProcedure 5 (Data Storage and IT Security) section 3.

https://market.allislandmarket.com/MIWebService/wshttps://market.allislandmarket.com/mi_webapps/https://mktcert.allislandmarket.com/MIWebService/wshttps://mktcert.allislandmarket.com/mi_webapps/http://www.pdffactory.com/http://www.pdffactory.com/http://www.pdffactory.com/https://mktcert.allislandmarket.com/mi_webapps/https://mktcert.allislandmarket.com/MIWebService/wshttps://market.allislandmarket.com/mi_webapps/https://market.allislandmarket.com/MIWebService/ws

8/8/2019 MPUD v6 5 (Clean)

14/199



2.2.Logical Overview

TYPE 2

TYPE 3

Market

Participant

Interface

Settlements

Web

Interface

MarketParticipant

Interface

Web Service(Participant)

Request

Meter DataInterface

Web Service

(Meter DataProvider)

Request

Response

Response

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 MarketParticipants, 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 isauthorised 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 andMeter Data Interface are developed on Microsofts .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 theMarket Participant).

The exception to this is settlement reports, the list of reports for which is broken down asfollows:

o Settlement Statements .csv

o Participant Information Report (PIR) .csv

o Invoices .xml

o Settlement Reallocation .csv

o Energy Market Financial Publication (MFR) .csv


8/8/2019 MPUD v6 5 (Clean)

15/199



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 thedata 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 toappropriately 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 areopen, 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 MarketOperator 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 Participants users. This is only

available on the Type 2 Channel.

1Details on SubmitBody and SubmitAttachment are available in the Market Participant Web Services Client

Toolkit


8/8/2019 MPUD v6 5 (Clean)

16/199



2.4.Security2.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 MarketParticipants.

The Market Participant is responsible for designating the read and write privileges for its Usersto each of the Functional Areas of the Market Participant Interface.

Each User is assigned a Digital Certificate which provides their credentials to the SEM CentralMarket 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 aUser 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 MarketSystems. 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 usingmint_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_namein 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 LevelsThe 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


8/8/2019 MPUD v6 5 (Clean)

17/199



2.4.2.1. Sample Scenarios1. 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, wouldhave: Read-Write access to Trading; Read-Write access to Registration (including the ability toadminister 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 bothRegistration and Settlements, but not Trading as only Read-Write access is available.

2.4.3. User TypesUsers 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 FullAccess 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) andthe 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 functionalarea/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


8/8/2019 MPUD v6 5 (Clean)

18/199



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 toadminister 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 bothRegistration 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 automatedUsers 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 aparticular 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 aUser 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.


8/8/2019 MPUD v6 5 (Clean)

19/199



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 theMarket Participant Web Services Client Toolkit.

Details in further sections on data formats and validation are based on the relevant XMLSchema (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 Transactionssupport multiple requests are specified on a Transaction Type or specific Transaction level

later in this document.

Transaction

Request

RequestRequest

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 inthe 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 spacein the number data field is also ignored.

2Market Participant User Interface Guide (section 2)

3These Schemas are supplied as part of the Market Participant User Interface Guide (Appendix A.3)


8/8/2019 MPUD v6 5 (Clean)

20/199



Comment lines must begin with . Any text between these two tagswill 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 listedin 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 valuehas 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 generatedduring 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 yyyyWhere:

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;


8/8/2019 MPUD v6 5 (Clean)

21/199



zzz is the time zone (and may reflect daylight saving time). Standard time zoneabbreviations 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 buildPlease 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 ValidationWhen 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 dataRequests 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 ischecked 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 againstMarket Price Cap and Market Price Floor.

Successfully validated and processed data is indicated to the Market Participant throughinformation messages, whereas the failure is indicated by error messages.

If any validation fails, then all subsequent validations are also performed to the extent possibleso 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 thisdocument. The Market Participant User Interface Guide has a generic list of these Return

Codes for both the Market Interface and Registration submissions.


8/8/2019 MPUD v6 5 (Clean)

22/199



3.5.Transaction Identification3.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 ofthat 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 apass-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 beused 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 Participants internet connection speed;

o The Market Participants Web Service implementation and choice ofSubmitAttachment 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 andpooling 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 multipleusers on multiple channels that may be submitting updates to the same data.

o As such, any specific requirement around sequencing which a Market Participantidentifies will need to have appropriate business and system processes

implemented by the Market Participant to match the implementation required by

them.


8/8/2019 MPUD v6 5 (Clean)

23/199



o For example, a Market Participant who chooses to only use the Type 3 Channelfrom 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 tobe 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 MarketParticipant 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 therelevant validations applied by in the SEM Central Market Systems.

Recommendations

SubmitAttachment is the recommended method for SOAP requests, as it offers fullcompatibility 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, werecommend 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 requestat the wsdl level. Valid values are SUCCESS and FAIL.

The ResStatus will be set to FAIL if any problems are encountered in validating digitalsignatures and if any low level web service code exceptions are raised.

Also, when requesting a standard Report or Settlement Report, the ResponseInfo.ResFileNamein 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

or


8/8/2019 MPUD v6 5 (Clean)

24/199



3.7.Interfacing overviewSystem Request Channel* DigSig

Reqd.

Request Response

Valid

Response Invalid

Registration Query SFW - mpr-all.xsd

Report MI List Reports SW - mi_file_exchange_sem.xsd

mi_file_exchange_sem.xsd

(incl. embedded messages)

Report Settlement List Reports SW - wsdl DIRL File List (~xml) Empty List (xml)

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)

Report Settlement Report SW -

mi_file_exchange_sem.xsd (incl. embedded messages)

Report MI Report SW - mi_file_exchange_sem.xsd Report

mpr-all.xsd mpr-all.xsd

(incl. Processing Statistics and embedded messages)

mpr-all.xsd (incl. embedded messages)

Registration Submit SFW Y

mint_sem.xsd mint_sem.xsd


Market Interface Query SFW - mint_sem.xsd mint_sem.xsd


Market Interface Submit SFW Y

Channels supported S = Screen, F = File Exchange, W = Web Services

Table 5: Overview of Interface System


8/8/2019 MPUD v6 5 (Clean)

25/199



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 MarketParticipants 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 DigitallySigned 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 notprovide a Digital Signature for these Transactions, the following error message will be issued:

Digital signature is mandatory and not provided for this transaction .

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 theDigital 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 Participants private key;

4. Encode the binary signature into a base64-encoded string5. 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

http://www.w3.org/TR/2001/REC-xml-c14nhttp://www.pdffactory.com/http://www.pdffactory.com/http://www.pdffactory.com/http://www.w3.org/TR/2001/REC-xml-c14n

8/8/2019 MPUD v6 5 (Clean)

26/199



Figure 5: Data Transfer Process

In the above and below figures the yellow boxes represent the steps on the Market Participantside 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 Operatorpublic key. This encrypted data is sent within an SSL tunnel to the Market Operator web

server.

Figure 6: Non-Repudiation Process

3.8.2. ContestingThe contesting party should send the original xml file to an agreed third party. Using a dedicatedoff 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 createdrelating 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. Timestampssubmitted by Market Participants will not affect decisions on Market Windows (see section

4.2).


8/8/2019 MPUD v6 5 (Clean)

27/199



3.10. Transaction TypesThere 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.


8/8/2019 MPUD v6 5 (Clean)

28/199



4. Market Interface

4.1.DescriptionThe 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 ProcedureMarket Interface XML Submission

MarketOperator

Check Validationand Rules

Adherance

MarketParticipant

Prepare XML DataXML Submission[Local XSD validation]

Update SEMSystems

1

3

2

- XML Format- Market Window Open

- Security

- Content

- Quality

- Submission or- Query

XML Response

- Processing Statistics- Original Data Submitted

- Queried Data (Query Only)- Error and/or Information Messages

4

Figure 7: Market Interface Data Processing Overview

Stage 1: Market Participants prepare the XML Data. (Details on how this needs to bepackaged, 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 bevalidated on the client (Market Participant) system to ensure compliance with the XML Schema

rules;


8/8/2019 MPUD v6 5 (Clean)

29/199



Stage 3: The Transaction is received by the SEM Central Market Systems and validationchecks, 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 asappropriate 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 insection 4.3.5.

The processing Market Windows during which Transactions can be submitted are outlined inthe table below:

Market Windows

Transactions Start

Time

End Time Comments

Submit Trading

Day5

Data

06:00 AM

on TD-29

(GC-28)

10:00 AM

on TD-1

The data submission window opens at 06:00 AM

28 days before Gate Closure (GC), and closes on

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

submitted

as

available

23:59 PM

on TD+7

Data may be Queried according to the Submit

timeline, with this functionality being available

for an additional 7 days after the Trading Day

(TD)

Submit Settlement

Re-allocation

06:00 AM

on TD-29

(GC-28)

10:00 AM

on Invoice

Day - 1

The Settlement Re-allocation data submission

window opens as above and closes one day

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

Data7

N/A N/A The submission of standing data window is

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 DataThe 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.16From Agreed Procedure 10: Settlement Reallocation

7Trading Day Data is defined in section 4.2.1


8/8/2019 MPUD v6 5 (Clean)

30/199



o It is automatically used to create Trading Day Data immediately after the openingof 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 enteredby 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 requiredfor use by the Central Market Systems.

o After Communication Channel Qualification i.e. once access to the system isgranted 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 notapplicable 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 typeStanding 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 StandingData 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 SubmissionWindow 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 isalways 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, andthe Market Participant will be informed of the results of validation and processing.

o The communication mechanism during data submission is synchronous, that is theparticipant 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 asnecessary within the appropriate Market Submission Window (28 days).

o Once Market Participants have successfully completed Communication ChannelQualification, and thus be granted access to the SEM Central Market Systems, they

will be able to modify both their Standing and Trading Day Data.


8/8/2019 MPUD v6 5 (Clean)

31/199



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 days

8

.

8There will be a Business Process to identify and resolve failed Data Conversion Standing to Trading Day


8/8/2019 MPUD v6 5 (Clean)

32/199

8/8/2019 MPUD v6 5 (Clean)

33/199



No Name Validation Message Submit /

Mandatory

or Optional

Query /

Mandatory

or Optional

Must be validcombination with

PARTICIPANT_NAME.

Invalid combination of

participant_name {0} and

user_name {1} for trading_date

{2}

Must have systemprivileges to allow

Market Trading.

The user_name {0} for

participant_name {1} does nothave system access privileges to

participate in Market Trading

for trading_date {2}.

The current version of thetemplate.CE-6 VERSION_NO

Must be 1.0.

Y/M Y/M

CE-7 MODE Must be NORMAL. Y/M Y/M

Table 7: Common Elements

4.3.2. Description of Hours and Intervals ElementsThe 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,

FORECAST_END_HR:

Start hour must be less than or equal to End hour.

FORECAST_START_INT,

FORECAST_END_INT:

Start interval must be less than or equal to End interval, if the Start

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)


8/8/2019 MPUD v6 5 (Clean)

34/199



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 asit 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

Download - MPUD v6 5 (Clean)

Top Related