My BSC Dashboard Subscriptions Kinnect Customer Solution

V 54 0

This version of the document has been superseded.

See the current version.

Previous version Next version

1 Introduction

2 Common Interface Conventions

3 External Interface Summary

4 BMRA External Inputs and Outputs

5 CDCA External Inputs and Outputs

6 CRA External Inputs and Outputs

7 ECVAA External Inputs and Outputs

8 SAA External Inputs and Outputs

9 SVAA External Inputs and Outputs

NETA Interface Definition and Design Document Part 1 – Interfaces with BSC Parties and their Agents

v 54.0

Effective From Date:01/08/2024

Status:SUPERSEDED

Other versions

Download

NETA Interface Definition and Design: Part 1

Interfaces with BSC Parties and their Agents

Synopsis	This document contains the definition and design of all interfaces between the BSC Service Systems and other Systems. It includes the specification of file formats and structure of electronic files. Part one only contains details for interfaces which involve BSC Parties and their Agents.
Version	54.0
Effective date	01 August 2024
Prepared by	Design Authority

Intellectual Property Rights, Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in Elexon or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make.

All other rights of the copyright owner not expressly dealt with above are reserved.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Elexon Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.

Amendment History

Date	Version	Details of Change	Committee Approval Ref
04/11/2010	26.0	Document rebadged and amended for November 2010 Release (P243, P244, CP1333)
03/11/2011	27.0	P253
28/06/2012	28.0	CP1364
		CP1367, BMRS Zones Review
27/06/2013	29.0	CP1382 – 27 June 2013 Release	ISG140/02
26/06/2014	30.0	CP1397 – 26 June 2014 Release	ISG150/02
01/08/14	31.0	ORD005 – Electricity Market Reform	Directed by the Secretary of State
16/12/14	32.0	P295, P291 – 16 December 2014 Release	ISG162/01
25/06/15	33.0	P310 – 25 June 2015 Release	ISG169/05
05/11/15	34.0	P305, P309, 5 November 2015 Release	ISG174/04
23/02/17	35.0	P326, 23 February 2017 Release	ISG188/05
29/06/2017	36.0	P321 Self-Governance, P329 Alternative 29 June 2017 Release	ISG194/02
02/11/2017	37.0	P336 Self-Governance; P342 Alternative 2 November 2017 Release	ISG198/04
01/11/2018	38.0	CP1503 – 1 November 2018 Release	P277/04
		CP1506 – 1 November 2018 Release	P280/09
28/02/2019	39.0	February 2019 Release – P344	P284C/01
		February 2019 Release – P359	ISG212/03
		February 2019 Release – P297	P222/06
		February 2019 Release – P373	P284/04
29/03/2019	40.0	March 2019 Standalone Release P369	P285/12
11/12/2019	41.0	11 December 2019 – Standalone Release CP1517	ISG220/01 ISG222/03
18/12/2019	42.0	18 December 2019 – December Standalone Release, CP1516	P292/06
01/04/2020	43.0	01 April 2020 – Standalone Release P354	ISG227/04
03/12/2020	44.0	03 December 2020 – Standalone Release CP1535	P305/06
18/03/2021	45.0	18 March 2021 – Standalone Release P408 Self-Governance	ISG234/02
01/04/2021	46.0	01 April 2021 – Standalone Release CP1538	ISG236/03
01/04/2021	47.0	01 September 2021 Non-Standard Release – P420	P316/05
04/11/2021	48.0	04 November 2021 Standard Release –P399	P310/04
24/02/2021	49.0	24 February 2022 Standard Release –CP1548	ISG247/01
30/06/2022	50.0	30 June 2022 Standard Release – P375, CP1562	P309/06 ISG253/04
23/02/2022	51.0	23 February 2023 Standard Release - P376,CP1569	P314/06, ISG259/09
29/06/2023	52.0	29 June 2023 Standard Release –CP1580	P338/04
02/11/2023	53.0	02 November Standard Release –P395,CP1576	P339/07 / P340/05
01/08/2024	54.0	01 August 2024 Non Standard Release	P349/03

1 Introduction

1.1 Purpose

1.1.1 Summary

This document is Part 1 of the Interface Definition and Design.

The scope of the document is, for each BSC Service System provided, the definition and design of all interfaces between the BSC Service System and other Systems.

The scope of Part 1 is limited to the definition and design of interfaces between the BSC Service System and the BSC Parties and their Agents.

Note that, subsequent to the introduction of P62, any of the following terms can represent a Licensed Distribution System Operator (LDSO) or any Party which distributes electricity.

Distribution Business
Distribution System Operator
Public Distribution System Operator(and abbreviation PDSO)
Distribution Company
Public Electricity Suppliers (PES), as operators of a distribution network
Distributor, as operator of a distribution network.

1.2 Scope

1.2.1 The Scope of this Document

This document describes the interfaces relevant to five of the seven BSC Service Systems (and some interfaces relating to a sixth). The interfaces relating to the Funds Administration Agent service are described separately in the FAA Interface Definition and Design. The services within the scope of this document are:

BMRA	Balancing Mechanism Reporting Agent
CDCA	Central Data Collection Agent
CRA	Central Registration Agent
ECVAA	Energy Contract Volume Aggregation Agent
SAA	Settlement Administration Agent
SVAA	Supplier Volume Allocation Agent (certain interfaces only)

These six are termed here the Central Services. Section 3.1.6 specifies which SVAA interfaces fall within the scope of this document (and which are specified elsewhere).

1.2.2 Types of Interface

Interfaces between the Central Services and other systems which are not part of the Central Services are termed External and are the main subject of the Interface Definition and Design. These interfaces are of two kinds:

Party interfaces – BSC Parties and Agents, including ECVNA, MVRNA, IA, IEA, SMRA and MOA. These interfaces are covered in Part 1 (this document).
System interfaces – to other BSC services: FAA, SVAA, the National Electricity Transmission System Operator (NETSO) and BSCCo Ltd. These interfaces are covered in Part 2 (a separate document).

External interfaces which do not connect to a Central Service, e.g. FAA to Bank, are not included in the Interface Definition and Design.

The interfaces with BSC Parties and Agents will need a wider forum of agreement than the other interfaces, and will be tested in Market Interface Testing (MIT). The Interface Definition and Design is therefore divided into two separate parts for these two interface types. The two parts will be issued independently and will therefore have different version numbers.

1.3 NETA Interface Overview

1.3.1 Introduction

The approach to the interface definition process adopted in this document is a layered top down structure. The highest layer is the business need for the interface to exist. This business transaction is supported by successive lower layers working down via the logical and physical design to the communications protocol and the physical format and media for the data transfer. This is summarised in the table below.

Layer	Defined in Section	Source/Based on
Business Process Definition	1.3.2	Business Process Model
Logical Flow Definition	1.3.3 & 2.2	Industry practice
Physical Message Definition	1.3.4	Industry practice (with MV90 for meter data)
Data Transfer Protocol	1.3.5	FTP over TCP/IP

1.3.2 The Business Process Level

A Business Process can be represented by a ‘transaction’ – a message or sequence of messages that fulfil a business function, for example ‘submit report request’ leads to ‘report sent’ or ‘error message – not available’. Each of these messages can be defined as a logical ‘flow’ to meet the requirement. The flow can classified by its characteristics at the business level:

Originating Party
Destination Party
Initiating event (e.g. user request, another flow, timer expires)
Frequency in unit time
Data content at the business level.
Mechanism: Electronic Data File Transfer or Manual
Volume – frequency * mean message size
Validation rules.

Flows are given unique identifiers. The same flow can be sent by more than one originator and to more than one party and as a result of different initiating events. These origin/destination/initiation cases are called here different ‘instances’ of the same flow. The same flow can have internal and external instances.

1.3.3 Logical Message Definition

The next step is to define the flow contents at the logical level. This defines what each flow will contain in terms of fields, their attributes and how the fields are grouped within the flow. At the same time, the rules for which fields and groups are optional or mandatory and whether and how often groups can be repeated need to be specified.

To do this, a naming convention and layout standards have been set for those flows so that the information can be presented in a consistent and unambiguous form. The format is based on industry practice, and is similar to that used by the industry to support the Supplier Volume Allocation settlement process.

1.3.4 Physical Message Definition

The Logical Message definition encompasses all the data visible at the user level and is closely aligned to the database design as the flows populate the database and/or are derived from their contents. Physical file formats define, for flows that are transferred electronically, the data representation and control information. Similarly to the logical definition, a naming convention and layout standards have been defined so that the information can be exchanged and validated in a consistent and unambiguous form. The definitions are again based on industry practice.

Details of the physical file format are specified in section 2.2

1.3.5 Data Transfer Protocols

This section only applies to flows which employ the electronic data file transfer mechanism.

Details of the proposed protocols for data transfer are in [COMMS]. For each flow, data transfer will be via FTP over TCP/IP unless specified otherwise.

1.4 Summary

Part 1 of the Interface Definition and Design covers interfaces with BSC Parties and Agents, and is organised as follows:

Section 2 describes common interface conventions, in particular defining the approach to interfacing via file transfer.
Section 3 gives a summary of the interfaces, organised by BSC agent and by corresponding party.
Sections 4 to 7.24.3 define the interfaces to each of the BSC Agents.

Part 2 of this document contains interfaces where the only parties involved are within the Central Volume Allocation system, i.e. interfaces between the following services / systems:

BMRA
CDCA
CRA
ECVAA
FAA
SAA
NETSO
SVAA
BSCCo Ltd

Note that parts 1 and 2 of the Interface Definition and Design are issued separately and will therefore have different issue numbers.

1.5 References

1.5.1 BSC Documents

[SD]	Draft Service Descriptions for Central Data Collection, Energy Contract Volume Aggregation, Central Registration, Balancing Mechanism Reporting, Settlement Administration,
[BPM]	RETA Business Process Models:
	Top Level Processes
	Central Registration
	Aggregate and Check Contract Volume
	Balancing Mechanism Reporting
	Central Data Collection and Aggregation
	Calculate Settlement Debits and Credits
	Indicative Reporting Requirement
	Entity Relationship Model
[COMMS]	Communications Requirements Document

1.6 Abbreviations

AMVLP	Asset Metering Virtual Lead Party
BM	Balancing Mechanism
BMRA	Balancing Mechanism Reporting Agent
BMU	Balancing Mechanism Unit
BSC	Balancing and Settlement Code
WDCALF	Working Day Credit Assessment Load Factor
NWDCALF	Non-Working Day Credit Assessment Load Factor
CDA	Central Design Authority
CDCA	Central Data Collection Agent
CRA	Central Registration Agent
ECV	Energy Contract Volume
ECVAA	Energy Contract Volume Aggregation Agent
ECVN	Energy Contract Volume Notification
ECVNA	Energy Contract Volume Notification Agent
ECVNAA	Energy Contract Volume Notification Agent Authorisation
ENTSO-E	European Network of Transmission System Operators for Electricity
FAA	Funds Administration Agent
FPN	Final Physical Notification
FTP	File Transfer Protocol
GMT	Greenwich Mean Time
GSP	Grid Supply Point
IA	Interconnector Administrator
IEA	Interconnector Error Administrator
ISO	International Standards Organisation
LAN	Local Area Network
MAR	Meter Advance Reconciliation
MDP	Maximum Delivery Period
MDV	Maximum Delivery Volume
MEL	Maximum Export Limit
MIDP	Market Index Data Provider
MIL	Maximum Import Limit
MOA	Meter Operator Agent
MPAN	Meter Point Administration Number
MVR	Meter Volume Reallocation
MVRN	Meter Volume Reallocation Notification
MVRNA	Meter Volume Reallocation Notification Agent
MVRNAA	Meter Volume Reallocation Notification Agent Authorisation
NETSO	National Electricity Transmission System Operator as the holder of the Transmission Licence and any reference to “NETSO”, “NGESO”, “National Grid Company” or “NGC” in the Code or any Subsidiary Document shall have the same meaning.
NETA	New Electricity Trading Arrangements
NWDBMCAEC	Non-Working Day BM Unit Credit Assessment Export Capability
NWDBMCAIC	Non-Working Day BM Unit Credit Assessment Import Capability
PTFF	Pool Transfer File Format
QPN	Quiescent (final) Physical Notification
RETA	Revised Electricity Trading Arrangements
SAA	Settlement Administration Agent
SECALF	Supplier Export Credit Assessment Load Factor
SMRA	Supplier Meter Registration Agent
SVAA	Supplier Volume Allocation Agent
TAA	Technical Assurance Agent
TCP/IP	Transport Control Protocol/Internet Protocol
VLP	Virtual Lead Party
WAN	Wide Area Network
WDBMCAEC	Working Day BM Unit Credit Assessment Export Capability
WDBMCAIC	Working Day BM Unit Credit Assessment Import Capability

2 Common Interface Conventions

2.1 Interface Mechanisms

This section outlines the different interface mechanisms used.

2.1.1 Manual

Some interfaces employ a manual mechanism. This means that the information is delivered by mail, by a telephone call, by email, or by fax from one person to another (Perhaps in an electronic file attached to an email or written to a floppy disc).

All incoming manual flows are required to have been initiated by an Authorised Signatory. The flow will contain the Authorised Signatory Name and Password plus:

for flows submitted by post or fax, the signatory’s signature is required;
for those flows which are submitted by email, the sending email address must be that registered for the signatory.

Where applicable, the sender will have read the information from a computer screen or printed it out before sending it. Similarly, where applicable, the recipient enters the information into a computer system, probably via a data entry screen-based interface.

More details of the manual mechanism are given where appropriate for a particular flow.

2.1.2 Electronic Data File Transfer

The majority of non-manual interfaces use electronic file transfer. A data file is created on the source system, and is then copied to a predetermined directory on the destination system. The mechanism for the network copy is described in [COMMS].

A common format is used for data files transferred between the Central Services and the BSC Parties and their Agents. This is specified in Section 2.2.

2.1.3 Meter System Interface

The MV-90 interface is used to interact with meter systems (This is defined in the CDCA Design Specification Appendix A.).

2.1.4 BMRA Publishing Interface

A TIBCO messaging interface running over IP is used for providing screen-based data for BMRA users.

2.2 Data File Format

A common format is used for data files transferred electronically between the Central Services and the BSC Parties and their Agents.

These files use the ASCII character set. They consist of:

Standard header
Collection of data records using standard format
Standard footer

The file format is similar to the Energy Market Data Specification file format defined for use in Supplier Volume Allocation. The difference is that the format defined for Central Volume Allocation has the following enhanced features:

sequence number added to the header;
Party Ids in the header longer than the 4 character Pool Participant Ids;
Role Codes in the header longer than the 1 character Pool Participant Role Codes;
Message Role (Data/Response) added to the header;
free-format message type allowed

The components of the file are specified below:

2.2.1 File Header

The file header will be a record containing the following fields:

AAA-File Header
Field	Field Name	Type	Comments
1	Record Type	Text(3)	= AAA
2	File Type	Text(8)	5 character type plus 3 character version
3	Message Role	char	‘D’ Data or ‘R’ Response Note that the P0283, P0284, P0293, P0294 , P0329 and P0330 files produced by SVAA have Role ‘D’
4	Creation Time	datetime	Date/Time file was created. Specified in GMT. (For Response messages this field contains the Creation Time of the message being replied to)
5	From Role Code	Text(2)
6	From Participant ID	Text(8)
7	To Role Code	Text(2)
8	To Participant ID	Text(8)
9	Sequence Number	integer(9), rolling over from 999999999 to 0	A separate Sequence Number is used for each From Role Code / From Participant ID / To Role Code / To Participant ID combination. NB numbers used must be contiguous so recipients can detect missing files. See section 2.2.8 for more details of the use of Sequence Number. (For Response messages this field contains the Sequence Number of the message being replied to. This includes the P0283, P0284, P0293, P0294, P0329 and P0330 files produced by SVAA.)
10	Test data flag	Text(4)	Indicates whether this file contains test data =OPER or omitted for operational use, other values for test phases

Either field 6 or field 8 will be the Participant ID of the Central Systems in every case. (For SVAA the Participant ID is ‘CAPG’).

The possible values for role code are

‘AV’	(AMVLP)
‘BM’	(BMRA)
‘BC’	(BSCCo Ltd)
‘BP’	(BSC Party)
‘CD’	(CDCA)
‘CR’	(CRA)
‘DB’	(Distribution Business)
‘EC’	(ECVAA)
‘EN’	(ECVNA)
‘ER’	(Energy Regulator)
‘FA’	(FAA)
‘IA’	(Interconnector Administrator)
‘MI’	(Market Index Data Provider)
‘MO’	(Meter Operator Agent)
‘MV’	(MVRNA)
‘PA’	(BSC Party Agent)
‘PB’	(Public - also used for files made available for shared access)
‘SA’	(SAA)
‘SG’	(BSC Service Agent)
‘SO’	(NETSO)
‘SV’	(SVAA)
‘TS’	(Supplier)
‘VP’	(VLP)

This is a subset of the domain ‘Organisation Type’ defined in section 2.2.11.9, containing only those organisation types which send or receive electronic data files. Considering flows to BSC Parties: when a party receives a file because it is a Distribution Business, the To Role Code will be ‘DB’; when it receives a file because it is an Interconnector Administrator, the To Role Code will be ‘IA’; in all other cases, the To Role Code will be ‘BP’.

Message Role is used for handling receipt acknowledgement, and is further described in Section 2.2.7.

2.2.2 File Footer

The file footer will be a record containing the following fields:

ZZZ-File Footer
Field	Field Name	Type	Comments
1	Record Type	text(3)	= ZZZ
2	Record count	integer(10)	Includes header and footer
3	Checksum	integer(10)	Although type is shown as integer(10) the value is actually a 32-bit unsigned value and hence will fit in an “unsigned long” C variable.

The value of Checksum is defined according to the following sequence:

initialise to zero
consider each record in turn (including header but excluding trailer)
Break each record into four byte (character) sections (excluding the end of line character), padded with nulls if required, and exclusive OR (XOR) them into checksum.

The algorithm for this is illustrated by the following ‘C-like’ pseudo code.

num_chars = strlen (record_buffer)

FOR (i = 0; i < num_chars;)

value = 0

FOR (j = 0; j < 4; i++, j++)

IF i < num_chars

value = ((value << 8 ) + record_buffer[i])

ELSE

value = value << 8

END IF

ENDFOR

checksum = checksum XOR value

ENDFOR

The checksum value is a 32 bit value. This is treated as an unsigned integer and appears in the file footer as integer(10).

2.2.3 Record Formats

Each record in the file is presented as follows:

Where:

record type : 3 characters
record delimiter : Line Feed (ASCII 10)
field separator: “|” (ASCII 124)

NB field separator will thus appear at end of record (i.e. after last field), prior to the linefeed

A record of n fields will have n+1 field separators.

Data fields are presented as follows:

type	Rules
integer (n)	optional leading “-“ for negative numbers no leading zeros maximum n digits field may have “-“ and from 1 to n digits
decimal (n,d)	maximum n digits maximum d digits after decimal point maximum (n-d) digits before decimal point leading “-” required for negative numbers no trailing zeros no leading zeros other than where -1< value <1, then number may start with “0.” To clarify, the value 0.123 can be represented as: 0.123 or .123, but not: 00.123 (an invalid leading zero) or 0.1230 (an invalid trailing zero) Valid representations of zero are: 0 0.0 .0 0. –0 –0.0 -.0 -0. but not as a decimal point with no digits.
text (n)	up to n characters field may not contain field separator no leading spaces no trailing spaces
boolean	T or F
date	YYYYMMDD
time	HHMM
timestamp	HHMMSS
datetime	YYYYMMDDHHMMSS
char	single character
null	if a field is no longer needed in a future version of a flow, then its data type will be defined to be null, meaning that its value is always null

Text and char fields may contain only the following characters:

Character	ASCII	Character	ASCII	Character	ASCII
space	32	+	43	@	64
!	33	,	44	A-Z	65-90
"	34	-	45	[	91
#	35	.	46	\	92
%	37	/	47	]	93
&	38	0-9	48-57	^	94
'	39	:	58	_	95
(	40	;	59	a-z	97-122
)	41	=	61	{	123
*	42	?	63	}	125

Optional fields are permitted to have nothing between the field separators.

2.2.4 File Types, Record Types and Repeating Structure

The structure of records and their nesting rules are specified using tables. The tables are defined in the NETA Interface Definition and Design Part 1 spreadsheet. The following explains the meaning of data in those tables.

Each interface (flow) may be represented by more than one physical message type (sub-flow) indicated by multiple file types in the physical file format spreadsheet e.g. CRA-I014 has multiple file types R0141, R0142 etc. The file type is made up of three parts: the first character identifies the system (‘B’ (BMRA), ‘C’ (CDCA), ‘R’ (CRA), ‘E’ (ECVAA), or ‘S’ (SAA)); the second to fourth characters are taken from the number within the flow name; the final character identifies the sub-flow id.

These tables are not provided for most manual flows. Where it is useful to provide this information for a manual flow, a note is provided in the “Physical Details” section of the logical definition of the flow.

Nesting is indicated by use of L1, L2 etc. Items at L2 make up a group at L1, items at L3 make up a group at L2 etc.

Id	Row Type	Flow version / range	L1	L2	data type	valid set	item name/group description (comments)
C0011	F (File Type)						Title of Flow (plus sub-flow number where appropriate)
ABC	R (Record Type)						record type appears as the first field in an electronic file. Record types are unique across all file types.
N0001	D (Data Item)						Each data item is assigned a Data Item Id. The Data Item Id is used for all occurrences of the same Data Item.
		1-*					range indicates how many occurrences of this record type may appear at the current level. (comment may further refine the repeating rules) 0-* indicates unlimited repeat (optional record type) 1-* indicates unlimited repeat with at least one instance of the record type 1 indicates the record type appears exactly once 2 indicates the record type appears exactly twice 46-50 is a special case meaning 46, 48 or 50 (but not 47 or 49) - this applies to the number of Settlement Periods in a Settlement Day (which might be a clock change day)
			G				G indicates that this is a repeating group i.e. a record type
				1			1 indicates that this is a data item within a record type
				O			O indicates that this is an optional data item within the record type (in electronic files, this means that the field may be empty)
				N			N indicates that this is an unused data item within the record type (in electronic files, this means that the field will be empty)
							Data items and nested record types must appear in the order stated.
							L1, L2… define the nesting structure.

					text(9)		this field will contain a text string with up to 9 characters
					integer(n)		this field will contain an integer with an optional leading “-“ followed by up to n digits
					decimal		this field will contain a real number
					decimal (n,d)		this field will contain a real number. There will be an optional leading “-“ followed by up to d digits after the decimal point and up to (n-d) before the decimal point
					char		this field will contain a single character
					boolean		this field will contain a single character T or F
					date		this field will contain a date YYYYMMDD
					datetime		this field will contain a date and time YYYYMMDDHHMMSS
						valid set id	the field’s values are constrained to be within the definition of the identified valid set - see section 2.2.11

Different versions of flows are documented in the tables as follows. On the ‘File Type’ record, the flow version / range field indicates the version of the flow (a blank entry indicates version 1). For example, the records shown below define version 1 and version 2 of flow E0221.

Id	Row Type	flow version / range	item name/group description (comments)
E0221	F		ECVAA-I022: Forward Contract Report
…	…
E0221	F	002	ECVAA-I022: Forward Contract Report (version 2)
…	…

2.2.4.1 The Tabs of the Spreadsheet

There is one tab for each of the Central Systems with which the BSC Parties and Party Agents communicate via electronic data file transfer: BMRA, CRA, ECVAA, CDCA, SAA and SVAA. The Response tab reproduces the structure of the ADT record given in section 2.2.7 below in spreadsheet format. The Valid Set tab reproduces the information given in section 2.2.11 below in spreadsheet format. The Flow Role tab lists which From Role Codes and To Role Codes can validly appear in the header for each File Type. The Groups tab is the master definition of each Record Type; the record type definitions in the BMRA, CRA, ECVAA, CDCA, SAA and SVAA tabs are copied from there. The Items tab is the master definition of each item; the item definitions in the BMRA, CRA, ECVAA, CDCA, SAA and SVAA tabs are copied from there. The Valid Sets, Flow Role, Groups and Items tabs in the IDD Part 1 spreadsheet encompass the contents of the IDD Part 1 and IDD Part 2 spreadsheets.

2.2.5 File names

Files delivered to and sent from NETA must have names which are unique across all Central Systems within any month. The following convention for filenames is proposed, and is in use by the Central Systems:

characters 1-2: Sender role

characters 3-14: Unique identifier (alphanumeric, e.g. may be a sequence number)

(This convention is sufficient for the Central Systems to uniquely identify all incoming files, because these systems move incoming files into a directory whose name identifies the sending participant id. If incoming files have filenames longer than 14 characters, then the Central Systems will truncate the filenames on receipt).

The filenames do not include an extension.

Where files are placed in a shared (read only) area for multiple users to download, the file name will contain meaningful fields to easy allow identification.

2.2.6 Unstructured File Format

To allow for flexibility, an unstructured file format is also defined. This could be used for:

Ad hoc data transfers and text reports
Newly defined messages which have not yet been allocated formal file formats

The unstructured file format will contain the following elements:

1. Standard header record with File Type set to UNSTR001

2. Any ASCII text, with the proviso that no lines may begin with ‘ZZZ’.

3. Standard trailer record

2.2.7 Response Messages

As described in [COMMS], participants have a choice between two methods of receiving files from the Central Systems: either the Central Systems push files to the participant systems (‘Push Method’), or the participant systems pull files from the Central Systems (‘Pull Method’). For the Push Method, the Central Systems consider that a data file has been successfully delivered when the FTP ‘push’ returns a success code. For the Pull Method, the participant systems indicate that they have successfully pulled a file by deleting it from the source directory.

Note the web submission service will allow an agent to create a notification file within the system, and in reply, receive a response to this on a web screen. The web service will therefore not send a file based response to a web submitted notification.

There is only one method available for sending files to the Central Systems: participant systems push the files to the Central Systems. Participant systems should use the FTP ‘push’ success code to determine that the file has been successfully sent.

The remainder of this section applies to electronic data files sent both to and from the Central Systems, other than SVAA (which responds to incoming data with specific response files such as the P0283, P0284, P0293 and P0294, rather than the generic response files described in this section).

When a system receives a data file, it must reply by sending a response file. The purpose of the response file is to indicate whether the data file has been validated as being syntactically correct.

The Message Role field in the header record is used for differentiating a response file from a data file. A data file is sent with the message role set to data. The response file comprises the header as received, with from/to participant and role reversed and message role set to response (see section 2.2.1), followed by the ADT record(s) and a standard trailer record (ZZZ). There may be more than one ADT record if multiple problems are found with the file.

ADT-Acknowledgement Details
Field	Field Name	Type	Comments
1	Record Type	Text(3)	= ADT
2	Received Time	datetime (GMT)	Time that the message being acknowledged was received by the receiving party
3	Response Time	datetime (GMT)	Time that the response message was generated by the receiving party
4	File Name	text(14)	Name of file this response relates to
5	Response Code	integer(3)	A code indicating the nature of the acceptance / rejection
6	Response Data	text (80)	Any data that gives additional information in fixing the problem

The possible values for the Response Code with the meaning and the appropriate action are:

Response Code	Meaning	Appropriate Action
	NACK codes	file is rejected
1	Syntax Error in Header Record	Correct and resend.
2	To Participant details in header record are not correct for the actual recipient.	Correct and resend.
3	Unexpected Sequence Number in Header record.	See section 2.2.8
4	Syntax Error in Body. Error Data field contains line number where error detected.	Correct and resend.
5	Syntax Error in Footer Record	Correct and resend.
6	Incorrect Line Count in Footer Record	Correct and resend.
7	Incorrect Checksum in Footer Record	Correct and resend.
	ACK codes	file has arrived and been accepted
100	File received	none - file has arrived and its contents have passed the validation checks covered by the NACK response codes
101	Duplicate file received	ensure files are not being resent unnecessarily - a file has arrived with a header identical to one already received

The diagram below illustrates an exchange of files using the push mechanism, where a data file is sent via FTP, and then at a later time, the response file is sent back. Each file transfer consists of an FTP session where the file is first copied to the remote system, and then renamed to a separate directory on the remote system, where it can be accessed for processing.

The diagram below illustrates an exchange of files using the pull mechanism, where a data file is retrieved via FTP, and then at a later time, the response file is sent back as before. The file retrieval consists of an FTP session where the file is detected, copied from the remote system, and then deleted on the remote system.

2.2.7.1 Positive Acknowledgement (ACK Message)

A file must be checked for any of the conditions covered by response codes in the range 1-99. If all the checks pass then an ACK message must be sent.

Standard Receipt Acknowledgement Messages are not explicitly listed in the interface definitions which follow, except where they have been allocated an interface name in the URS - in this case, a section is included which contains only a reference back to this section, 2.2.7.

Receipt acknowledgement does not imply acceptance of the contents of the message.

2.2.7.2 Negative Acknowledgement (NACK Message)

This section applies to electronic data files sent both to and from the Central Systems.

In some cases it may be possible for an addressee to detect a failed message transmission. In this case a message may be returned to the sender with message role set to response.

Standard Negative Acknowledgement Messages are not explicitly listed in the interface definitions which follow.

When a system receives a NACK message, it should alert the operator of the system, informing them of the contents of the ADT record. The operator should read the Response Code field contained in the ADT record (defined in section 2.2.7) and take the appropriate action.

2.2.7.3 Response to response messages

On receipt of a response message, no response is sent.

2.2.7.4 Application Rejection and Acceptance

When a message has been received (and the receipt acknowledged as described above), the content of the message may be accepted or rejected during processing. The approach adopted to this is up to each individual application:

Rejection of a message may cause a message to be sent to the sender indicating the identifier of the message being rejected, and the reasons for rejection. The way in which rejections are dealt with will be described in the application specifications. In some cases, the Rejection message may be transmitted by a manual mechanism rather than as an electronic data file. Where a rejection message has been identified, it is listed as an interface in this document.
Acceptance of a message will not normally be signalled to the sender. In cases where this is required, a message is explicitly defined for the purpose.

2.2.8 Use of Sequence Numbers

The Central Systems expect each data file from a BSC Party in a certain role to have a sequence number for each Central System role in the file header which increments each time a file is sent. In the following processing rules, greater / less than comparisons will be implemented to cater for when a sequence number wraps round through 0. Note that sequence numbers start from 1.

If the received file has a sequence number less than the next expected, and the header is not identical to the file already received with that sequence number, the system generates an out-of-sequence response for the file.

If the received file has a sequence number greater than the next expected, the Central Systems will save the file, but will not process or acknowledge it until:

a) the missing file(s) arrive and the file becomes the next expected sequence and so is processed as normal (and an appropriate response sent according to the validation rules);

b) more than [n] (configurable) files have subsequently arrived all of which are flagged as out-of-sequence. The system generates an out-of-sequence response for the file;

c) more than [t] (configurable) minutes have elapsed since the file arrived. The system generates an out-of-sequence response for the file;

d) an operator manually sets the next expected sequence number to be greater than that of the file.

An out-of-sequence response is a response message with response code 3 and the expected sequence number in the Response Data field of the ADT record of the response message. It is up to the sender of the original file to correct the problem and send back a file with the correct sequence number.

The Central Systems will not process any subsequent files sent until a file with the expected sequence number is received. The sender will have to resend any such files after the sequence number problem has been corrected.

There is no automatic process by which the Central Systems will alter the value of the next expected sequence number which it holds (either up or down), apart from the normal increment when a file is successfully received. The only method by which a BSC Party or Agent can achieve a change in the value of the next expected sequence number held by a Central System will be by manual agreement.

The rules for updating the next expected sequence number in the case of a NACK being generated are as follows:

if a file is rejected because of problems with the HEADER the sequence number is not "used up" and so the next expected sequence number remains unchanged (NACK codes 1,2,3);
if a file is rejected because of problems with the BODY or TRAILER (record count, checksum), the sequence number is used up and the next expected sequence number is incremented (NACK codes 4,5,6,7).

Note that sequence number validation for the P0282, P0292 and P0328 flows sent to SVAA is slightly different. SVAA also looks for a separate Sequence Number for each From Role Code / From Participant ID / To Role Code / To Participant ID combination. It will reject a new file if it has a lower sequence number than one that has already been processed, but it will allow gaps in the sequence.

2.2.9 Time

All data items with data format datetime are in GMT.

Settlement Periods are integers defining a half hour period within a Settlement Day. These start at midnight local time, and are numbered sequentially from 1 to 46/48/50.

2.2.10 The CRA Encryption Key

In flow CRA-I012, the CRA system sends out an Encryption Key. How this is used is explained in [COMMS]. This flow is not sent electronically.

2.2.11 Valid Sets

This section defines the Valid Sets referred to in the repeating structure tables.

Note also that BSC Party Ids and BSC Party Agent Ids may contain only characters from this restricted set:

A-Z
0-9
- (dash)

BM Unit Ids, GSP Ids, GSP Group Ids, Interconnector Ids, Joint BMU Unit Ids and Metering System Ids may contain only characters from this restricted set:

A-Z
0-9
- (dash)
_ (underscore)

2.2.11.1 Action Code

One of the values:

‘Change’ (New or updated record)

‘No Action’ (Record unchanged)

‘Delete’ (record deleted)

Note: The Action Code field is used in CRA reports to indicate changes since the previous issue of the report, which could include the application of several registration requests. The Action Description field is a free format text field used in registration requests to allow the participant to identify the reason and nature of the change to the CRA operator.

2.2.11.2 Action Indicator

One of the values:

‘N’ (New)

‘U’ (Update)

‘C’ (Change of Registrant)

‘D’ (Delete)

2.2.11.3 Activity

One of the values:

‘A’ (Changing Authorisations)

‘B’ (Accept / Reject Data Estimation)

‘C’ (Site Witness of Meter Readings and on-site Meter Readings)

‘D’ (Work on Metering Systems)

‘E’ (Submitting SVA Entry Process Requests)

‘EA’ – Discontinued (Raise / Agree Standing Data Changes)

‘F’ (BM Units)

‘G’ (Metering System Registrations and MOA Appointment)

‘H’ (Metering System Technical Details and Proving Tests)

‘I’ – Discontinued (TA Site Visit Acceptance)

‘J’ (Party Registration / Changes)

‘K’ (Submit / Terminate ECVNAA or MVRNAA)

‘L’ (Submitting Aggregation Rules)

‘M’ (Amend Report Requirements)

‘N’ (Banking Details Registration / Changes)

‘O’ (Query / Dispute Process)

‘P’ (Submitting CVA Line Loss Factors)

‘Q’ (Registration & Deregistration of Trading Units)

‘R’ (Metering Dispensations applications)

‘S’ (Party Withdrawal)

‘T’ (Transfer of Metering Systems between SMRS and CMRS)

‘U’ (Party Agent Registration & Changes to Details)

‘V’ (Transmission of Reports to all Parties)

‘W’ (Submitting SVA Standing Data Changes)

‘X’ (Submitting SVA Line Loss Factors)

‘Y’ (Submitting MDD Change Reports)

‘Z’ (Manage ECVAA Web Service access)

‘ZA’ (Register LDSO TSO Boundary Point)

‘ZB’ (Signing the SAD and the Qualification Letter and delegating authority for the signing of other Qualification related documentation)

‘ZC’ (A delegated person acting as the signing authority for that company’s Annual Statement of Qualified Status process, re-Qualification Letter and any other documentation relating to Qualification)

2.2.11.4 Alarm Code

One of the values:

Interval Status Codes:

‘PO’ (Power outages)

‘SI’ (Short intervals)

‘LI’ (Long intervals)

‘CR’ (CRC checksum errors)

‘RA’ (RAM checksum errors)

‘RO’ (ROM checksum errors)

‘LA’ (Data missing)

‘CL’ (Clock errors)

‘BR’ (Recorder hardware resets)

‘WT’ (Watchdog timeouts)

‘TR’ (Time resets)

‘TM’ (Test mode)

‘LC’ (Load control)

Channel Status Codes:

‘AD’ (Added interval)

‘RE’ (Replaced data)

‘ES’ (Estimated data)

‘OV’ (Data overflow)

‘HL’ (Data out of limits)

‘XC’ (Excluded data)

‘PY’ (Parity error)

‘TY’ (Energy type change)

‘LR’ (Alarm error)

‘DI’ (Harmonic distortion)

2.2.11.5 AMSID Pair Differencing Indicator

One of the values:

‘T’ (AMSID Pair used for Differencing)

'F' (AMSID Pair used for Asset Metering)

2.2.11.6 Asset Metering Type

One of the values:

‘1’ (Metering of circuits with a rated capacity greater than 100MVA)

‘2’ (Metering of circuits with a rated capacity not exceeding 100MVA)

‘3’ (Metering of circuits with a rated capacity not exceeding 10MVA)

‘4’ (Metering of energy transfers with a Maximum Demand of up to (and including) 1MW)

‘5’ (Metering (embedded within another device) for energy transfers with a Maximum Demand of up to (and including) 100kW).

2.2.11.7 Baselining Indicator

One of the values:

S (Submitted)
I (Inactive)
B (Baselined)

2.2.11.8 Baselining Methodology

One of the values:

BL01
Null

2.2.11.9 Baselining Status

One of the values:

T (Baselined)
F (Non-Baselined)

2.2.11.10 BM Unit Type

One of the values:

‘T’ (directly connected to the Transmission network)

‘E’ (Embedded)

‘G’ (GSP Group, default BM unit for a supplier)

‘I’ (Interconnector User)

‘S’ (GSP Group, Specific BM unit identified by a supplier)

‘V’ Secondary BM Unit

2.2.11.11 Certification/Accreditation Status

One of the values:

‘1’ (applied for certification)

‘2’ (completed certification return)

‘3’ (certification report completed)

‘4’ (accredited)

‘5’ (accreditation removed)

2.2.11.12 Estimation method

One of the values:

‘A’ (Generation: Main meter data missing or incorrect in Primary and Secondary Outstations, Check meter data available – copied from Primary Check)

‘D’ (Demand: Main meter data missing or incorrect, Check meter data available – copied from Primary Check)

‘E’ (Demand: Main meter data missing or incorrect, Check meter not fully functional, but Main meter or Check meter register advance available – profiled using Meter Reading Estimation Tool)

‘I’ (Demand: Main meter data missing or incorrect, Check meter not fully functional, Main meter and Check meter register advance NOT available – profiled using Trend)

‘J’ (Generation: Main meter data missing, or incorrect, in Primary Outstation, Secondary Outstation main meter data available – substituted from Secondary Main)

‘K’ (Generation: Main and Check meter data missing or incorrect in Primary and Secondary Outstations, data estimated to zero awaiting confirmation of generation)

‘L’ (Demand; Primary Main meter data missing, or incorrect, Secondary Outstation Main meter data available – substituted from Secondary Main)

‘M’ (Demand: Main meter data missing or incorrect, data copied from suitable settlement period(s))

‘N’ (Validation Failure: Main meter data deemed correct)

‘U’ (Used party’s own reading)

‘X’ (Used different estimation method)

2.2.11.13 Event Day Type

One of the values:

B (Balancing Service)
O (Other)
D (Delete)

2.2.11.14 I/E Flag

One of the values:

‘I’ (Import)

‘E’ (Export)

2.2.11.15 L/S Flag

Either ‘L’ (Lead) or ‘S’ (Subsidiary). This is used in the Forward Contract Report (ECVAA-I022) to indicate whether the recipient of the report was the lead or subsidiary Party specified in a reported MVRNA Authorisation.

2.2.11.16 Main / Check Indicator

One of the values:

‘M’ (Main)

‘C’ (Check)

2.2.11.17 Measurement Class Id

One of the values:

‘C’ Half Hourly metered in 100kW Premises

‘E’ Half Hourly sub-100kW Non-Domestic Current Transformer

‘F’ Half Hourly sub-100kW domestic

‘G’ Half Hourly sub 100kW non-domestic whole-current

2.2.11.18 Measurement Quantity

One of the values:

‘AE’ (Active Export)

‘AI’ (Active Import)

‘RE’ (Reactive Export)

‘RI’ (Reactive Import)

2.2.11.19 Meter Reading Status

One of the values:

‘A’ (Valid)

‘B’ (Invalid)

‘C’ (Unavailable)

‘D’ (Substituted from Secondary Outstation Meter Data)

2.2.11.20 MSID Pair Indicator

‘T’ MSID Pair is not an Associated MSID Pair to an AMSID Pair in a Secondary BM Unit

‘A’ MSID Pair is an Associated MSID Pair to an AMSID Pair that will be used for the purposes of Asset Metering in a Secondary BM Unit

‘M’ MSID Pair is an Associated MSID Pair to an AMSID Pair that will be used for the purposes for Asset Differencing.

2.2.11.21 Multi-day Flag

One of the values:

‘M’ (Multi-day)

‘S’ (Single day)

Note that this flag is not used in any current report.

2.2.11.22 Organisation Type

One of the values:

‘AV’ (AMVLP)

‘BM’ (BMRA)

‘BC’ (BSCCo Ltd)

‘BP’ (BSC Party)

‘CD’ (CDCA)

‘CR’ (CRA)

‘DB’ (Distribution Business)

‘EC’ (ECVAA)

‘EN’ (ECVNA)

‘ER’ (Energy Regulator)

‘FA’ (FAA)

‘HA’ (Half Hourly Data Aggregator)

‘HC’ (Half Hourly Data Collector)

‘HP’ (Helpdesk)

‘IA’ (Interconnector Administrator)

‘IE’ (Interconnector Error Administrator)

‘MA’ (Meter Administration Agent)

‘MI’ (Market Index Data Provider)

‘MO’ (Half Hourly Meter Operator Agent))

‘MS’ (Supplier Meter Administration Agent)

‘MV’ (MVRNA)

‘NA’ (Non Half Hourly Data Aggregator)

‘NC’ (Non Half Hourly Data Collector)

‘NO’ (Non Half Hourly Meter Operator Agent)

‘PA’ (BSC Party Agent)

‘SA’ (SAA)

‘SG’ (BSC Service Agent)

‘SM’ (SMRA)

‘SO’ (NETSO)

‘SV’ (SVAA)

‘TA’ (TAA)

‘TG’ (Trading Party - Generator)

‘TI’ (Trading Party - Interconnector User)

'TL' (Transmission Loss Factor Agent)¹

‘TN’ (Trading Party - Non-physical)

‘TS’ (Trading Party - Supplier)

‘VP’ (VLP)

2.2.11.23 Party Sequence

Either ‘1’ or ‘2’. This is used in the Forward Contract Report (ECVAA-I022) to indicate whether the recipient of the report was the first or second Party specified in a reported ECVNA Authorisation.

2.2.11.24 P/C Flag

One of the values:

‘P’ (Production)

‘C’ (Consumption)

2.2.11.25 P/C Status

One of the values:

‘P’ (Production)

‘C’ (Consumption)

2.2.11.26 Point Type

One of the values:

‘BG’ (Gensets connected to TS; boundary point)

‘BS’ (Station Transformer connected to TS; boundary point)

‘BD’ (Demand sites connected to TS; boundary point)

‘BI’ (Interconnector with other TS from TS; boundary point)

‘BE’ (Embedded > 50MW; boundary point)

‘BO’ (Other embedded; boundary point)

‘BT’ (Interconnector with other TS from DS; boundary point)

‘SG’ (Grid Supply Points; system connection point)

‘SD’ (Interconnector between Distribution Networks; system connection point)

2.2.11.27 Price Derivation Code

One of the values:

‘A’	(SBP = Main price; SSP = Reverse Price)
‘B’	(SSP Capped to SBP)
‘C’	(SSP Defaulted to SBP)
‘D’	(SBP & SSP Defaulted to Market Price)
‘E’	(SSP & SBP Defaulted to Zero)
‘F’	(SSP = Main Price; SBP = Reverse Price)
‘G’	(SBP Capped to SSP)
‘H’	(SBP Defaulted to SSP)
‘I’	(SBP & SSP Defaulted to Market Price)
‘J’	(SSP & SBP Defaulted to Zero)
‘K’	(SSP & SBP Defaulted to Market Price)
‘L’	(SSP & SBP Defaulted to Zero)
‘N’	(SSP Defaulted to Main price; SBP = SSP)
‘P’	(SBP Defaulted to Main price; SSP = SBP)

2.2.11.28 Registration Status

One of the values:

‘S’ (Successful Registration)

‘P’ (Registration Pending)

2.2.11.29 Registration Type

One of the values:

‘PY’ (BSC Party)

‘PA’ (BSC Party Agent)

‘SA’ (BSC Service Agent)

‘BM’ (BM Unit)

‘EI’ (Interconnector)

‘TU’ (Trading Unit)

‘BP’ (Boundary Point/System Connection Point)

‘MS’ (Metering System)

‘GG’ (GSP Group)

‘GS’ (GSP)

‘MI’ (Market Index Data Provider)

2.2.11.30 Run Type

One of the values:

‘II’ (Interim Initial)

‘SF’ (Initial Settlement)

‘R1’ (First Reconciliation)

‘R2’ (Second Reconciliation)

‘R3’ (Third Reconciliation)

‘RF’ (Final Reconciliation)

‘D’ (Dispute)

‘DF’ (Final Dispute)

(Multiple dispute runs for the same Settlement Date are distinguished using run number.)

2.2.12 Example File Formats

The first example is based on CDCA-I0041. A file defined like this in the spreadsheet:

C0411	F							CDCA-I041: Interconnector Aggregation Report

AIV	R	1-*	G					Interconnector Aggregation Report
N0125	D			1		integer(10)		Interconnector Id
N0200	D			1		date		Settlement Date
AIP	R	46-50		G				Aggregated Interconnector Volume - Period
N0201	D				1	integer(2)		Settlement Period
N0090	D				1	boolean		Estimate Indicator
N0062	D				1	date		Date of Aggregation
N0139	D				1	decimal(10,3)		Meter Volume
N0049	D				1	integer(2)		CDCA Run Number
N0121	D				1	char	I/E Flag	Import/Export Indicator

looks like this:

AAA|C0411001|D|20000204093055|CD|LOGICA|IA|FRANCE|516||

AIV|FRANCE|20000203|

AIP|1|F|20000204|501.2|1|E|

AIP|2|F|20000204|498.6|1|E|

AIP|48|F|20000204|468.9|1|E|

ZZZ|51|1067512|

Here are some more examples, based on the ECVN flow ECVAA-I004

An ECVN is defined as follows in the spreadsheet:

E0041	F							ECVAA-I004: ECVNs

EDN	R	1	G					ECVNs
N0080	D			1		text(10)		ECVNAA Id
N0297	D			1		text(10)		ECVNAA Key
M0310	D			1		text(10)		ECVN ECVNAA Id
N0077	D			1		text(10)		ECVN Reference Code
N0081	D			1		date		Effective From Date
N0083	D			O		date		Effective To Date
OTD²	R	0-1		G				Omitted Data No Change
N0483	D				1	boolean		No Change to Existing Data
CD9	R	0-*		G				Energy Contract Volumes
N0201	D				1	integer(2)		Settlement Period
N0085	D				1	decimal(10,3)	MWh	energy contract volume

This allows the following file formats:

1) An open-ended ECVN for a single period (effective-to date field omitted):

AAA|E0041001|D|20000204093055|EN|ECVNA1|EC|LOGICA|545546||

EDN|00195|3444343|00195|ECV65011|20000207||

CD9|23|1445233.323|

ZZZ|4|1313360725|

2) Termination of the previous ECVN after a month (no CDV records):

AAA|E0041001|D|20000204103055|EN|ECVNA1|EC|LOGICA|545676||

EDN|00195|3444343|00195|ECV65011|20000207|20000307|

ZZZ|3|51341339|

3) ECVN covering a single (long) day (multiple CDV records):

AAA|E0041001|D|20000204113055|EN|ECVNA1|EC|LOGICA|545873||

EDN|1095|0634343|1095|ECV65043|20000208|20000208|

CD9|1|100|

CD9|2|100|

CD9|3|110.323|

CD9|4|0.9|

CD9|5|0|

….

CD9|45|120|

CD9|46|0|

CD9|47|-120|

CD9|48|-120.5|

CD9|49|-121.0|

CD9|50|-121.0|

ZZZ|53|456423424|

3 External Interface Summary

This section provides convenient summary lists of the interfaces by system and by party or party agent type. Note that this section defines the default rules for distribution of reports: copies of other reports may be requested through BSCCo Ltd. using the Flexible Reporting procedure.

3.1 Interfaces by BSC Agent

3.1.1 BMRA Interfaces

The BMRA publishes balancing mechanism information to BSC Parties, including:

Balancing Mechanism Data
System Related Data
Derived Data
Replacement Reserve Data

The BMRA interfaces to BSC Parties, Agents and Market Index Data Providers are listed below. Note that the numbering convention for the interfaces includes internal interfaces and interfaces with other Service Providers (including the NETSO) which are not listed here because they are included in the IDD Part 2.

Agent-id	Name	Dirn	User	Type
BMRA-I004	Publish Balancing Mechanism Data	to	BMR Service User	BMRA Publishing Interface
BMRA-I005	Publish System Related Data	to	BMR Service User	BMRA Publishing Interface
BMRA-I006	Publish Derived Data	to	BMR Service User	BMRA Publishing Interface
BMRA-I019	Publish Credit Default Notices	to	BMR Service User	BMRA Publishing Interface
BMRA-I010	Data Exception Report	to	MIDP	Electronic data file transfer
BMRA-I015	Receive Market Index Data	from	MIDP	Electronic data file transfer
BMRA-I028	Receive REMIT Data	from	BMR Service User, NETSO	Electronic data file transfer
BMRA-I030	Publish REMIT Data	to	BMR Service User	BMRA Publishing Interface
BMRA-I031	Publish Transparency Regulation Data	to	BMR Service User, ENTSO-E	BMRA Publishing Interface
BMRA-I035	Publish Trading Unit Data	to	BMR Service User	BMRA Publishing Interface
BMRA-I037	Publish Replacement Reserve Data	to	BMR Service User	BMRA Publishing Interface

3.1.2 CDCA Interfaces

The CDCA interfaces to BSC Parties and Agents are listed below. Note that the numbering convention for the interfaces includes internal interfaces (which are not listed).

Agent-id	Name	Dirn	User	Type
CDCA-I001	Aggregation Rules	From	BSC Party	Manual
CDCA-I003	Meter Technical Data	From	MOA	Manual
CDCA-I003	Meter Technical Data	From	Registrant	Manual
CDCA-I004	Notify new Meter Protocol	To	MOA	Manual
CDCA-I005	Load New Meter Protocol	From	MOA	Manual
CDCA-I006	Meter Data for Proving Test	To	MOA	Manual
CDCA-I007	Proving Test Report/Exceptions	To	BSC Party	Manual
CDCA-I007	Proving Test Report/Exceptions	To	MOA	Manual
CDCA-I008	Obtain Metered Data from Metering Systems	From	Physical meters	Meter System Interface
CDCA-I009	Meter Period Data collected via site visit	From	Hand Held Device/Data Capture Device (MV-90)	Manual
CDCA-I010	Exception Report for missing and invalid meter period data	To	BSC Party	Electronic data file transfer
CDCA-I010	Exception Report for missing and invalid meter period data	To	MOA	Electronic data file transfer
CDCA-I011	Dial Readings from meter, for MAR	From	Hand Held Device/Data Capture Device (MV-90)	Manual
CDCA-I012	Report raw meter data	To	BSC Party	Electronic data file transfer
CDCA-I012	Report raw meter data	To	Distribution Business	Electronic data file transfer
CDCA-I013	Response to Estimated data	From	BSC Party	Manual
CDCA-I014	Estimated Data Report	To	BSC Party	Electronic data file transfer
CDCA-I014	Estimated Data Report	To	MOA	Electronic data file transfer
CDCA-I015	Reporting Metering Equipment Faults	From	MOA	Manual
CDCA-I017	Meter Reading Schedule for MAR	To	BSC Party	Manual
CDCA-I017	Meter Reading Schedule for MAR	To	MOA	Manual
CDCA-I018	MAR Reconciliation Report	To	BSC Party	Manual
CDCA-I018	MAR Reconciliation Report	To	Distribution Business	Manual
CDCA-I018	MAR Reconciliation Report	To	MOA	Manual
CDCA-I019	MAR Remedial Action Report	To	BSC Party	Manual
CDCA-I019	MAR Remedial Action Report	To	Distribution Business	Manual
CDCA-I019	MAR Remedial Action Report	To	MOA	Manual
CDCA-I021	Notification of Metering Equipment Work	From	MOA	Manual
CDCA-I025	Aggregation Rule Exceptions	To	BSC Party	Manual
CDCA-I026	Aggregated Meter Volume Exceptions	To	BSC Party	Manual
CDCA-I029	Aggregated GSP Group Take Volumes	To	BSC Party	Electronic data file transfer
CDCA-I029	Aggregated GSP Group Take Volumes	To	Distribution Business	Electronic data file transfer
CDCA-I030	Meter Period Data for Distribution Area	To	Distribution Business	Electronic data file transfer
CDCA-I037	Estimated Data Notification	To	BSC Party	Manual
CDCA-I037	Estimated Data Notification	To	MOA	Manual
CDCA-I038	Reporting Metering Equipment Faults	To	BSC Party	Manual
CDCA-I038	Reporting Metering Equipment Faults	To	MOA	Manual
CDCA-I041	Interconnector Aggregation Report	To	IA	Electronic data file transfer
CDCA-I042	BM Unit Aggregation Report	To	BSC Party	Electronic data file transfer
CDCA-I044	Meter System Proving Validation	From	MOA	Manual
CDCA-I045	Meter Data from routine work and Metering Faults	From	MOA/Data Capture Device (MV-90)	Manual
CDCA-I046	Site Visit Inspection Report	To	BSC Party	Manual
CDCA-I046	Site Visit Inspection Report	To	MOA	Manual
CDCA-I047	Correspondence Receipt Acknowledgement	To	BSC Party	Manual
CDCA-I048	Report of Aggregation Rules	To	BSC Party	Manual
CDCA-I051	Report Meter Technical Details	To	BSC Party,	Manual
CDCA-I051	Report Meter Technical Details	To	Distribution Business	Manual
CDCA-I051	Report Meter Technical Details	To	MOA	Manual
CDCA-I054	Meter Status Report	To	BSC Party,	Electronic data file transfer
CDCA-I054	Meter Status Report	To	Distribution Business	Electronic data file transfer
CDCA-I054	Meter Status Report	To	MOA,	Electronic data file transfer
CDCA-I055	`Transfer from SMRS information	From	BSC Party	Manual
CDCA-I057	Transfer to SMRS information	from	BSC Party	Manual
CDCA-I059	Initial Meter Reading Report	To	BSC Party	Manual
CDCA-I060	SVA Party Agent Details	From	SVA Registrant, CVA Registrant	Manual
CDCA-I067	Disconnected CVA BM Units	From	Distribution Businesses, NETSO	Manual

3.1.3 CRA Interfaces

The CRA interfaces to BSC Parties and Agents are listed below. Note that the numbering convention for the interfaces includes internal interfaces (which are not listed).

Agent-id	Name	Dirn	User	Type
CRA-I001	BSC Party Registration Data	from	BSC Party	Manual
CRA-I002	Interconnector Admin Registration Data	from	BSC Party	Manual
CRA-I003	BSC Party Agent Registration Data	from	BSC Party Agent	Manual
CRA-I005	BM Unit Registration Data	from	BSC Party	Manual
CRA-I006	Trading Unit Registration	from	BSC Party	Manual
CRA-I007	Boundary Point and System Connection Point Registration Data	from	DB	manual
CRA-I008	Interconnector Registration	from	Distribution Business	Manual
CRA-I012	CRA Encryption Key	to	BSC Party	Manual
CRA-I012	CRA Encryption Key	to	BSC Party Agent	Manual
CRA-I012	CRA Encryption Key	to	MIDP	Manual
CRA-I014	Registration Report	to	BSC Party	Electronic data file transfer
CRA-I014	Registration Report	to	BSC Party Agent	Electronic data file transfer
CRA-I021	Registered Service List	to	BSC Party	Electronic data file transfer
CRA-I021	Registered Service List	to	Public	Manual
CRA-I024	Certification and Accreditation Status Report	to	BSC Party	Electronic data file transfer
CRA-I024	Certification and Accreditation Status Report	to	BSC Party Agents	Electronic data file transfer
CRA-I027	GSP Group and GSP Registration	from	Distribution Business	Manual
CRA-I031	Metering System Data	from	BSC Party	Manual
CRA-I034	Flexible Reporting Request	from	BSC Party	Manual
CRA-I034	Flexible Reporting Request	from	BSC Party Agent	Manual
CRA-I034	Flexible Reporting Request	from	BSC Service Agent	Manual
CRA-I034	Flexible Reporting Request	from	BSCCo Ltd	Manual
CRA-I034	Flexible Reporting Request	from	NETSO	Manual
CRA-I038	Transfer from SMRS Information	from	BSC Party	Manual
CRA-I040	Transfer to SMRS Information	from	BSC Party	Manual
CRA-I048	GC Breach or DC Breach Notification	to	BSC Party, BSCCo	Manual
CRA-I049	GC Breach or DC Breach Estimation Challenge	from	BSC Party	Manual
CRA-I051	Notification of Breach Challenge Data	to	BSC Party	Manual

3.1.4 ECVAA Interfaces

The ECVAA interfaces to BSC Parties and Agents are listed below. Note that the numbering convention for the interfaces includes internal interfaces (which are not listed).

Agent-id	Name	Dirn	User	Type
ECVAA-I002	ECVNAA Data	from	BSC Party	Manual
ECVAA-I002	ECVNAA Data	from	ECVNA	Manual
ECVAA-I003	MVRNAA Data	from	BSC Party	Manual
ECVAA-I003	MVRNAA Data	from	MVRNA	Manual
ECVAA-I004	ECVN	from	ECVNA	Electronic data file transfer
ECVAA-I005	MVRNs	from	MVRNA	Electronic data file transfer
ECVAA-I007	ECVNAA Feedback	to	BSC Party	Manual / Electronic data file transfer
ECVAA-I007	ECVNAA Feedback	to	ECVNA	Manual / Electronic data file transfer
ECVAA-I008	MVRNAA Feedback	to	BSC Party	Manual / Electronic data file transfer
ECVAA-I008	MVRNAA Feedback	to	MVRNA	Manual / Electronic data file transfer
ECVAA-I009	ECVN Feedback (Rejection)	to	BSC Party	Electronic data file transfer
ECVAA-I009	ECVN Feedback (Rejection)	to	ECVNA	Electronic data file transfer
ECVAA-I010	MVRN Feedback (Rejection)	to	BSC Party	Electronic data file transfer
ECVAA-I010	MVRN Feedback (Rejection)	to	MVRNA	Electronic data file transfer
ECVAA-I013	Authorisation Report	to	BSC Party	Electronic data file transfer
ECVAA-I013	Authorisation Report	to	ECVNA	Electronic data file transfer
ECVAA-I013	Authorisation Report	to	MVRNA	Electronic data file transfer
ECVAA-I014	Notification Report	to	BSC Party	Electronic data file transfer
ECVAA-I014	Notification Report	to	ECVNA	Electronic data file transfer
ECVAA-I014	Notification Report	to	MVRNA	Electronic data file transfer
ECVAA-I021	Credit Limit Warning	to	BSC Party	Manual
ECVAA-I022	Forward Contract Report	to	BSC Party	Electronic data file transfer
ECVAA-I024	Credit Cover Minimum Eligible Amount Request	from	BSC Party	Manual
ECVAA-I025	Credit Cover Minimum Eligible Amount Report	to	BSC Party	Manual
ECVAA-I028	ECVN Acceptance Feedback	to	BSC Party	Electronic data file transfer
ECVAA-I028	ECVN Acceptance Feedback	to	ECVNA	Electronic data file transfer
ECVAA-I029	MVRN Acceptance Feedback	to	BSC Party	Electronic data file transfer
ECVAA-I029	MVRN Acceptance Feedback	to	MVRNA	Electronic data file transfer
ECVAA-I035	Forward Contract Report Start Period Override	from	BSC Party	Manual
ECVAA-I037	Receive Volume Notification Nullification Request	from	BSC Party	Manual
ECVAA-I038	Issue Volume Notification Nullification Confirmation Report	to	BSC Party	Manual
ECVAA-I039	Issue Nullification Completion Report	to	BSC Party	Manual
ECVAA-I042	Banning/Unbanning Individual User Access to the ECVAA Web Service	from	BSC Party ECVNA MVRNA	Manual
ECVAA-I043	ECVAA Web Service – BSC Party View ECVNs	to	BSC Party	Electronic
ECVAA-I044	ECVAA Web Service – BSC Party View MVRNs	to	BSC Party	Electronic
ECVAA-I045	ECVAA Web Service – ECVNA View ECVNs	to	ECVNA	Electronic
ECVAA-I046	ECVAA Web Service – MVRNA View MVRNs	to	MVRNA	Electronic

3.1.5 SAA Interfaces

The SAA interfaces to BSC Parties and Agents are listed below. Note that the numbering convention for the interfaces includes internal interfaces (which are not listed).

Agent-id	Name	Dirn	User	Type
SAA-I006	BM Unit Metered Volumes for Interconnector Users	from	IA	Electronic data file transfer
SAA-I012	Dispute Notification	from	BSC Party	Manual
SAA-I014	Settlement Reports	to	BSC Party	Electronic data file transfer
SAA-I016	Settlement Calendar	to	BSC Party	Manual
SAA-I016	Settlement Calendar	to	BSC Party Agent	Manual
SAA-I017	SAA Exception Reports	to	BSC Party (IA), MIDP	Electronic data file transfer
SAA-I018	Dispute Reports	to	BSC Party	Manual
SAA-I030	Receive Market Index Data	From	MIDP	Electronic data file transfer
SAA-I058	Aggregated Non-Chargeable Demand Report	To	BSC Party	Elexon Portal³

3.1.6 SVAA Interfaces

The SVAA interfaces to BSC Parties are listed below. Note that these flows are specific to Wider Access, Metering Behind the Boundary Point, VLPs, AMVLPs and Secondary BM Units, and transferred using the electronic data transfer mechanisms described in [COMMS]. All other interfaces between SVAA and BSC Parties for Supplier Volume Allocation purposes use the SVA transfer mechanisms described in the SVA Data Catalogue and are not defined in the IDD documents and spreadsheets.

Agent-id	Name	Dirn	User	Type
P0282	Delivered Volume Notification	from	VLP, AMVLP	Electronic data file transfer
P0283	Rejection of Delivered Volume	to	VLP, AMVLP	Electronic data file transfer
P0284	Confirmation of Delivered Volume	to	VLP, AMVLP	Electronic data file transfer
P0285	Delivered Volume Exception Report	to	VLP, AMVLP	Electronic data file transfer
P0287	Metering System Half Hourly Volume Adjustments	to	Supplier	Electronic data file transfer
P0288	Secondary Half Hourly Consumption Volumes	to	VLP, AMVLP	Electronic data file transfer
P0297	Asset Registration	from	AMVLP Supplier	Self-Service Gateway or email
P0298	Rejection of Asset Registration	to	AMVLP Supplier	Self-Service Gateway or email
P0299	Confirmation of Asset Registration	to	AMVLP Supplier	Self-Service Gateway or email
P0300	Registration of Asset Metering Agents	from	AMVLP Supplier	Self-Service Gateway or email
P0301	Rejection of Asset Metering Agents	to	AMVLP Supplier	Self-Service Gateway or email
P0302	Confirmation of Registration of Asset Metering Agents	to	AMVLP Supplier	Self-Service Gateway or email
P0303	Asset Meter Registration	from	AMVLP Supplier	Self-Service Gateway or email
P0304	Rejection of Asset Meter Registration	to	AMVLP Supplier	Self-Service Gateway or email
P0305	Confirmation of Asset Meter Registration	to	AMVLP Supplier	Self-Service Gateway or email
P0306	AMSID Pair Allocation to a Secondary BM Unit	from	AMVLP	Self-Service Gateway or email
P0307	Confirmation of AMSID Pair Allocation to a Secondary BM Unit	to	AMVLP	Self-Service Gateway or email
P0308	Rejection of AMSID Pair Allocation to a Secondary BM Unit	to	AMVLP	Self-Service Gateway or email
P0309	Notification of use of AMSID Pair by another AMVLP	to	AMVLP	Self-Service Gateway or email
P0310	Missing Metering System Data	to	HHDA, HHDC, AMVLP, Supplier	Electronic Data Transfer
P0311	Invalid Metering System Data	to	HHDA, HHDC, AMVLP, Supplier	Electronic Data Transfer
P0320	Loss of AMSID Pair Allocation	to	AMVLP	Self-Service Gateway or email
P0323	BM Unit Allocation Event Day	from	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0324	Rejection of BM Unit Allocation Event Day	to	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0325	Confirmation of BM Unit Allocation Event Day	to	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0326	BM Unit Allocation Baselining Detail	from	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0327	Rejection of BM Unit Baselining Allocation Detail	to	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0328	BM Unit Submitted Expected Volume Notification	from	AMVLP, VLP, Supplier	Electronic Data Transfer
P0329	BM Unit Submitted Expected Volume Rejection	to	AMVLP, VLP, Supplier	Electronic Data Transfer
P0330	BM Unit Submitted Expected Volume Acceptance	to	AMVLP, VLP, Supplier	Electronic Data Transfer
P0331	BM Unit Submitted Expected Volume Warning	to	AMVLP, VLP, Supplier	Electronic Data Transfer
P0333	Baselining Expected Volume Report	to	AMVLP, VLP, Supplier	Electronic Data Transfer
P0334	Confirmation of BM Unit Baselining Allocation Detail	to	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0335	BM Unit Baselining Status	from	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0336	Rejection of BM Unit Baselining Status	to	AMVLP, VLP, Supplier	Self-Service Gateway or email
P0337	Confirmation of BM Unit Baselining Status	to	AMVLP, VLP, Supplier	Self-Service Gateway or email

3.2 Interfaces by Corresponding Party

3.2.1 BSC Party Interfaces

The interfaces to BSC Parties in general are listed below.

Dir’n	User	Agent-id	Name	Type
to	BSC Party	BMRA flows	Publish Balancing Mechanism Reports	Publishing
from	BSC Party	CDCA-I001	Aggregation Rules	Manual
to	BSC Party	CDCA-I007	Proving Test Report/Exceptions	Manual
to	BSC Party	CDCA-I010	Exception Report for missing and invalid meter period data	Electronic data file transfer
to	BSC Party	CDCA-I012	Report raw meter data	Electronic data file transfer
from	BSC Party	CDCA-I013	Response to Estimated data	Manual
to	BSC Party	CDCA-I014	Estimated Data Report	Electronic data file transfer
to	BSC Party	CDCA-I017	Meter Reading Schedule for MAR	Manual
to	BSC Party	CDCA-I018	MAR Reconciliation Report	Manual
to	BSC Party	CDCA-I019	MAR Remedial Action Report	Manual
to	BSC Party	CDCA-I025	Aggregation Rule Exceptions	Manual
to	BSC Party	CDCA-I026	Aggregated Meter Volume Exceptions	Manual
to	BSC Party	CDCA-I029	Aggregated GSP Group Take Volumes	Electronic data file transfer
to	BSC Party	CDCA-I037	Estimated Data Notification	Manual
to	BSC Party	CDCA-I038	Reporting Metering Equipment Faults	Manual
to	BSC Party	CDCA-I042	BM Unit Aggregation Report	Electronic data file transfer
to	BSC Party	CDCA-I046	Site Visit Inspection Report	Manual
to	BSC Party	CDCA-I047	Correspondence Receipt Acknowledgement	Manual
to	BSC Party	CDCA-I048	Report of Aggregation Rules	Manual
to	BSC Party	CDCA-I051	Report Meter Technical Details	Manual
to	BSC Party	CDCA-I054	Meter Status Report	Electronic data file transfer
to	BSC Party	CDCA-I059	Initial Meter Reading Report	Manual
From	SVA Registrant, CVA Registrant	CDCA-I060	SVA Party Agent Details	Manual
from	BSC Party	CRA-I001	BSC Party Registration Data	Manual
from	BSC Party	CRA-I002	Interconnector Admin Registration Data	Manual
from	BSC Party	CRA-I005	BM Unit Registration Data	Manual
from	BSC Party	CRA-I006	Trading Unit Registration	Manual
From	DB	CRA-I007	Boundary Point and System Connection Point Registration Data	manual
to	BSC Party	CRA-I012	CRA Encryption Key	Manual
to	BSC Party	CRA-I014	Registration Report	Electronic data file transfer
to	BSC Party	CRA-I021	Registered Service List	Electronic data file transfer
to	BSC Party	CRA-I024	Certification and Accreditation Status Report	Electronic data file transfer
from	BSC Party	CRA-I031	Metering System Data	Manual
to	BSC Party	CRA-I048	GC or DC Breach Notification	Manual
from	BSC Party	CRA-I049	GC Breach or DC Breach Challenge	Manual
to	BSC Party	CRA-I051	Notification of Breach Challenge Data	Manual
from	BSC Party	ECVAA-I002	ECVNAA Data	Manual
from	BSC Party	ECVAA-I003	MVRNAA Data	Manual
to	BSC Party	ECVAA-I007	ECVNAA Feedback	Manual / Electronic data file transfer
to	BSC Party	ECVAA-I008	MVRNAA Feedback	Manual / Electronic data file transfer
to	BSC Party	ECVAA-I009	ECVN Feedback	Electronic data file transfer
to	BSC Party	ECVAA-I010	MVRN Feedback	Electronic data file transfer
to	BSC Party	ECVAA-I013	Authorisation Report	Electronic data file transfer
to	BSC Party	ECVAA-I014	Notification Report	Electronic data file transfer
to	BSC Party	ECVAA-I021	Credit Limit Warning	Manual
to	BSC Party	ECVAA-I022	Forward Contract Report	Electronic data file transfer
from	BSC Party	ECVAA-I024	Credit Cover Minimum Eligible Amount Request	Manual
to	BSC Party	ECVAA-I025	Credit Cover Minimum Eligible Amount Report	Manual
to	BSC Party	ECVAA-I028	ECVN Acceptance Feedback	Electronic data file transfer
to	BSC Party	ECVAA-I029	MVRN Acceptance Feedback	Electronic data file transfer
from	BSC Party	ECVAA-I035	Forward Contract Report Start Period Override	Manual
from	BSC Party	ECVAA-I037	Receive Volume Notification Nullification Request	Manual
to	BSC Party	ECVAA-I038	Issue Volume Notification Nullification Confirmation Report	Manual
to	BSC Party	ECVAA-I039	Issue Nullification Completion Report	Manual
from	BSC Party	CRA-I034	Flexible Reporting Request	Manual
from	BSC Party	SAA-I012	Dispute Notification	Manual
to	BSC Party	SAA-I014	Settlement Reports	Electronic data file transfer
to	BSC Party	SAA-I016	Settlement Calendar	Manual
to	BSC Party	SAA-I017	SAA Exception Reports	Electronic data file transfer
to	BSC Party	SAA-I018	Dispute Reports	Manual
to	BSC Party	SAA-I058	Aggregated Non-Chargeable Demand Report	Elexon Portal3
from	VLP, AMVLP	P0282	Delivered Volume Notification	Electronic data file transfer
to	VLP, AMVLP	P0283	Rejection of Delivered Volume	Electronic data file transfer
to	VLP, AMVLP	P0284	Confirmation of Delivered Volume	Electronic data file transfer
to	VLP, AMVLP	P0285	Delivered Volume Exception Report	Electronic data file transfer
to	BSC Party	P0287	Metering System Half Hourly Volume Adjustments	Electronic data file transfer
to	VLP, AMVLP	P0288	Secondary Half Hourly Consumption Volumes	Electronic data file transfer
from	AMVLP	P0297	Asset Registration	Self Service Gateway, Email
to	AMVLP	P0298	Rejection of Asset Registration	Self Service Gateway, Email
to	AMVLP	P0299	Confirmation of Asset Registration	Self Service Gateway, Email
from	AMVLP	P0300	AMVLP Agent Registration	Self Service Gateway, Email
to	AMVLP	P0301	Rejection of AMVLP Agent Registration	Self Service Gateway, Email
to	AMVLP	P0302	Confirmation of AMVLP Agent Registration	Self Service Gateway, Email
from	AMVLP	P0303	Registration of Asset Meters	Self Service Gateway, Email
to	AMVLP	P0304	Rejection of Asset Meter Registration	Self Service Gateway, Email
to	AMVLP	P0305	Confirmation of Asset Meter Registration	Self Service Gateway, Email
from	AMVLP	P0306	AMSID Pair Allocation to a Secondary BM Unit	Self Service Gateway, Email
to	AMVLP	P0307	Rejection of AMSID Pair Allocation to a Secondary BM Unit	Self Service Gateway, Email
to	AMVLP	P0308	Confirmation of AMSID Pair Allocation to a Secondary BM Unit	Self Service Gateway, Email
to	AMVLP	P0309	Notification of use of AMSID Pair by another AMVLP	Self Service Gateway, Email
to	HHDA,HHDC, AMVLP	P0310	Missing Metering System Data	Electronic Data Transfer
to	HHDA,HHDC, AMVLP	P0311	Invalid Metering System Data	Electronic Data Transfer
to	AMVLP	P320	Loss of AMSID Pair Allocation	Self Service Gateway, Email

Interfaces specific to distribution businesses are listed below:

Dir’n	User	Agent-id	Name	Type
to	Distribution Business	CDCA-I012	Report raw meter data	Electronic data file transfer
to	Distribution Business	CDCA-I018	MAR Reconciliation Report	Manual
to	Distribution Business	CDCA-I019	MAR Remedial Action Report	Manual
to	Distribution Business	CDCA-I029	Aggregated GSP Group Take Volumes	Electronic data file transfer
to	Distribution Business	CDCA-I030	Meter Period Data for Distribution Area	Electronic data file transfer
to	Distribution Business	CDCA-I051	Report Meter Technical Details	Manual
to	Distribution Business	CDCA-I054	Meter Status Report	Electronic data file transfer
from	Distribution Business	CDCA-I067	Disconnected BM Units	Manual
from	Distribution Business	CRA-I008	Interconnector Registration	Manual
from	Distribution Business	CRA-I027	GSP Group and GSP Registration	Manual

Interfaces specific to the Interconnector Administrator are listed below:

Dir’n	User	Agent-id	Name	Type
to	IA	CDCA-I041	Interconnector Aggregation Report	Electronic data file transfer
from	IA	SAA-I006	BM Unit Metered Volumes for Interconnector Users	Electronic data file transfer
to	IA	SAA-I017	SAA Exception Reports	Electronic data file transfer

For completeness, interfaces specific to meter reading are listed below:

Dir’n	User	Agent-id	Name	Type
from	Physical meters	CDCA-I008	Obtain Metered Data from Metering Systems	Meter System Interface
from	Hand Held Device/Data Capture Device (MV-90)	CDCA-I009	Meter Period Data collected via site visit	Manual
from	Hand Held Device/Data Capture Device (MV-90)	CDCA-I011	Dial Readings from meter, for MAR	Manual
from	MOA/Data Capture Device (MV-90)	CDCA-I045	Meter Data from routine work and Metering Faults	Manual

3.2.2 BSC Party Agent Interfaces

The interfaces specific to BSC Party Agents in general are listed below.

Dir’n	User	Agent-id	Name	Type
from	BSC Party Agent	CRA-I003	BSC Party Agent Registration Data	Manual
to	BSC Party Agent	CRA-I012	CRA Encryption Key	Manual
to	BSC Party Agent	CRA-I014	Registration Report	Electronic data file transfer
To	BSC Party Agent	CRA-I024	Certification and Accreditation Status Report	Electronic data file transfer
from	BSC Party Agent	CRA-I034	Flexible Reporting Request	Manual
to	BSC Party Agent	SAA-I016	Settlement Calendar	Manual

Interfaces specific to Meter Operator Agents are listed below:

Dir’n	User	Agent-id	Name	Type
to	MOA	TAA-I006	Notification of Metering Systems to be subject to site visits and request for site details	Manual
to	MOA	TAA-I024	Rectification Plan Response	Manual
from	MOA	CDCA-I003	Meter Technical Data	Manual
to	MOA	CDCA-I004	Notify new Meter Protocol	Manual
from	MOA	CDCA-I005	Load New Meter Protocol	Manual
to	MOA	CDCA-I006	Meter Data for Proving Test	Manual
to	MOA	CDCA-I007	Proving Test Report/Exceptions	Manual
to	MOA	CDCA-I010	Exception Report for missing and invalid meter period data	Electronic data file transfer
to	MOA	CDCA-I014	Estimated Data Report	Electronic data file transfer
from	MOA	CDCA-I015	Reporting Metering Equipment Faults	Manual
to	MOA	CDCA-I017	Meter Reading Schedule for MAR	Manual
to	MOA	CDCA-I018	MAR Reconciliation Report	Manual
to	MOA	CDCA-I019	MAR Remedial Action Report	Manual
from	MOA	CDCA-I021	Notification of Metering Equipment Work	Manual
to	MOA	CDCA-I037	Estimated Data Notification	Manual
to	MOA	CDCA-I038	Reporting Metering Equipment Faults	Manual
from	MOA	CDCA-I044	Meter System Proving Validation	Manual
from	MOA	CDCA-I045	Meter Data from routine work and Metering Faults	Manual
to	MOA	CDCA-I046	Site Visit Inspection Report	Manual
to	MOA	CDCA-I051	Report Meter Technical Details	Manual
to	MOA	CDCA-I054	Meter Status Report	Electronic data file transfer

Interfaces specific to Meter Volume Reallocation Notification Agents are listed below:

Dir’n	User	Agent-id	Name	Type
from	MVRNA	ECVAA-I003	MVRNAA Data	Manual
from	MVRNA	ECVAA-I005	MVRNs	Electronic data file transfer
to	MVRNA	ECVAA-I008	MVRNAA Feedback	Manual / Electronic data file transfer
to	MVRNA	ECVAA-I010	MVRN Feedback	Electronic data file transfer
to	MVRNA	ECVAA-I013	Authorisation Report	Electronic data file transfer
to	MVRNA	ECVAA-I014	Notification Report	Electronic data file transfer
to	MVRNA	ECVAA-I029	MVRN Acceptance Feedback	Electronic data file transfer

Interfaces specific to ECVN Agents are listed below:

Dir’n	User	Agent-id	Name	Type
from	ECVNA	ECVAA-I002	ECVNAA Data	Manual
from	ECVNA	ECVAA-I004	ECVN	Electronic data file transfer
to	ECVNA	ECVAA-I007	ECVNAA Feedback	Manual / Electronic data file transfer
to	ECVNA	ECVAA-I009	ECVN Feedback	Electronic data file transfer
to	ECVNA	ECVAA-I013	Authorisation Report	Electronic data file transfer
to	ECVNA	ECVAA-I014	Notification Report	Electronic data file transfer
to	ECVNA	ECVAA-I028	ECVN Acceptance Feedback	Electronic data file transfer

3.2.3 Market Index Data Provider Interfaces

The interfaces to Market Index Data Providers in general are listed below:

Dir’n	User	Agent-id	Name	Type
to	MIDP	CRA-I012	CRA Encryption Key	Manual
to	MIDP	BMRA-I010	Data Exception Report	Electronic data file transfer
from	MIDP	BMRA-I015	Market Index Data	Electronic data file transfer
to	MIDP	SAA-I017	SAA Exception Report	Electronic data file transfer
from	MIDP	SAA-I030	Market Index Data	Electronic data file transfer

4 BMRA External Inputs and Outputs

The outputs from BMRA which are presented to users are available in two formats - near real time broadcast of data using TIBCO messaging software and data download files available from the BMRA web site. The TIBCO type messages are available only on the High Grade Service, whereas the data files for download are obtainable from both the High Grade Service and the Low Grade Service.

The precise nature of the data available is specified in the BMRA URS. As noted in section 2.1.4, some of this data is provided via a publishing interface and it is not appropriate to include the physical structure of the screens data in this document.

Sections 4.1 to 4.3 comprise the logical definition of the data. Section 4.4 gives information on the contents of the raw data published in TIB message format from the BMRA High Grade Service, and section 4.5 gives information on the contents of the data files which are available for download from both the BMRA High Grade Service and the BMRA Low Grade Service web sites.

4.1 BMRA-I004: (output) Publish Balancing Mechanism Data

Interface ID:

BMRA-I004

User:

BMR Service User

Title:

Publish Balancing Mechanism Data

BSC reference:

BMRA SD 8.2, P71, P217

Mechanism:

BMRA Publishing Interface

Frequency:

Continuous (as made available from the NETSO)

Volumes:

Between 1000 - 5000 BM units. In each settlement period, at least 1 FPN data, 1 dynamic data and 1 Bid-Offer Acceptance per BM unit. At most 10 Bid-Offer Pairs per BM unit (estimated 1000) that receives bids and offers.

Up to 5000 Balancing Services Volume data items per day.

Interface Requirement:

The BMRA Service shall publish Balancing Mechanism data continuously, as it is received from the NETSO.

The Balancing Mechanism data consists of the following:

Gate Closure Data

Acceptance and Balancing Services Data

Declaration Data

The following breakdown summarises the details which will be available.

4.1.1 Gate Closure Data

Point FPN Data

BM Unit ID

Time From

Level From (MW)

Time To

Level To (MW)

Point Quiescent FPN Data

BM Unit ID

Time From

Level From (MW)

Time To

Level To (MW)

Bid-Offer Data:

BM Unit ID

Time From

Time To

Bid-Offer Pair Number

Level From (MW)

Level To (MW)

Offer Price (£/MWh)

Bid Price (£/MWh)

Maximum Export Limit:

BM Unit ID

Time From

Maximum Export Level From (MW)

Time To

Maximum Export Level To (MW)

Maximum Import Limit:

BM Unit ID

Time From

Maximum Import Level From (MW)

Time To

Maximum Import Level To (MW)

4.1.2 Acceptance and Balancing Services Data

For Settlement Dates prior to the P217 effective date:

Bid-Offer Acceptance Level Data:

BM Unit ID

Acceptance Time

Deemed Acceptance Flag

Time From

Level From (MW)

Time To

Level To (MW)

For Settlement Dates on or after the P217 effective date:

Bid-Offer Acceptance Level Flagged Data:

BM Unit ID

Acceptance Time

Deemed Acceptance Flag

SO-Flag

Time From

Level From (MW)

Time To

Level To (MW)

Acceptance STOR Provider Flag (for dates after the P217 effective date and before the P305 effective date the STOR Provider Flag will be reported as null)

Applicable Balancing Services Volume Data

BM Unit ID

Settlement Date

Settlement Period

Applicable Balancing Services Volume (MWh)

4.1.3 Declaration Data

Run Up Rates Export

BM Unit ID

Effective Time

Run-Up Rate 1 (MW / minute)

Run-Up Elbow 2 (MW)

Run-Up Rate 2 (MW / minute)

Run-Up Elbow 3 (MW)

Run-Up Rate 3 (MW / minute)

Run Up Rates Import

BM Unit ID

Effective Time

Run-Up Rate 1 (MW / minute)

Run-Up Elbow 2 (MW)

Run-Up Rate 2 (MW / minute)

Run-Up Elbow 3 (MW)

Run-Up Rate 3 (MW / minute)

Run Down Rates Export

BM Unit ID

Effective Time

Run-Down Rate 1 (MW / minute)

Run-Down Elbow 2 (MW)

Run-Down Rate 2 (MW / minute)

Run-Down Elbow 3 (MW)

Run-Down Rate 3 (MW / minute)

Run Down Rates Import

BM Unit ID

Effective Time

Run-Down Rate 1 (MW / minute)

Run-Down Elbow 2 (MW)

Run-Down Rate 2 (MW / minute)

Run-Down Elbow 3 (MW)

Run-Down Rate 3 (MW / minute)

Notice to Deviate from Zero

BM Unit ID

Effective Time

Notice To Deviate From Zero (Minutes)

Notice to Deliver Offers

BM Unit ID

Effective Time

Notice to Deliver Offers (Minutes)

Notice to Deliver Bids

BM Unit ID

Effective Time

Notice to Deliver Bids (Minutes)

Minimum Zero Time

BM Unit ID

Effective Time

Minimum Zero Time (Minutes)

Minimum Non-Zero Time

BM Unit ID

Effective Time

Minimum Non-Zero Time (Minutes)

Stable Export Limit

BM Unit ID

Effective Time

Stable Export Limit (MW)

Stable Import Limit

BM Unit ID

Effective Time

Stable Import Limit (MW)

Maximum Delivery Volume

BM Unit ID

Effective Time

Maximum Delivery Limit (MWh)

Maximum Delivery Period

BM Unit ID

Effective Time

Maximum Delivery Period (Minutes)

Physical Interface Details:

4.2 BMRA-I005: (output) Publish System Related Data

Interface ID:

BMRA-I005

User:

BMR Service User

Title:

Publish System Related Data

BSC reference:

BMRA SD 7.2, P8, P78, P172, P219, P220, P217, P243, P244, CP1333, CP1367, P399

Mechanism:

BMRA Publishing Interface

Frequency:

Continuous (as made available from the NETSO)

Volumes:

Various

Interface Requirement:

The BMRA Service shall publish System data continuously, as it is received from the NETSO.

The System Related data consists of the following:

Indicated Generation

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Sum of PN Generation (MW)

Indicated Demand

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Sum of PN Demand (MW)

National Demand Forecast⁴

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Demand (MW)

Transmission System Demand Forecast⁵

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Demand (MW)

Initial National Demand Out-Turn

Publishing Period Commencing Time

Start Time of ½ Hour Period

Demand (MW)

Initial Transmission System Demand Out-Turn

Publishing Period Commencing Time

Start Time of ½ Hour Period

Demand (MW)

National Demand Forecast Day, 2-14 Day

Publishing Period Commencing Time

Day of Forecast

Demand (MW)

Transmission System Demand Forecast Day, 2-14 Day

Publishing Period Commencing Time

Day of Forecast

Demand (MW)

National Demand Forecast Week, 2-52 Week

Publishing Period Commencing Time

Calendar Week Number

Demand (MW)

National Surplus Forecast, 2-156 Week

Publishing Period Commencing Time

Calendar Week Number

Surplus (MW)

Transmission System Demand Forecast Week, 2-52 Week

Publishing Period Commencing Time

Calendar Week Number

Demand (MW)

National Surplus Forecast, 2-14 Day

Publishing Period Commencing Time

Day of Forecast

Surplus (MW)

National Surplus Forecast, 2-52 Week

Publishing Period Commencing Time

Calendar Week Number

Surplus (MW)

Indicated Margin

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Margin (MW)

Indicated Imbalance

Publishing Period Commencing Time

Start Time of ½ Hour Period

National/Boundary Identifier

Imbalance Value (MW)

National Output Usable, 2-14 Day

Publication Time

System Zone

Settlement Date

Output Usable (MW)

National Output Usable by Fuel Type, 2-14 Day

Fuel Type

Publication Time

System Zone

Settlement Date

Output Usable (MW)

National Output Usable by Fuel Type and BM Unit, 2-14 Day

BM Unit

Fuel Type

Publication Time

System Zone

Settlement Date

Output Usable (MW)

National Output Usable, 2-52 Week

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

National Output Usable, 2-156 Week

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

National Output Usable by Fuel Type, 2-52 Week

Fuel Type

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

National Output Usable by Fuel Type, 2-156 Week

Fuel Type

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

National Output Usable by Fuel Type and BM Unit, 2-52 Week

BM Unit

Fuel Type

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

National Output Usable by Fuel Type and BM Unit, 2-156 Week

BM Unit

Fuel Type

Publication Time

System Zone

Calendar Week Number

Calendar Year

Output Usable (MW)

Generating Plant Demand Margin, 2-14 Days

Publication Time

Settlement Date

Generating Plant Demand Margin (MW)

Generating Plant Demand Margin, 2-52 Weeks

Publication Time

Calendar Week Number

Generating Plant Demand Margin (MW)

Generating Plant Demand Margin, 2-156 Weeks

Publication Time

Calendar Week Number

Generating Plant Demand Margin (MW)

System Zone Map

NGC-BSC BM Unit Mapping

System Warnings

SO-SO Prices

Balancing Services Adjustment Data:

Settlement Date

Settlement Period

Net Energy Buy Price Cost Adjustment (EBCA) (£)

Net Energy Buy Price Volume Adjustment (EBVA) (MWh)

Net System Buy Price Volume Adjustment (SBVA) (MWh)

Buy Price Price Adjustment (BPA) (£/MWh)

Net Energy Sell Price Cost Adjustment (ESCA) (£)

Net Energy Sell Price Volume Adjustment (ESVA) (MWh)

Net System Sell Price Volume Adjustment (SSVA) (MWh)

Sell Price Price Adjustment (SPA) (£/MWh)

Balancing Services Adjustment Action Data (for Settlement Dates after, and including the P217 effective date):

Settlement Date

Settlement Period

Balancing Services Adjustment Action ID (unique for Settlement Period)

Balancing Services Adjustment Action Cost (£)

Balancing Services Adjustment Action Volume (MWh)

Balancing Services Adjustment Action SO-Flag (T/F)

Balancing Services Adjustment Action STOR Flag (T/F) (for dates after the P217 effective date and before the P305 effective date the STOR Provider Flag will be reported as null)

Balancing Services Adjustment Action Data (for Settlement Dates after, and including the P399 effective date):

BSAD Party Id

BSAD Asset Id

Tendered Status

Service Type

Market Index Data:

Market Index Data Provider Identifier

Settlement Date

Settlement Period (1-50)

Market Index Price

Market Index Volume

Missing Market Index Data Messages

Temperature Data

Publishing Period Commencing Time

Settlement Date

Outturn Temperature (degrees Celsius)

Normal Reference Temperature (degrees Celsius)

High Reference Temperature (degrees Celsius)

Low Reference Temperature (degrees Celsius)

Wind Generation Forecast

Publishing Period Commencing Time

Start Time of ½ Hour Period

Generation Forecast (MW)

Total Registered Capacity (MW)

Instantaneous Generation By Fuel Type

Publishing Period Commencing Time

Start Time of ½ Hour Period

Spot Time

Fuel Type – ID representing one of:

CCGT

Oil Plant

OCGT

Coal

Nuclear

Power Park Module

Pumped Storage Plant

Non Pumped Storage Hydro Plant

External Interconnector Flows from France to England

External Interconnector Flows from Northern Ireland to Scotland

External Interconnector Flows from the Netherlands to England

External Interconnector Flows from Ireland to Wales

External Interconnector Flows from Belgium to England

Biomass

Other

Generation (MW)

Half Hourly Generation By Fuel Type

Publishing Period Commencing Time

Start Time of ½ Hour Period

Fuel Type – ID representing one of:

CCGT

Oil Plant

OCGT

Coal

Nuclear

Power Park Module

Pumped Storage Plant

Non Pumped Storage Hydro Plant

External Interconnector Flows from France to England

External Interconnector Flows from Northern Ireland to Scotland

External Interconnector Flows from the Netherlands to England

External Interconnector Flows from Ireland to Wales

External Interconnector Flows from Belgium to England

Biomass

Other

Generation (MW)

Daily Energy Volume Data

Publishing Period Commencing Time

Settlement Date

Outturn Volume (MWh)

Normal Volume (MWh)

High Volume (MWh)

Low Volume (MWh)

Realtime Transmission System Frequency Data

Publishing Period Commencing Time

Spot Time

Frequency (Hz)

Non-BM STOR Out-Turn

Publishing Period Commencing Time

Start Time of ½ Hour Period

Non-BM STOR Volume (MWh)

Loss of Load Probability and De-rated Margin

Settlement Date

Settlement Period

1200 Forecast – LoLP and DRM

8 hour forecast – LoLP and DRM

4 hour forecast – LoLP and DRM

2 hour forecast – LoLP and DRM

1 hour forecast – LoLP and DRM

Demand Control Instruction

Demand Control ID

Affected DSO

Instruction Sequence

Demand Control Event Flag

Time From

Time To

Demand Control Level

SO-Flag

STOR Availability Window

Season Year

Season Number

STOR Availability Dates

Weekday Start Time

Weekday End Time

Non-weekday Start Time

Non-weekday End Time

The System Warnings functionality will be utilised, within existing constraints, to report the issuing of all Emergency Instructions, and to notify whether or not each instruction should be treated as an Excluded Emergency Acceptance.

Balancing Services Adjustment Data for Settlement Dates after, and including the P217 effective date will always have a value of zero for the following data items:

Net Energy Buy Price Cost Adjustment (EBCA)

Net Energy Buy Price Volume Adjustment (EBVA)

Net System Buy Price Volume Adjustment (SBVA)

Net Energy Sell Price Cost Adjustment (ESCA)

Net Energy Sell Price Volume Adjustment (ESVA)

Net System Sell Price Volume Adjustment (SSVA)

Physical Interface Details:

Within the Balancing Services Adjustment Action Data the SO-Flag will be set to ‘T’ where the associated Action has been flagged by the NETSO as potentially impacted by transmission constraints.

4.3 BMRA-I006: (output) Publish Derived Data

Interface ID:

BMRA-I006

User:

BMR Service User

Title:

Publish Derived Data

BSC reference:

BMRA SD 9.1, CP560, P18A, P78, P217, CP1333, P305, CP1517

Mechanism

BMRA Publishing Interface

Frequency:

Once, for each settlement period.

Volumes:

Between 1000 - 5000 BM units. In each settlement period, at least 1 FPN data and 1 Bid-Offer Acceptance per BM unit. At most 12 Bid-Offer Pairs per BM unit (estimated 1000) that receives bids and offers.

Interface Requirement:

The BMRA Service shall normally publish Derived data once for each settlement period, as soon as it is calculated. Where as a result of an outage, calculations have been based on incomplete or incorrect data from the NETSO, derived data may be republished.

The Derived data shall include:

Derived BM Unit Data (for all Settlement Dates)

Period Bid and Offer Acceptance Volumes (QAB^kn_ij, QAO^kn_ij and CADL Flag)

Estimated Period Balancing Mechanism Bid and Offer Cashflows (CBⁿ_ij and CO ⁿ_ij)

Derived BM Unit Data (for Settlement Dates prior to the P217 effective date)

Estimated Period BM Unit Total Accepted Bid and Offer Volume (QABⁿ_ij and QAOⁿ_ij)

Derived BM Unit Data (for Settlement Dates after, and including the P217 effective date)

Estimated Period BM Unit Original Accepted Bid and Offer Volume (QABⁿ_ij and QAOⁿ_ij)

Estimated Period BM Unit Tagged Accepted Bid and Offer Volume (QTABⁿ_ij and QTAOⁿ_ij)

Estimated Period BM Unit Repriced Accepted Bid and Offer Volume (QRABⁿ_ij and QRAOⁿ_ij)

Estimated Period BM Unit Originally-Priced Accepted Bid and Offer Volume (QOABⁿ_ij and QOAOⁿ_ij)

Derived System-wide Data (for Settlement Dates prior to the P217 effective date)

Estimated System Sell/Buy Prices (SBP_j and SSP_j)

Price Derivation Code (PDC_j)

Indicative Net Imbalance Volume (NIV_j)

Total Accepted Bid Volume and Total Accepted Offer Volume

Total Unpriced Accepted Bid Volume and Total Unpriced Accepted Offer Volume

Total Priced Accepted Bid Volume and Total Priced Accepted Offer Volume

Total Bid Volume and Total Offer Volume

Derived System-wide Data (for Settlement Dates after, and including the P217 effective date)

Estimated System Sell/Buy Prices (SBP_j and SSP_j)

Price Derivation Code (PDC_j)

Indicative Net Imbalance Volume (NIV_j)

Replacement Price (RP_j)

Replacement Price Calculation Volume (RPV_j)

Total Accepted Bid Volume

Total Accepted Offer Volume

Tagged Accepted Bid Volume

Tagged Accepted Offer Volume

Total Adjustment Buy Volume

Total Adjustment Sell Volume

Tagged Adjustment Buy Volume

Tagged Adjustment Sell Volume

Reserve Scarcity Price (for dates after the P217 effective date and before the P305 effective date the STOR Provider Flag will be reported as null)

The BMRA Service shall publish details of the Indicative System Price Stacks once for each Settlement Period. This will detail all items on both the Buy and Sell Stacks including a description of the ordering of items within each stack. Each stack item will have the following data reported against it:

Indicative System Price Stack Item (see below for further details)

Index

Component Identifier

Acceptance Number

Bid-Offer Pair Number

CADL Flag (T/F)

SO-Flag (T/F)

Acceptance STOR Provider Flag (T/F)

Repriced Indicator (T/F)

Bid-Offer Original Price (£/MWh)

Volume (MWh)

DMAT Adjusted Volume (MWh)

Arbitrage Adjusted Volume (MWh)

NIV Adjusted Volume (MWh)

PAR Adjusted Volume (MWh)

Reserve Scarcity Price (£/MWh)

Stack Item Original Price (£/MWh)

Final Price (£/MWh)

Transmission Loss Multiplier

TLM Adjusted Volume (MWh)

TLM Adjusted Cost (£)

Notes:

i. The Index will be a unique positive integer representing the item’s relative position in the stack. The first item in the stack has an index of 1. The reported ordering of items reflects the final order of the stack.

ii. The Component Identifier will hold any of the following: the associated BM Unit’s Identifier for Acceptance Volume stack items, the NETSO allocated ID for Disaggregated BSAD stack items or a unique ID that BSC Agent System derives for Demand Control Volume stack items, a specific identifier for Replacement Reserve actions and Volume of GB Need Met,.

iii. For Disaggregated BSAD and Demand Control Volume stack items no Acceptance Number and Bid Offer Pair Number values will be reported.

iv. The Repriced Indicator will reflect whether or not the stack item has been repriced.

v. The Price value will be the final derived price for the stack item as used to derive the TLM Adjusted Cost (i.e. it will be the Replacement Price where appropriate).

vi. The various “Adjusted Volume” values will be that part of the original volume that remains untagged after applying the associated process – e.g. PAR Adjusted Volume will be that volume which remains untagged after having carried out PAR Tagging.

vii. The Transmission Loss Multiplier will be the Transmission Loss Multiplier for the stack item’s associated BM Unit. For Disaggregated BSAD stack items, which have no associated BM Unit, this will always be a value of 1.

viii. TLM Adjusted Volume = PAR Adjusted Volume x TLM

ix. TLM Adjusted Cost = PAR Adjusted Volume x TLM x Price

x. The Bid-Offer Original Price is the Bid or Offer Price associated to the System Action based on its associated Bid-Offer Data or Balancing Services Adjustment Data sent by the NETSO. For STOR Actions, the Bid-Offer Original Price is sometimes referred to as the Utilisation Price.

xi. The Reserve Scarcity Price will be null for System Actions that are not STOR Actions.

xii. The Stack Item Original Price is a System Action’s initial price when first added to a price stack (i.e. the System Action Price (SAP)). Typically the Stack Item Original Price will be equal to the Bid-Offer Original Price except if it is a STOR Action in which case it will be the greater of the Bid-Offer Original Price and the Reserve Scarcity Price.

For a full derivation of the various data items, refer to the Indicative System Price Calculation in the BMRA URS.

Derived data will be published for each Settlement Period within <CADL> + 15 (parameterised) minutes from the end of the Settlement Period.

Physical Interface Details:

See SAA URS for Price Derivation Codes.

4.3.1 Indicative System Price Stack Data

For a full definition of what the variables mean and their derivation, refer to the Indicative System Price Calculation in the BMRA URS.

Each stack (Buy or Sell) will consist of a number of stack items listed in descending price order. Each stack item’s data consists of the following:

Data Item	Description
Index	A unique positive integer representing the item’s relative position in the stack. The first item in the stack has an index of 1. The reported ordering of items reflects the final order of the stack.
Component Identifier	For Acceptance Volume stack items the Component Identifier will represent the associated BM Unit’s Identifier. For Balancing Services Adjustment Action stack items Component Identifier will represent the NETSO allocated ID. For Replacement Reserve actions, the Component Identifier will take the form ‘RRAUSB’ and ‘RRAUSS’ for the Buy and Sell stacks respectively. For Volume of GB Need Met, the Component Identifier will take the form of ‘Q1’ and ‘Q2’ for each of the Quarter Hour periods within the Settlement Period. For Demand Control Volume stack items a unique ID that the BSC Agent’s System derives.
Acceptance Number	Only reported for Acceptance Volume stack items (null for Balancing Services Adjustment Action and Demand Control Volume stack items.)
Bid-Offer Pair Number	Only reported for Acceptance Volume stack items (null for Balancing Services Adjustment Action and Demand Control Volume stack items.)
CADL Flag	A value of ‘T’ indicates where an Acceptance stack item is considered to be a Short Duration Acceptance.
SO-Flag	A value of ‘T’ indicates where the NETSO has flagged this stack item as potentially impacted by transmission constraints.
STOR Provider Flag	A value of ‘T’ indicates where the NETSO has flagged this stack item as relating to STOR Providers. This flag only indicates that the action MAY be a STOR Action.
Repriced Indicator	A value of ‘T’ indicates where a stack item has been repriced.
Bid-Offer Original Price	The Offer or Bid Price or BSAA Cost of the stack item (£/MWh) as reported in the original BOD or BSAD
Reserve Scarcity Price	For a particular Settlement Period, the price determined as the product of VOLL and LoLP.
Stack Item Original Price	The original price of the stack item (£/MWh), typically the Stack Item Original Price will be equal to the Bid-Offer Original Price except if it is a STOR Action in which case it will be the greater of the Bid-Offer Original Price and the Reserve Scarcity Price.
Volume	The initial volume of the stack item (MWh).
DMAT Adjusted Volume	The volume of the stack item which is not considered to be impacted by DMAT (MWh).
Arbitrage Adjusted Volume	The volume of the stack item which is not impacted by Arbitrage (MWh).
NIV Adjusted Volume	The volume of the stack item which is not NIV tagged (MWh).
PAR Adjusted Volume	The volume of the stack item which is not PAR tagged (MWh).
Final Price	The final price of the stack item (as used to determine the TLM Adjusted Cost) (£/MWh).
Transmission Loss Multiplier	The Transmission Loss Multiplier associated with the stack item. For Acceptance Volume stack items this will be determined from the related BM Unit. For Balancing Services Adjustment Action stack items This will be considered to be 1.
TLM Adjusted Volume	PAR Adjusted Volume x TLM (MWh)
TLM Adjusted Cost	TLM Adjusted Volume x Price (£)

4.4 BMRA-I019: (output) Publish Credit Default Notices

Interface ID:

BMRA-I019

User:

BMR Service User

Title:

Publish Credit Default Notices

BSC reference:

CP703

Mechanism:

BMRA Publishing Interface

Frequency:

Ad-Hoc

Volumes:

Low.

Interface Requirement:

The BMRA Service shall publish Credit Default Notices, as they are received from the ECVAA.

Credit Default Notices shall include all data listed in BMRA-I018, i.e.:

Credit Default Notice:

BSC Party ID

Credit Default Level

Entered Default Settlement Day

Entered Default Settlement Period

Cleared Default Settlement Day

Cleared Default Settlement Period

Cleared Default Reason

Notes:

1. The Credit Default Level may be one of the following:

Level 1 Default;
Level 2 Default;

2. The Entered Settlement Day and Entered Settlement Period indicate when the BSC Party entered the reported default level.

3. The Cleared Settlement Day and Cleared Settlement Period indicate when the BSC Party cleared the reported default level.

4. The Cleared Default Reason indicates why the Party cleared default as supplied by ECVAA.

Data shall be published according to the formats defined in BMRA URS Appendix C. For more information please refer to the BMRA System Specification and Design Specification.

Credit Default Notices will be published 3 (parameterised) times at 20 minute (parameterised) intervals after receipt.

Physical Interface Details:

4.5 BMRA-I010: (output) BMRA Data Exception Reports

Interface ID:

BMRA-I010

User:

NETSO, BSCCo Ltd, CRA, MIDP

Title:

BMRA Data Exception Reports

BSC reference:

BMRA SD 6.2, 7.3, 8.3, 8.4, P78

Mechanism:

Electronic data file transfer

Frequency:

Continuous

Volumes:

The BMRA Service shall issue Exception Reports to the NETSO, BSCCo Ltd, MIDPs or CRA if an input message fails validation, or if insufficient data has been received or, in the case of Adjustment Data, if a system parameter is set to indicate that an exception file is required. This covers errors in all message types.

The exception reports shall include:

Header of file being processed

File Type

Creation Time

From Role Code

From Participant Id

To Role Code

To Participant Id

Sequence Number

Test Data Flag

Header of NGC file being processed

NGC Filename

BMRA Data Exceptions

Exception Type

Exception Description

The header of file being processed may be a NETA File Header, a NGC File Header, or it may be omitted if, for example, the exception is that a file is missing.

The exception type may be one of the following:

Balancing Mechanism data incomplete
Input file validation error

Note that the file may contain one or many exception descriptions. A file may contain several problems, all of which will be reported in the one file. For example, exceptions on a FPN file may be reported against two different BMU identifiers which are not recognised by BMRA.

4.6 BMRA-I015: (input) Receive Market Index Data

Interface ID:

BMRA-I015

Source:

MIDP

Title:

Receive Market Index Data

BSC reference:

P78

Mechanism:

Automatic

Frequency:

Continuous for each Settlement Period

Volumes:

Up to 5 Providers, each sending data for each Settlement Period. Each Provider will submit either 1 file per period, or 1 file per day.

Interface Requirement:

The BMRA shall receive Market Index Data, from Market Index Data Providers, for each Settlement Period.

The flow shall include:

Market Index Data

Market Index Data Provider ID

Settlement Date

Settlement Period Market Index Data (1-50)

Settlement Period

Market Index Price

Market Index Volume

Traded Price (to be ignored)

Traded Volume (to be ignored)

Note:

1. Data submitted after the related period’s Indicative System Buy and Sell Price calculation has begun will be rejected.

2. Amendments to previously submitted data will be loaded and published by the BMRA as the most recent data, only if received before the related period’s calculation has begun.

3. No validation is carried out between BMRA and SAA to determine whether or not the same Market Index Data is submitted to both systems for each Settlement Period.

Physical Interface Details:

4.7 BMRA-I028: (input) Receive REMIT Data

Interface ID:

BMRA-I028

Source:

BMR Service User,

NETSO

Title:

Receive REMIT Data

BSC reference:

P291, P329

Mechanism:

Electronic data file transfer, XML

Frequency:

Continuous

Volumes:

Up to 3000 messages per day

Interface Requirement:

The BMRA shall receive REMIT message data from BMR Service Users (via the ELEXON Portal) and the NETSO. The data will be received in individual XML files and will include:

Message Type (Unavailabilities Of Electricity Facilities or Other Market Information)
Message ID
Message Heading
Participant ID
Participant Registration Code
Asset ID
Asset Type
Affected Unit and EIC code*
Affected Area
Bidding Zone*
Fuel Type*
Event Type*
Unavailability Type*
Event Status
Event Start and End dates
Duration uncertainty
Normal , Available and Unavailable Capacity*
Event cause
Outage Profile
- Outage Profile Start
- Outage Profile End
- Outage Profile Capacity

* Only required for ‘Unavailabilities Of Electricity Facilities’ Message Type

Physical Interface Details:

These files will be received in a format defined by an XML Schema (REMIT XSD version 2.0) established and maintained by the BMRA.

4.8 BMRA-I030: (output) Publish REMIT Data

Interface ID:

BMRA-I030

User:

BMR Service User,

Title:

Publish REMIT Data

BSC reference:

P291, P329

Mechanism:

BMRA Publishing Interface

Frequency:

Continuous upon receipt

Volumes:

Up to 3000 individual messages per day.

Interface Requirement:

The BMRA Service shall publish messages submitted under REMIT (Regulation on Energy Market Integrity and Transparency) as soon as they are received from BMR Service Users or the NETSO.

REMIT message data shall include:

Message Type (Unavailabilities Of Electricity Facilities or Other Market Information)
Message ID
Message Heading
Participant ID
Participant Registration Code
Asset ID
Asset Type
Affected Unit and EIC code*
Affected Area
Bidding Zone*
Fuel Type*
Event Type*
Unavailability Type*
Event Status
Event Start and End dates
Duration uncertainty
Normal, Available, and Unavailable Capacity*
Event cause
Outage Profile
- Outage Profile Start
- Outage Profile End
- Outage Profile Capacity

* Only required for ‘Unavailabilities Of Electricity Facilities’ Message Type

Physical Interface Details:

The detailed contents of this interface are defined by an XML Schema (REMIT XSD version 2.0) established and maintained by the BMRA.

4.9 BMRA-I031: (output) Publish Transparency Regulation Data

Interface ID:

BMRA-I031

Source:

BMR Service User,

ENTSO-E

Title:

Publish Transparency Regulation Data

BSC reference:

P295

Mechanism:

BMRA Publishing Interface;

Electronic data file transfer

Frequency:

Continuous upon receipt

Volumes:

Interface Requirement:

The BMRA Service shall publish data provided under the Transparency Regulations as soon as it has been received from the NETSO. Data shall be provided to BMR Service Users through the publishing interface and directly to ENTSO-E for further publication on the Electricity Market Fundamental Information Platform (EMFIP).

Transparency Regulation Data shall include information relating to the following categories:

Load
Outages
Transmission
Congestion Management
Generation
Balancing

Details of the individual articles reported are provided in Section 4.10.

Physical Interface Details:

The interface to ENTSO-e shall comprise an FTP connection to the Energy Communications Platform (ECP). The files will be published in XML and PDF formats defined by ENTSO-e. Data items in XML files will be defined in the relevant XML Schema Definition (XSD) and in accordance to the ENTSO-e’s Manual of Procedures (V2.1); details are available from the Transparency section of the ENTSO-e Website (www.entsoe.eu).

4.10 BMRA-I035: (output) Publish Trading Unit Data

Interface ID:

BMRA-I035

Source:

BMR Service User,

Title:

Publish Trading Unit Data

BSC reference:

P321

Mechanism:

BMRA Publishing Interface

Frequency:

Continuous upon receipt

Volumes:

Interface Requirement:

The BMRA Service shall publish Trading Unit Data as soon as it has been received from the SAA.

The following data items shall be included:

Trading Unit Name
Trading Unit Type
Settlement Date
Settlement Period
Settlement Run Type
Delivery Mode
Import Volume
Export Volume
Net Volume

This information will be available through a BMRS API, although it will not be available through the Tibco service.

Physical Interface Details:

4.11 BMRA-I037: (output) Publish Replacement Reserve Data

Interface ID:

BMRA-I037

Source:

BMR Service User,

Title:

Publish Replacement Reserve Data

BSC reference:

CP1517

Mechanism:

BMRA Publishing Interface

Frequency:

Continuous upon receipt and/or derivation

Volumes:

High

Interface Requirement:

The BMRA Service shall publish data relating to Replacement Reserve.

The information shall include:

RR Bid Data
RR Activation Data
RR GB Need Met
RR Interconnector Schedule
Indicative Accepted RR Bid and Offer Volumes, by Settlement Period and Quarter Hour Period
Indicative RR Cashflows, by Settlement Period and Quarter Hour Period
Aggregated RR information

Physical Interface Details:

4.12 BMRA TIBCO Message Publishing - Data Formats

The BMRA service publishes all data received from the NETSO and additional data derived by the BMRA Service via the use of TIBCO messaging software. TIB messages are broadcast over the High Grade Service WAN and will be received by any client software that explicitly listens for them. The messages are anticipated to be used in one or both of two ways: firstly to provide the Near Real Time update to data screens used by traders, and secondly to load market data into participant bespoke applications.

The material in this section defines the structure of all the TIB messages sent from the BMRA service which subscribing client software may receive.

The hardware and software specification for the TIBCO client software required to support the High Grade Service is given in [COMMS]. Guidelines for how to subscribe to published TIBCO messages are given in section 4.10.5

This section of the document describes the following information

message types
subject naming conventions
field definitions and formats
message definitions and formats
any special formatting or arrangement of data in messages

4.12.1 Message Types

The following table lists all of the message types sent from BMRA and specifies the External Interface Requirement met by each one.

	External Interface Requirement		Data Type		Message Type
	BMRA-I004		Final Physical Notification		FPN
	BMRA-I004		Quiescent Physical Notification		QPN
	BMRA-I004		Bid-Offer Pairs		BOD
	BMRA-I004		Maximum Export Limit		MEL
	BMRA-I004		Maximum Import Limit		MIL
	BMRA-I004		Bid-Offer Acceptances		BOAL
	BMRA-I004		Bid-Offer Acceptance Level Flagged		BOALF
	BMRA-I004		BM Unit Applicable Balancing Services Volume		QAS
	BMRA-I004		Run Up Rates Export		RURE
	BMRA-I004		Run Up Rates Import		RURI
	BMRA-I004		Run Down Rates Export		RDRE
	BMRA-I004		Run Down Rates Import		RDRI
	BMRA-I004		Notice to Deviate from Zero		NDZ
	BMRA-I004		Notice to Deliver Offers		NTO
	BMRA-I004		Notice to Deliver Bids		NTB
	BMRA-I004		Minimum Zero Time		MZT
	BMRA-I004		Minimum Non-Zero Time		MNZT
	BMRA-I004		Stable Export Limit		SEL
	BMRA-I004		Stable Import Limit		SIL
	BMRA-I004		Maximum Delivery Volume		MDV
	BMRA-I004		Maximum Delivery Period		MDP
	BMRA-I005		Indicated Generation		INDGEN
	BMRA-I005		Indicated Demand		INDDEM
	BMRA-I005		National Demand Forecast		NDF
	BMRA-I005		Transmission System Demand Forecast		TSDF
	BMRA-I005		Initial National Demand Out-turn		INDO
	BMRA-I005		Initial Transmission System Demand Out-Turn		ITSDO
	BMRA-I005		Demand forecast. 2 -14 days ahead		NDFD
	BMRA-I005		Demand forecast. 2 -52 weeks ahead		NDFW
	BMRA-I005		Transmission System Demand Forecast, 2 -14 day		TSDFD
	BMRA-I005		Transmission System Demand Forecast, 2 -52 week		TSDFW
	BMRA-I005		Surplus forecast. 2 -14 days ahead		OCNMFD⁶
	BMRA-I005		Surplus forecast. 2 -52 weeks ahead		OCNMFW⁷
	BMRA-I005		Surplus forecast. 2-156 weeks ahead		OCNMF3Y
	BMRA-I005		Indicated Margin		MELNGC
	BMRA-I005		Indicated Imbalance		IMBALNGC
	BMRA-I005		System Warnings		SYSWARN
	BMRA-I005		SO-SO Prices		SOSO
	BMRA-I005		Net Balancing Services Adjustment Data		NETBSAD
	BMRA-I005		Balancing Services Adjustment Action Data		DISBSAD
	BMRA-I005		System Message		SYSMSG
	BMRA-I005		Market Index Data		MID
	BMRA-I005		Temperature Data		TEMP
	BMRA-I005		Wind Generation Forecast		WINDFOR
	BMRA-I005		Instantaneous Generation by Fuel Type		FUELINST
	BMRA-I005		Half-Hourly Generation by Fuel Type		FUELHH
	BMRA-I005		Daily Energy Volume Data		INDOD
	BMRA-I005		Realtime Transmission System Frequency Data		FREQ
	BMRA-I005		Non-BM STOR Out-turn		NONBM
BMRA-I005		National Output Usable by Fuel Type, 2-14 days ahead		FOU2T14D
BMRA-I005		National Output Usable by BM Unit and Fuel Type, 2-14 days ahead		UOU2T14D
BMRA-I005		National Output Usable by Fuel Type, 2-52 weeks ahead		FOU2T52W
BMRA-I005		National Output Usable by BM Unit and Fuel Type, 2-52 weeks ahead		UOU2T52W
BMRA-I005		National Output Usable by Fuel Type, 2-156 weeks ahead		FOU2T3YW
BMRA-I005		National Output Usable by BM Unit and Fuel Type, 2-156 weeks ahead		UOU2T3YW
BMRA-I005		Generating Plant Demand Margin, 2-14 days ahead		OCNMFD2
BMRA-I005		Generating Plant Demand Margin, 2-52 weeks ahead		OCNMFW2
BMRA-I005		Generating Plant Demand Margin, 2-156 weeks ahead		OCNMF3Y2
BMRA-I005		Loss of Load Probability and De-rated Margin		LOLP
BMRA-I005		Demand Control Instructions		DCONTROL
BMRA-I006		Period B-O Acceptance Volumes		BOAV
BMRA-I006		Period Total B-O Acceptance Volume		PTAV
BMRA-I006		Disaggregated Period Total B-O Acceptance Volume		DISPTAV
BMRA-I006		Estimated period B-O cash flows		EBOCF
BMRA-I006		Net Estimated Buy/Sell Price and Total Accepted Bid/Offer Volumes		NETEBSP
BMRA-I006		Disaggregated Estimated Buy/Sell Price and Total Accepted Bid/Offer Volumes		DISEBSP
BMRA-I006		Total Bid Volume and Total Offer Volume		TBOD
BMRA-I006		Indicative System Price Stack		ISPSTACK
BMRA-I019		Credit Default Notices		CDN
BMRA-I030		REMIT Data		REMIT
BMRA-I031		Transparency Regulation Data		TRANSPARENCY
BMRA-I037		Replacement Reserve Data		RR

Data has been divided up into a granular level, i.e. publication of data on a record by record basis. This allows the programmatic interface to insert the data more efficiently into any bespoke applications that need to receive the data feed.

BMRA publishes data using the TIBCO subject-based addressing messaging system - data is broadcast across the WAN in messages, each associated with a unique subject name which describes the type of data within the message. Any client software will ‘subscribe’ to the data by subject name. Thus, although all data is available, each piece of client software will only accept and process the data it specifically subscribes to.

4.12.2 Message Subject Naming

Subject names are used not only to provide an insight into the kind of data contained within the message, but also to divide the data into logical segments. TIBCO subject names consist of a string of characters that is divided into elements by a dot(.), and so data is organised hierarchically by assigning a specific meaning to each element in a subject name.

4.12.2.1 Base subject name

All subject names published by the BMRA system will have the following prefix:-

BMRA

It is important to prefix all messages from the BMRA system with an ‘identity key’ to allow BMRA data to be distinguished from other TIBCO message data. By establishing a prefix for BMRA messages now, possible confusion or corruption of data may be avoided in the future.

4.12.2.2 Sub-division of data through Subject Names

Published data will further be divided by data type - that is that all BM related data will be grouped together under an extended prefix, all system related data will be grouped together and all dynamic data will be grouped together.

The following table lists the subject name prefixes that the different types of data will be grouped under:

Data Group	Subject name prefix
System related data	BMRA.SYSTEM
BM related data	BMRA.BM.<BM_UNIT>
Dynamic Data	BMRA.DYNAMIC.<BM_UNIT>
Party Related Data	BMRA.BP.<PARTICIPANT>
REMIT Data	REMIT.BMRS
Transparency Regulation Data	TRANSPARENCY.BMRS.<ARTICLE>
Replacement Reserve Data	BMRA.RR
Informational	BMRA.INFO

System Data will contain all data that applies at a national (or zonal) level, rather than at BM Unit level. This includes all forecasting data, system warnings, National Demand Out-turn and estimated Buy and Sell prices (derived).

BM related data will contain the principal data relating to the Balancing mechanism. This includes FPN, QPN, B-O pairs, Acceptances, Maximum Import and Export Limits, Acceptance Volumes (derived) and B-O Cash Flows (derived).

Dynamic data will contain all the dynamic data relating to a BM Unit.

Replacement Reserve data will contain data relating to RR auctions and activations. Some data is available per BM Unit.

Transparency Regulation data will contain data relating to the individual articles that comprise the Transparency Regulations, each of which may contain data for a range of time periods and BM Units.

REMIT data will contain information submitted by individual participants in compliance with the Regulation on Energy Market Integrity and Transparency. Each message will relate to a specific event, e.g. failure, outage or return to service of a particular asset identified by the participant.

Party related data will contain all published data related to a participant. At present, this will include only Credit Default notices.

Information data will contain subjects relating to the BMRS itself. Its initial use will be for test messages and heartbeats for the TIBCO messaging protocol. These should currently be ignored by participants but the message definitions are given here for completeness.

This sub-division of data by subject name has been done to ease subscription to data by grouping related data types together. This means that wildcards may be used to subscribe to a selection of subject names which may all be plotted on the same graph, or listed in the same table. For example, much of the BM data may be viewed on the same graph and much of the dynamic data may be listed in the same table.

4.12.3 Message Formats

The messages are published using TIBCO Rendezvous software, using a subject-based addressing system and self describing data. A standard TIBCO message is composed of a header which contains the subject name, and an optional reply subject name, following by a string of data fields. Each field contains a single element of data together with details describing the data for platform independence.

Messages are built from a list of defined field types which have been identified to describe all of the data published by BMRA. Each of these two character BMRA Field Types is described later in this section, and has associated with it a unique field name and data types. No message will be published by BMRA containing fields outside of this set.

Note that the message definitions in this document contain only the data fields created by BMRA. Additional fields added to messages by Rendezvous - such as header fields and data description elements - will also be present in the published messages, but these are not listed in the definitions given in this document. Details of the standard TIBCO header fields may be found in TIBCO Rendezvous documentation.

In addition, certain messages published via TIBCO will consist of an XML payload rather than the standard message structure as described above. In these cases, subscribers will need to refer to relevant XML Schemas in order to process the payload. See section 4.10.5 ‘Message Definitions for further details on the schemas in use.

4.12.4 Field Type Definitions

This section identifies and defines all of the fields which are used to compose the BMRA messages. Each field in a message is associated with a Field Name, TIB Data type and a valid set of values. The fields are described using the following format:-

Field Data Type :	The data the field represents.
Field Type :	The reference identity of the field type, as used in message definitions.
Field Name :	The field name used within the message to identify the field.
Description :	A brief description of the data the field represents.
TIB Data Type :	The data type used in the TIB wire format of the message. This is a data type defined in and used internally by the TIBCO Rendezvous software. They are platform and network independent.
C/Java Type :	The C and Java data types which correspond to the TIB data type. The TIBCO Rendezvous software will convert the incoming TIB data type into this data type when the API is used for bespoke applications. Due to the nature of the C data type “float”, it should be noted that where the data type “float” is given, it is the responsibility of the participant’s API software to perform rounding to the appropriate accuracy (see section 4.10.7 and its subsections for additional information).
Messages containing field :	The TIB message types which are broadcast by BMRA which contain the field.
Additional Information :	Any additional information - such as the units of the data and the valid set of values if appropriate (note that £ and £/MWh are always to 2 decimal places).

Field Type Index by Data Type

Data Type	Field Type
Acceptance Level Value	VA
Acceptance Number	NK
Acceptance Time	TA
Adjustment Cost	JC
Adjustment Identifier	AI
Adjustment Volume	JV
Amendment Flag	AM
Applicable Balancing Services Volume	SV
Arbitrage Adjusted Volume	AV
Affected LDSO	DS
Bid Cashflow	BC
Bid Price	BP
Bid Volume	BV
Bid/Offer Indicator	BO
Bid-Offer Level Value	VB
Bid-Offer Pair Number	NN
BMRS Informational Text	IN
BSAD Asset Id	AX
BSAD Defaulted	BD
Buy Price	PB
BSAD Party Id	PX
Buy Price Cost Adjustment	A4
Buy Price Price Adjustment	A6
Buy Price Volume Adjustment	A5
CADL Flag	CF
Calendar Year	CY
Calendar Week Number	WN
Cleared Default Settlement Date	CD
Cleared Default Settlement Period	CP
Component Identifier	CI
Contract Identification	IC
Credit Default Level	DL
Deemed Bid-Offer Flag	AD
Demand Control Event Flag	EV
Demand Control ID	ID
Demand Control Level	VO
Demand Margin	DM
Demand Value	VD
DMAT Adjusted Volume	DA
Effective From Time	TE
Entered Default Settlement Date	ED
Entered Default Settlement Period	EP
Energy Volume Daily High Reference	EH
Energy Volume Daily Low Reference	EL
Energy Volume Daily Normal Reference	EN
Energy Volume Outturn	EO
Export Level Value	VE
Fuel Type	FT
Fuel Type Generation	FG
GB Reference High Noon Temperature	TH
GB Noon Temperature Outturn	TO
GB Reference Low Noon Temperature	TL
GB Reference Normal Noon Temperature	TN
Generation Value	VG
Imbalance Value	VI
Import Level Value	VF
Indicative Net Imbalance Volume	NI
Instruction Sequence No	SQ
Margin/Surplus Value	VM
Market Index Data Provider ID	MI
Market Index Price	M1
Market Index Volume	M2
Maximum Delivery Period	DP
Maximum Delivery Volume	DV
Message Type	MT
Minimum non-Zero Time	MN
Minimum Zero Time	MZ
Net Energy Buy Price Cost Adjustment	A9
Net Energy Buy Price Volume Adjustment	A10
Net Energy Sell Price Cost Adjustment	A7
Net Energy Sell Price Volume Adjustment	A8
Net System Buy Price Volume Adjustment	A12
Net System Sell Price Volume Adjustment	A11
NIV Adjusted Volume	NV
Non-BM STOR Volume	NB
Notice to Deliver Bids	DB
Notice to Deliver Offers	DO
Notice to Deviate from Zero	DZ
Number of Records	NR
Number Of Spot Points	NP
Offer Cashflow	OC
Offer Price	OP
Offer Volume	OV
Output Usable	OU
PAR Adjusted Volume	PV
Period Originally-Priced BM Unit Bid Volume	P6
Period Originally-Priced BM Unit Offer Volume	P3
Period Repriced BM Unit Bid Volume	P5
Period Repriced BM Unit Offer Volume	P2
Period Tagged BM Unit Bid Volume	P4
Period Tagged BM Unit Offer Volume	P1
PN Level Value	VP
Price Derivation Code	PD
Publishing Time	TP
Replacement Price	RP
Replacement Price Calculation Volume	RV
Repriced Indicator	RI
Reserve Scarcity Price	RSP
RR Accepted Bid Volume	BI
RR Accepted Offer Volume	OF
RR Associated TSO	AT
RR Auction Period End	AE
RR Auction Period Start	AS
RR Bid Resolution	BR
RR Business Type	TY
RR Cashflow	CR
RR Divisible	DI
RR Exclusive Bid Id	EB
RR Flow Direction	FD
RR Instruction Flag	RN
RR Interconnector Identifier	II
RR Linking Bid Id	LB
RR Market Balance Area	BA
RR Maximum Quantity	QX
RR Multipart Bid Id	MB
RR Position	PO
RR Price	PR
RR Quantity	QI
RR Quarter Hour Period	QP
RR Schedule Flag	SC
RR Status	RS
Run Down Elbow 2	RB
Run Down Elbow 3	RC
Run Down Rate 1	R1
Run Down Rate 2	R2
Run Down Rate 3	R3
Run Up Elbow 2	UB
Run Up Elbow 3	UC
Run Up Rate 1	U1
Run Up Rate 2	U2
Run Up Rate 3	U3
Sell Price	PS
Sell Price Cost Adjustment	A1
Sell Price Price Adjustment	A3
Sell Price Volume Adjustment	A2
Sequence Number	SN
Service Type	SX
Settlement Date	SD
Settlement Period	SP
Short Acceptance Flag	SA
Spot Time	TS
Stable Export Limit	SE
Stable Import Limit	SI
Stack Item Final Price	FP
Stack Item Original Price	IP
Stack Item Volume	IV
STOR Provider Flag	PF
SO-Flag	SO
SO-SO Start Time	ST
SO-SO Trade Type	TT
System Frequency	SF
System Message Text	SM
System Total Priced Accepted Bid Volume	PC
System Total Priced Accepted Offer Volume	PP
System Total Unpriced Accepted Bid Volume	AC
System Total Unpriced Accepted Offer Volume	AP
System Warning Text	SW
Tagged Accepted Bid Volume	T2
Tagged Accepted Offer Volume	T1
Tagged Adjustment Buy Volume	J4
Tagged Adjustment Sell Volume	J3
Tendered Status	TX
Time From	TF
Time To	TI
TLM Adjusted Cost	TC
TLM Adjusted Volume	TV
Total Accepted Bid Volume	AB
Total Accepted Offer Volume	AO
Total Adjustment Buy Volume	J2
Total Adjustment Sell Volume	J1
Total Bid Volume	BT
Total Offer Volume	OT
Total Registered Capacity	TR
Total Volume of Activated Bids	BS
Total Volume of Offered Bids	OS
Total Volume of Unavailable Bids	US
Trade Direction	TD
Trade Price	PT
Trade Quantity	TQ
Transmission Loss Multiplier	TM
Bid-Offer Original Price	UP
Week Start Date	WD
Zone Indicator	ZI

4.12.4.2 Field Type Index

Field Type	Data Type
A1	Sell Price Cost Adjustment
A10	Net Energy Buy Price Volume Adjustment
A11	Net System Sell Price Volume Adjustment
A12	Net System Buy Price Volume Adjustment
A2	Sell Price Volume Adjustment
A3	Sell Price Price Adjustment
A4	Buy Price Cost Adjustment
A5	Buy Price Volume Adjustment
A6	Buy Price Price Adjustment
A7	Net Energy Sell Price Cost Adjustment
A8	Net Energy Sell Price Volume Adjustment
A9	Net Energy Buy Price Cost Adjustment
AB	Total Accepted Bid Volume
AC	System Total Unpriced Accepted Bid Volume
AD	Deemed Bid-Offer Flag
AE	RR Auction Period End
AI	Adjustment Identifier
AM	Amendment Flag
AO	Total Accepted Offer Volume
AP	System Total Unpriced Accepted Offer Volume
AS	RR Auction Period Start
AT	RR Associated TSO
AV	Arbitrage Adjusted Volume
AX	BSAD Asset Id
BA	RR Market Balance Area
BC	Bid Cashflow
BD	BSAD Defaulted
BI	RR Accepted Bid Volume
BO	Bid/Offer Indicator
BP	Bid Price
BR	RR Bid Resolution
BS	Total Volume of Activated Bids
BT	Total Bid Volume
BV	Bid Volume
CD	Cleared Default Settlement Date
CF	CADL Flag
CI	Component Identifier
CP	Cleared Default Settlement Period
CR	RR Cashflow
CY	Calendar Year
DA	DMAT Adjusted Volume
DB	Notice to Deliver Bids
DI	RR Divisible
DL	Credit Default Level
DM	Demand Margin
DO	Notice to Deliver Offers
DP	Maximum Delivery Period
DS	Affected LDSO
DV	Maximum Delivery Volume
DZ	Notice to Deviate from Zero
EB	RR Exclusive Bid Id
ED	Entered Default Settlement Date
EH	Energy Volume Daily High Reference
EL	Energy Volume Daily Low Reference
EN	Energy Volume Daily Normal Reference
EO	Energy Volume Outturn
EP	Entered Default Settlement Period
FD	RR Flow Direction
FG	Fuel Type Generation
FP	Stack Item Final Price
FT	Fuel Type
IC	Contract Identification
ID	Demand Control ID
II	RR Interconnector Identifier
IN	BMRS Informational Text
IP	Stack Item Original Price
IV	Stack Item Volume
J1	Total Adjustment Sell Volume
J2	Total Adjustment Buy Volume
J3	Tagged Adjustment Sell Volume
J4	Tagged Adjustment Buy Volume
JC	Adjustment Cost
JV	Adjustment Volume
LB	RR Linking Bid Id
M1	Market Index Price
M2	Market Index Volume
MB	RR Multipart Bid Id
MI	Market Index Data Provider ID
MN	Minimum non-Zero Time
MT	Message Type
MZ	Minimum Zero Time
NB	Non-BM STOR Volume
NI	Indicative Net Imbalance Volume
NK	Acceptance Number
NN	Bid-Offer Pair Number
NP	Number Of Spot Points
NR	Number of Records
NV	NIV Adjusted Volume
OC	Offer Cashflow
OF	RR Accepted Offer Volume
OP	Offer Price
OS	Total Volume of Offered Bids
OT	Total Offer Volume
OU	Output Usable
OV	Offer Volume
P1	Period Tagged BM Unit Offer Volume
P2	Period Repriced BM Unit Offer Volume
P3	Period Originally-Priced BM Unit Offer Volume
P4	Period Tagged BM Unit Bid Volume
P5	Period Repriced BM Unit Bid Volume
P6	Period Originally-Priced BM Unit Bid Volume
PB	Buy Price
PC	System Total Priced Accepted Bid Volume
PD	Price Derivation Code
PF	STOR Provider Flag
PI	Party Id
PO	RR Position
PP	System Total Priced Accepted Offer Volume
PR	RR Price
PS	Sell Price
PT	Trade Price
PV	PAR Adjusted Volume
PX	BSAD Party Id
QI	RR Quantity
QP	RR Quarter Hour Period
QX	RR Maximum Quantity
R1	Run Down Rate 1
R2	Run Down Rate 2
R3	Run Down Rate 3
RB	Run Down Elbow 2
RC	Run Down Elbow 3
RI	Repriced Indicator
RN	RR Instruction Flag
RP	Replacement Price
RS	RR Status
RSP	Reserve Scarcity Price
RV	Replacement Price Calculation Volume
SA	Short Acceptance Flag
SC	RR Schedule Flag
SD	Settlement Date
SE	Stable Export Limit
SF	System Frequency
SI	Stable Import Limit
SM	System Message Text
SN	Sequence Number
SO	SO-Flag
SP	Settlement Period
SQ	Instruction Sequence No
ST	SO-SO Start Time
SV	Applicable Balancing Services Volume
SW	System Warning Text
SX	Service Type
T1	Tagged Accepted Offer Volume
T2	Tagged Accepted Bid Volume
TA	Acceptance Time
TC	TLM Adjusted Cost
TD	Trade Direction
TE	Effective From Time
TF	Time From
TH	GB Reference High Noon Temperature
TI	Time To
TL	GB Reference Low Noon Temperature
TM	Transmission Loss Multiplier
TN	GB Reference Normal Noon Temperature
TO	GB Noon Temperature Outturn
TP	Publishing Time
TQ	Trade Quantity
TR	Total Registered Capacity
TS	Spot Time
TT	SO-SO Trade Type
TV	TLM Adjusted Volume
TY	RR Business Type
TX	Tendered Status
U1	Run Up Rate 1
U2	Run Up Rate 2
U3	Run Up Rate 3
UB	Run Up Elbow 2
UC	Run Up Elbow 3
UP	Bid-Offer Original Price
US	Total Volume of Unavailable Bids
VA	Acceptance Level Value
VB	Bid-Offer Level Value
VD	Demand Value
VE	Export Level Value
VF	Import Level Value
VG	Generation Value
VI	Imbalance Value
VM	Margin/Surplus Value
VO	Demand Control Level
VP	PN Level Value
WD	Week Start Date
WN	Calendar Week Number
ZI	Zone Indicator

4.12.4.3 Acceptance Level Value

Field Data Type :	Acceptance Level Value
Field Type :	VA
Field Name :	“VA”
Description :	Level of Acceptance. Used to describe either a ‘from level’ or a ‘to level’.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	BOAL, BOALF
Additional Information :	Value in MW. Valid Values: -9999 to +9999.

4.12.4.4. Acceptance Number

Field Data Type :	Acceptance Number
Field Type :	NK
Field Name :	“NK”
Description :	The number of an individual acceptance.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	BOAL, BOAV, BOALF, ISPSTACK
Additional Information :	Valid values: 1 to 2147483647.

4.12.4.5 Acceptance Time

Field Data Type :	Acceptance Time
Field Type :	TA
Field Name :	“TA”
Description :	The time an acceptance was made.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	BOAL, BOALF
Additional Information :

4.12.4.6 Adjustment Cost

Field Data Type :	Adjustment Cost
Field Type :	JC
Field Name :	“JC”
Description :	The defined cost of the Adjustment item.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISBSAD
Additional Information :	Value in £. Can be NULL.

4.12.4.7 Adjustment Identifier

Field Data Type :	Adjustment Identifier
Field Type :	AI
Field Name :	“AI”
Description :	The unique identifier allocated to a single Balancing Services Adjustment Action item.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	DISBSAD
Additional Information :	Unique within each Settlement Period.

4.12.4.8 Adjustment Volume

Field Data Type :	Adjustment Volume
Field Type :	JV
Field Name :	“JV”
Description :	The defined volume of the Adjustment item.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISBSAD
Additional Information :	Value in MWh.

4.12.4.9 Applicable Balancing Services Volume

Field Data Type :	BM Unit Applicable Balancing Services Volume
Field Type :	SV
Field Name :	“SV”
Description :	Energy Volume associated with provision of balancing services
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	QAS
Additional Information :	Value in MWh

4.12.4.10 Arbitrage Adjusted Volume

Field Data Type :	Arbitrage Adjusted Volume
Field Type :	AV
Field Name :	“AV”
Description :	The volume remaining against a stack item after applying Arbitrage.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.11 Bid Cashflow

Field Data Type :	Bid Cashflow
Field Type :	BC
Field Name :	“BC”
Description :	The period bid cashflow for a single Bid-Offer pair.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	EBOCF
Additional Information :	Value in £.

4.12.4.12 Bid Price

Field Data Type :	Bid Price
Field Type :	BP
Field Name :	“BP”
Description :	The bid price attached to a Bid-Offer pair for a given settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	BOD
Additional Information :	Value in £/MWh.

4.12.4.13 Bid Volume

Field Data Type :	Bid Volume
Field Type :	BV
Field Name :	“BV”
Description :	Bid volume accepted for a Bid-Offer pair.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	BOAV, PTAV
Additional Information :	Value in MWh

4.12.4.14 Bid/Offer Indicator

Field Data Type :	Bid/Offer Indicator
Field Type :	BO
Field Name :	“BO”
Description :	Indicates whether the associated stack item is from the Bid or Offer Stack.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	ISPSTACK
Additional Information :	Single character. Can be either “B” or “O”.

4.12.4.15 Bid-Offer Level Value

Field Data Type :	Bid-Offer Level Value
Field Type :	VB
Field Name :	“VB”
Description :	Level of Bid-Offer. Used to describe either a ‘from level’ or a ‘to level’.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	BOD
Additional Information :	Value in MW.

4.12.4.16 Bid-Offer Pair Number

Field Data Type :	Bid-Offer Pair Number
Field Type :	NN
Field Name :	“NN”
Description :	The number of a Bid-Offer pair.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	BOD, BOAV, PTAV, EBOCF, DISPTAV
Additional Information :	Valid values: -6 to 6.

4.12.4.17 BMRS Informational Text

Field Data Type :	BMRS Informational Text
Field Type :	IN
Field Name :	“IN”
Description :	General Informational message
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	MSG
Additional Information :	For future use. Should currently be ignored

4.12.4.18 BSAD Defaulted

Field Data Type :	BSAD Defaulted
Field Type :	BD
Field Name :	“BD”
Description :	Flag to indicate that the BSAD data shown is default values
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.19 Buy Price

Field Data Type :	Buy Price
Field Type :	PB
Field Name :	“PB”
Description :	The system buy price for a particular settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in £/MWh.

4.12.4.20 Buy Price Price Adjustment

Field Data Type :	Buy Price Price Adjustment
Field Type :	A6
Field Name :	“A6”
Description :	Adjustment applied to quotient in computation of Buy Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	NETBSAD, NETEBSP, DISEBSP
Additional Information :	Value in £/MWh.

4.12.4.21 CADL Flag

Field Data Type :	CADL Flag
Field Type :	CF
Field Name :	“CF”
Description :	A value of ‘T’ indicates where the associated stack item is considered to be a Short Duration Acceptance.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	ISPSTACK
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.22 Calendar Week Number

Field Data Type :	Calendar Week Number
Field Type :	WN
Field Name :	“WN”
Description :	The number of a week in the year.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	OCNMFW, NDFW, TSDFW, FOU2T52W, UOU2T52W, OCNMFW2, OCNMF3Y, FOU2T3YW, UOU2T3YW, OCNMF3Y2
Additional Information :	Valid values: 1 - 53. The first week in the year with 4 days or more is Week number 1.

4.12.4.23 Calendar Year

Field Data Type :	Calendar Year
Field Type :	CY
Field Name :	“CY”
Description :	The year to which data in a message pertains.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	FOU2T52W, UOU2T52W, OCNMFW2, FOU2T3YW, UOU2T3YW, OCNMF3Y2
Additional Information :

4.12.4.24 Cleared Default Settlement Date

Field Data Type :	Cleared Default Settlement Date
Field Type :	CD
Field Name :	“CD”
Description :	The settlement date on which a party cleared credit default, at the level specified elsewhere in the message.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	CDN
Additional Information :	The time section of the DateTime is truncated to zero hours, zero minutes and zero seconds

4.12.4.25 Cleared Default Settlement Period

Field Data Type :	Cleared Default Settlement Period
Field Type :	CP
Field Name :	“CP”
Description :	The settlement Period on which a party cleared credit default, at the level specified elsewhere in the message.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	CDN
Additional Information :	Valid values : 1 – 50

4.12.4.26 Cleared Default Text

Field Data Type :	Cleared Default Text
Field Type :	CT
Field Name :	“CT”
Description :	Reason that a party has cleared credit default, at the level specified elsewhere in the message.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	CDN
Additional Information :	The cleared default text will be plain ascii text, in the majority of cases, be less than 128 bytes in length.

4.12.4.27 Component Identifier

Field Data Type :	Component Identifier
Field Type :	CI
Field Name :	“CI”
Description :	For Acceptance items this is the associated BM Unit’s Identifier. For Balancing Services Adjustment Action items this is the NETSO allocated, unique ID. For RR items this is an identifier that distinguishes the item as being related to Replacement Reserve.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	ISPSTACK
Additional Information :

4.12.4.28 Contract Identification

Field Data Type :	Contract Identification
Field Type :	IC
Field Name :	“IC”
Description :	A unique identifier for an offered SO-SO trade.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	SOSO
Additional Information :

4.12.4.29 Credit Default Level

Field Data Type :	Credit Default Level
Field Type :	DL
Field Name :	“DL”
Description :	The credit default level.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	CDN
Additional Information :	Valid values : 1, 2

4.12.4.30 Deemed Bid-Offer Flag

Field Data Type :	Deemed Bid-Offer Flag
Field Type :	AD
Field Name :	“AD”
Description :	Indicates whether Bid-Offer was made for an acceptance.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	BOAL, BOALF
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.31 Demand Margin

Field Data Type:	Demand Margin
Field Type :	DM
Field Name :	“DM”
Description :	A value of the demand margin from generating plants.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	OCNMFD2, OCNMFW2, OCNMF3Y2
Additional Information :	Value in MW. Valid values: -99999 to +99999.

4.12.4.32 Demand Value

Field Data Type :	Demand Value
Field Type :	VD
Field Name :	“VD”
Description :	A value of demand.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NDFD, NDFW, INDDEM, INDO, NDF, TSDF, TSDFD, TSDFW, ITSDO
Additional Information :	Value in MW. Valid values: INDDEM: -99999 to 0 others: 0 to +99999.

4.12.4.33 DMAT Adjusted Volume

Field Data Type :	DMAT Adjusted Volume
Field Type :	DA
Field Name :	“DA”
Description :	The volume remaining against a stack item after applying DMAT.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.34 Effective From Time

Field Data Type :	Effective From Time
Field Type :	TE
Field Name :	“TE”
Description :	The date and time that a value of dynamic data starts to be effective.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	RURE, RURI, RDRE, RDRI, NDZ, NTO, NTB, MZT, MNZT, SEL, SIL, MDV, MDP
Additional Information :

4.12.4.35 Energy Volume Daily High Reference

Field Data Type :	Energy Volume Daily High Reference
Field Type :	EH
Field Name :	“EH”
Description :	MWh.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	INDOD
Additional Information :

4.12.4.36 Energy Volume Daily Low Reference

Field Data Type :	Energy Volume Daily Low Reference
Field Type :	EL
Field Name :	“EL”
Description :	MWh.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	INDOD
Additional Information :

4.12.4.37 Energy Volume Daily Normal Reference

Field Data Type :	Energy Volume Daily Normal Reference
Field Type :	EN
Field Name :	“EN”
Description :	MWh.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	INDOD
Additional Information :

4.12.4.38 Energy Volume Daily Outturn

Field Data Type :	Energy Volume Daily Outturn
Field Type :	EO
Field Name :	“EO”
Description :	MWh.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	INDOD
Additional Information :

4.12.4.39 Entered Default Settlement Date

Field Data Type :	Entered Default Settlement Date
Field Type :	ED
Field Name :	“ED”
Description :	The settlement date on which a party entered credit default, at the level specified elsewhere in the message.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	CDN
Additional Information :	The time section of the DateTime is truncated to zero hours, zero minutes and zero seconds

4.12.4.40 Entered Default Settlement Period

Field Data Type :	Entered Default Settlement Period
Field Type :	EP
Field Name :	“EP”
Description :	The settlement Period on which a party entered credit default, at the level specified elsewhere in the message.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	CDN
Additional Information :	Valid values : 1 – 50

4.12.4.41 Export Level Value

Field Data Type :	Export Level Value
Field Type :	VE
Field Name :	“VE”
Description :	A level of export capability.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	MEL
Additional Information :	Value in MW.

4.12.4.42 Fuel Type

Field Data Type :

Fuel Type

Field Type :

Field Name :

“FT”

Description :

The class of generation fuel type.

TIB Data Type :

TIBRVMSG_STRING

C/Java Type :

Char*/String

Messages containing field :

FUELINST, FUELHH, FOU2T14D, FOU2T52W, FOU2T3YW, UOU2T14D, UOU2T52W, UOU2T3YW

Additional Information :

One of: CCGT OIL COAL NUCLEAR WIND PS NPSHYD OCGT OTHER INTFR INTIRL INTNED	Combined Cycle Gas Turbine Oil Plant Coal Plant Nuclear Plant Power Park Modules metered by the Transmission Operator Pumped Storage Plant Non Pumped Storage Hydro Plant Open Cycle Gas Turbine Plant Any other generation not covered by the other categories External Interconnector flows with France (IFA) External Interconnector flows with Ireland (Moyle) External Interconnector flows with the Netherlands (BritNed)
INTEW BIOMASS INTNEM	External Interconnector flows with Ireland (East-West) Biomass Plant External Interconnector flows with Belgium (Nemo Link)
INTELEC	External Interconnector flows with France (ElecLink)
INTIFA2	External Interconnector flows with France (IFA2)
INTNSL	External Interconnector flows with Norway 2 (North Sea Link)
INTVKL	External Interconnector flows with Denmark 1 (Viking Link)
INTGRNL	External Interconnector flows with Ireland (Greenlink)

4.12.4.43 Fuel Type Generation

Field Data Type :	Fuel Type Generation
Field Type :	FG
Field Name :	“FG”
Description :	Fuel Type Generation (MW).
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	FUELINST, FUELHH
Additional Information :	Value in MW. Valid values: -99999 to +99999.

4.12.4.44 GB Noon Temperature

Field Data Type :	GB Noon Temperature Outturn
Field Type :	TO
Field Name :	“TO”
Description :	Degree celsius Outturn temperature.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TEMP
Additional Information :	Value in degrees Celsius. Valid Values: -99.9 to 99.9

4.12.4.45 GB Reference Normal Noon Temperature

Field Data Type :	GB Reference Normal Temperature
Field Type :	TN
Field Name :	“TN”
Description :	Degree celsius temperature.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TEMP
Additional Information :	Value in degrees Celsius. Valid Values: -99.9 to 99.9

4.12.4.46 GB Reference High Noon Temperature

Field Data Type :	GB Reference High Noon Temperature
Field Type :	TH
Field Name :	“TH”
Description :	Degree celsius temperature.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TEMP
Additional Information :	Value in degrees Celsius. Valid Values: -99.9 to 99.9

4.12.4.47 GB Reference Low Noon Temperature

Field Data Type :	GB Reference Low Noon Temperature
Field Type :	TL
Field Name :	“TL”
Description :	Degree celsius temperature.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TEMP
Additional Information :	Value in degrees Celsius. Valid Values: -99.9 to 99.9

4.12.4.48 Generation Value

Field Data Type :	Generation Value
Field Type :	VG
Field Name :	“VG”
Description :	A value of Generation.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	INDGEN, WINDFOR
Additional Information :	Value in MW. Valid values: 0 to +99999.

4.12.4.49 Imbalance Value

Field Data Type :	Imbalance Value
Field Type :	VI
Field Name :	“VI”
Description :	A value of Imbalance.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	IMBALNGC
Additional Information :	Value in MW. Valid values: -99999 to +99999.

4.12.4.50 Import Level Value

Field Data Type :	Import Level Value
Field Type :	VF
Field Name :	“VF”
Description :	A level of Import capability.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	MIL
Additional Information :	Value in MW.

4.12.4.51 Indicative Net Imbalance Volume

Field Data Type :	Indicative Net Imbalance Volume
Field Type :	NI
Field Name :	“NI”
Description :	The Indicative Net Imbalance Volume
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :

4.12.4.52 Margin/Surplus Value

Field Data Type :	Margin/Surplus Value
Field Type :	VM
Field Name :	“VM”
Description :	A value of margin or surplus.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	OCNMFD, OCNMFW, OCNMF3Y, MELNGC
Additional Information :	Value in MW. Valid values: -99999 to +99999.

4.12.4.53 Market Index Data Provider ID

Field Data Type :	Market Index Data Provider ID
Field Type :	MI
Field Name :	“MI”
Description :	The Identifier of a Market Index Data Provider.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	MID
Additional Information :	The Identifier will be plain ascii text, in the majority of cases, be less than 4Kb in length.

4.12.4.54 Market Index Price

Field Data Type :	Market Index Price
Field Type :	M1
Field Name :	“M1”
Description :	Market Index Price.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	MID
Additional Information :	Value in £/MWh.

4.12.4.55 Market Index Volume

Field Data Type :	Market Index Volume
Field Type :	M2
Field Name :	“M2”
Description :	Market Index Volume.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	MID
Additional Information :	Value in MWh.

4.12.4.56 Maximum Delivery Period

Field Data Type :	Maximum Delivery Period
Field Type :	DP
Field Name :	“DP”
Description :	The minimum length of time in which the maximum delivery volume may be delivered.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	MDP
Additional Information :	Value in Minutes. Valid Values: 1 to 239.

4.12.4.57 Maximum Delivery Volume

Field Data Type :	Maximum Delivery Volume
Field Type :	DV
Field Name :	“DV”
Description :	The maximum amount which may be delivered within the maximum delivery period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	MDV
Additional Information :	Value in MWh. Valid Values: -99999 to +99999.

4.12.4.58 Message Type

Field Data Type :	Message type
Field Type :	MT
Field Name :	“MT”
Description :	A 6 character code that specifies a system message type
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	SYSMSG
Additional Information :	Valid Values: ‘MIDNP’, and such values that are allocated from time to time.

4.12.4.59 Minimum non-Zero Time

Field Data Type :	Minimum non-Zero Time
Field Type :	MN
Field Name :	“MN”
Description :	The minimum time a BM unit may operate at non-zero level as a result of accepted BM action.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	MNZT
Additional Information :	Value in Minutes. Valid values: 0 to 999.

4.12.4.60 Minimum Zero Time

Field Data Type :	Minimum Zero Time
Field Type :	MZ
Field Name :	“MZ”
Description :	The minimum time a BM unit must operate at zero or import before returning to export.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	MZT
Additional Information :	Value in Minutes. Valid values: 0 to 999.

4.12.4.61 Net Energy Buy Price Cost Adjustment

Field Data Type :	Net Energy Buy Price Cost Adjustment
Field Type :	A9
Field Name :	“A9”
Description :	Adjustment included in computation of Buy Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in £

4.12.4.62 Net Energy Buy Price Volume Adjustment

Field Data Type :	Net Energy Buy Price Volume Adjustment
Field Type :	A10
Field Name :	“A10”
Description :	Adjustment included in computation of Buy Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in MWh.

4.12.4.63 Net Energy Sell Price Cost Adjustment

Field Data Type :	Net Energy Sell Price Cost Adjustment
Field Type :	A7
Field Name :	“A7”
Description :	Adjustment included in computation of Sell Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in £

4.12.4.64 Net Energy Sell Price Volume Adjustment

Field Data Type :	Net Energy Sell Price Volume Adjustment
Field Type :	A8
Field Name :	“A8”
Description :	Adjustment included in computation of Sell Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in MWh.

4.12.4.65 Net System Buy Price Volume Adjustment

Field Data Type :	Net System Buy Price Volume Adjustment
Field Type :	A12
Field Name :	“A12”
Description :	Adjustment included in computation of Buy Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in MWh.

4.12.4.66 Net System Sell Price Volume Adjustment

Field Data Type :	Net System Sell Price Volume Adjustment
Field Type :	A11
Field Name :	“A11”
Description :	Adjustment included in computation of Sell Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETBSAD, NETEBSP
Additional Information :	Value in MWh.

4.12.4.67 NIV Adjusted Volume

Field Data Type :	NIV Adjusted Volume
Field Type :	NV
Field Name :	“NV”
Description :	The volume remaining against a stack item after applying NIV.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.68 Non-BM STOR Volume

Field Data Type :	Non-BM STOR Volume
Field Type :	NB
Field Name :	“NB”
Description :	Non-BM STOR Instructed Volume (MWh).
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	NONBM
Additional Information :	Value in MWh. Valid values: 0 to +99999.

4.12.4.69 Notice to Deliver Bids

Field Data Type :	Notice to Deliver Bids
Field Type :	DB
Field Name :	“DB”
Description :	Notification time for BM unit to deliver a bid
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	NTB
Additional Information :	Value in Minutes. Valid values: 0 to 239.

4.12.4.70 Notice to Deliver Offers

Field Data Type :	Notice to Deliver Offers
Field Type :	DO
Field Name :	“DO”
Description :	Notification time for BM unit to deliver an offer.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	NTO
Additional Information :	Value in Minutes. Valid values: 0 to 239.

4.12.4.71 Notice to Deviate from Zero

Field Data Type :	Notice to Deviate from Zero
Field Type :	DZ
Field Name :	“DZ”
Description :	Notification time required for BM unit to change operating level from zero.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	NDZ
Additional Information :	Value in Minutes. Valid values: 0 to 999.

4.12.4.72 Number of Records

Field Data Type :	Number of Records
Field Type :	NR
Field Name :	“NR”
Description :	A number of records contained within the message. The context of this field will be described at the message definition level.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	OCNMFD, OCNMFW, OCNMF3Y, NDFD, NDFW, MELNGC, IMBALNGC, INDDEM, INDGEN, NDF, TSDF, TSDFD, TSDFW, WINDFOR, FOU2T14D, FOU2T52W, FOU2T3YW, UOU2T14D, UOU2T52W, UOU2T3YW, OCNMFD2, OCNMFW2, OCNMF3Y2
Additional Information :

4.12.4.73 Number of Spot Points

Field Data Type :	Number of Spot Points
Field Type :	NP
Field Name :	“NP”
Description :	The number of spot times and levels that are contained within a message.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	FPN, QPN, BOD, BOAL, MIL, MEL, BOALF
Additional Information :	See section on ‘Conversion of Effective From/To Time Data to Spot Time Data’.

4.12.4.74 Offer Cashflow

Field Data Type :	Offer Cashflow
Field Type :	OC
Field Name :	“OC”
Description :	The period offer cashflow for a single Bid-Offer pair.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	EBOCF
Additional Information :	Value in £.

4.12.4.75 Offer Price

Field Data Type :	Offer Price
Field Type :	OP
Field Name :	“OP”
Description :	The offer price attached to a Bid-Offer pair for a given settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	BOD
Additional Information :	Value in £/MWh.

4.12.4.76 Offer Volume

Field Data Type :	Offer Volume
Field Type :	OV
Field Name :	“OV”
Description :	The offer volume accepted for a Bid-Offer pair.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	BOAV, PTAV
Additional Information :	Value in MWh.

4.12.4.77 Output Usable

Field Data Type :	Output Usable
Field Type :	OU
Field Name :	“OU”
Description :	The volume of energy expected to be available over a given period (in the case of Interconnectors, this is the expected capacity).
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	FOU2T14D, FOU2T52W, FOU2T3YW, UOU2T14D, UOU2T52W, UOU2T3YW
Additional Information :	Value in MW. Valid values: 0 to +99999

4.12.4.78 PAR Adjusted Volume

Field Data Type :	PAR Adjusted Volume
Field Type :	PV
Field Name :	“PV”
Description :	The volume remaining against a stack item after applying PAR.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.79 Period Originally-Priced BM Unit Bid Volume

Field Data Type :	Period Originally-Priced BM Unit Bid Volume
Field Type :	P6
Field Name :	“P6”
Description :	The total originally-priced bid volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.80 Period Originally-Priced BM Unit Offer Volume

Field Data Type :	Period Originally-Priced BM Unit Offer Volume
Field Type :	P3
Field Name :	“P3”
Description :	The total originally-priced offer volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.81 Period Repriced BM Unit Bid Volume

Field Data Type :	Period Repriced BM Unit Bid Volume
Field Type :	P5
Field Name :	“P5”
Description :	The total repriced bid volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.82 Period Repriced BM Unit Offer Volume

Field Data Type :	Period Repriced BM Unit Offer Volume
Field Type :	P2
Field Name :	“P2”
Description :	The total repriced offer volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.83 Period Tagged BM Unit Bid Volume

Field Data Type :	Period Tagged BM Unit Bid Volume
Field Type :	P4
Field Name :	“P4”
Description :	The total tagged bid volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.84 Period Tagged BM Unit Offer Volume

Field Data Type :	Period Tagged BM Unit Offer Volume
Field Type :	P1
Field Name :	“P1”
Description :	The total tagged offer volume of the associated BM Unit for a given Bid-Offer pair and settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISPTAV
Additional Information :	Value in MWh.

4.12.4.85 PN Level Value

Field Data Type :	PN Level Value
Field Type :	VP
Field Name :	“VP”
Description :	Level of Physical Notice. Used to describe either a ‘from level’ or a ‘to level’ of Final or Quiescent PN.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	FPN, QPN
Additional Information :	Value in MW.

4.12.4.86 Price Derivation Code

Field Data Type :	Price Derivation Code
Field Type :	PD
Field Name :	“PD”
Description :	A 2 character code that describes how the SBP and SSP were derived
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Valid Values: are defined in BMRA-I006

4.12.4.87 Publishing Time

Field Data Type :	Publishing Time
Field Type :	TP
Field Name :	“TP”
Description :	The time a message or a particular field was originally published. The context of this field will be described at the message definition level.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	OCNMFD, OCNMFW, OCNMF3Y, NDFD, NDFW, MELNGC, IMBALNGC, INDDEM, INDGEN, SYSWARN, INDO, MSG, NDF, TSDF, TSDFD, TSDFW, ITSDO, TEMP, FUELINST, FUELHH, WINDFOR, NONBM, INDOD, FOU2T14D, FOU2T52W, FOU2T3YW, UOU2T14D, UOU2T52W, UOU2T3YW, OCNMFD2, OCNMFW2, OCNMF3Y2
Additional Information :

4.12.4.88 Replacement Price

Field Data Type :	Replacement Price
Field Type :	RP
Field Name :	“RP”
Description :	The Replacement Price used for a given settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in £/MWh.

4.12.4.89 Replacement Price Calculation Volume

Field Data Type :	Replacement Price Calculation Volume
Field Type :	RV
Field Name :	“RV”
Description :	The derived Replacement Price Calculation Volume for a given Settlement Period (as defined in the Indicative System Price Calculation function in the BMRA URS).
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.90 Repriced Indicator

Field Data Type :	Repriced Indicator
Field Type :	RI
Field Name :	“RI”
Description :	A value of ‘T’ indicates where the associated stack item has been repriced.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	ISPSTACK
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.91 Run Down Elbow 2

Field Data Type :	Run Down Elbow 2
Field Type :	RB
Field Name :	“RB”
Description :	The point at which run down rate 2 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.92 Run Down Elbow 3

Field Data Type :	Run Down Elbow 3
Field name :	RC
Field Name :	“RC”
Description :	The point at which run down rate 3 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.93 Run Down Elbow 4

Field Data Type :	Run Down Elbow 4
Field Type :	RD
Field Name :	“RD”
Description :	The point at which run down rate 4 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.94 Run Down Elbow 5

Field Data Type :	Run Down Elbow 5
Field Type :	RE
Field Name :	“RE”
Description :	The point at which run down rate 5 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.95 Run Down Elbow 6

Field Data Type :	Run Down Elbow 6
Field Type :	RF
Field Name :	“RF”
Description :	The point at which run down rate 6 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.96 Run Down Elbow 7

Field Data Type :	Run Down Elbow 7
Field Type :	RG
Field Name :	“RG”
Description :	The point at which run down rate 7 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.97 Run Down Elbow 8

Field Data Type :	Run Down Elbow 8
Field Type :	RH
Field Name :	“RH”
Description :	The point at which run down rate 8 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.98 Run Down Elbow 9

Field Data Type :	Run Down Elbow 9
Field Type :	RJ
Field Name :	“RJ”
Description :	The point at which run down rate 9 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.99 Run Down Elbow 10

Field Data Type :	Run Down Elbow 10
Field Type :	RK
Field Name :	“RK”
Description :	The point at which run down rate 10 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RDRE, RDRI
Additional Information :	Value in whole MW.

4.12.4.100 Run Down Rate 1

Field Data Type :	Run Down Rate 1
Field Name :	R1
Field Name :	“R1”
Description :	Decrease in active power consumption between zero and run down elbow 2.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RDRE, RDRI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0.

4.12.4.101 Run Down Rate 2

Field Data Type :	Run Down Rate 2
Field Name :	R2
Field Name :	“R2”
Description :	Decrease in active power consumption between run down elbows 2 and 3.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RDRE, RDRI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0 or 0 (representing a null value).

4.12.4.102 Run Down Rate 3

Field Data Type :	Run Down Rate 3
Field Name :	R3
Field Name :	“R3”
Description :	Decrease in active power consumption after run down elbow 3.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RDRE, RDRI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0 or 0 (representing a null value).

4.12.4.103 Run Up Elbow 2

Field Data Type :	Run Up Elbow 2
Field Type :	UB
Field Name :	“UB”
Description :	The point at which run up rate 2 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RURE, RURI
Additional Information :	Value in whole MW.

4.12.4.104 Run Up Elbow 3

Field Data Type :	Run Up Elbow 3
Field Type :	UC
Field Name :	“UC”
Description :	The point at which run up rate 3 applies.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RURE, RURI
Additional Information :	Value in whole MW.

4.12.4.105 Run Up Rate 1

Field Data Type :	Run Up Rate 1
Field Type :	U1
Field Name :	“U1”
Description :	Increase in active power production between zero and run up elbow 2.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RURE, RURI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0.

4.12.4.106 Run Up Rate 2

Field Data Type :	Run Up Rate 2
Field Type :	U2
Field Name :	“U2”
Description :	Increase in active power production between run up elbows 2 and 3.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RURE, RURI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0 or 0 (representing a null value).

4.12.4.107 Run Up Rate 3

Field Data Type :	Run Up Rate 3
Field Type :	U3
Field Name :	“U3”
Description :	Increase in active power production after run up elbow 3.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	RURE, RURI
Additional Information :	Value in MW/Minute. Valid values: 0.2 to 999.0 or 0 (representing a null value).

4.12.4.108 Sell Price

Field Data Type :	Sell Price
Field Type :	PS
Field Name :	“PS”
Description :	The system sell price for a particular settlement period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in £/MWh.

4.12.4.109 Sell Price Price Adjustment

Field Data Type :	Sell Price Price Adjustment
Field Type :	A3
Field Name :	“A3”
Description :	Adjustment applied to quotient in computation of Sell Price
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	NETBSAD, NETEBSP, DISEBSP
Additional Information :	Value in £/MWh.

4.12.4.110 Sequence Number

Field Data Type :	Sequence Number
Field Type :	SN
Field Name :	“SN”
Description :	The stack item’s Index number, representing the relative position of the associated stack item within its related stack. A value of 1 represents the first item in a stack.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	ISPSTACK
Additional Information :	A positive integer greater than zero.

4.12.4.111 Settlement Date

Field Data Type :	Settlement Date
Field Type :	SD
Field Name :	“SD”
Description :	The settlement date.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	OCNMFD, NDFD, MELNGC, IMBALNGC, INDDEM, INDGEN, INDO, FPN, QPN, BOD, MIL, MEL, BOAV, PTAV, EBOCF, NETEBSP, TBOD, NDF, TSDF, TSDFD, ITSDO, FUELINST, FUELHH, WINDFOR, NONBM, INDOD, DISEBSP, NETBSAD, DISBSAD, DISPTAV, ISPSTACK, OCNMFD2, FOU2T14D, UOU2T14D
Additional Information :	The time section of the DateTime is truncated to zero hours, zero minutes and zero seconds

4.12.4.112 Settlement Period

Field Data Type :	Settlement Period
Field Type :	SP
Field Name :	“SP”
Description :	The settlement Period.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	OCNMFD, NDFD, MELNGC, IMBALNGC, INDDEM, INDGEN, INDO, FPN, QPN, BOD, MIL, MEL, BOAV, PTAV, EBOCF, NETEBSP, TBOD, NDF, TSDF, TSDFD, ITSDO, FUELINST, FUELHH, WINDFOR, NONBM, DISEBSP, NETBSAD, DISBSAD, DISPTAV, ISPSTACK, LOLP, DCONTROL
Additional Information :	Valid values: 1 - 50

4.12.4.113 Short Acceptance Flag

Field Data Type :	Short Acceptance Flag
Field Type :	SA
Field Name :	“SA”
Description :	Flag indicating whether the Acceptance was of “short” duration
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	BOAV
Additional Information :	Valid values: ‘S’ or ‘L’

4.12.4.114 SO-Flag

Field Data Type :	SO-Flag
Field Type :	SO
Field Name :	“SO”
Description :	A value of ‘T’ indicates where an Acceptance or Balancing Services Adjustment Action item should be considered to be potentially impacted by transmission constraints.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	BOALF, ISPSTACK, DISBSAD
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.115 SO-SO Start Time

Field Data Type :	SO-SO Start Time
Field Type :	ST
Field Name :	“ST”
Description :	The date and time from which an SO-SO price applies.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	SOSO
Additional Information :

4.12.4.116 SO-SO Trade Direction

Field Data Type :	SO-SO Trade Direction
Field Type :	TD
Field Name :	“TD”
Description :	Flag indicating whether the direction of an SO-SO trade is up or down.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	SOSO
Additional Information :	Valid values: ‘A01’ (up) or ‘A02’ (down)

4.12.4.117 SO-SO Trade Type

Field Data Type :	SO-SO Trade Type
Field Type :	TT
Field Name :	“TT”
Description :	The type of SO-SO Trade.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	SOSO
Additional Information :

4.12.4.118 Spot Time

Field Data Type :	Spot Time
Field Type :	TS
Field Name :	“TS”
Description :	The time applicable to a given value in a Spot Point pair.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	FPN, QPN, BOD, BOAL, MIL, MEL, TEMP, FREQ, FUELINST, BOALF
Additional Information :	See section on ‘Conversion of Effective From/To times to Spot Times’

4.12.4.119 Stable Export Limit

Field Data Type :	Stable Export Limit
Field Type :	SE
Field Name :	“SE”
Description :	Range in which power export is stable.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	SEL
Additional Information :	Value in MW. Valid Values: 0 to 9999.

4.12.4.120 Stable Import Limit

Field Data Type :	Stable Import Limit
Field Type :	SI
Field Name :	“SI”
Description :	Range in which power import is stable.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	float
Messages containing field :	SIL
Additional Information :	Value in MW. Valid Values: -9999 to 0.

4.12.4.121 Stack Item Final Price

Field Data Type :	Stack Item Final Price
Field Type :	FP
Field Name :	“FP”
Description :	The final price of the associated stack item as used to determine the item’s final cost.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in £/MWh.

4.12.4.122 Stack Item Original Price

Field Data Type :	Stack Item Original Price
Field Type :	IP
Field Name :	“IP”
Description :	The original price of the associated stack item. Typically the Bid-Offer Original Price except for STOR Actions where the Stack Item Original Price is the derived price based on either the Bid-Offer Original Price or Reserve Scarcity Price (i.e. the STOR Action Price).
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in £/MWh.

4.12.4.123 Stack Item Volume

Field Data Type :	Stack Item Volume
Field Type :	IV
Field Name :	“IV”
Description :	The volume of the associated stack item.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.124 System Frequency

Field Data Type :	System Frequency
Field Type :	SF
Field Name :	“SF”
Description :	System Frequency in Hz.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	FREQ
Additional Information :	Value in Hz. Valid Values: 0 to 99.999

4.12.4.125 System Message Text

Field Data Type :	System Message text
Field Type :	SM
Field Name :	“SM”
Description :	This field contains the body text of any system messages that are generated by BMRA.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	SYSMSG
Additional Information :	The message text will be plain ascii text, in the majority of cases, be less than 4Kb in length.

4.12.4.126 System Total Priced Accepted Bid Volume

Field Data Type :	System Total Priced Accepted Bid Volume
Field Type :	PC
Field Name :	“PC”
Description :	System wide total Priced Accepted Bid Volume for the Settlement Period
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in MWh.

4.12.4.127 System Total Priced Accepted Offer Volume

Field Data Type :	System Total Priced Accepted Offer Volume
Field Type :	PP
Field Name :	“PP”
Description :	System wide total Priced Accepted Offer Volume for the Settlement Period
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in MWh.

4.12.4.128 System Total Unpriced Accepted Offer Volume

Field Data Type :	System Total Unpriced Accepted Offer Volume
Field Type :	AP
Field Name :	“AP”
Description :	System wide total Unpriced Accepted Offer Volume for the Settlement Period
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP
Additional Information :	Value in MWh.

4.12.4.129 System Total Unpriced Accepted Bid Volume

Field Data Type :	System Total Unpriced Accepted Bid Volume
Field Type :	AC
Field Name :	“AC”
Description :	System wide total Unpriced Accepted Bid Volume for the Settlement Period
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP
Additional Information :	Value in MWh.

4.12.4.130 System Warning Text

Field Data Type :	System Warning text
Field Type :	SW
Field Name :	“SW”
Description :	This field contains the body text of any system warnings that are announced by the NETSO.
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	SYSWARN
Additional Information :	The warning text will be plain ascii text, in the majority of cases, be less than 4Kb in length.

4.12.4.131 TLM Adjusted Cost

Field Data Type :	TLM Adjusted Cost
Field Type :	TC
Field Name :	“TC”
Description :	The derived cost of a stack item based on the final untagged volume, price and associated transmission loss multiplier.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in £.

4.12.4.132 TLM Adjusted Volume

Field Data Type :	TLM Adjusted Volume
Field Type :	TV
Field Name :	“TV”
Description :	The derived volume of a stack item based on the final untagged volume and associated transmission loss multiplier.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Value in MWh.

4.12.4.133 Total Bid Volume

Field Data Type :	Total Bid Volume
Field Type :	BT
Field Name :	“BT”
Description :	System wide total Bid Volume for the Settlement Period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TBOD
Additional Information :	Value in MWh

4.12.4.134 Total Offer Volume

Field Data Type :	Total Offer Volume
Field Type :	OT
Field Name :	“OT”
Description :	System wide total Offer Volume for the Settlement Period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	TBOD
Additional Information :	Value in MWh

4.12.4.135 Total Registered Capacity

Field Data Type :	Total Registered Capacity
Field Type :	TR
Field Name :	“TR”
Description :	Total Registered Wind Generation Capacity (MW).
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	Int
Messages containing field :	WINDFOR
Additional Information :

4.12.4.136 Total System Accepted Bid Volume

Field Data Type :	Total System Accepted Bid Volume
Field Type :	AB
Field Name :	“AB”
Description :	System wide total Accepted Bid Volume for the Settlement Period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in MWh

4.12.4.137 Total System Accepted Offer Volume

Field Data Type :	Total System Accepted Offer Volume
Field Type :	AO
Field Name :	“AO”
Description :	System wide total Accepted Offer Volume for the Settlement Period.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	NETEBSP, DISEBSP
Additional Information :	Value in MWh

4.12.4.138 Total System Adjustment Buy Volume

Field Data Type :	Total System Adjustment Buy Volume
Field Type :	J2
Field Name :	“J2”
Description :	Total volume of Adjustment items held on the Buy Stack.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.139 Total System Adjustment Sell Volume

Field Data Type :	Total System Adjustment Sell Volume
Field Type :	J1
Field Name :	“J1”
Description :	Total volume of Adjustment items held on the Sell Stack.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.140 Total System Tagged Accepted Bid Volume

Field Data Type :	Total System Tagged Accepted Bid Volume
Field Type :	T2
Field Name :	“T2”
Description :	Total tagged Accepted Bid volume.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.141 Total System Tagged Accepted Offer Volume

Field Data Type :	Total System Tagged Accepted Offer Volume
Field Type :	T1
Field Name :	“T1”
Description :	Total tagged Accepted Offer volume.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.142 Total System Tagged Adjustment Buy Volume

Field Data Type :	Total System Tagged Adjustment Buy Volume
Field Type :	J4
Field Name :	“J4”
Description :	Total tagged volume of Adjustment items held on the Buy Stack.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.143 Total System Tagged Adjustment Sell Volume

Field Data Type :	Total System Tagged Adjustment Sell Volume
Field Type :	J3
Field Name :	“J3”
Description :	Total tagged volume of Adjustment items held on the Sell Stack.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DISEBSP
Additional Information :	Value in MWh.

4.12.4.144 Trade Quantity

Field Data Type :	Trade Quantity
Field Type :	TQ
Field Name :	“TQ”
Description :	Level of an offered SO-SO trade.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	SOSO
Additional Information :	Value in MW

4.12.4.145 Trade Price

Field Data Type :	Trade Price
Field Type :	PT
Field Name :	“PT”
Description :	The price of an SO-SO trade.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	SOSO
Additional Information :	Value in unit currency per MWh. The currency used (e.g. EUR or GBP) will potentially be different for different SO-SO Trade Types (i.e. different Interconnectors and products)

4.12.4.146 Transmission Loss Multiplier

Field Data Type :	Transmission Loss Multiplier
Field Type :	TM
Field Name :	“TM”
Description :	The Transmission Loss Multiplier for the associated stack item derived from its associated BM Unit (for Balancing Services Adjustment Action items the value is set as 1.)
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	ISPSTACK
Additional Information :	Always a positive value.

4.12.4.147 Week Start Date

Field Data Type :	Week Start Date
Field Type :	WD
Field Name :	“WD”
Description :	The date of the Monday in a particular week.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	OCNMFW, OCNMF3Y, NDFW, TSDFW
Additional Information :	The time section of the DateTime will be truncated to zero hours, zero minutes and zero seconds.

4.12.4.148 Zone Indicator

Field Data Type :	Zone Indicator
Field Type :	ZI
Field Name :	“ZI”
Description :	The Zone that a forecast is applicable to
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	INDDEM, INDGEN, MELNGC, IMBALNGC, NDF, TSDF
Additional Information :	Valid Values: ”B1”, “B2”, “B3”, “B4”, “B5”, “B6”, “B7”, “B8”, “B9”, “B10”, “B11”, “B12”, “B13”, “B14”, “B15”, “B16”, “B17” and “N”

4.12.4.149 STOR Provider Flag

Field Data Type :	STOR Provider Flag
Field Type :	PF
Field Name :	“PF”
Description :	A value of ‘T’ indicates where an Acceptance or Balancing Services Adjustment Action item should be considered being related to a STOR Provider
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	BOALF, ISPSTACK, DISBSAD
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.150 De-rated Margin

Field Data Type :	De-rated Margin
Field Type :	DR
Field Name :	“DR”
Description :	***.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	LOLP
Additional Information :	Value in MW

4.12.4.151 Loss of Load Probability

Field Data Type :	Loss of Load Probability
Field Type :	LP
Field Name :	“LP”
Description :	***.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	LOLP
Additional Information :	Always less than or equal to 1

4.12.4.152 Affected LDSO

Field Data Type :	Affected LDSO
Field Type :	DS
Field Name :	“DS”
Description :	The LDSO affected by a demand control instruction
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	DCONTROL
Additional Information :

4.12.4.153 Demand Control ID

Field Data Type :	Demand Control ID
Field Type :	ID
Field Name :	“ID”
Description :	The unique identifier for a demand control instruction
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	DCONTROL
Additional Information :

4.12.4.154 Instruction Sequence No

Field Data Type :	Instruction Sequence No
Field Type :	SQ
Field Name :	“SQ”
Description :	The sequence number relating to the demand control event
TIB Data Type :	TIBRVMSG_32
C/Java Type :	Int
Messages containing field :	DCONTROL
Additional Information :

4.12.4.155 Demand Control Event Flag

Field Data Type :	Demand Control Event Flag
Field Type :	EV
Field Name :	“EV”
Description :	A value of ‘I’ indicates an instruction initiated by the NETSO or an Emergency Manual Disconnection. A Value of ‘L’ indicates an Automatic Low Frequency Demand Disconnection
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	char*/String
Messages containing field :	DCONTROL
Additional Information :

4.12.4.156 Time From

Field Data Type :	Time From
Field Type :	TF
Field Name :	“TF”
Description :	The time from which the demand control instruction takes effect
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	Time_t/Date
Messages containing field :	DCONTROL
Additional Information :

4.12.4.157 Time To

Field Data Type :	Time To
Field Type :	TI
Field Name :	“TI”
Description :	The time to which the demand control instruction takes effect
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	Time_t/Date
Messages containing field :	DCONTROL
Additional Information :

4.12.4.158 Demand Control Level

Field Data Type :	Demand Control Level
Field Type :	VO
Field Name :	“VO”
Description :	The level of demand during the demand control event in MW
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	DCONTROL
Additional Information :

4.12.4.159 Amendment Flag

Field Data Type :	Amendment Flag
Field Type :	AM
Field Name :	“AM”
Description :	ORI (Original), INS (Insert), UPD (Update)
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	DCONTROL
Additional Information :

4.12.4.160 Reserve Scarcity Price

Field Data Type :	Reserve Scarcity Price
Field Type :	RSP
Field Name :	“RSP”
Description :	The Reserve Scarcity Price for a given Settlement Period. This field will be NULL where related to an action that is not a STOR Action.
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Double
Messages containing field :	ISPSTACK, DISEBSP
Additional Information :	Value in £/MWh

4.12.4.161 Bid-Offer Original Price

Field Data Type :	Bid-Offer Original Price
Field Type :	UP
Field Name :	“UP”
Description :	The Offer or Bid Price or BSAA Cost of the System Action (£/MWh) as derived from the original BOD or BSAD
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Double
Messages containing field :	ISPSTACK
Additional Information :	Value in £/MWh

4.12.4.162 RR Quarter Hour Period

Field Data Type :	RR Quarter Hour Period
Field Type :	QP
Field Name :	“QP”
Description :	The Quarter Hour Period within a given Settlement Period.
TIB Data Type :	TIBRVMSG_I32
C/Java Type :	int
Messages containing field :	RRBD, AD, GBNM, IS, QRRC
Additional Information :	Valid values 1 - 2.

4.12.4.163 Party Id

Field Data Type :	Party Id
Field Type :	PI
Field Name :	“PI”
Description :	The unique identifier of a BSC Party
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.164 RR Market Balance Area

Field Data Type :	RR Market Balance Area
Field Type :	BA
Field Name :	“BA”
Description :	The identifier of the balancing area for Replacement Reserve
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.165 RR Associated TSO

Field Data Type :	RR Associated TSO
Field Type :	AT
Field Name :	“AT”
Description :	The identifier of the Transmission System Operator associated with Replacement Reserve data
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.166 RR Divisible

Field Data Type :	RR Divisible
Field Type :	DI
Field Name :	“DI”
Description :	Indicator of whether a RR bid is divisible
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :	Valid values: ‘A01’ (yes) or ‘A02’ (no)

4.12.4.167 RR Linking Bid Id

Field Data Type :	RR Linking Bid Id
Field Type :	LB
Field Name :	“LB”
Description :	Identifier to link bids, where applicable
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.168 RR Multipart Bid Id

Field Data Type :	RR Multipart Bid Id
Field Type :	MB
Field Name :	“MB”
Description :	Identifier to establish multipart bids, where applicable
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.169 RR Exclusive Bid Id

Field Data Type :	RR Exclusive Bid Id
Field Type :	EB
Field Name :	“EB”
Description :	Identifier to establish exclusive bids, where applicable
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.170 RR Flow Direction

Field Data Type :	RR Flow Direction
Field Type :	FD
Field Name :	“FD”
Description :	Indicator of direction of bid
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD, AD, GBNM, IS
Additional Information :	Valid values: ‘A01’ (up) or ‘A02 (down)

4.12.4.171 RR Quantity

Field Data Type :	RR Quantity
Field Type :	QI
Field Name :	“QI”
Description :	A quantity of an RR bid
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRBD, AD, GBNM, IS
Additional Information :	Value in MW

4.12.4.172 RR Maximum Quantity

Field Data Type :	RR Maximum Quantity
Field Type :	QX
Field Name :	“QX”
Description :	Quantity offered in bid
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRBD
Additional Information :	Value in MW

4.12.4.173 RR Bid Resolution

Field Data Type :	RR Bid Resolution
Field Type :	BR
Field Name :	“BR”
Description :	Resolution of bid
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :	Valid Values: ‘PT60M’, ‘PT30M’, ‘PT15M’

4.12.4.174 RR Position

Field Data Type :	RR Position
Field Type :	PO
Field Name :	“PO”
Description :	Position within the bid resolution interval
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :

4.12.4.175 RR Price

Field Data Type :	RR Price
Field Type :	PR
Field Name :	“PR”
Description :	Price of RR bid
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	TIBRVMSG_F32
Messages containing field :	RRBD, AD, GBNM
Additional Information :	Value in £/MWh

4.12.4.176 RR Status

Field Data Type :	RR Status
Field Type :	RS
Field Name :	“RS”
Description :	Status of the RR bid
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	RRBD
Additional Information :	Valid values: ‘A06’ (available, ‘A28’ (unshared), ‘A11’ (restricted)

4.12.4.177 RR Auction Period Start

Field Data Type :	Auction Period Start
Field Type :	AS
Field Name :	“AS”
Description :	The datetime of the start of an Auction Period.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	RRAGGINFO
Additional Information :

4.12.4.178 RR Auction Period End

Field Data Type :	Auction Period End
Field Type :	AE
Field Name :	“AE”
Description :	The datetime of the end of an Auction Period.
TIB Data Type :	TIBRVMSG_DATETIME
C/Java Type :	time_t/Date
Messages containing field :	RRAGGINFO
Additional Information :

4.12.4.179 RR Total Volume of Offered Bids

Field Data Type :	Total Volume of Offered Bids
Field Type :	OS
Field Name :	“OS”
Description :	Total volume of offered RR bids
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRAGGINFO
Additional Information :	Value in MWh

4.12.4.180 RR Total Volume of Activated Bids

Field Data Type :	Total Volume of Activated Bids
Field Type :	BS
Field Name :	“BS”
Description :	Total volume of activated RR bids
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRAGGINFO
Additional Information :	Value in MWh

4.12.4.181 RR Total Volume of Unavailable Bids

Field Data Type :	Total Volume of Unavailable Bids
Field Type :	US
Field Name :	“US”
Description :	Total volume of unavailable RR bids
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRAGGINFO
Additional Information :	Value in MWh

4.12.4.182 RR Business Type

Field Data Type :	RR Business Type
Field Type :	TY
Field Name :	“TY”
Description :	Type of Replacement Reserve
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	AD, GBNM, IS
Additional Information :	Value in MW

4.12.4.183 RR Interconnector Identifier

Field Data Type :	RR Interconnector Identifier
Field Type :	II
Field Name :	“II”
Description :	Identifier of interconnector
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	IS
Additional Information :	Value in MW

4.12.4.184 RR Cashflow

Field Data Type :	RR Cashflow
Field Type :	CR
Field Name :	“CR”
Description :	Cashflow associated with RR
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	QRRC, PRRC
Additional Information :	Value in £

4.12.4.185 RR Accepted Bid Volume

Field Data Type :	RR Accepted Bid Volume
Field Type :	BV
Field Name :	“BI”
Description :	Volume of accepted RR offers
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRBOAV, RRPTAV
Additional Information :	Value in MWh

4.12.4.186 RR Accepted Offer Volume

Field Data Type :	RR Accepted Offer Volume
Field Type :	OV
Field Name :	“OV”
Description :	Volume of accepted RR offers
TIB Data Type :	TIBRVMSG_F32
C/Java Type :	Float
Messages containing field :	RRBOAV, RRPTAV
Additional Information :	Value in MWh

4.12.4.187 RR Instruction Flag

Field Data Type :	RR Instruction Flag
Field Type :	RN
Field Name :	“RN”
Description :	Indicator of whether an acceptance is part of an RR instruction
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	BOALF
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.188 RR Schedule Flag

Field Data Type :	RR Schedule Flag
Field Type :	SC
Field Name :	“SC”
Description :	Indicator of when an acceptance is part of an RR schedule
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	BOALF
Additional Information :	Valid Values: ‘T’ or ‘F’.

4.12.4.189 Marketobjectstatus

Field Data Type:	Marketobjectstatus
Field Type:	MOS
Field Name:	“MOS”
Description:	Status of RR Bid
TIB Data Type:	TIBRVMSG_STRING
C/Java Type:	Char*/String
Messages containing field:	AD
Additional Information:	Valid values: Ordered, Available and Cancelled, which correspond to the LIBRA codes A10, A06 and A09 respectively

4.12.4.190 BSAD Party Id

Field Data Type :	BSAD Party Id
Field Type :	PX
Field Name :	“PX”
Description :	The name or unique identifier of the person who provides Balancing Services outside of the Balancing Mechanism
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	DISBSAD
Additional Information :

4.12.4.191 BSAD Asset Id

Field Data Type :	BSAD Asset Id
Field Type :	AX
Field Name :	“AX”
Description :	The name or unique identifier of the asset providing the relevant Balancing Services Adjustment Action
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	DISBSAD
Additional Information :

4.12.4.192 Tendered Status

Field Data Type :	Tendered Status
Field Type :	TX
Field Name :	“TX”
Description :	Whether the Balancing Service was procured by NETSO through a tender
TIB Data Type :	TIBRVMSG_STRING
C/Java Type :	Char*/String
Messages containing field :	DISBSAD
Additional Information :

4.12.4.193 Service Type

Field Data Type :	Service Type
Field Type :	SX
Field Name :	“SX”
Description :	The type of Balancing Service procured
TIB Data Type :	TIBRVMSG_STRINGT
C/Java Type :	Char*/String
Messages containing field :	DISBSAD
Additional Information :

4.12.5 Message Definitions

4.12.5.1 OCNMFD - Surplus Forecast 2-14 days ahead

This message contains peak-of-the-day surplus forecast values for the following 2 weeks. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of records	NR	The number of times the next THREE fields are repeated.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Margin/Surplus Value	VM	The surplus in MW.

Message Subject Name

BMRA.SYSTEM.OCNMFD

4.12.5.2 OCNMFW - Surplus Forecast 2-52 weeks ahead

This message contains peak-of-the-week surplus forecast values for the following year. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Week Start Date	WD	The start date of the week (in GMT).
Margin/Surplus Value	VM	The Surplus in MW.

Message Subject Name

BMRA.SYSTEM.OCNMFW

4.12.5.2A OCNMF3Y - Surplus Forecast 2-156 weeks ahead

This message contains peak-of-the-week surplus forecast values for the following three years. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Week Start Date	WD	The start date of the week (in GMT).
Margin/Surplus Value	VM	The Surplus in MW.

Message Subject Name

BMRA.SYSTEM.OCNMF3Y

4.12.5.3 NDFD - Demand Forecast 2-14 days ahead

This message contains peak-of-the-day demand forecast values for the following 2 weeks. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand Value	VD	The demand in MW.

Message Subject Name

BMRA.SYSTEM.NDFD

4.12.5.4 TSDFD – Transmission System Demand Forecast 2-14 days ahead

This message contains peak-of-the-day Transmission System demand forecast values for the following 2 weeks. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand Value	VD	The demand in MW.

Message Subject Name

BMRA.SYSTEM.TSDFD

4.12.5.5 NDFW - Demand Forecast 2-52 weeks ahead

This message contains peak-of-the-week demand forecast values for the following year. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Week Start Date	WD	The start date of the week (in GMT).
Demand Value	VD	The Demand in MW.

Message Subject Name

BMRA.SYSTEM.NDFW

4.12.5.6 TSDFW – Transmission System Demand Forecast 2-52 weeks ahead

This message contains peak-of-the-week Transmission System demand forecast values for the following year. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Number of Records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Week Start Date	WD	The start date of the week (in GMT).
Demand Value	VD	The Demand in MW.

Message Subject Name

BMRA.SYSTEM.TSDFW

4.12.5.7 NDF – National Demand Forecast

This message contains the National Demand Forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Every time an updated forecast is received from the NETSO, BMRA publishes the data in this message and additionally includes previously received forecast values from period 1 of the current day onwards. The Publishing Time field is therefore applicable to each period in the forecast and indicates the time that data for a particular period was last received and the data reported is always that most recently received for each period. The records in the message are ordered by Settlement Date and Period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. N for national data.
Number of Records	NR	This field indicates how many times the next FOUR fields appear in the message.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand	VD	The Demand in MW.

Message Subject Name

BMRA.SYSTEM.NDF.c

(where c is ‘N’ and indicates the forecast is National)

4.12.5.8 TSDF – Transmission System Demand Forecast

This message contains the Transmission System Demand Forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

The NETSO cannot provide Demand values for Interconnectors and pumped storage (Transmission System Demand forecast) for the 09:00am hour forecast. Therefore NETSO estimates these values or enters them as a ‘zero’ value.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. B1-B17 for zonal data, N for national data.
Number of Records	NR	This field indicates how many times the next FOUR fields appear in the message.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand	VtD	The Demand in MW.

Message Subject Name

BMRA.SYSTEM.TSDF.c

(where c is ‘N’, or ‘B1’ to ‘B17’ and indicates whether the forecast is National or Regional)

4.12.5.9 MELNGC - Indicated Margin

This message contains margin forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. B1-B17 for zonal data, N for national data.
Number of Records	NR	This field indicates how many times the next FOUR fields appear in the flow.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Indicated Margin	VM	The indicated margin in MW.

Message Subject Name

BMRA.SYSTEM.MELNGC.c

(where c is ‘N’, or ‘B1’ to ‘B17’ and indicates whether the forecast is National or Regional)

4.12.5.10 IMBALNGC - Indicated Imbalance

This message contains imbalance forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. B1-B17 for zonal data, N for national data.
Number of Records	NR	This field will indicate how many times the next FOUR fields appear in the flow.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Indicated Imbalance	VI	The indicated imbalance in MW.

Message Subject Name

BMRA.SYSTEM.IMBALNGC.c

(where c is ‘N’, or ‘B1’ to ‘B17’ and indicates whether the forecast is National or Regional)

4.12.5.11 INDGEN - Indicated Generation

This message contains generation forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. B1-B17 for zonal data, N for national data.
Number of Records	NR	This field will indicate how many times the next FOUR fields appear in the flow.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Indicated Generation	VG	The indicated generation in MW.

Message Subject Name

BMRA.SYSTEM.INDGEN.c

(where c is ‘N’, or ‘B1’ to ‘B17’ and indicates whether the forecast is National or Regional)

4.12.5.12 INDDEM - Indicated Demand

This message contains indicated demand forecast values for every half hour period from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Zone Indicator	ZI	The zone that this forecast applies to. B1-B17 for zonal data, N for national data.
Number of Records	NR	This field will indicate how many times the next FOUR fields appear in the flow.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which weather forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Indicated Demand	VD	The indicated demand in MW.

Message Subject Name

BMRA.SYSTEM.INDDEM.c

(where c is ‘N’, or ’B1’ to ‘B17’ and indicates whether the forecast is National or Regional)

4.12.5.13 SYSWARN - System Warnings

This message contains the text of any system warnings that are issued by the NETSO. Note that the Publishing Time is the time that the message was published by BMRA, not NETSO.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Time	TP	The time (in GMT) the warning was published by BMRA.
System Warning Text	SW	The body text of the system warning.

Message Subject Name

BMRA.SYSTEM.SYSWARN

4.12.5.14 INDO - Initial National Demand Out-turn

This message is published when the appropriate data is received from the NETSO. A single message is published every settlement period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	This is the time that the data was published by the NETSO.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand Out-turn	VD	The average demand in MW.

Message Subject Name

BMRA.SYSTEM.INDO

4.12.5.15 ITSDO – Initial Transmission System Demand Out-turn

This message is published when the appropriate data is received from the NETSO. A single message is published every settlement period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	This is the time that the data was published by the NETSO.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Demand Out-turn	VD	The average demand in MW.

Message Subject Name

BMRA.SYSTEM.ITSDO

4.12.5.16 TEMP – Temperature Data

This message contains the weighted average temperature as measured at noon local time in a number of GB locations, along with 3 additional reference data values for the Normal, High and Low temperatures.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO.
Spot Time	TS	The datetime at which the temperature was measured.
Outturn temperature	TO	Temperature in degrees celsius.
Normal Reference temperature	TN	Temperature in degrees celsius.
Low Reference temperature	TL	Temperature in degrees celsius.
High Reference temperature	TH	Temperature in degrees celsius.

Message Subject Name

BMRA.SYSTEM.TEMP

4.12.5.17 FREQ – System Frequency

This message contains the System Frequency at a spot time, measured in Hz.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Spot Time	TS	The datetime at which the frequency was measured.
System Frequency	SF	System Frequency in Hz.

Message Subject Name

BMRA.SYSTEM.FREQ

4.12.5.18 FUELINST – Instantaneous Generation by Fuel Type

This message contains the Instantaneous Generation by Fuel Type for a particular Settlement Period.

It should be noted that the TIBCO messages cap negative values received from NETSO at zero for all fuel types (including interconnectors).

Furthermore, the BMRA does NOT publish a Total Instantaneous figure across all fuel types.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that this element was originally published by the NETSO.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Spot Time	TS	The datetime at which the generation was measured.
Fuel Type	FT	Fuel Type.
Generation	FG	The Generation in MW.

Message Subject Name

BMRA.SYSTEM.FUELINST

4.12.5.19 FUELHH – Half-Hourly Generation by Fuel Type

This message contains the Generation by Fuel Type for a particular Half Hour.

It should be noted that the TIBCO messages cap negative values received from NETSO at zero for all non-interconnector fuel types. For interconnector fuel types, NO capping is applied, values are publish exactly as received.

Furthermore, the BMRA does NOT publish a Total Half-Hourly Outturn figure across all fuel types.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Fuel Type	FT	Fuel Type.
Generation	FG	The Generation in MW.

Message Subject Name

BMRA.SYSTEM.FUELHH

4.12.5.20 WINDFOR – Forecast Peak Wind Generation

This message contains the peak wind generation forecast values for various half hour periods from the start of the current day to the furthest ahead forecast that has so far been received by the BMRA.

Each forecast file contains data for the following local times:

21:00 D

00:00 D+1

05:00 D+1

08:00 D+1

12:00 D+1

17:00 D+1

21:00 D+1

00:00 D+2

05:00 D+2

08:00 D+2

12:00 D+2

17:00 D+2

21:00 D+2

Every time an updated forecast is received from the NETSO, BMRA publishes the data in this message and additionally includes previously received forecast values from period 1 of the current day onwards (where previously received). The Publishing Time field is therefore applicable to each period in the forecast and indicates the time that data for a particular period was last received and the data reported is always that most recently received for each period. The records in the message are ordered by Settlement Date and Period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Number of Records	NR	This field indicates how many times the next FOUR fields appear in the message.
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO. It is included so users can see which forecast this value comes from, and therefore which forecast the value was based upon.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Generation	VG	The Generation in MW.
Total Registered Capacity	TR	Total Registered Wind Generation Capacity (MW)

Message Subject Name

BMRA.SYSTEM.WINDFOR

4.12.5.21 INDOD – Daily Energy Volume Data

This message is published when the appropriate data is received from the NETSO. A single message is published every settlement day.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	This is the time that the data was published by the NETSO.
Settlement Date	SD	The settlement date.
Energy Volume Out-turn	EO	The Outturn Daily Energy Volume in MWh.
Energy Volume Low Reference	EL	The Daily Energy Low Reference Volume in MWh.
Energy Volume High Reference	EH	The Daily Energy High Reference Volume in MWh.
Energy Volume Normal Reference	EN	The Daily Energy Normal Reference Volume in MWh.

Message Subject Name

BMRA.SYSTEM.INDOD

4.12.5.22 NONBM – Non-BM STOR Generation Instructed Volume

This message contains the total volume of instructions issued to non-BM STOR units under Short Term Operating Reserve (STOR) contracts for a particular Half Hour.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that this element of the forecast was originally published by the NETSO.
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Non-BM STOR Volume	NB	The Non-BM STOR Instructed Volume in MWh.

Message Subject Name

BMRA.SYSTEM.NONBM

4.12.5.23 FPN - Final Physical Notice

This message contains FPN values for a single BM Unit, for a single settlement period. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a whole settlement period.

If the Number of Records field is set to zero, BMRA has received invalid data for that settlement period and BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VP field value is valid.
FPN Level	VP	FPN in MW at the above spot time.

Message Subject Name

BMRA.BM.<BM_UNIT>.FPN

4.12.5.24 QPN - Quiescent Physical Notice

This message contains QPN values for a single BM Unit, for a single settlement period. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a whole settlement period.

If the Number of Records field is set to zero, BMRA has received invalid data for that settlement period and BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VP field value is valid.
QPN Level	VP	QPN in MW at the above spot time.

Message Subject Name

BMRA.BM.<BM_UNIT>.QPN

4.12.5.25 BOD - Bid-Offer Pairs

This message contains Bid-Offer values for a single BM Unit, for a single settlement period, for a single bid-offer pair number. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a whole settlement period.

If the Number of Records field is set to zero, BMRA has received invalid data for that settlement period and BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer pair number	NN	B-O pair number.
Offer price	OP	Offer price.
Bid price	BP	Bid price.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot time	TS	The time at which the following VB field value is valid.
Bid-Offer Level Value	VB	Bid-Offer level in MW at the above spot time.

Message Subject Name

BMRA.BM.<BM_UNIT>.BOD.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.26 BOAL - Bid-Offer Acceptances

This message contains acceptance data for a single BM Unit, for a single acceptance for Settlement Dates prior to the P217 effective date. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a single acceptance.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Acceptance number	NK	The acceptance number described in this message.
Acceptance Time	TA	Time that acceptance was made.
Deemed Acceptance flag	AD	If true, no Bid-Offer was made.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VA field value is valid.
Acceptance Level Value	VA	Acceptance in MW at the above spot time.

Message Subject Name

BMRA BM.<BM_UNIT>.BOAL

4.12.5.27 BOALF – Bid-Offer Acceptance Level Flagged

This message contains acceptance data for a single BM Unit, for a single acceptance for Settlement Dates on and after the P217 effective date. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a single acceptance.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Acceptance number	NK	The acceptance number described in this message.
SO-Flag	SO	A value of 'T' indicates the Acceptance should be considered to be potentially impacted by transmission constraints.
STOR Provider Flag	PF	Indicates the item relates to a STOR Provider
RR Instruction Flag	RN	Indicates the item relates to an RR Instruction
RR Schedule Flag	SC	Indicates the item relates to the RR Schedule
Acceptance Time	TA	Time that acceptance was made.
Deemed Acceptance flag	AD	If true, no Bid-Offer was made.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VA field value is valid.
Acceptance Level Value	VA	Acceptance in MW at the above spot time.

Message Subject Name

BMRA BM.<BM_UNIT>.BOALF

4.12.5.28 MEL - Maximum Export Limit

This message contains MEL values for a single BM Unit, for a single settlement period. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a whole settlement period.

If the Number of Records field is set to zero, BMRA has received invalid data for that settlement period and BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Number of Spot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VE field value is valid.
MEL	VE	MEL in MW at the above spot time.

Message Subject Name

BMRA.BM.<BM_UNIT>.MEL

4.12.5.29 MIL - Maximum Import Limit

This message contains MIL values for a single BM Unit, for a single settlement period. The data is published as it is received from the NETSO.

Note that the Effective From Time and Effective To Times are converted to spot times for purposes of distribution. One message will contain the data for a whole settlement period.

If the Number of Records field is set to zero, BMRA has received invalid data for that settlement period and BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Number of Plot Points	NP	The number of spot points. Implies that what follows is a series of spot data points, each of which consist of TWO fields.
Spot Time	TS	The time at which the following VF field value is valid.
MIL	VF	MIL in MW at the above spot time

Message Subject Name

BMRA.BM.<BM_UNIT>.MIL

4.12.5.30 BOAV - Bid-Offer Acceptance Volumes

This message contains data derived by BMRA concerning bid and offer acceptance volumes - one message is published per acceptance, per bid-offer pair number, per BM Unit. Due to the granularity of this message, many BOAV messages types can be published every settlement period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer pair number	NN	B-O pair number that the acceptance volumes apply to.
Acceptance Number	NK	Acceptance number that the volumes apply to.
Period BM Unit Offer Accepted Volume	OV	Total Offer Volume accepted for a particular B-O pair.
Period BM Unit Bid Accepted Volume	BV	Total Bid Volume accepted for a particular B-O pair.
Short Acceptance Flag	SA	Flag indicating whether the Acceptance was of “short” duration

Message Subject Name

BMRA.BM.<BM_UNIT>.BOAV.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0)

4.12.5.31 PTAV - Period Total Bid-Offer Acceptance Volumes

This message contains data derived by BMRA concerning period total bid and offer acceptance volumes - one message is published per bid-offer pair number, per settlement period, per BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer pair number	NN	B-O pair number that the acceptance volumes apply to.
Period Total BM Unit Offer Volume	OV	Total Offer Volume accepted for a particular B-O pair.
Period Total BM Unit Bid Volume	BV	Total Bid Volume accepted for a particular B-O pair.

Message Subject Name

BMRA.BM.<BM_UNIT>.PTAV.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.32 DISPTAV – Disaggregated Period Total Bid-Offer Acceptance Volumes

This message contains data derived by BMRA concerning period total bid and offer acceptance volumes - one message is published per Bid-Offer Pair Number, per Settlement Period, per BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The Settlement Date.
Settlement Period	SP	The Settlement Period.
Bid-Offer Pair Number	NN	B-O Pair Number that the acceptance volumes apply to.
Period Total BM Unit Offer Volume	OV	Total Offer Volume accepted for a particular B-O Pair.
Period Tagged BM Unit Offer Volume	P1	Tagged element of the Total Offer Volume accepted for a particular B-O Pair.
Period Repriced BM Unit Offer Volume	P2	Repriced element of the Total Offer Volume accepted for a particular B-O Pair.
Period Originally-Priced BM Unit Offer Volume	P3	Originally-priced element of the Total Offer Volume accepted for a particular B-O Pair.
Period Total BM Unit Bid Volume	BV	Total Bid Volume accepted for a particular B-O Pair.
Period Tagged BM Unit Bid Volume	P4	Tagged element of the Total Bid Volume accepted for a particular B-O Pair.
Period Repriced BM Unit Bid Volume	P5	Repriced element of the Total Bid Volume accepted for a particular B-O Pair.
Period Originally-Priced BM Unit Bid Volume	P6	Originally-priced element of the Total Bid Volume accepted for a particular B-O Pair.

Message Subject Name

BMRA.BM.<BM_UNIT>.DISPTAV.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.33 EBOCF - Estimated Bid-Offer Cash Flows

This message contains data derived by BMRA concerning bid and offer cashflows - one message is published per bid-offer pair number, per settlement period, per BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer pair number	NN	B-O pair number that the acceptance volumes apply to.
Period BM Unit Offer Cash Flow	OC	Period Offer Cash Flow for a particular B-O pair.
Period BM Unit Bid Cash Flow	BC	Period Bid Cash Flow for a particular B-O pair.

Message Subject Name

BMRA.BM.<BM_UNIT>.EBOCF.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.34 DISEBSP – Disaggregated Estimated Buy and Sell Price

This message contains data derived by BMRA concerning estimated system buy and sell prices for Settlement Dates on and after the P217 effective date - one message is published per settlement period.

Note: where no Replacement Price has been calculated the values of the ‘Replacement Price’ and ‘Replacement Price Calculation Volume’ fields will be considered to be NULL and therefore they will not be included in the associated Tibco message

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The Settlement Date.
Settlement Period	SP	The Settlement Period.
Buy Price	PB	The price that must be paid for electricity which is out of balance.
Sell Price	PS	The price received for electricity which is out of balance.
Price Derivation Code	PD	A code that describes the way in which SSP and SBP were calculated
Reserve Scarcity Price	RSP	The Reserve Scarcity Price
Replacement Price	RP	The derived Replacement Price value. This field can be NULL and so may not always be included in the Tibco message.
Replacement Price Calculation Volume	RV	The volume used to derive the Replacement Price. This field can be NULL and so may not always be included in the Tibco message.
BSAD Defaulted	BD	If True the following BSAD fields are default values
Sell Price Price Adjustment	A3	SPA in £/MWh
Buy Price Price Adjustment	A6	BPA in £/MWh
Indicative Net Imbalance Volume	NI	The Indicative NIV
Total System Accepted Offer Volume	AO	System wide total Accepted Offer Volume for the Settlement Period
Total System Accepted Bid Volume	AB	System wide total Accepted Bid Volume for the Settlement Period
Total System Tagged Accepted Offer Volume	T1	System wide total tagged Accepted Offer Volume for the Settlement Period
Total System Tagged Accepted Bid Volume	T2	System wide total tagged Accepted Bid Volume for the Settlement Period
System Total Priced Accepted Offer Volume	PP	System wide total Priced Accepted Offer Volume for the Settlement Period
System Total Priced Accepted Bid Volume	PC	System wide total Priced Accepted Bid Volume for the Settlement Period
Total System Adjustment Sell Volume	J1	System wide total Adjustment Sell Volume for the Settlement Period
Total System Adjustment Buy Volume	J2	System wide total Adjustment Buy Volume for the Settlement Period
Total System Tagged Adjustment Sell Volume	J3	System wide total tagged Adjustment Sell Volume for the Settlement Period
Total System Tagged Adjustment Buy Volume	J4	System wide total tagged Adjustment Buy Volume for the Settlement Period

Message Subject Name

BMRA.SYSTEM.DISEBSP

4.12.5.35 RURE - Run Up Rates Export

This messages contains dynamic data, which is published whenever it is received from the NETSO. The message describes the run up rates of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following U* field values are effective from.
Run up rate 1	U1
Run up elbow 2	UB
Run up rate 2	U2
Run up elbow 3	UC
Run up rate 3	U3

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.RURE

4.12.5.36 RURI - Run Up Rates Import

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the run up rates of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following U* field values are effective from.
Run up rate 1	U1
Run up elbow 2	UB
Run up rate 2	U2
Run up elbow 3	UC
run up rate 3	U3

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.RURI

4.12.5.37 RDRE - Run Down Rates Export

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the run down rates of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following R* field values are effective from.
Run down rate 1	R1
Run down elbow 2	RB
Run down rate 2	R2
Run down elbow 3	RC
run down rate 3	R3

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.RDRE

4.12.5.38 RDRI - Run Down Rates Import

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the run down rates of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following R* field values are effective from.
Run down rate 1	R1
Run down elbow 2	RB
Run down rate 2	R2
Run down elbow 3	RC
run down rate 3	R3

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.RDRI

4.12.5.39 NDZ - Notice to Deviate from Zero

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the notice to deviate from zero time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following DE field value is effective from.
Notice to Deviate from Zero	DZ

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.NDZ

4.12.5.40 NTO - Notice to Deliver Offers

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the notice to deliver offers time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following DO field value is effective from.
Notice to Deliver Offers	DO

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.NTO

4.12.5.41 NTB - Notice to Deliver Bids

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the notice to deliver bids time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following DB field value is effective from.
Notice to Deliver Bids	DB

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.NTB

4.12.5.42 MZT - Minimum Zero Time

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the minimum zero time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following MZ field value is effective from.
Minimum Zero Time	MZ

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.MZT

4.12.5.43 MNZT - Minimum non-Zero Time

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the minimum non-zero time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following MN field value is effective from.
Minimum non-Zero Time	MN

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.MNZT

4.12.5.44 SEL - Stable Export Limit

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the stable export limit of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following SE field value is effective from.
Stable Export Limit	SE

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.SEL

4.12.5.45 SIL - Stable Import Limit

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the stable import limit of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following SI field value is effective from.
Stable Import Limit	SI

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.SIL

4.12.5.46 MDV - Maximum Delivery Volume

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the maximum delivery volume of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following DV field value is effective from.
Maximum Delivery Volume	DV

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.MDV

4.12.5.47 MDP - Maximum Delivery Period

This message contains dynamic data, which is published whenever it is received from the NETSO. The message describes the maximum delivery period time of a single BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Effective From Time	TE	Time that the following DP field value is effective from.
Maximum Delivery Period	DP

Message Subject Name

BMRA.DYNAMIC.<BM_UNIT>.MDP

4.12.5.48 TBOD - Total Bid Offer Data

This message contains data derived by BMRA concerning total bid and total offer volumes - one message is published per settlement period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Total Offer Volume	OT	System wide total Offer Volume for the Settlement Period
Total Bid Volume	BT	System wide total Bid Volume for the Settlement Period

Message Subject Name

BMRA.SYSTEM.TBOD

4.12.5.49 DISBSAD – Balancing Services Adjustment Action Data

This message contains values for a single Balancing Services Adjustment Action data item for a half hour period for Settlement Dates on or after the P217 effective date.

Every time the data for a period is received from the NETSO, BMRA publishes the data in this message.

Note: where a Balancing Services Adjustment Action has no defined cost then the associated Tibco message will not include an ‘Adjustment Cost’ field.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date
Settlement Period	SP	The settlement period
Adjustment Identifier	AI	The item’s unique (for the settlement period) identifier
SO-Flag	SO	A value of 'T' indicates the Balancing Services Adjustment Action should be considered to be potentially impacted by transmission constraints
STOR Provider Flag	PF	Indicates the item relates to a STOR Provider
Adjustment Cost	JC	in £. Where an Action has no defined cost then this field will not be included in the Tibco message.
Adjustment Volume	JV	in MWh
BSAD Party Id	PX	The name or unique identifier of the person who provides Balancing Services outside of the Balancing Mechanism
BSAD Asset Id	AX	The name or unique identifier of the asset providing the relevant Balancing Services Adjustment Action
Tendered Status	TX	Whether the Balancing Service was procured by NETSO through a tender
Service Type	SX	The type of Balancing Service procured

Message Subject Name

BMRA.SYSTEM.DISBSAD

4.12.5.50 MSG – BMRS Informational Message

This message contains only informational data. It is reserved for future use but may appear in the general message transfers from time to time. It should be ignored by participants.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Time	TP	The time (in GMT) the information was published by BMRA.
Information Text	IN	The body text of the informational message.

Message Subject Name

BMRA.INFO.MSG

4.12.5.51 NETEBSP - Estimated Buy and Sell Price

This message contains data derived by BMRA concerning estimated system buy and sell prices, for Settlement Dates prior to the P217 effective date - one message is published per Settlement Period.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The Settlement Date.
Settlement Period	SP	The Settlement Period.
Buy Price	PB	The price that must be paid for electricity which is out of balance.
Sell Price	PS	The price received for electricity which is out of balance.
Price Derivation Code	PD	A code that describes the way in which SSP and SBP were calculated
Total Accepted Offer Volume	AO	System wide total Accepted Offer Volume for the Settlement Period
Total Accepted Bid Volume	AB	System wide total Accepted Bid Volume for the Settlement Period
Total Unpriced Accepted Offer Volume	AP	System wide total Unpriced Accepted Offer Volume for the Settlement Period
Total Unpriced Accepted Bid Volume	AC	System wide total Unpriced Accepted Bid Volume for the Settlement Period
Total Priced Accepted Offer Volume	PP	System wide total Priced Accepted Offer Volume for the Settlement Period
Total Priced Accepted Bid Volume	PC	System wide total Priced Accepted Bid Volume for the Settlement Period
Indicative Net Imbalance Volume	NI	The Indicative NIV
BSAD Defaulted	BD	If True the following BSAD fields are default values
Net Energy Sell Price Cost Adjustment	A7	ESCA in £
Net Energy Sell Price Volume Adjustment	A8	ESVA in MWh
Net System Sell Price Volume Adjustment	A11	SSVA in MWh
Sell Price Price Adjustment	A3	SPA in £/MWh
Net Energy Buy Price Cost Adjustment	A9	EBCA in £
Net Energy Buy Price Volume Adjustment	A10	EBVA in MWh
Net System Buy Price Volume Adjustment	A12	SBVA in MWh
Buy Price Price Adjustment	A6	BPA in £/MWh

Message Subject Name

BMRA.SYSTEM.NETEBSP

4.12.5.52 NETBSAD - Balancing Services Adjustment Data

This message contains a set of adjustment values for a half hour period.

Every time the data for a period is received from the NETSO, BMRA publishes the data in this message. Note that for Settlement Dates on or after the P217 effective date the following data items will always be zero:

Net Energy Buy Price Cost Adjustment (EBCA)
Net Energy Buy Price Volume Adjustment (EBVA)
Net System Buy Price Volume Adjustment (SBVA)
Net Energy Sell Price Cost Adjustment (ESCA)
Net Energy Sell Price Volume Adjustment (ESVA)
Net System Sell Price Volume Adjustment (SSVA)

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The Settlement Date
Settlement Period	SP	The Settlement Period
Net Energy Sell Price Cost Adjustment	A7	ESCA in £
Net Energy Sell Price Volume Adjustment	A8	ESVA in MWh
Net System Sell Price Volume Adjustment	A11	SSVA in MWh
Sell Price Price Adjustment	A3	SPA in £/MWh
Net Energy Buy Price Cost Adjustment	A9	EBCA in £
Net Energy Buy Price Volume Adjustment	A10	EBVA in MWh
Net System Buy Price Volume Adjustment	A12	SBVA in MWh
Buy Price Price Adjustment	A6	BPA in £/MWh

Message Subject Name

BMRA.SYSTEM.NETBSAD

4.12.5.53 SYSMSG - System Messages

This message contains the text of any system messages that are generated by BMRA. Note that the Publishing Time is the time that the message was published by BMRA.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Message Type	MT	The ‘type’ of message being reported.
Publishing Time	TP	The time (in GMT) the message was published by BMRA.
System Message Text	SM	The body text of the system message.

Message Subject Name

BMRA.SYSTEM.SYSMSG

4.12.5.54 MID – Market Index Data

This message contains a set of Market Index Data values for a half hour period.

Every time the data for a period is received from an MIDP, BMRA publishes the data in this message.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Market Index Data Provider ID	MI	Market Index Data Provider Identifier
Settlement Date	SD	The Settlement Date
Settlement Period	SP	The Settlement Period
Market Index Price	M1	Market Index Price in £/MWh
Market Index Volume	M2	Market Index Volume in MWh

Message Subject Name

BMRA.SYSTEM.MID

4.12.5.55 SOSO – SO-SO Prices

This message contains details of prices for trades offered between the NETSO and another System Operator. The data is published by BMRA as it is received from the NETSO.

Message Definition

Field	Field Type	Description of field
SO-SO Trade Type	TT	A code identifying the type of trade being made
SO-SO Start Time	ST	The start date and time for which a Trade Price applies
SO-SO Trade Direction	TD	The direction of the trade
Contract Identification	IC	A unique identifier for an offered trade
Trade Quantity	TQ	The quantity of an offered trade in MW
Trade Price	PT	The price of the trade in units of currency per MWh

Message Subject Name

BMRA.SYSTEM.SOSO

4.12.5.56 QAS - BM Unit Applicable Balancing Services Volume

This message contains the Applicable Balancing Services Volume for a BM Unit in a specific Settlement Period. The data is published as it is received from the NETSO.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The Settlement Date.
Settlement Period	SP	The Settlement Period.
BM Unit Applicable Balancing Services Volume	SV	Energy Volume in MWh for the Settlement Period

Message Subject Name

BMRA.BM.<BM_UNIT>.QAS

4.12.5.57 CDN – Credit Default Notice

This message contains Credit Default Notices values for a single BSC Party, and the settlement date and period the default level was entered and cleared (if applicable). The data is published as it is received from ECVAA and repeated up to 3 times at 20 minute intervals (Note that both the repeat count and the interval are configurable).

NOTE: The last 3 fields of the message (Cleared Default Settlement Date, Cleared Default Settlement Period, and Cleared Default Text) are all optional and will not be present in all messages. The absence of these fields indicates that the party is currently in the Credit Default Level published. The message will therefore always contain either 3 (for Parties entering default) or 6 (for Parties clearing default) fields.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Credit Default Level	DL	The credit default level
Entered Default Settlement Date	ED	The entered default settlement date.
Entered Default Settlement Period	EP	The entered default settlement period.
Cleared Default Settlement Date	CD	(Optional) The cleared default settlement date.
Cleared Default Settlement Period	CP	(Optional) The cleared default settlement period.
Cleared Default Text	CT	(Optional) The cleared default text

Message Subject Name

BMRA.BP.<PARTICIPANT>.CDN

4.12.5.58 ISPSTACK – Indicative System Price Stack

This message contains data derived by BMRA when calculating the System Price. The Indicative System Price Stacks (Buy and Sell) consist of a number of ordered stack items which can be either BM Unit Acceptance or Balancing Services Adjustment Action data. Each message relates to a single item on the Bid or Offer Stack for a given Settlement Period. The total stack data for a given Settlement Period is therefore communicated using a number of messages. Each individual message indicates which stack (Buy or Sell) it relates to as well as indicating the relative position of the data item within that stack.

Note: where a stack item has no defined cost then the associated Tibco message will not include a ‘Stack Item Original Price’ field. For Balancing Services Adjustment Action and Demand Control Volume stack items the ‘Acceptance Number’ and ‘Bid-Offer Pair Number’ fields will not be included in the associated Tibco message because these items are NULL.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid/Offer Indicator	BO	Indicates whether this is a Bid or an Offer item.
Sequence Number	SN	The stack item’s Index number, representing the relative position of the associated stack item within its related stack. A value of 1 representing the first item in the stack.
Component Identifier	CI	For an acceptance data item this will hold the associated BM Unit’s Id. For Balancing Services Adjustment Action items this will hold the item’s unique ID as allocated by the SO. For RR actions and Volume of GB Need Met this will be a standard identifer used distinguish these items as being related to Replacement Reserve. For Demand Control Volume stack items a unique ID that BSC Agent’s System derives.
Acceptance Number	NK	The acceptance number (for Balancing Services Adjustment Action and Demand Control Volume items this will be NULL and therefore not included in the associated Tibco message.)
Bid-Offer Pair Number	NN	The Bid-Offer Pair number (for Balancing Services Adjustment Action and Demand Control Volume items this will be NULL and therefore not included in the associated Tibco message.)
CADL Flag	CF	A value of 'T' indicates that an Acceptance is considered to be a Short Duration Acceptance.
SO-Flag	SO	A value of 'T' indicates that an Acceptance or Balancing Services Adjustment Action item should be considered to be potentially impacted by transmission constraints.
STOR Provider Flag	PF	Indicates the item relates to a STOR Provider
Repriced Indicator	RI	Indicates where the item has been repriced.
Bid-Offer Original Price	UP	The Offer or Bid Price of the stack item (£/MWh) as reported in the original BOD
Reserve Scarcity Price	RSP	The calculated Reserve Scarcity Price. This field will be NULL where the action is outside of a STOR Availability Window
Stack Item Original Price	IP	The stack item’s original price in £/MWh (i.e. the Bid-Offer Original Price). For STOR Actions, the Stack Item Original Price is the derived price based on either the Bid-Offer Original Price or Reserve Scarcity Price. For items which are initially unpriced this value will be NULL and therefore not included in the associated Tibco message.
Stack Item Volume	IV	The stack item’s volume in MWh
DMAT Adjusted Volume	DA	The item’s volume after DMAT has been applied.
Arbitrage Adjusted Volume	AV	The item’s volume after Arbitrage has been applied.
NIV Adjusted Volume	NV	The item’s volume after NIV has been applied,
PAR Adjusted Volume	PV	The item’s volume after PAR has been applied.
Stack Item Final Price	FP	The stack item’s final price in £/MWh
Transmission Loss Multiplier	TM	The associated BM Unit’s Transmission Loss Multiplier value (for Balancing Services Adjustment Action items this will be 1.)
TLM Adjusted Volume	TV	PAR Adjusted Volume x TLM
TLM Adjusted Cost	TC	PAR Adjusted Volume x TLM x Price

Message Subject Name

BMRA.SYSTEM.ISPSTACK

4.12.5.59 OCNMFD2 – Generating Plant Demand Margin, 2-14 days ahead

This message contains peak-of-the-day generating plant demand margin values for the following 2 weeks. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSP
Number of records	NR	The number of times the next TWO fields are repeated.
Settlement Date	SD	The settlement date.
Demand Margin	DM	The demand margin for generating plants in MW

Message Subject Name

BMRA.SYSTEM.OCNMFD2

4.12.5.60 OCNMFW2 – Generating Plant Demand Margin, 2-52 weeks ahead

This message contains peak-of-the-week generating plant demand margin values for the following year. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Demand Margin	DM	The demand margin for generating plants in MW

Message Subject Name

BMRA.SYSTEM.OCNMFW2

4.12.5.60A OCNMF3Y2 – Generating Plant Demand Margin, 2-156 weeks ahead

This message contains peak-of-the-week generating plant demand margin values for the following three years. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next THREE fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Demand Margin	DM	The demand margin for generating plants in MW

Message Subject Name

BMRA.SYSTEM.OCNMF3Y2

4.12.5.61 FOU2T14D – National Output Usable by Fuel Type, 2-14 days ahead

This message contains peak-of-the-day output usable values for the following 2 weeks by fuel type. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next THREE fields are repeated.
Settlement Date	SD	The settlement date.
Fuel Type	FT	The fuel type.
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.FOU2T14D

4.12.5.62 UOU2T14D – National Output Usable by Fuel Type and BM Unit, 2-14 days ahead

This message contains peak-of-the-day output usable values for the following 2 weeks by fuel type and BM Unit. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next THREE fields are repeated.
Settlement Date	SD	The settlement date.
Fuel Type	FT	The fuel type.
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.<BM_UNIT>.UOU2T14D

4.12.5.63 FOU2T52W – National Output Usable by Fuel Type, 2-52 weeks ahead

This message contains peak-of-the-week output usable values for the following year by fuel type. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next FOUR fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Fuel Type	FT	The fuel type
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.FOU2T52W

4.12.5.63A FOU2T3YW – National Output Usable by Fuel Type, 2-156 weeks ahead

This message contains peak-of-the-week output usable values for the following three years by fuel type. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next FOUR fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Fuel Type	FT	The fuel type
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.FOU2T3YW

4.12.5.64 UOU2T52W – National Output Usable by Fuel Type and BM Unit, 2-52 weeks ahead

This message contains peak-of-the-week output usable values for the following year by fuel type and BM Unit. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next FOUR fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Fuel Type	FT	The fuel type
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.<BM_UNIT>.UOU2T52W

4.12.5.64A UOU2T3YW – National Output Usable by Fuel Type and BM Unit, 2-156 weeks ahead

This message contains peak-of-the-week output usable values for the following three years by fuel type and BM Unit. The data is published by BMRA as it is received from the NETSO. The Publishing Time in the message is applicable to the forecast as a whole. The records in the message are ordered by time.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next FOUR fields are repeated.
Calendar Week Number	WN	The number of the week.
Calendar Year	CY	The year to which the data pertains
Fuel Type	FT	The fuel type
Output Usable	OU	The output usable in MW.

Message Subject Name

BMRA.SYSTEM.<BM_UNIT>.UOU2T3YW

4.12.5.65 REMIT – Data relating to Regulation on Energy Market Integrity and Transparency)

This message contains information submitted by BMR Service Users in accordance with REMIT regulations, detailing outages and/or expected changes in capacity of assets under their control.

Message Definition

Each message is delivered as an XML payload through the TIBCO channel; for details of the schema refer to the REMIT XSD maintained and made available by the BMRA.

Message Subject Name

REMIT.BMRS

4.12.5.66 TRANSPARENCY – Data relating to Transparency Regulations

This message contains information relating to known outages and changes in capacity that is required to be reported under the Transparency Regulations. There are several different articles of data established under these Regulations.

The following details are reported by the BMRS:

Article ref	Category	Description
6.1.(a)	Load	Actual Total Load per Bidding Zone
6.1.(b)	Load	Day Ahead Total Load per Biding Zone
6.1.(c)	Load	Week Ahead Total Load Forecast per Bidding Zone
6.1.(d)	Load	Month Ahead Total Load Forecast per Bidding Zone
6.1.(e)	Load	Year Ahead Total Load Forecast per Bidding Zone
7.1.(a)	Outages	Planned Unavailability of Consumption Units (>=100MW)
7.1.(b)	Outages	Changes in Actual Availability of Consumption Units (>=100MW)
8.1	Load	Year Ahead Forecast Margin
9.1	Transmission	Expansion and Dismantling Projects (≥100MW)
10.1.(a)	Outages	Planned Unavailability in the Transmission Grid (≥100MW)
10.1.(b)	Outages	Changes in Actual Availability in the Transmission Grid (≥100MW)
10.1.(c)	Outages	Changes in Actual Availability of Off-Shore Grid Infrastructure
13.(b)	Congestion Management	Countertrading
13.1(c)	Congestion Management	Costs of Congestion Management
14.1.(a)	Generation	Installed Generation Capacity Aggregated (>1MW)
14.1.(b)	Generation	Installed Generation Capacity per Unit (>100MW)
14.1.(c)	Generation	Day-Ahead Aggregated Generation
14.1.(d)	Generation	Day-Ahead Generation Forecasts for Wind and Solar (MWh)
15.1.(a)	Outages	Planned Unavailability of Generation Units (>100MW)
15.1.(b)	Outages	Changes in Actual Availability of Generation Units (>100MW)
15.1.(c)	Outages	Planned Unavailability of Production Units (≥200 MW including changes of 100 MW or more)
15.1.(d)	Outages	Changes in Actual Availability of Production Units (≥200 MW)
16.1.(a)	Generation	Actual Generation Output Per Generation Unit
16.1.(b)	Generation	Aggregated Generation per Type (units >100MW installed capacity)
16.1.(c)	Generation	Actual or Estimated Wind and Solar Power Generation
17.1.(b)	Balancing	Amount of Balancing Reserves under Contract
17.1.(c)	Balancing	Prices of Procured Balancing Reserves
17.1.(d)	Balancing	Accepted Aggregated Offers
17.1.(e)	Balancing	Activated Balancing Energy
17.1.(f)	Balancing	Prices of Activated Balancing Energy
17.1.(g)	Balancing	Market Imbalance Prices
17.1.(h)	Balancing	Aggregated Imbalance Volumes
17.1.(i)	Balancing	Financial Expenses And Income For Balancing
17.1.(j)	Balancing	Cross-Border Balancing Volumes of Exchanged Bids and Offers. Prices Energy Activated

The article code can be used to subscribe to specific articles of interest.

Message Definition

Each message is delivered as an XML payload through the TIBCO channel. Each of the categories makes use of a schema defined by ENTSO-E and available from the Transparency section of the ENTSO-E Website (www.entsoe.eu).

Message Subject Name

TRANSPARENCY.BMRS.<ARTICLE>

4.12.5.67 LoLP – Loss of Load Probability and De-rated Margin

This message contains values of indicative and final Loss of Load Probability along with De-rated Margin.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next FOUR fields are repeated.
Settlement Date	SD	The Settlement Date
Settlement Period	SP	The Settlement Period
LoLP	LP	Loss of Load Probability
De-rated Margin	DR	De-rated Margin in MW

Message Subject Name

BMRA.SYSTEM.LOLP

4.12.5.68 DCONTROL – Demand Control Instruction Notification

This message contains details of Demand Control instructions issued by the NETSO.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Publishing Date	TP	The time that the data was originally published by the NETSO
Number of records	NR	The number of times the next NINE fields are repeated.
Affected LDSO	DS	The LDSO affected by the instruction
Demand Control ID	ID	The unique identifier for a demand control instruction
Instruction Sequence No	SQ	The sequence number relating to the demand control event
Demand Control Event Flag	EV	A value of ‘I’ indicates an instruction initiated by the NETSO or an Emergency Manual Disconnection. A Value of ‘L’ indicates an Automatic Low Frequency Demand Disconnection.
Time From	TF	The time from which the instruction takes effect
Time To	TI	The time to which the instruction takes effect
Demand Control Level	VO	The level of demand during the event in MW
SO-Flag	SO	A value of 'T' indicates that an instruction should be considered to be potentially impacted by transmission constraints.
Amendment Flag	AM	ORI (Original), INS (Insert), UPD (Update)

Message Subject Name

BMRA.SYSTEM.DCONTROL

4.12.5.69 RRBD – RR Bid Data

This message contains data on Replacement Reserve bids.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
RR Quarter Hour Period	QP	The quarter hour period
Party ID	PI
Associated TSO	AT
Market Balance Area	BA
Divisible	DI
Linked Bind ID⁸	LB
Multipart Bid ID⁸	MB
Exclusive Bid ID⁸	EB
RR Flow Direction	FD
Minimum Quantity	QI
Maximum Quantity	QX
Bid Resolution	BR
Position	PO
Price	PR
Status	RS

Message Subject Name

BMRA.RR.<BM_UNIT>.RRBD

4.12.5.70 RRBOAV – Indicative Period RR Accepted Bid and Offer Volumes

This message contains data derived by BMRA concerning bid and offer acceptance volumes associated with Replacement Reserve. One message is published per acceptance, per bid-offer pair number, per BM Unit. Due to the granularity of this message, many RRBOAV messages types can be published every settlement period.

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer Pair Number	NN	B-O pair number that the acceptance volumes apply to.
Acceptance Number	NK	Acceptance number that the volumes apply to.
Period RR Accepted Bid Volume	BI	Total Bid Volume accepted for a particular RR B-O pair.
Period RR Accepted Offer Volume	OF	Total Offer Volume accepted for a particular RR B-O pair.

Message Subject Name

BMRA.RR.<BM_UNIT>.RRBOAV.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.71 RRPTAV – Indicative Period Total Bid-Offer RR Acceptance Volumes

This message contains data derived by BMRA concerning period total bid and offer acceptance volumes associated with Replacement Reserve. One message is published per bid-offer pair number, per settlement period, per BM Unit.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Bid-Offer pair number	NN	B-O pair number that the acceptance volumes apply to.
Period RR Total Accepted Bid Volume	BI	Total Bid Volume accepted for a particular RR B-O pair.
Period RR Total Accepted Offer Volume	OF	Total Offer Volume accepted for a particular RR B-O pair.

Message Subject Name

BMRA.RR.<BM_UNIT>.RRPTAV.n

(where n represents the Bid-Offer Pair number, in the range -6 to 6 excluding 0).

4.12.5.72 QRRC – Indicative Quarter Hour RR Cashflows

This message contains data derived by BMRA concerning Quarter Hour cashflows associated with Replacement Reserve.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
RR Quarter Hour Period	QP	The Quarter Hour period
Indicative Quarter Hour RR Cashflow	CR	RR Cashflow for the Quarter Hour Period

Message Subject Name

BMRA.RR.<BM_UNIT>.QRRC

4.12.5.73 PRRC – Indicative Period RR Cashflows

This message contains data derived by BMRA concerning Settlement Period cashflows associated with Replacement Reserve.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
Indicative Period RR BM Unit Cashflow	CR	RR Cashflow for the settlement period

Message Subject Name

BMRA.RR.<BM_UNIT>.PRRC

4.12.5.74 AD – RR Activation Data

This message contains data regarding Replacement Reserve Activations.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
RR Quarter Hour Period	QP	The quarter hour period
Type	TY	Where TY=B74
RR Flow Direction	FD	Up or Down
Activated Quantity	QI	Quantity in MW
Activation Price	PR	Price in £/MWh
Marketobjectstatus	MOS	Available, Ordered or Cancelled

Message Subject Name

BMRA.RR._<BM_Unit>.AD

4.12.5.75 GBNM – RR GB Need Met

This message contains data regarding the overall GB need that has been met through Replacement Reserve activations.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
RR Quarter Hour Period	QP	The quarter hour period
Type	TY	Where TY=B75
RR Flow Direction	FD	Up or Down
Activated Quantity	QI	Quantity in MW
Activation Price	PR	Price in £/MWh

Message Subject Name

BMRA.RR.GBNM

4.12.5.76 IS – RR Interconnector Schedule

This message contains data regarding the Replacement Reserve activations that have been delivered by interconnectors.

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Interconnector Id	II	Identifier of the interconnector
Settlement Date	SD	The settlement date.
Settlement Period	SP	The settlement period.
RR Quarter Hour Period	QP	The quarter hour period
Type	TY	Where TY=A05 or B09
RR Flow Direction	FD	Up or Down
Activated Quantity	QI	Quantity in MW

Message Subject Name

BMRA.RR.IS

4.12.5.77 AGGINFO – RR Aggregated Information

Message Definition

The following table lists the fields that are required in the message.

Field	Field Type	Description of field
Auction Period Start	AS	Start of auction period
Auction Period End	AE	End of auction period
Total Volume of Offered Bids	OS	Total volume of offered RR bids
Total Volume of Activated Bids	BS	Total volume of activated RR bids
Total Volume of Unavailable Bids	US	Total volume of unavailable RR bids

Message Subject Name

BMRA.RR.AGGINFO

4.12.6 Format of Data within TIB Messages

4.12.6.1 The Use of Time Locales

All data published by BMRA that involves time stamps or DateTime data formats are published in GMT. Data is received from the NETSO in GMT and is published without conversion into local time.

Messages for all data that is based around settlement periods contain Settlement Dates and Settlement Period numbers, which are a number between 1 and 50 describing the number of the half hour period relative to midnight LOCAL time.

4.12.6.2 Conversion of Effective from/to data into Spot Time data

Some data received from the NETSO is received in the format of effective from and to times. The types of data which is received in this format are: - FPN, QPN, MIL, MEL, BOD and BOAL.

This data is not represented in this same fashion in the BMRA published messages. Instead it is described in the form of spot times and values. This is to eliminate data redundancy in the messages and reduce network traffic.

Since a ‘from time’ is the same as the previous ‘to time’, and in the vast majority of cases the ‘from level’ is also the same as the previous ‘to level’, it is inefficient to send both. BMRA therefore converts the data from the NETSO into a series of spot points and levels. This is a sequence of times, each of which has an associated level. The spot times are always on the boundaries of ‘from times’ or ‘to times’.

The diagram overleaf illustrates how this conversion is done. The shaded areas in the from/to level formats are the non-redundant data parts which are added to the list of spot times. Those that are not shaded are redundant and therefore left out of the list of spot times.

The spot time data may be converted back into from/to level data using the number of spot times and comparing spot times to see if a step in levels has occurred.

The following diagram shows how data in the form of From and To times is converted into Spot Times. To avoid redundancy in the published data, From Times and Levels which are identical to the previous To Times and Levels are removed. The shaded data is retained and passed on as spot times in the published message.

4.12.7 Writing an Application that Subscribes to TIB Messages

Third party applications may be written or adapted to interface to the near real-time TIB messages that are published by BMRA. The application registers interest in specific message(s) by subscribing to message subject names(s). Message(s) are then received by the application, which then has to processes the field data and store or display as required.

In order to receive and process TIB messages a licensed copy of TIB/Rendezvous version 6.2 must be installed on the host machine for the application to be adapted. TIB/Rendezvous software includes an application program interface (API) for making all the necessary requests for subscribing to a TIB message, receiving it and processing the composite field data. The API is available in C, C++, Java and Perl programming languages. (The API is also available in Active X/Visual Basic if TIB/Rendezvous version 5.3 is installed. TIBCO have confirmed that TIB/Rendezvous version 5.3 is compatible with published TIB/Rendezvous version 6.2 data.)

For each supported API, TIBCO provide example source code that may be used and adapted for development of a bespoke TIB/Rendezvous application adapter. For the C API for example, “tibrvlisten.c” is a working program that listens for all messages on a specified list of subjects. The code will need to be adapted to:

1. specify the correct service group in the creation of the rv transport;

2. listen to the desired subject names;

3. process the received message;

4. parse the message for field data;

5. interface the field data with the application, as required.

4.12.7.1 Specifying the service group

The UDP port (or service group) must be configured in creation of the rv transport. The UDP port defines the broadcast channel for which TIB/Rendezvous messages are sent and received on the participant LAN. The default port for TIB/Rendezvous (UDP port 7500) will be the port configured on the participant Rendezvous Routing Daemon to publish TIB messages originating from the BMRA.

4.12.7.2 Listening for message subject names

A “listener” is created to listen for message subject name(s). The listener must be given the subject name to listen to and the call back function to process the message when it arrives. Subject names that are published by the BMRA are listed in section 4.10.5.

Subject names are hierarchical and consist of multiple elements separated by dots. The listener can receive a group of related messages by specifying a wildcard (“>” or “*”) in the subject name. “BMRA.BM.BMUNIT01.>” can be used for example to listen to all message subject names that begin “BMRA.BM.BMUNIT01”, i.e. all balancing mechanism data for BMUNIT01.

Extreme care must be taken when specifying wildcards in message subject names. The use of the wildcard character in place of the BM unit id would mean that messages for all BM Units (there are estimated to be between 1,000 and 5,000 BM Units) would be received and have to be processed by the application.

4.12.7.3 Processing the received message

Each message that is received and identified by a listener will invoke the specified call back function. Code must be written for the call back function to process the message and parse the field data.

4.12.7.4 Parsing the message for field data

Each message consists of field data. The structure of each message, broken down into its composite fields, is listed in section 4.10.5. Each field has a defined type and is listed in section 4.10.4.

In order to parse the message for each field, the GetFieldInstance function (of the TibrvMsg class) can be used to specify the field type and return each instance of the field type. In this way, messages that consist of multiple fields of the same field type can be indexed to return data for each field instance. For example, National Demand Forecast messages (section 4.10.5.7) consist of multiple instances of Publishing Date (TP), Settlement Date (SD), Settlement Period (SP) and Demand (VD). Repeated calls of the GetFieldInstance function, specifying the field type and an incrementing number for the field instance, will return each specified instance of the field type.

4.12.7.5 Interfacing the field data with the application

Field data that is returned from the GetFieldInstance function must be cast to the appropriate C/Java type for use by the application. The application can then use the data as required.

(The data could be stored for later off-line analysis in a database/data warehouse. Alternatively the data could be written to the display to present a near real-time dynamically updateable view of subscribed data.)

Care must be taken with data fields of type “float” to ensure that the correct rounding is performed.

4.12.7.6 Further information

For further information on TIB/Rendezvous concepts and programming please refer to the following documentation supplied by TIBCO Software Inc and available from their web site at www.tibco.com.

TIB/Rendezvous Concepts, Software Release 6.2, March 2000;
TIB/Rendezvous Administration, Software Release 6.2, March 2000;
TIB/Rendezvous C Reference, Software Release 6.2, March 2000;
TIB/Rendezvous C++ Reference, Software Release 6.2, March 2000;
TIB/Rendezvous Java Reference, Software Release 6.2, March 2000;

4.13 NOT USED

To Level	number

5 CDCA External Inputs and Outputs

5.1 CDCA Flow Overview

5.2 CDCA-I001: (input) Aggregation rules

Interface ID:

CDCA-I001

Source:

BSC Party

Title:

Receive aggregation rules

BSC reference:

CDCA SD 4.1, 22.2, A

CDCA BPM 3.5, 4.17, CP753, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

On demand.

Volumes:

50 per month

Interface Requirement:

The CDCA receives, from the BSC Party, Aggregation Rules for each of the following:

BM Unit;
Grid Supply Point;
Inter-GSP-Group Connection;
GSP Group;
Interconnector.

The flow will include an indication whether the aggregation rules are provided as part of a transfer from SMRS, in which case there are initially only validated. Data entry only occurs once the transfer coordinator has confirmed the effective dates of the transfer.

Other information, as may be required, to support the Aggregation Rules. This may include, but shall not be limited to the following:-

network diagrams;

NGESO. connection agreement;

installation documentation;

The lowest level of measurement value referred to by Aggregation Rules is the Metering Subsystem Quantity. Each Quantity represents one of the four possible quantities that can be measured by physical meters for each single energy flow (e.g. Active Import, Active Export, Reactive Import, Reactive Export), as referenced by the Metering Subsystem. A Metering Subsystem is a virtual entity consisting of the complete set of registers within a single Metering System which measure a single unique energy flow. Metering Subsystem Quantity Id is a text string consisting of the Metering System Id followed by the Subsystem Id followed by the Measurement Quantity. Here Subsystem Id is an identifier unique within the Metering System and Measurement Quantity is ‘AE’,’AI’, ‘RE’ or ‘RI’. e.g. a valid Metering Subsystem Id Quantity Id within Metering System ‘1234’ would be ‘1234SUB1AE’.

Aggregation rules are constructed from unary or binary triplets.

Binary rules are specified as triplets (identifier A, identifier B, operator), where:

identifier A or B specifies the aggregated entity (either Metering Subsystem Quantity, BM Unit, GSP, Interconnector, Inter-GSP-Group Connection, or another suitable triplet)

operator is one of (=, +, -, *, /)

Rules for BM Units, GSPs, Interconnectors and Inter-GSP-Group Connections, can only be made up of Metering Subsystem Quantity aggregations.

Rules for GSP Groups can only be made up of Metering Subsystem Quantity, BM Unit, GSP, Interconnector, or Inter-GSP-Group Connection aggregations.

Valid binary rules include:

(GSP ID, Metering Subsystem Quantity Id, operator)

(BM Unit ID, Metering Subsystem Quantity Id, operator)

(Interconnector ID, Metering Subsystem Quantity Id, operator)

(Inter-GSP-Group Connection, Metering Subsystem Quantity Id, operator)

(GSP Group ID, Metering Subsystem Quantity Id, operator)

(GSP Group ID, GSP ID, operator)

(GSP Group ID, BM Unit ID, operator)

(GSP Group ID, Interconnector ID, operator)

(GSP Group ID, Inter-GSP-Group Connection, operator)

Unary rules are specified as triplets, allowing constant transforms to be applied to meter readings.

Unary rules are specified as triplets (identifier, operator, argument), where:

identifier specifies the aggregated entity (Metering Subsystem Quantity, BM Unit, GSP, Interconnector or Inter-GSP-Group Connection)

operator is one of (=, +, -, *, /)

argument is the numeric scaling to apply. This can either be an explicit numeric factor (e.g. for slugging), or may be a scaling category, e.g. “LLF”, which means that the Line Loss Factor applicable given the Settlement Date and Period of the meter reading must be applied during aggregation.

This interface covers addition, modification and deletion of Aggregation Rules. Aggregation rules will have effective dates which will be in clock time and may be retrospective.

Physical Interface Details:

5.3 CDCA-I003: (input) Meter technical data

Interface ID:

CDCA-I003

Source:

MOA, Registrant

Title:

Receive meter technical data

BSC reference:

CDCA SD 5

BPM 4.20, CP619, CP751, CP753, CP756, CP1201

Mechanism:

Manual, by email, letter or fax

Frequency:

On demand.

Volumes:

50 per month

Interface Requirement:

The CDCA receives records of Metering Equipment Technical Details (including passwords where appropriate) associated with each Metering System, associated data collector outstation and communications facility applicable to that Metering System, as received from the relevant MOA or Registrant. The details will have effective dates which may be retrospective.

This data consists of the following:

Metering System Details

Metering System Identifier

Effective from Settlement Date

Distribution Business Id

Energisation Status

Energisation Status Effective from date

Energisation Status Effective to date

Metering System Contact Name

Metering System Contact Telephone Number

Metering System Contact Fax Number

Metering System Address Line 1

Metering System Address Line 2

Metering System Address Line 3

Metering System Address Line 4

Metering System Address Line 5

Metering System Address Line 6

Metering System Address Line 7

Metering System Address Line 8

Metering System Address Line 9

Metering System Postcode

Metering System Latitude

Metering System Longitude

Meter Equipment/Service Location

Dispensation Reference;

Dispensation Effective From Date;

Dispensation Effective To Date;

Reason for Dispensation.

Transfer flag (indicates this is a transfer from SMRS)

Outstation Details

Outstation Id

Outstation Type

Outstation Serial Number

Outstation Number of Channels

Outstation Number of Dials

Outstation PIN

Outstation Password A

Outstation Password B

Outstation Password C

Communications Address

Baud Rate

Previous Metering System Identifier

Previous Outstation Id

Outstation Channel

Outstation Id

Outstation Channel Number

Meter Serial Number

Meter Register Id

Outstation Channel Precedence (Primary, Secondary, Tertiary etc.)

Pulse Multiplier

Outstation Channel Multiplier

Minimum MWh Value

Maximum MWh Value

Physical Meter Details

Meter Serial Number

Manufacturers Make & Type

Meter Current Rating

Meter Code of Practice

VT Ratio

CT Ratio

System Voltage

Number of Phases

Meter Register Details

Meter Register Id

Meter Register Multiplier

Measurement Quantity Id

Metering Subsystem Id (for Main channels only)

Number of Register Digits

Associated Meter Id (for Check channels pointing to a Main)

Associated Meter Register Id (for Check channels pointing to a Main)

Metering Subsystem Id is an identifier associated with Main channels, for the purpose of referencing filtered measurement quantities within aggregation rules supplied by a BSC Party via CDCA-I001.

Other data required by CDCA may include schematics and network diagrams from MOAs or Registrants in order to support validation of meter technical data.

Physical Interface Details:

5.4 CDCA-I004: (output) Notify New Meter Protocol

Interface ID:

CDCA-I004

User:

MOA

Title:

Notify New Meter Protocol

BSC reference:

CDCA SD 6.1-4

Mechanism:

Manual

Frequency:

As required

Volumes:

One or two per year

Interface Requirement:

The CDCA will inform all MOAs registered with the CRA of any newly approved protocol within seven days of approval;

The data will include

protocol name

effective from date

Physical Interface Details:

5.5 CDCA-I005: (input) Load New Meter Protocol

Interface ID:

CDCA-I005

Source:

MOA or Protocol Provider

Title:

Load New Meter Protocol

BSC reference:

CDCA SD 6.1-4, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

Volumes:

One or two per year

Interface Requirement:

The CDCA receives notifications of newly approved protocols from an MOA or other Protocol Provider, so that the protocol can be loaded onto its data collection systems, such that data can be collected from the meter.

Details of the interface depend on the data capture device used. This is likely to be MV-90.

The CDCA shall be responsible for procuring whatever translation interface modules or other device drivers necessary to allow the data capture device to remotely interrogate the metering equipment.

Physical Interface Details:

A flow description is not provided for this interface, as different protocols will be provided.

5.6 CDCA-I006: (output) Meter Data for Proving Test

Interface ID:

CDCA-I006

User:

MOA

Title:

Meter Data for Proving Test

BSC reference:

CDCA SD 7.2

Mechanism:

Manual

Frequency:

As required

Volumes:

Low

Interface Requirement:

In the process of proving tests for meter data collection, the CDCA transfers the test data received to the relevant MOA responsible for that Metering System for validation of accuracy.

The data content will be a subset of CDCA-I008

Physical Interface Details:

5.7 CDCA-I007: (output) Proving Test Report/Exceptions

Interface ID:

CDCA-I007

User:

MOA, BSC Party

Title:

Proving Test Report/Exceptions

BSC reference:

CDCA SD 7.6

Mechanism:

Manual

Frequency:

As required

Volumes:

Low

Interface Requirement:

In the process of proving tests for meter data collection, the CDCA reports any proving, validation and communications errors associated with any Metering System to the relevant MOA. and a duplicate report to the registrant BSC Party.

Physical Interface Details:

5.8 CDCA-I008: (input) Obtain metered data from metering systems

Interface ID:

CDCA-I008

Source:

Physical meters

Title:

Obtain metered data from metering systems

BSC reference:

CDCA SD 8.1- 8.4, 8.7

Mechanism:

Meter System interface

Frequency:

Daily

Volumes:

1100 - 5000 per day

Interface Requirement:

The CDCA collects meter period data remotely over a communications link, via a data capture device (MV-90).

For each registered meter the CDCA shall collect and record meter period data as follows:

a). Export Active Energy;

b). Import Active Energy;

c). Export Reactive Energy; and

d). Import Reactive Energy;

The CDCA shall collect meter period data relating all Main and Check meters, and/or the corresponding data collector outstation registers, where installed and operational, and which are used for settlement purposes.

The CDCA shall record and store all meter period data collected from Metering Systems. The data items recorded and stored shall include, but not be limited to the following:-

Date and Time of Reading

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Measurement Quantity (Active Import , Active Export, Reactive Import, or Reactive Export)

Main/Check Indicator

Settlement Period (46, 48 or 50 occurrences)

Meter Reading Volume

Meter Reading Status

Meter Reading Status can be one of:

A - Valid meter data

B - Invalid meter data

C - Unavailable meter data

Note that there may be more than one Check channel for the same Main, for a given Measurement Quantity.

This flow includes data collection from all metering systems registered with the CRA, including

those associated with both External Interconnectors (points of connection between transmission

networks) and Internal Interconnectors (points of connection between distribution networks).

Physical Interface Details:

No physical structure is defined as protocols vary

5.9 CDCA-I009: (input) Meter Period Data Collected via Site Visit

Interface ID:

CDCA-I009

Source:

Hand Held Device/Data Capture Device (MV-90)

Title:

Meter Period Data Collected via Site Visit

BSC reference:

CDCA SD 8.5, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

On demand.

Volumes:

Low

Interface Requirement:

The CDCA shall make provisions to collect the meter period data manually, by visit to site, where collection of meter period data via a communication link is not possible.

Meter data will be collected manually using a Hand Held Device/Data Capture Device (MV-90), and the information collected will then be loaded automatically into CDCA.

The CDCA shall manually collect meter period data relating to all Main and Check meters, and/or the corresponding data collector outstation registers, where installed and operational, and which are used for settlement purposes.

The data items recorded and stored shall include, but not be limited to the following:-

Metering System Identifier

Settlement Date

Outstation Id

Date and time of Reading

Channel Number

Measurement Quantity (Active Import , Active Export, Reactive Import, or Reactive Export)

Settlement Period (46, 48 or 50 occurrences)

Meter Reading Volume

Meter Reading Status

Meter Reading Status can be one of:

A - Valid meter data

B - Invalid meter data

C - Unavailable meter data

Note that there may be more than one Check channel for the same Main, for a given Measurement Quantity.

Physical Interface Details:

No physical structure is defined as protocols vary

5.10 CDCA-I010: (output) Exception report for missing and invalid meter period data

Interface ID:

CDCA-I010

User:

BSC Party, MOA

Title:

Exception report for missing and invalid meter period data

BSC reference:

CDCA SD 8.6, 19.2

BPM 4.12, CP527

Mechanism:

Electronic data file transfer

Frequency:

Daily.

Volumes:

estimate 50 per day (1% of 5000)

Interface Requirement:

When meter reading data is either not available for collection or the data is deemed to be invalid, the CDCA sends exception reports to:

The Responsible Party for the Metering System

The MOA operating the Metering System

For each exception the report will include:

BSC Party Identifier

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Measurement Quantity (Active Import , Active Export, Reactive Import, or Reactive Export)

Main/Check Indicator

Settlement Period (46, 48 or 50 occurrences)

Meter Reading Volume

Meter Reading Status

Exception Description related to validation rule

Meter Reading Status can be one of:

A - Valid meter data

B - Invalid meter data

C - Unavailable meter data

Physical Interface Details:

5.11 CDCA-I011: (input) Dial Readings from meter, for MAR

Interface ID:

CDCA-I011

Source:

Hand Held Device/Data Capture Device (MV-90)

Title:

Dial Readings from meter, for MAR

BSC reference:

CDCA SD 12.2

CDCA BPM 4.1, CP756 CP1153

Mechanism:

Manual, by email, letter or fax

Frequency:

As Required

Volumes:

1100 - 5000 metering systems

Interface Requirement:

The CDCA shall receive meter readings for MAR

Meter data will be collected manually using a Hand Held Device/Data Capture Device (MV-90), and the information collected will then be loaded automatically into CDCA. The information collected will include:

Metering System Identifier

Settlement Date

Outstation Id

Date and time of Reading

Channel Number

Meter Serial Number

Measurement Quantity (Active Import or Active Export only)

Dial Reading

Physical Interface Details:

No physical structure is defined as protocols vary

5.12 CDCA-I012: (output) Report Raw meter Data

Interface ID:

CDCA-I012

User:

BSC Party, Distribution Business, NETSO

Title:

Report Raw meter Data

BSC reference:

CDCA SD 19.1

CDCA BPM 4.21, CP841

Mechanism:

Electronic data file transfer

Frequency:

Daily

Volumes:

up to 240000 period readings to each agent

(5000 * 48)

Interface Requirement:

The CDCA provides the relevant BSC Party(s), including the Distribution Business, and the NETSO, with a Metering System data collection report relating to the raw meter period data collected from each meter or associated outstation.

The readings will not include any estimated data. All readings reported will not be line loss adjusted. The report will report data in clock time.

The data included, for each BSC Party will consist of those Metering Systems for which the BSC Party is the Responsible Party, and will consist of:

BSC Party Identifier

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Measurement Quantity (Active Import , Active Export, Reactive Import, or Reactive Export)

Main/Check Indicator

Settlement Period (46, 48 or 50 occurrences)

Meter Reading Volume

Meter Reading Status

Meter Reading Status can be one of:

A - Valid meter data

B - Invalid meter data

C - Unavailable meter data

D – Substituted from secondary outstation meter data

Note that there may be more than one Check channel for the same Main, for a given Measurement Quantity.

This report is also sent to the System Operators, covering all metering systems.

Physical Interface Details:

5.13 CDCA-I013: (input) Response to Estimated data

Interface ID:

CDCA-I013

Source:

BSC Party

Title:

Response to Estimated data

BSC reference:

CDCA SD 10.8

CDCA BPM 4.22?

CP566, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

Daily

Volumes:

estimate 50 per day (1% of 5000)

Interface Requirement:

BSC Parties will respond to CDCA-I037 ‘Estimated Data Notification’ messages, indicating their agreement to an estimate made when meter readings are unavailable.

The flow contains at minimum:

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Measurement Quantity (Active Import , Active Export)

Settlement Period (46, 48 or 50 occurrences)

Agreement Flag (A/P)

Estimated Meter Reading Volume (Agreed estimate or Proposed value for estimate)

Basis for proposed value

Physical Interface Details:

5.14 CDCA-I014: (output) Estimated Data Report

Interface ID:

CDCA-I014

User:

BSC Party, MOA, BSCCo Ltd, NETSO

Title:

Estimated Data Report

BSC reference:

CDCA SD 10.7, 10.9, CP751, CP841, CP1245

Mechanism:

Electronic data file transfer

Frequency:

As required

Volumes:

estimate 50 per day (1% of 5000)

Interface Requirement:

The estimated data report contains all estimate notifications issued by CDCA in a given period.

An estimated data report is sent to:

1. BSCCo Ltd (on request) - data for all metering systems

2. MOA (Daily) - data for metering systems operated by the MOA

3. BSC Party (Daily) - data for metering systems for which the party is the responsible party.

4. the host Distribution business or the NETSO, depending who has registered the metering system (Daily).

This report will be run at the end of the working day to report estimates carried out on that day.

The information provided is as follows for each Metering System included in the report:

Total Volume Estimated in Report

BSC Party Identifier

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Meter Serial Number

Measurement Quantity (Active Import , Active Export)

Settlement Period (46, 48 or 50 occurrences)

Original Meter Reading Volume (if available)

Estimated Meter Reading Volume

Estimation Method

Estimate Agreed Indicator (T/F)

Estimation method is an indicator of the method used for estimation:

A - Generation: Main meter data missing or incorrect in Primary and Secondary Outstations, Check meter data available – copied from Primary Check

D - Demand: Main meter data missing or incorrect, Check meter data available – copied from Primary Check

E - Demand: Main meter data missing or incorrect, Check meter not fully functional, but Main meter or Check meter register advance available – profiled using Meter Reading Estimation Tool

I - Demand: Main meter data missing or incorrect, Check meter not fully functional, Main meter and Check meter register advance NOT available – profiled using Trend

J - Generation: Main meter data missing, or incorrect, in Primary Outstation, Secondary Outstation main meter data available – substituted from Secondary Main

K - Generation: Main and Check meter data missing or incorrect in Primary and Secondary Outstations, data estimated to zero awaiting confirmation of generation

L - Demand; Primary Main meter data missing, or incorrect, Secondary Outstation Main meter data available – substituted from Secondary Main

M - Demand: Main meter data missing or incorrect, data copied from suitable settlement period(s)

N - Validation Failure: Main meter data deemed correct

U - Used parties own reading

X - Used different estimation method

Physical Interface Details:

5.15 CDCA-I015: (input) Reporting metering system faults

Interface ID:

CDCA-I015

Source:

MOA

Title:

Reporting metering system faults.

BSC reference:

CDCA SD 11.1-11.4

BPM , CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

As required

Volumes:

estimate 10 per day (0.2% of 5000)

Interface Requirement:

The CDCA receives reports from the MOA in respect of Metering Equipment faults.

This includes free format text which could be communicated by a letter, email, fax or phone call.

Physical Interface Details:

5.16 CDCA-I017: (output) Meter Reading Schedule for MAR

Interface ID:

CDCA-I017

User:

BSC Party, MOA

Title:

Meter Reading Schedule for MAR

BSC reference:

CDCA SD 12.1

BPM

Mechanism:

Manual

Frequency:

Annual

Volumes:

One schedule for all metering systems

Interface Requirement:

The CDCA issues a Meter Reading Schedule for MAR for each metering system on an annual basis, at least three months ahead and forward it to the relevant BSC Parties trading at the metering system, and the MOA responsible for the maintenance of the metering system.

The Schedule will contain, for each Metering System:

BSC Party

Metering System Id

Metering System Location Details

Planned date of Site Visit

Physical Interface Details:

No physical structure is defined for this flow

5.17 CDCA-I018: (output) MAR Reconciliation Report

Interface ID:

CDCA-I018

User:

BSC Party, MOA, BSCCo Ltd,

Distribution Business

Title:

MAR Reconciliation Report

BSC reference:

CDCA SD 12.6, 19.2

CDCA BPM 4.2

CN116 CP1153

Mechanism:

Manual

Frequency:

As Required

Volumes:

100 per working day based upon 5000 metering systems

Interface Requirement:

The results of each Meter Advance Reconciliation is provided to the relevant BSC Party(s) with a reconciliation report detailing the actual difference calculated for each active energy meter or associated outstation register.

The MAR report is sent to the relevant BSC Party, the relevant MOA, and, if appropriate, any other parties such as the Distribution Business. It may also be sent to BSCCo Ltd for dispute resolution. The information, for each metering system, includes:

Metering System Identifier

Advance Period Start Date

Advance Period End Date

Original Energy volume reading for all relevant channels (MWh) (e.g. main, check, active, reactive etc.)

MAR Energy volume reading for all relevant channels

Percentage Variation

BSCP Requirement

Compliance Indicator (T/F)

Import/Export Indicator (I/E)

The Import/Export indicator indicates the direction of the energy flow: the Meter Volume is therefore unsigned.

Physical Interface Details:

5.18 CDCA-I019: (output) MAR Remedial Action Report

Interface ID:

CDCA-I019

User:

BSC Party, MOA, BSCCo Ltd,

Distribution Business

Title:

MAR Remedial Action Report

BSC reference:

CDCA SD 12.9

BPM 4.2

Mechanism:

Manual

Frequency:

Ad hoc

Volumes:

2 per day based upon 2% of the 100 MARs undertaken each day.

Interface Requirement:

When the CDCA initiates remedial action to resolve a Meter Advance Reconciliation discrepancy, it notifies the interested parties of the remedial action(s) taken. The interested parties are the relevant BSC Party, the relevant MOA, and, if appropriate, any other parties such as the Distribution Business. It may also be sent to BSCCo Ltd for dispute resolution.

Physical Interface Details:

5.19 CDCA-I021: (input) Notification of Metering Equipment Work

Interface ID:

CDCA-I021

Source:

MOA

Title:

Notification of Metering Equipment Work

BSC reference:

CDCA SD 13.5, CP756, CP1152

Mechanism:

Manual, by telephone

Frequency:

Ad hoc.

Volumes:

50 per month

Interface Requirement:

The CDCA receives notifications of work on Metering Equipment from the relevant MOA by telephone.

Physical Interface Details:

5.20 CDCA-I022: (input) Distribution Line Loss Factors

This interface is from BSCCo Ltd to CDCA and therefore is defined in Part 2 of the IDD, which covers interfaces that do not affect BSC Parties or their agents. However a copy of the definition is included here for information. The BSC Parties have sent the Distribution Line Loss Factors to the BSCCo Ltd for validation, then the BSCCo Ltd sends them on to CDCA via this interface. This interface is not included in the summary tables in section 3, and the physical definition is not included in the spreadsheet.

Interface ID:

CDCA-I022

Source:

BSCCo Ltd

Title:

Distribution Line Loss Factors

BSC reference:

CDCA SD 15.1

CDCA BPM 4.5 (?)

Mechanism:

Electronic data file transfer

Frequency:

Annually

Volumes:

17568000 factors

(1000 metering systems * 366 * 48)

Interface Requirement:

The CDCA receives Line Loss Factors relating to a Metering System from BSCCo Ltd.

Metering System Identifier

Settlement Date

Settlement Period

Line loss Factor

Physical Interface Details:

5.21 CDCA-I023: (output) Missing Line Loss Factors

Interface ID:

CDCA-I023

User:

BSCCo Ltd

Title:

Missing Line Loss Factors

BSC reference:

CDCA SD 15.2, CP527

Mechanism:

Manual

Frequency:

Annually

Volumes:

17520000 factors

(1000 metering systems * 365 * 48)

Interface Requirement:

The CDCA shall validate such Line Loss Factors received from the BSCCo Ltd. Any missing or invalid factor values will be reported back to the BSCCo Ltd.

Attributes are likely to include:

File Reference for Line Loss Factors

Date LLF File Received

File Acceptance Status (all accepted, partially accepted, file rejected)

Date of Acceptance Status

File Rejection Reason (if File Acceptance Status = file rejected)

Details of any individual exceptions:

Metering System Identifier (for site specific Line Losses)

Settlement Date

Time Period

Line Loss Factor

Reason for rejection

Physical Interface Details:

5.22 CDCA-I025: (output) Aggregation Rules Exceptions

Interface ID:

CDCA-I025

User:

BSC Party

Title:

Aggregation Rules Exceptions

BSC reference:

CDCA SD 19.2, 22.3

BPM 4.12

Mechanism:

Manual

Frequency:

On demand.

Volumes:

Low

Interface Requirement:

The CDCA validates all Aggregation Rules received from the relevant BSC Party, and identifies metering systems registered with the CRA for which no aggregation rules exist.

Missing or invalid aggregation rules will be reported to the relevant BSC Party.

Physical Interface Details:

5.23 CDCA-I026: (output) Aggregated Meter Volume Exceptions

Interface ID:

CDCA-I026

User:

BSC Party

Title:

Aggregated Meter Volume Exceptions

BSC reference:

CDCA SD 19.2

BPM 4.12

Mechanism:

Manual

Frequency:

Ad hoc

Volumes:

Low

Interface Requirement:

When an exception occurs exceptions during aggregation process, the CDCA sends an exception report to the relevant BSC Party.

For each exception the report will include:

Settlement Date

Settlement Period

Exception Type

Item being Aggregated

Component contributing to Aggregation

Factor value contributing to Aggregation

Exception Description

Physical Interface Details:

5.24 CDCA-I029: (output) Aggregated GSP Group Take Volumes

Interface ID:

CDCA-I029

User:

BSC Party, including the Distribution Business;

NETSO.

Title:

Aggregated GSP Group Take Volumes

BSC reference:

CDCA SD 22, 23.1, A, B

CDCA BPM 4.4

BPM IRR CDCA2, CP559

Mechanism:

Electronic data file transfer

Frequency:

Daily per aggregation run

Volumes:

Interface Requirement:

Reports on aggregated meter flow volumes for the GSP Groups are sent to BSC Parties, as follows for each GSP Group:

GSP Group Id

Settlement Date

Settlement Run Type

CDCA Run Number

Date of aggregation

Settlement Period

Estimate Indicator

Import/Export Indicator

Meter Volume

These reports are distributed to the following BSC Parties:

To the distribution business associated with the GSP group

To all BSC Parties which are lead parties for the BM Units within the GSP group and to the NETSO.

Physical Interface Details:

5.25 CDCA-I030: (output) Meter Period Data for Distribution Area

Interface ID:

CDCA-I030

User:

Distribution Business

Title:

Meter Period Data for Distribution Area

BSC reference:

CDCA SD 19.4

BPM IRR CDCA8

CR_991027_06b, CP559

Mechanism:

Electronic data file transfer

Frequency:

Daily

Volumes:

Several hundred Metering Systems

Interface Requirement:

CDCA will forward meter period data for all Grid Supply Points Metering Systems, Interconnectors and Inter-GSP-Group Connections, to the relevant host distribution business(es), where required.

A report will be sent to the Distribution Business associated with each GSP Group which shall include the following data:

GSP Group Id

Settlement Date

Settlement Run Type

CDCA Run Number

Date of aggregation

GSP Id

Settlement Period

Estimate Indicator (T/F)

Meter Volume

Import/Export indicator (I/E)

Interconnector Id

Settlement Period

Estimate Indicator (T/F)

Meter Volume

Import/Export indicator (I/E)

Inter-GSP-Group Connection Id

Settlement Period

Estimate Indicator (T/F)

Meter Volume

Import/Export indicator (I/E)

The file can be provided on request to a BSC Party which is active within the relevant GSP Group.

The Import/Export indicator indicates the direction of the energy flow: the Meter Volume is therefore unsigned.

Physical Interface Details:

5.26 CDCA-I033: File Receipt Acknowledgement

See Section 2.2.7.

5.27 CDCA-I037: (output) Estimated Data Notification

Interface ID:

CDCA-I037

User:

BSC Party, MOA

Title:

Estimated Data Notification

BSC reference:

CDCA SD 10.8

CDCA BPM 4.22? , CP751, CP841

Mechanism:

Manual

Frequency:

Daily

Volumes:

estimate 50 per day (1% of 5000)

Interface Requirement:

This flow notifies the MOA and BSC Party of an estimate made when a meter readings is unavailable or invalid.

The information provided is as follows:

BSC Party Identifier

Metering System Identifier

Settlement Date

Outstation Id

Channel Number

Meter Serial Number

Measurement Quantity (Active Import , Active Export)

Settlement Period (46, 48 or 50 occurrences)

Original Meter Reading Volume (if available)

Estimated Meter Reading Volume

Estimation Method

Estimation method is an indicator of the method used for estimation:

A - Generation: Main meter data missing or incorrect in Primary and Secondary Outstations, Check meter data available – copied from Primary Check

D - Demand: Main meter data missing or incorrect, Check meter data available – copied from Primary Check

E - Demand: Main meter data missing or incorrect, Check meter not fully functional, but Main meter or Check meter register advance available – profiled using Meter Reading Estimation Tool

I - Demand: Main meter data missing or incorrect, Check meter not fully functional, Main meter and Check meter register advance NOT available – profiled using Trend

K - Generation: Main and Check meter data missing or incorrect in Primary and Secondary Outstations, data estimated to zero awaiting confirmation of generation

M - Demand: Main meter data missing or incorrect, data copied from suitable settlement period(s)

N - Validation Failure: Main meter data deemed correct

U - Used parties own reading

X - Used different estimation method

If Estimation method = X, the method used will be described.

Method codes J and L (see CDCA-I014) refer specifically to substitution, rather than estimation, and are therefore not reported via this flow.

Physical Interface Details:

5.28 CDCA-I038: (output) Reporting metering system faults

Interface ID:

CDCA-I038

User:

MOA, BSC Party

Title:

Reporting metering system faults.

BSC reference:

CDCA SD 11.1-11.4

BPM

Mechanism:

Manual

Frequency:

As required

Volumes:

estimate 10 per day (0.2% of 5000)

Interface Requirement:

The CDCA reports to the MOA and the BSC party who is responsible for the meter (the Registrant) all suspected metering faults detected while performing its responsibilities. This will include details of the fault. Note that the faults reported may relate to exception reports for missing or invalid meter period data (CDCA-I010).

Physical Interface Details:

5.29 CDCA-I041: (output) Interconnector Aggregation Report

Interface ID:

CDCA-I041

User:

Title:

Interconnector Aggregation Report

BSC reference:

CDCA SD 19.3, B

CDCA BPM 4.4

BPM IRR CDCA5, CP559

Mechanism:

Electronic data file transfer

Frequency:

Daily, per aggregation run

Volumes:

Initially 96 (2 interconnectors * 48 readings). The number of interconnectors is expected to increase to 5 or 6.

Interface Requirement:

A report on aggregated meter flow volumes for each Interconnector is sent to the BSC party who is the Interconnector Administrator associated with the Interconnector.

The following information is sent:

Interconnector Id

Settlement Date

Settlement Run Type

CDCA Run Number

Date of aggregation

Settlement Period

Estimate Indicator (T/F)

Meter Volume

Import/Export indicator (I/E)

The Import/Export indicator indicates the direction of the energy flow: the Meter Volume is therefore unsigned.

Physical Interface Details:

5.30 CDCA-I042: (output) BM Unit Aggregation Report

Interface ID:

CDCA-I042

User:

BSC Party

NETSO

Title:

BM Unit Aggregation Report

BSC reference:

CDCA SD 22, 23.1, A, B

CDCA BPM 4.4

BPM IRR CDCA3, CP559

Mechanism:

Electronic data file transfer

Frequency:

Daily, per aggregation run

Volumes:

Interface Requirement:

A report on aggregated meter flow volumes for each BM Unit is sent to the BSC party who is the lead party for the BM Unit, and copied to the NETSO.

The following information is sent:

BM Unit Id

Settlement Date

Settlement Run Type

CDCA Run Number

Date of aggregation

Settlement Period

Estimate Indicator (T/F)

Meter Volume

Import/Export Indicator (I/E)

The Import/Export indicator indicates the direction of the energy flow: the Meter Volume is therefore unsigned.

Physical Interface Details:

5.31 CDCA-I044: (input) Meter System Proving Validation

Interface ID:

CDCA-I044

Source:

MOA

Title:

Meter System Proving Validation

BSC reference:

CDCA SD 7.3, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

Volumes:

Interface Requirement:

The MOA will confirm that the data from meter system proving is valid.

Physical Interface Details:

5.32 CDCA-I045: (input) Meter Data from routine work and Metering Faults

Interface ID:

CDCA-I045

Source:

MOA/Data Capture Device (MV-90)

Title:

Meter Data from routine work and Metering Faults

BSC reference:

CDCA SD 13.1- 13.7, CP756, P190

Mechanism:

Manual, by email, letter or fax

Frequency:

Volumes:

Interface Requirement:

Meter data will be collected manually during planned work by the MOA on site and by CDCA using a Data Capture Device (MV-90), and the information collected will then be loaded automatically into CDCA.

This data shall include:

Metering System Identifier

Settlement Date

Outstation Id

Date and Time of Reading

Channel Number

Meter Serial Number

Measurement Quantity (Active Import , Active Export, Reactive Import, or Reactive Export)

Settlement Period (46, 48 or 50 occurrences)

Meter Reading Volume

Meter Reading Status

Meter Reading Status can be one of:

A - Valid meter data

B - Invalid meter data

C - Unavailable meter data

Physical Interface Details:

5.33 CDCA-I046: (output) Site Visit Inspection Report

Interface ID:

CDCA-I046

User:

MOA, BSC Party

Title:

Site Visit Inspection Report

BSC reference:

CDCA SD 13.1- 13.7, P190

Mechanism:

Manual

Frequency:

Ad hoc

Volumes:

50 per month

Interface Requirement:

On completion of a site inspection, the CDCA shall provide the relevant MOA with a written report detailing the outcome of the site inspection including, but not limited to meter readings. A duplicate of this report shall be sent to the relevant BSC Party registrant.

Physical Interface Details:

5.34 CDCA-I047: (output) Correspondence Receipt Acknowledgement

Interface ID:

CDCA-I047

User:

BSC Party, BSCCo Ltd

Title:

Correspondence Receipt Acknowledgement

BSC reference:

CDCA SD 20.3

Mechanism:

Manual

Frequency:

As required

Volumes:

One per incoming item of manual data

Interface Requirement:

CDCA will acknowledge receipt of manual data received from any BSC Party (including BSCCo Ltd). The following information will be sent to the BSC Party:

Correspondence reference

Date/Time of receipt

Physical Interface Details:

5.35 CDCA-I048: (output) Report of Aggregation Rules

Interface ID:

CDCA-I048

User:

BSC Party

Title:

Report of Aggregation Rules

BSC reference:

CDCA SD 4.6

BPM 3.2

Mechanism:

Manual

Frequency:

On demand

Volumes:

All rules for relevant BSC Party

Interface Requirement:

The CDCA shall produce a physical copy of the aggregation rules to the BSC Party to ensure the correct recording of the aggregation rules. This shall be provided on demand and as confirmation of the process of loading the rules into the system.

The information sent to the BSC Party will be similar to that included in CDCA-I001 and will include a report of the Aggregation Rule(s) for each of the following types of registrations for the BSC Party:

BM Unit;
Grid Supply Point;
Inter-GSP-Group Connections;
GSP Group;
Interconnector.

Physical Interface Details:

5.36 CDCA-I051: (output) Report Meter Technical Details

Interface ID:

CDCA-I051

User:

BSC Party, MOA, Distribution Business, NETSO

Title:

Report Meter Technical Details

BSC reference:

CR 78a, CP751, CP1201

Man/auto:

Manual

Frequency:

On Demand

Volumes:

50 per month

Interface Requirement:

The CDCA shall report the Meter Technical Details (which are received from Meter Operator Agents or Registrants in flow CDCA-I003) to the MOA, Registrant, Distributor (where appropriate) and NETSO, as confirmation of the process of loading the details into the system. This report shall also be provided on demand.

The information sent will be similar to that included in CDCA-I003, and will include the following:

Metering System Details

Metering System Identifier

Effective from Settlement Date

Distribution Business Id

Energisation Status

Metering System Contact Name

Metering System Contact Telephone Number

Metering System Contact Fax Number

Metering System Address Line 1

Metering System Address Line 2

Metering System Address Line 3

Metering System Address Line 4

Metering System Address Line 5

Metering System Address Line 6

Metering System Address Line 7

Metering System Address Line 8

Metering System Address Line 9

Metering System Postcode

Metering System Latitude

Metering System Longitude

Meter Equipment/Service Location

Dispensation Reference

Dispensation Effective From Date

Dispensation Effective To Date

Reason for Dispensation

Outstation Details

Outstation Id

Outstation Type

Outstation Serial Number

Outstation Number of Channels

Outstation Number of Dials

Outstation PIN

Outstation Password A

Outstation Password B

Outstation Password C

Communications Address

Baud Rate

Previous Metering System Identifier

Previous Outstation Id

Outstation Channel

Outstation Id

Outstation Channel Number

Meter Serial Number

Meter Register Id

Outstation Channel Precedence (Primary, Secondary, tertiary etc.)

Pulse Multiplier

Outstation Channel Multiplier

Min MWh Value

Max MWh Value

Physical Meter Details

Meter Serial Number

Manufacturers Make & Type

Meter Current Rating

Meter Code of Practice

VT Ratio

CT Ratio

System Voltage

Number of Phases

Meter Register Details

Meter Serial Number

Meter Register Id (1, 2, 3, or 4)

Meter Register Multiplier

Measurement Quantity Id (AE, AI, RE, RI)

Metering Subsystem Id (for Main channels only)

Number of Register Digits

Associated Meter Id (for Check channels pointing to a Main)

Associated Meter Register Id (for Check channels pointing to a Main)

Metering Subsystem Id is an identifier associated with Main channels, for the purpose of referencing filtered measurement quantities within aggregation rules supplied by a BSC Party via CDCA-I001.

Physical Interface Details:

5.37 CDCA-I054:(output) Meter Status Report

Interface ID:

CDCA-I054

User:

BSC Party

MOA

Distribution Business

Title:

Meter Status Report.

BSC reference:

CP511

Mechanism:

Electronic Data Transfer

Frequency:

Daily, reporting on the previous Settlement Day

Volumes:

Approximately 100 per day (2% of 5000)

Interface Requirement:

This data flow will be sent whenever a potential fault is identified with the metering equipment. The CDCA will send meter status reports to:

The Responsible Party for the Metering System

The MOA operating the Metering System

The Distribution Business associated with the Metering System (if any)

For each metering system where a fault is identified the report will include:

Settlement Date

BSC Party

BSC Party Identifier

Metering System

Metering System Identifier

Meter Equipment Location

Missing Data (note 1)

Outstation ID

Number of days since data was last downloaded successfully from the outstation.

Alarms

Outstation ID

Channel (optional, omit if alarm applies to all channels)

Alarm Code

First Settlement Period of Alarm

Last Settlement Period of Alarm

Main/Check discrepancies over Settlement Day (note 2)

Outstation ID for Main Meter

Meter Serial Number for Main Meter

Meter Register ID for Main Meter

Channel Number for Main Meter

Outstation ID for Check Meter

Meter Serial Number for Check Meter

Meter Register ID for Check Meter

Channel Number for Check Meter

Metering Subsystem ID

Measurement Quantity

Difference (MWh)

Difference (% of main)

Primary/Secondary discrepancies (note 3)

Primary Outstation ID

Primary Channel Number

Secondary Outstation ID

Secondary Channel Number

Meter Serial Number

Meter Register ID

Metering Subsystem ID

Measurement Quantity

Period Data

Settlement Period

Discrepancy Value

Discrepancy, expressed as a percentage of primary

Data outside limits (note 4)

Outstation ID

Meter Serial Number

Meter Register ID

Channel Number

Metering Subsystem ID

Measurement Quantity

Minimum Threshold

Maximum Threshold

Period Data

Settlement Period

Value Recorded

Notes:

1. Count of contiguous Settlement Days up to and including the Day being reported on for which no data has been downloaded from any channel for any Settlement Period

2 Main/Check checks using data aggregated over the whole Settlement Day apply the same validation checks that are applied to individual Settlement Periods as defined in CDCA-F007. Note that data will be summed for all periods for which data is available (i.e. missing period data will default to 0)

3. Primary/Secondary checks are those applied in CDCA-F007

4. Data Limits checks are those applied in CDCA-F007

Physical Interface Details:

If there is nothing to report, a null report will not be issued

5.38 CDCA-I055: (input) Transfer from SMRS information

Interface ID:

CDCA-I055

User:

Transfer Coordinator, BSC Party

Title:

Transfer from SMRS information

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Demand

Volumes:

low

Interface Requirement:

Where metering is transferred from SMRS into CDCA, the following information will be provided.

Status (New, rejected, confirmed, confirmation request)

Effective from date (if confirmed)

Name of Registrant

Address

Contact for Transfer

Telephone number

Email address

Participant ID

Site name

Site address

Transfer details

Circuit description

Measurement quantity

Metering System ID

Metering Subsystem ID

Metering system details

NGC BMU identifiers

BMU ID

GSP reference

CVA MOA

Physical Interface Details:

The flow will include a schematic diagram where appropriate

5.39 CDCA-I057: (input) Transfer to SMRS information

Interface ID:

CDCA-I057

User:

Transfer Coordinator, BSC Party

Title:

Transfer to SMRS information

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Demand

Volumes:

low

Interface Requirement:

Where metering is transferred from CDCA into SMRS, the following information will be provided.

Status (New, rejected, confirmed, confirmation request)

Effective to date (if confirmed)

Name of Registrant

Address

Contact for Transfer

Telephone number

Email address

Participant ID

Site name

Site address

Transfer details

Circuit description

Measurement quantity

Metering System ID

Metering Subsystem ID

Metering system details

NGC BMU identifiers

BMU ID

GSP reference

CVA MOA Details

CVA MOA

Contact Name

Telephone Number

Email address

Physical Interface Details:

The flow will include a schematic diagram where appropriate

5.40 CDCA-I059: (output) Initial Meter Reading Report

Interface ID:

CDCA-I059

User:

BSC Party

Title:

Initial Meter Reading Report

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Request

Volumes:

low

Interface Requirement:

If requested by the old HHDC or by the new registrant following a transfer from SMRS

Meter Details

CVA MSID

CVA Metering Subsystem ID

Date/time of reading

Reading Details

Measurement Quantity

Reading (MWh)

Physical Interface Details:

5.41 CDCA-I060: (input) SVA Party Agent Details

Interface ID:

CDCA-I060

Source:

SVA Registrant, CVA Registrant

Title:

SVA Party Agent Details

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Demand

Volumes:

Low

Interface Requirement:

1. Where an Outstation is shared between CDCA (Export) and SMRA (Import), the CDCA will receive from the SVA registrant details of the SVA Half Hourly Data Collector

2. The CVA (CRA) registrant of the Metering System will submit a request to allow the SVA HHDC to access the Import metering system

Physical Interface Details:

5.42 CDCA-I067: (input) Disconnected BM Units

Interface ID:

CDCA-I067

Source:

SO, Distribution Business

Title:

Disconnected CVA BM Units

BSC reference:

P305

Mechanism:

Manual

Frequency:

As required

Volumes:

low

Interface Requirement:

Where a Demand Control Event occurs, the CDCA will receive details of any CVA BM Units disconnected as a result of the Event from:

The NETSO, in the case of directly-connected CVA BM Units; and/or

Distribution Businesses, in the case of embedded CVA BM Units.

The information received shall include:

BM Unit IDs subject to Demand Disconnection as part of a Demand Control Event

Demand Disconnection Start Date and Time

Demand Disconnection End Date and Time

Note: This interface is not defined in the IDD spreadsheet that accompanies this document. This is because the communication of Disconnected BM Units is a manual flow. The NETSO and DSOs should email the details described above to the CDCA.

Physical Interface Details:

6 CRA External Inputs and Outputs

6.1 CRA Flow Overview

6.2 CRA-I001: (input) BSC Party Registration Data

Interface ID:

CRA-I001

Source:

BSC Party, BSCCo Ltd.

Title:

BSC Party Registration Data

BSC reference:

CRA SD 4.1, CRA BPM 3.1, ERM, CRA BPM 4.5, RETA SCH 4,B, 2.4.2, CRAWS-20, CRAWS-22, CR_18_990909, CP508, CP546/CP726, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Mostly at initial setup

The CRA shall receive BSC Party information containing the following data content:

Action Description

BSC Party Details

BSC Party Name

BSC Party ID

Authentication Details

Name

Password

Party Role Details**

Party Type

Registration Effective From Date

Registration Effective To Date

Role Address Details

Contact Name⁸

Address

Telephone No

Fax No

e-mail Address

Party Stage 2 Participant Details**

Stage 2 Participant ID (if BSC Party is a Stage 2 participant)

Party Authentication Key

Key Details

Authorised Signatories**

Name

Password

Contact Phone No

e-mail Address

Authorisation Levels**

Activity

Effective From Date

Effective To Date

Settlement Report Details

Report Type

Distribution Method

Interconnector Error Administration Details (if BSC Party is an IEA)**

Interconnector ID

Effective From Date

Effective To Date

** Registration changes relating to participant capacity or authorised person shall be confirmed by BSCCo Ltd in order to ensure that the new registration details are valid and are consistent with the current status of the BSC Party. This confirmation shall be submitted via a CRA-I001 flow from BSCCo Ltd containing the change. The registration changes requiring this confirmation are:

Add new party role
Change party role effective dates
Change Stage 2 participant details
Add, remove authorised signatory
Add authorisation level
Change effective dates on authorisation level
Changes Interconnector Administration details

Other registration changes do not require confirmation by BSCCo Ltd.

Physical Interface Details:

A physical structure is defined for this manual interface because the registrant can send this information as an electronic data file over the network; the CRA operator enters the information via a screen-based interface however it is sent.

6.3 CRA-I002: (input) Interconnector Administrator Registration Data

Interface ID:

CRA-I002

Source:

BSC Party (who is the Interconnector Administrator)

Title:

Interconnector Administrator Registration Data

BSC reference:

CRA SD 4.1.3, CRA BPM 3.1, CRA BPM 4.11, ERM, RETA SCH 4,B, 2.4.2, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Mostly at initial setup

The CRA shall receive Interconnector Administrator Registration Details including the following.

This interface allows for the registration of the Administrator for an Interconnector and as well as defining the definitive notification of the error administrator for the Interconnector at any one time. Registration of the Interconnector itself is provided through requirement CRA-I008.

Action Description

Party Authentication Details

Name

Password

Interconnector Administrator Details

Interconnector Administrator ID

Interconnector Details

Interconnector ID

Interconnector Error Administrator Data

Interconnector Error Administrator ID

Effective From Date

Effective To Date

Physical Interface Details:

6.4 CRA-I003: (input) BSC Party Agent Registration Data

Interface ID:

CRA-I003

Source:

BSC Party Agent, BSCCo Ltd

Title:

BSC Party Agent Registration Data

BSC reference:

CRA SD 4.2, CRA BPM 3.1, ERM, CRA BPM 4.2, RETA SCH 2.4.2, CP756, P197

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary.

Volumes:

Low

Initial registration of a BSC party agent will be by BSCCo Ltd. Changes to an agent’s details will be provided by the agent.

Note: Certification/Accreditation refers to Qualification.

The CRA shall receive BSC Party Agent Details including the following:

Action Description

Party Authentication Details (if source is a BSC Party)

Name

Password

BSC Party Agent Details

Agent Name

Agent Identifier

Agent Role Details

Agent Type

Registration Effective From Date

Registration Effective To Date

Role Address Details

Address

Telephone No

Fax No

e-mail Address

Certification/Accreditation Details

Certification/Accreditation Status

Party Agent Authentication Details

Name

Password

Authorised Signatories

Name

Password

Contact Phone No

e-mail Address

Authorisation Levels

Activity

Effective From Date

Effective To Date

Physical Interface Details

6.5 CRA-I005: (input) BM Unit Registration Data

Interface ID:

CRA-I005

Source:

BSC Party

Title:

BM Unit Registration Data

BSC reference:

CRA SD 6.0, CRA BPM 3.2, ERM, CRA BPM 4.3, RETA SCH 4,B, 2.4.2, CP753, CP756, P100

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

The CRA shall receive BM Unit Registration Details from a BSC Party. The registrant is the lead party.

The flow is meant to incorporate two forms of data:

1) The individual BM Units may be registered

2) Where required, by the NETSO, the flow may be used to register that a set of individual BM units should form a Joint BM Unit.

The information shall include the following:

Action Description

Authentication Details

Name

Password

BM Unit Registration Details

BM Unit Details

Name

BM Unit ID

BM Unit Type

NGC BM Unit Name

Zone

NETSO Reference

GSP Group ID (where appropriate)

Generation Capacity (MW)

Demand Capacity (MW)

Production / Consumption Flag

Base TU Flag (for Exempt Export BM Units only)

FPN Flag

Interconnector ID (where appropriate)

Effective From Date

Effective To Date

Transfer flag (indicates this is a transfer from SMRS)

SVA Metering Mapping Details

SVA MSID

Effective From Date

Effective To Date

BM Unit Group Details

Joint BM Unit ID

Effective From Date

Effective To Date

Joint BM Unit Details

BM Unit ID

Physical Interface Details:

The physical structure does not include SVA Metering Mapping Details as these are always sent manually, on paper.

6.6 CRA-I006: (input) Trading Unit Registration

Interface ID:

CRA-I006

Source:

BSC Party

Title:

Trading Unit Registration

BSC reference:

CRA SD 6.2, CRA BPM 3.2, ERM, CRA BPM 4.17, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

The CRA shall receive Trading Unit Registration Details from a BSC Party. The flow may be used to register an individual Trading Unit as well as to add and subtract the BM Units that make up the Trading Unit at a later time.

The flow shall be composed of the following Details

Action Description

Authentication Details

Name

Password

Trading Unit Details

Trading Unit Name

BM Unit Details

BM Unit ID

Effective From Date

Effective To Date

Physical Interface Details:

6.7 CRA-I007: (input/output) Boundary Point and System Connection Point Data

Interface ID:

CRA-I007

Source:-

NETSO, Distribution Business

Destination:

BSCCo Ltd

Title:

Boundary Point and System Connection Point Data

BSC reference:

CRA SD 6.4, CRA BPM 3.3, ERM, CRA BPM 4.9, RETA SCH 4,B, 2.4.2, CP615, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

The CRA shall receive information concerning the initial registration, decommissioning and changes to registered data for Boundary Points and System Connection Points. The information shall include the following:

Action Description

Authentication Details

Name

Password

Point Details

Boundary Point or System Connection Point Identifier

Boundary Point or System Connection Point Type

Effective From Date

Effective To Date

Where the information concerns a new registration, or the permanent decommissioning of an existing point, then CRA shall forward a copy of the information to BSCCo Ltd. The forwarded copy will include any additional information provided.

Physical Interface Details:

6.8 CRA-I008: (input) Interconnector Registration Details

Interface ID:

CRA-I008

Source:

NETSO or Distribution Business

Title:

Interconnector Registration Details

BSC reference:

CRA SD 6.3, CRA BPM 3.5, ERM, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

Interface Requirement:

The CRA shall receive new registrations and changes to the registration details of Interconnectors. Changes to the administration of the Interconnector are considered within the requirements of the Interconnector Administrator requirements:

Action Description

Authentication Details

Name

Password

Interconnector Details

Name

Additional Details (including GSP Group Id where appropriate)

Interconnector ID

Effective From Date

Effective To Date

Physical Interface Details:

6.9 CRA-I012: (output) CRA Encryption Key

Interface ID:

CRA-I012

User:

BSC Party,

BSC Party Agent, MIDP

Title:

CRA Encryption Key

BSC reference:

CRA SD 4.1.7, P78

Mechanism:

Manual

Frequency:

As necessary

Volumes:

Low

See [COMMS] for details of the encryption key.

The CRA system shall issue a report containing the authentication details for a BSC Party, Market Index Data Provider and other agents where necessary. The Authentication details shall consist of:

Encryption details

CRA public Key

Effective Start Date

Physical Interface Details:

6.10 CRA-I014: (output) Registration Report

Interface ID:

CRA-I014

User:

BSC Party,

BSC Party Agent,

BSC Service Agent,

NETSO,

BSCCo Ltd

Title:

Registration Report

BSC reference:

CRA SD 4, CRA BPM 3.5, CRA BPM 3.1, CRA BPM 4.16, ERM, CP546/CP726, P78, P100, CP962, P215

Mechanism:

Electronic data file transfer

(except Manual to BSC Service Agents and BSCCo Ltd)

Frequency:

As necessary

Volumes:

Low

The CRA system shall issue a report detailing changes and new registration data once it has been input into the CRA system. The report will be issued to the interested parties in the registration:

In most cases, the update only directly affects the registrant (i.e. the participant that submitted the registration request), but in a few particular cases, additional participants must be informed.

The report is issued to the relevant participants according to the following rules, dependent on the entity updated:

1. If the entity is a BSC Party then the report will be issued to that BSC Party;

2. If the entity is a BSC Party Agent then the report is issued to that BSC Party Agent;

3. If the entity is a BSC Service Agent then the report is issued to that BSC Service Agent;

4. If the entity is a BM Unit then the owning BSC Party of that unit is issued with the report;

5. If the entity is a Joint BM Unit Group then all BSC Parties having BM Units in the Group(s) concerned are issued with the report, as well as the owner of the Joint BM Unit Group;

6. If the entity is a Trading Unit then all BSC Parties having BM Units in the Trading Unit concerned are issued with the report, as well as the owner of the Trading Unit;

7. If the entity is a Metering System, the owning BSC Party and the BSC Party Agent appointed as Meter Operator Agent are issued with the report;

8. If the entity is a Boundary Point, then the owning BSC Party of that Boundary Point is issued with the report;

9. If the entity is a GSP Group, GSP or Distribution Systems Connection Point (DSCP) then the owning BSC Party is issued with the report;

10. If the entity is an Interconnector or an Interconnector Administration appointment then all BSC Parties owning Interconnector-usage BM Units on that Interconnector are issued with the report, as well as the Parties acting as Administrator and Error Administrator, and the owner of the Interconnector.

11. If the entity is a Market Index Data Provider then BSCCo Ltd will be issued with the report.

For Market Index Data Provider Registration a full refresh of the MIDP’s current registration details will be sent as a manual flow, back to BSCCo Ltd. This manual flow will include:

Market Index Data Provider ID

Market Index Data Provider Name

Registration Details

Registration Effective From

Registration Effective To

Name

Address

Telephone No

Fax No

e-mail address

For all other Registration types an automatic flow will be generated, which will meet the following requirements:

The interface may be used to either send updated details (received over the course of a day), or a full refresh of all the BSC Party’s current registration details.

The report shall contain the details of the registration along with the success / failure / pending nature and where appropriate, the reasons for failure / pending status.

The report shall contain a header detailing the status of the registration attempt / change, along with the structure and content of the input data flow for which this is a report. The structure of the individual response shall correspond to that contained on the incoming flow (CRA-I001⁹, CRA-I002, CRA-I003, CRA-I004, CRA-I005, CRA-I006, CRA-I007, CRA-I008, CRA-I027, CRA-I031).

The content of the report corresponding to incoming flow CRA-I005 shall be extended to include the following data items, in addition to the details contained in the incoming flow:

WDCALF (as received in interface CRA-I011)¹⁰
NWDCALF (as received in interface CRA-I011)¹¹
SECALF (as received in interface CRA-I011)¹²
TLF (as received in interface CRA-I029)
Exempt Export Flag (as received in interface CRA-I043)
Manual Credit Qualifying Flag (as received in interface CRA-I009)
Credit Qualifying Status (derived value)

WDBMCAIC (derived value)
NWDBMCAIC (derived value)

WDBMCAEC (derived value)
NWDBMCAEC (derived value)
Production / Consumption Status (derived value)

Updates shall be reported in response to incoming flow CRA-I005 or where any of the data items above have changed. A report may also be issued following changes to the composition of a Trading Unit, or changes to any of the component BM Units belonging to a Trading Unit, that result in re-computation of Production / Consumption Status even though that re-computation may derive the same Status as before.

The header details shall contain the following information:

Registration Details

Requesting Registrant,

Registration Type (Party, Party Agent, Service Agent, BM Unit etc.)

Registration Status (success, failure, pending)

Additional Details

The requesting registrant field will normally contain the Id of the registrant; but for the report sent in response to CRA-I003, it will always be the Id of the Party Agent being registered.

The registration status details the result of the registration request. This may be:

Success: The registration request was successful
Failure: The request failed validation and was rejected
Pending: The request relied upon corroborative material and is thus pending the arrival of this information.

Where BSC Parties, BSC Party Agents and BSC Service Agents have registered multiple roles, the report includes a separate registration status for each role.

Followed by the individual registration details, omitting authentication details, but including any additional details (such as identifiers and BM Units automatically assigned).

Each record of the report contains an Action Code, indicating whether the record has a) been added or changed; b) been deleted or c) not changed. When the report is sent as a full refresh, the action code is omitted for each record.

Note that there is no data item “Energy Account ID” since each party has a Production and a Consumption account which are identified by the Party ID and the P/C Indicator.

Physical Interface Details:

In the physical report, Registration Status can only be success or pending. Reporting that a registration has failed is a manual process. Accordingly, the physical report does not contain “Additional Details”.

For the response to CRA-I005, where a BM Unit's Production / Consumption Status changes on a date where no other BM Unit attributes change (for example as a result of another BM Unit being added or removed from the Trading Unit to which the BM Unit belongs), the BM Unit information will be reported as separate date ranges in order to accurately report the changing Status.

6.11 CRA-I021: (output) Registered Service List

Interface ID:

CRA-I021

User:

BSC Party, Public

Title:

Registered Service List

BSC reference:

RETA SCH 4,B, 2.2.2, CRA BPM 4.12, P197

Mechanism:

Electronic data file transfer/Manual

Frequency:

On Request

Volumes:

Low

The CRA system shall issue a report listing the registered services to BSC Parties (automatically) and issue a subset of this information to the public (manually) on request.

Note: Certification/Accreditation refers to Qualification.

This will contain:

BSC Party Agent Details

Agent Name

Agent Identifier

Agent Role Details

Agent Type

Role Address Details

Address

Telephone No

Fax No

e-mail Address

Certification/Accreditation Details

Certification/Accreditation Status

BSC Service Agent Details

Agent Name

Agent Identifier

Service Agent Role Details

Agent Type

Effective From Date

Effective To Date

Role Address Details

Address

Telephone No

Fax No

e-mail Address

Physical Interface Details:

6.12 CRA-I024: (output) Certification and Accreditation Status Report

Interface ID:

CRA-I024

User:

BSC Party BSC Party Agents BSc Service Agents

Title:

Certification and Accreditation Status Report

BSC reference:

CRA SD 5.3, P197

Mechanism:

Electronic data file transfer (except Manual to BSC Service Agents)

Frequency:

On Request

Volumes:

Low

The CRA system shall issue a report to the BSC Parties, Party Agents and (manually in the case of) Service Agents detailing changes to the Qualification status of BSC Party Agents and BSC Service Agents.

Note: Certification/Accreditation refers to Qualification.

The report shall contain the following data:

BSC Party Agent Details

Action Code

Agent Name

Agent Identifier

Agent Role Details

Action Code

Agent Type

Effective From Date

Effective To Date

Role Address Details

Action Code

Address

Telephone No

Fax No

e-mail Address

Certification/Accreditation Details

Action Code

Certification/Accreditation Status BSC

Service Agent Details

Action Code

Agent Name

Agent Identifier

Service Agent Role Details

Action Code

Agent Type

Effective From Date

Effective To Date

Role Address Details

Action Code

Address

Telephone No

Fax No

e-mail Address

The first field of each record of the report is an Action Code, indicating whether the record has a) been added or changed; b) been deleted or c) not changed.

Physical Interface Details:

6.13 CRA-I025: Receive Acknowledgement

See Section 2.2.7.

6.14 CRA-I026: Issue Acknowledgement

See Section 2.2.7.

6.15 CRA-I027: (input) GSP Group and GSP Registration

Interface ID:

CRA-I027

Source:

BSC Party (Distribution Business)

Title:

GSP Group Registration

BSC reference:

CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

The CRA shall receive GSP Group Registration Details from a Distribution Business. The flow may be used to register an individual GSP Group as well as GSP’s and inter-GSP-Group Connections. The CRA shall not maintain a relationship between the three data items.

The flow shall be composed of the following Details

Action Description

Authentication Details

Name

Password

GSP Group Details

GSP Group ID

GSP Group Name

Effective From Date

Effective To Date

GSP Details

GSP ID

Effective From Date

Effective To Date

Inter-GSP Group Connection Details

Inter-GSP Group Connection ID

Effective From Date

Effective To Date

Physical Interface Details:

6.16 CRA-I031: (input) Metering System Data

Interface ID:

CRA-I031

Source:

BSC Party

Title:

Metering System Data

BSC reference:

CRA SD 6.4, CRA BPM 3.3, ERM, CRA BPM 4.9, RETA SCH 4,B, 2.4.2, CP569, CP753, CP756

Mechanism:

Manual, by email, letter or fax, or can be sent as an electronic data file over the network

Frequency:

As Necessary

Volumes:

Low

The CRA shall receive Metering System Registration Details. The CRA records the master set of registration details for the Metering Systems. This information is later augmented by the CDCA to record the full details for NETA. The information shall include the following:

Action Description

Authentication Details

Name

Password

Metering System Details

Metering System Identifier

Meter Operator Agent ID

Effective From Date

Effective To Date

Transfer flag (indicates this is a transfer from SMRS)

For each new Metering System registration, the Registrant shall include confirmation that either:

The Registrant is the Equipment Owner, or
The Registrant has obtained the Equipment Owner’s consent for the appointment.

Physical Interface Details:

A physical structure is defined for this manual interface because the registrant can send this information (except for the equipment owner’s confirmation for new registrations) as an electronic data file over the network; the CRA operator enters the information via a screen-based interface however it is sent.

6.17 CRA-I034: (input) Flexible Reporting Request

Interface ID:

CRA-I034

Source:

BSCCo, BSC Party, BSC Party Agent, NETSO, BSC Service Agents

Title:

Flexible Reporting Request

BSC reference:

CR 53, P8, CP756

Mechanism:

Manual, by email, letter or fax

Frequency:

As Necessary

Volumes:

Low

Interface Requirement:

The CRA shall receive authorisations:

a) to start or stop sending copies of reports generated for one organisation to another organisation

i) a BSC Party (P) may receive copies of reports generated for another BSC Party (P’). The request must be submitted by BSCCo or, for those reports designated by BSCCo, by BSC Party P.

ii) BSCCo may receive copies of reports generated for any organisation. The request must be submitted by BSCCo.

b) to specify which version of a report to create for an organisation (If present this requests a specific version of the report be generated for the party. The default is to issue the latest version of a report. Old versions of reports are supported for a limited period (as agreed between the BSC Service Agent providing the report and BSCCo Ltd) following the introduction of a new version) The request will come from the organisation;

Requesting BSC Party Details

organisation Id

organisation type

Report Copy Details

Report Type

Effective from date

Effective to date

organisation Id

organisation type

Start/Stop Flag

Report Version Details

Report Type

Effective from date

Effective to date

Version (specific or “latest”)

Note: If receiving a copy of another party’s report, the version copied will be the version generated for the original party

Note: in this specification, “organisation” is any of BSCCo, BSC Party, BSC Party Agent, NETSO, BSC Service Agents

Physical Interface Details:

The flow may contain requests from one or more organisation and each request may cover a number of report types/BSC Parties.

6.18 CRA-I038: Transfer from SMRS information

Interface ID:

CRA-I038

Source:

Transfer Coordinator, BSC Party

Title:

Transfer from SMRS information

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Demand

Volumes:

low

Interface Requirement:

Where metering is transferred from SMRS into CRA, the following information will be provided.

Status (New, rejected, confirmed, confirmation request)

Effective from date (if confirmed)

Name of Registrant

Address

Contact for Transfer

Telephone number

Email address

Participant ID

Site name

Site address

Transfer details

Circuit description

Measurement quantity

Metering System ID

Metering Subsystem ID

Metering system details

NGC BMU identifiers

BM Unit identifier

GSP reference

CVA MOA

Physical Interface Details:

The flow will include a schematic diagram where appropriate

6.19 CRA-I040: Transfer to SMRS information

Interface ID:

CRA-I040

Source:

Transfer Coordinator, BSC Party

Title:

Transfer to SMRS information

BSC reference:

CP753

Mechanism:

Manual

Frequency:

On Demand

Volumes:

low

Interface Requirement:

Where metering is transferred from CRA into SMRS, the following information will be provided.

Status (New, rejected, confirmed, confirmation request)

Effective to date (if confirmed)

Name of CVA Registrant

Address

Contact for Transfer

Telephone number

Email address

Participant ID

Site name

Site address

Transfer details

Circuit description

Measurement quantity

Metering System ID

Metering Subsystem ID

Metering system details

NGC BMU identifiers

BM Unit ID

GSP reference

CVA MOA

Physical Interface Details:

The flow will include a schematic diagram where appropriate

6.20 CRA-I048: GC or DC Breach Notification

Interface ID:

CRA-I048

User:

CRA, BSCCo

Title:

GC or DC Breach Notification

BSC reference:

P359

Mechanism:

Manual

Frequency:

As required

Volumes:

low

Interface Requirement:

Where a GC Breach or a DC Breach has been identified for a BM Unit, the CRA shall provide the following information to the Lead Party:

BM Unit Id

GC or DC Breach Type

Settlement Day

Settlement Period

CRA-estimated GC or DC Amount

Effective From Date for CRA-Estimated GC or DC Amount

Other information deemed by BSCCo to be relevant

Please note that this notification will also be published on the BSC Website

Physical Interface Details:

6.21 CRA-I049: GC or DC Breach Estimation Challenge

Interface ID:

CRA-I049

Source:

BSC Party

Title:

GC or DC Breach Estimation Challenge

BSC reference:

P359

Mechanism:

Manual

Frequency:

As required

Volumes:

low

Interface Requirement:

Where a BSC Party Challenges a GC or DC Breach Estimation for a BM Unit, they shall provide the following information:

BM Unit Id

Type of GC or DC Breach

Settlement Day

Settlement Period

Evidence of error

Please note that this notification will also be published on the BSC Website

Physical Interface Details:

6.22 CRA-I051: Notification of Breach Challenge Data

Interface ID:

CRA-I051

User:

BSC Party

Title:

Notification of Breach Challenge Data

BSC reference:

P359

Mechanism:

Manual

Frequency:

As required

Volumes:

Low

Interface Requirement:

The CRA shall publish data relating to a BM Unit in GC Breach or DC Breach on the BSC Website for not less than 24 calendar months after the date of the Breach notification:

Breach Identification Date/Time stamp
GC or DC breach
BM Unit ID
Breach SD
Breach SP
Actual BM Unit Metered Volume that triggered breach
[Prevailing] GC or DC
CRA calculated estimate of BM Unit Metered Volume
EFD for GC or DC based on CRA estimate
Appeal status – default value at the time of breach identification will be ‘No appeal’. Allowable values are: ‘No appeal’, ‘Appealed’, ‘Upheld’, ‘Rejected’
Estimated BM Unit Metered Volume following the conclusion of an appeal (default value is NULL)
Effective From Date of the amended volume due to an appeal. When an appeal has been successfully completed the effected from date of the new GC and/or DC resulting from the appeal.

The CRA shall ensure that only the Lead Party of the relevant BM Unit will be entitled to see the above details.

The CRA shall also issue the above details to the Lead Party of the relevant BM Unit by email.

Physical Interface Details:

7 ECVAA External Inputs and Outputs

7.1 ECVAA Flow Overview

7.2 ECVAA-I002: (input) ECVNAA Data

Interface ID:

ECVAA-I002

User:

ECVNA, BSC Party

Title:

ECVNAA Data

BSC reference:

ECVAA SD: 6.1, 6.6, A

ECVAA BPM: 3.1, 4.1, 4.4

RETA SCH: 4, B, 3.4, CP547, P110, CP888, P98, P309

Mechanism:

Manual, by letter or fax, or can be sent as an electronic file over the network

Frequency:

Ad hoc

Volumes:

Low

The ECVAA Service shall receive the following ECVNAA data on an ad hoc basis.

i. ECVNAA requests. Each request shall be submitted separately by two BSC Parties and either one or two ECVNAs, each providing identical details of the request as shown below along with their individual password/signature.

ii. ECVNAA Authorisation Termination requests. Each termination request shall be submitted by either of the two BSC Parties or an ECVNA for the relevant ECVNAA.

iii. ECVNAA Key Change requests. Each request shall be submitted by an ECVNA for the relevant ECVNAA.

iv. ECVNAA Report Requirement Change requests. Each request shall be submitted by an ECVNA, or BSC Party for the relevant ECVNAA.

The ECVNAA data shall comprise:

ECVNAA Requests:

ECVNAA Change (‘T’ or ‘F’)

ECVNA ID

ECVNA Name

ECV Party 1 ID

ECV Party 1 Name

ECV Party 1 production/consumption flag

ECVNA ID 2 (optional)

ECVNA Name 2 (optional)

ECV Party 2 ID

ECV Party 2 Name

ECV Party 2 production/consumption flag

Effective From Date

Effective To Date

ECVN Amendment Type (Additional/Replacement/Both)

Notification Amendment Type Effective From Date

Report Requirements (optional – specific to submitter)

ECVNAA Termination Requests:

ECVNAA ID

ECVNA ID

ECV Party 1 ID

ECVNA ID 2 (optional)

ECV Party 2 ID

Associated VNNR Indicator

ECVNAA Key Change Requests (specific to submitter):

ECVNAA ID

ECVNA ID

ECV Party 1 ID

ECVNA ID 2 (optional)

ECV Party 2 ID

ECVNAA Report Requirement Change Requests (specific to submitter):

ECVNAA ID

ECVNA ID

ECV Party 1 ID

ECVNA ID 2 (optional)

ECV Party 2 ID

Report Requirement

Notes:

The ECVNAA Key is not included in the key change request since this is a manual interface. However standard authentication checks will ensure that the party submitting the request is the ECVNA for the relevant ECVNAA.

The Associated VNNR Indicator is used to inform the ECVAA that this ECVNAA Termination Request should be processed prior to processing the corresponding Volume Notification Nullification Request.
The EVCN Amendment Type allows the user to specify whether follow-up notifications submitted under the relevant ECVNAA should be accepted as either Additional or Replacement notifications, or whether both mechanisms are acceptable.

Only if the Authorisation Request is a new or successor request, then the Notification Amendment Effective From Date should equal the Effective From Date (N0081).
The Report Requirement will allow the following report variants to be selected for a given BSC Party or ECVNA and ECVNAA:

Physical Interface Details: Physical flow details are defined for this manual interface because the registrant can send this information as an electronic data file over the network; the ECVAA operator enters the information via a screen-based interface however it is sent..

7.3 ECVAA-I003: (input) MVRNAA Data

Interface ID:

ECVAA-I003

User:

MVRNA, BSC Party

Title:

MVRNAA Data

BSC reference:

ECVAA SD: 7.1, 7.6, 7.7, A

ECVAA BPM: 3.2, 4.6, 4.10, 4.12

RETA SCH: 4, B, 3.4

CR 005, CP547, P110, CP888, P98

Mechanism:

Manual, by letter or fax, or can be sent as an electronic data file over the network

Frequency:

Ad hoc

Volumes:

Low

The ECVAA Service shall receive the following MVRNAA data on an ad hoc basis.

i. MVRNAA requests. Each request shall be submitted separately by the BM Unit Lead Party, BM Unit Subsidiary Party and either one or two MVRNAs, each providing identical details as shown below along with their individual password/signature.

ii. MVRNAA Termination requests. Each termination request shall be submitted by the BM Unit Lead Party, BM Unit Subsidiary Party or a MVRNA of the relevant MVRNAA.

iii. MVRNAA Key Change requests. Each request shall be submitted by a MVRNA for the relevant MVRNAA.

iv. MVRNAA Report Requirement Change requests. Each request shall be submitted by a MVRNA or BSC Party for the relevant MVRNAA.

The MVRNAA data shall comprise:

MVRNAA Requests:

MVRNA ID

MVRNA Name

BM Unit ID

Lead Party ID

Lead Party Name

Lead Party production/consumption flag

MVRNA ID 2 (optional)

MVRNA Name 2 (optional)

Subsidiary Party ID

Subsidiary Party Name

Subsidiary Party production/consumption flag

Effective From Date

Effective To Date

Report Requirements (optional - specific to submitter)

MVR Termination Requests:

MVRNAA ID

MVRNA ID

BM Unit ID

Lead Party ID

MVRNA ID 2 (optional)

Subsidiary Party ID

Associated VNNR Indicator

MVRNAA Key Change Requests (specific to submitter):

MVRNAA ID

MVRNA ID

BM Unit ID

Lead Party ID

MVRNA ID 2 (optional)

Subsidiary Party ID

MVRNAA Report Requirement Change Requests (specific to submitter):

MVRNAA ID

MVRNA ID

BM Unit ID

Lead Party ID

MVRNA ID 2 (optional)

Subsidiary Party ID

Report Requirement

Notes:

The MVRNAA Key is not included in the key change request since this is a manual interface. However standard authentication checks will ensure that the party submitting the request is the MVRNA for the relevant MVRNAA.
The Associated VNNR Indicator is used to inform the ECVAA that this MVRNAA Termination Request should be processed prior to processing the corresponding Volume Notification Nullification Request.

The Report Requirement will allow the following report variants to be selected for a given BSC Party or MVRNA and MVRNAA:

Receive AFR (with accepted data groups only) and RFR
Receive AFR (with accepted and matched data groups) and RFR
Receive no AFR and no RFR

7.4 ECVAA-I004: (input) ECVN

Interface ID:

ECVAA-I004

User:

ECVNA

Title:

ECVNs

BSC reference:

ECVAA SD: 8.1, A

ECVAA BPM: 3.3, 4.18

RETA SCH: 4, B, 3.4

CR 008, CP527, P98

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous

Volumes:

High

Interface Requirement:

i. The ECVAA Service shall receive the following ECVNs from ECVNAs continuously for every Settlement Period up until the Submission Deadline (the notification deadline for the purposes of submitting ECVNs and MVRNs for each Settlement Period as defined in Annex X-1).

Note that ECVN Withdrawal is implemented by sending a notification containing a null ECV.

The ECVNs shall comprise:

Energy Contract Volume Notification:

ECVNA ID

ECVNAA ID

ECVNAA Key

ECVN ECVNAA ID

ECVN Reference Code

Effective From Date

Effective To Date (optional)

Settlement Period (1-50)

Energy Contract Volume (MWh) (volume sold by party 1 to party 2, may be negative))

Omitted Data: No Change (optional)¹³

Physical Interface Details:

The ECVNA Id is the From Participant Id in the AAA header record of the physical file and so is not included in the EDN record.

The ECVN ECVNAA Id should always be either

a) the ECVNAA Id of the Agent submitting the ECVN, or

b) an ECVNAA Id that has now expired (i.e. effective to date < todays date) but was for the same pair of trading Party Energy Accounts (specified in the same order in each ECVNAA);

An ECVN that does not follow these rules should be rejected in full.

See section 7.24 for more details.

7.5 ECVAA-I005: (input) MVRN

Interface ID:

ECVAA-I005

Source:

MVRNA

Title:

Meter Volume Reallocation (MVR) Notifications

BSC reference:

ECVAA SD: 9.1, A

RETA ERR 2

ECVAA BPM: 3.3, 4.19

RETA SCH: 4, B, 3.4

CR 005, CR 008, CP527, P98

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous

Volumes:

High

The ECVAA Service shall receive MVRNs from MVRNAs continuously for every Settlement Period up until the Submission Deadline.

The MVRNs shall comprise:

Meter Volume Reallocation Notification:

MVRNA ID

MVRNAA ID

MVRNAA Key

MVRN MVRNAA ID

MVRN Reference Code

Effective From Date

Effective To Date (optional)

Settlement Period (1-50)

Metered Volume Fixed Reallocation (MWh)

Metered Volume Percentage Reallocation (%)

Omitted Data: No Change (optional)¹⁴

Physical Interface Issues:

The MVRNA Id is the From Participant Id in the AAA header record of the physical file and so is not included in the MVN record.

The MVRN MVRNAA Id should always be either

the MVRNAA Id of the Agent submitting the new/replacement MVRN (If an MVRN already exists with the same reference code, the new MVRNs will be processed as amendments, i.e. being an replacement rather than being additive), or
an MVRNAA Id that has now expired (i.e. to date < todays date) but was for the same Lead and Subsidiary Party Energy Account;

An MVRN that does not follow these rules should be rejected in full.

See section 7.24 for more details; the information given there on ECVNs is equally applicable to MVRNs.

7.6 ECVAA-I007: (output) ECVNAA Feedback

Interface ID:

ECVAA-I007

User:

BSC Party,

ECVNA

Title:

ECVNAA Feedback

BSC reference:

ECVAA SD: 6.2, 6.3, 6.4, 6.7, 6.8, A

ECVAA BPM: 3.1, 4.2, 4.3, 4.5

RETA SCH: 4, B, 3.2, CP547, CP571, CP888, P98, Variation 59

Mechanism:

Manual for Rejections and Deletions; Electronic Data File Transfer for Confirmations

Frequency:

Ad hoc, in response to ECVNAA requests and registration data changes

Volumes:

Low

Interface Requirement:

The ECVAA Service shall issue the following ECVNAA Feedback data in response to ECVNAA requests:

i. Confirmed ECVNAA - issued to both BSC Parties and ECVNA(s).

ii. Rejected ECVNAA - issued to both BSC Parties and ECVNA(s).

iii. Confirmed ECVNAA Termination - issued to both BSC Parties and ECVNA(s).

iv. Rejected ECVNAA Termination - issued to the BSC Party or ECVNA.

v. Confirmed ECVNAA Key Change - issued to the relevant ECVNA.

vi. Rejected ECVNAA Key Change - issued to the relevant ECVNA.

vii. Confirmed ECVNAA Deletion – issued to the relevant BSC Parties and ECVNA(s).

viii. Rejected ECVNAA Deletion – issued to the relevant BSC Party or ECVNA.

ix. Confirmed ECVNAA Reporting Option Change - issued to the requesting BSC Party or ECVNA.

x. Rejected ECVNAA Reporting Option Change - issued to the requesting BSC Party or ECVNA.

The ECVNAA Feedback shall include:

Confirmed ECVNAA:

Original details received in ECVAA-I002 Authorisation request plus -

ECVNAA ID (to both BSC Parties and relevant ECVNA(s))

ECVNAA Key (to ECVNA only, each ECVNA receives their Key)

Nb confirmation of an Authorisation Change will not include the Notification Amendment Type Effective From Date

Rejected ECVNAA:

Original details received in ECVAA-I002 Authorisation request plus -

Rejection Reason

Note: if the rejection is due to non-receipt of matching authorisations, then both parties and the ECVNA are still informed, and the feedback sent to each shall not include another’s authentication information

Confirmed ECVNAA Termination:

Original details received in ECVAA-I002 Termination request plus-

Effective To Date

Termination Reason

Note: Termination Reason indicates whether party or ECVNA request or triggered by change to registration data.

Rejected ECVNAA Termination:

Original details received in ECVAA-I002 Termination request plus -

Rejection Reason

Confirmed ECVNAA Key Change:

ECVNAA ID

ECVNAA Key (new key)

Effective From Date

Rejected ECVNAA Key Change:

Original details received in Key Change request plus -

Rejection Reason

Confirmed ECVNAA Deletion:

Original details received in Termination request plus-

Termination Reason

Note: This is sent in response to a Termination request where the Termination Date is before the Effective From Date.

Rejected ECVNAA Deletion:

Original details received in Termination request plus-

Rejection Reason

Note: This is sent in response to a Termination request where the Termination Date is before the Effective From Date.

Confirmed ECVNAA Reporting Option Change:

Authorisation Details after Reporting Option Change request applied

Rejected ECVNAA Reporting Option Change:

Original details received in Reporting Option Change request plus -

Rejection Reason

Note that Reporting Options and details of the second ECVNA will only be reported if the ECVNAA is a dual agent authorisation.

7.7 ECVAA-I008: (output) MVRNAA Feedback

Interface ID:

ECVAA-I008

User:

BSC Party,

MVRNA

Title:

MVRNAA Feedback

BSC reference:

ECVAA SD: 7.2, 7.3, 7.4, 7.7, 7.8, 7.11, 7.12, A

ECVAA BPM: 3.2, 4.9, 4.10, 4.11, 4.14

RETA SCH: 4, B, 3.2#

CR 005, CP547, CP571, CP888, P98, Variation 59

Mechanism:

Manual for Rejections and Deletions; Electronic Data File Transfer for Confirmations

Frequency:

Ad hoc, in response to MVRNAA requests and registration data changes

Volumes:

Low

Interface Requirement:

The ECVAA Service shall issue the following MVRNAA Feedback data , in response to MVRNAA requests :

i. Confirmed MVRNAA - issued to the relevant BM Unit Lead Party, BM Unit Subsidiary Party and MVRNA(s).

ii. Rejected MVRNAA - issued to the relevant BM Unit Lead Party, BM Unit Subsidiary Party and MVRNA(s).

iii. Confirmed MVRNAA Termination - issued to the relevant BM Unit Lead Party, BM Unit Subsidiary Party and MVRNA(s).

iv. Rejected MVRNAA Termination - issued to the relevant BM Unit Lead Party, BM Unit Subsidiary Party or MVRNA.

v. Confirmed MVRNAA Key Change - issued to the relevant MVRNA.

vi. Rejected MVRNAA Key Change - issued to the relevant MVRNA.

vii. Confirmed MVRNAA Deletion - issued to the relevant BM Unit Lead Party, BM Unit Subsidiary Party and MVRNA(s).

viii. Rejected MVRNAA Deletion - issued to the relevant BM Unit Lead Party or BM Unit Subsidiary Party or MVRNA.

ix. Confirmed MVRNAA Reporting Option Change - issued to the requesting BM Unit Lead Party, BM Unit Subsidiary Party or MVRNA.

x. Rejected MVRNAA Reporting Option Change - issued to the requesting BM Unit Lead Party, BM Unit Subsidiary Party or MVRNA.

The MVRNAA Feedback shall include:

Confirmed MVRNAA:

Original details received in ECVAA-I003 Authorisation request plus -

MVRNAA ID (to Lead, Subsidiary Party and relevant MVRNA(s))

MVRNAA Key (to MVRNA only, each MVRNA receives their Key)

Rejected MVRNAA:

Original details received in ECVAA-I003 Authorisation request plus -

Rejection Reason

Note: if the rejection is due to non-receipt of matching authorisations, then both parties and the MVRNA are still informed, and the feedback sent to each shall not include another’s authentication information.

Confirmed MVRNAA Termination:

Original details received in ECVAA-I003 Termination request plus-

Effective To Date

Termination Reason

Note: Termination Reason indicates whether party or MVRNA request or triggered by change to registration data.

Rejected MVRNAA Termination:

Original details received in ECVAA-I003 Termination request plus -

Rejection Reason

Confirmed MVRNAA Key Change:

MVRNAA ID

MVRNAA Key (new key)

Effective From Date

Rejected MVRNAA Key Change:

Original details received in Key Change request plus -

Rejection Reason

Confirmed MVRNAA Deletion:

Original details received in Termination request plus-

Termination Reason

Note: This is sent in response to a Termination request where the Termination Date is before the Effective From Date.

Rejected MVRNAA Deletion:

Original details received in Termination request plus-

Rejection Reason

Note: This is sent in response to a Termination request where the Termination Date is before the Effective From Date.

Confirmed MVRNAA Reporting Option Change:

Authorisation Details after Reporting Option Change request applied

Rejected MVRNAA Reporting Option Change:

Original details received in Reporting Option Change request plus -

Rejection Reason

Note that Reporting Options and details of the second MVRNA will only be reported if the MVRNAA is a dual agent authorisation.

7.8 ECVAA-I009: (output) ECVN Feedback (Rejection)

Interface ID:

ECVAA-I009

User:

BSC Party,

ECVNA

Title:

ECVN Feedback (Rejection)

BSC reference:

ECVAA SD: 8.3, A

ECVAA BPM: 3.3, 4.22, 4.23, 4.24, 4.25

RETA SCH: 4, B, 3.2

CR 12, CP527, CP703, P98, CP1221

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous, for rejected ECVNs and ECVN components

Volumes:

Medium

Interface Requirement:

The ECVAA Service shall issue ECVN Feedback (rejection) to BSC Parties and ECVNAs continuously to report:

i. the rejection of ECVNs on receipt; and

ii. the rejection of ECVN components during the half-hourly credit check process.

The ECVN Feedback (rejection) shall comprise:

Rejected ECVN:

ECVNA Id

ECVNAA Id

ECVN ECVNAA Id

ECVN Reference Code

Effective From Date

Effective To Date (optional)

Settlement Period (1-50)

Energy Contract Volume (MWh)

Rejection Reason, including:

Invalid time stamp

Level 2 Credit Default

Notes:

i. For rejection of ECVNs on receipt, the ECVN Feedback (rejection) shall comprise the original details received in the ECVN (except the ECVNAA Key).

ii. For rejection of ECVN components during the half-hourly credit check process, the ECVN Feedback (rejection) shall comprise the single Settlement Period component from the original ECVN which is rejected.

iii. Each Party and their ECVNA receives feedback on Notifications as determined from the ECVNAA used in submission (subject to Reporting Options selected by the Party and ECVNA for that ECVNAA - see ECVAA-F003).

7.9 ECVAA-I010: (output) MVRN Feedback (Rejection)

Interface ID:

ECVAA-I010

User:

BSC Party,

MVRNA

Title:

MVRN Feedback (Rejection)

BSC reference:

ECVAA SD: 9.2, A

RETA ERR: 2

ECVAA BPM: 3.3, 4.22, 4.23, 4.24, 4.25

RETA SCH: 4, B, 3.2

CR 12, CP527, CP703, P98 CP1221

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous, for rejected MVRNs and MVRN components

Volumes:

Medium

Interface Requirement:

The ECVAA Service shall issue MVRN Feedback (rejection) to BSC Parties and MVRNAs continuously to report:

i. the rejection of MVRNs on receipt; and

ii. the rejection of MVRN components during the half-hourly credit check process.

The MVRN Feedback (rejection) shall comprise:

Rejected MVRN:

MVRNA Id

MVRNAA Id

MVRN MVRNAA Id

MVRN Reference Code

Effective From Date

Effective To Date (optional)

Settlement Period (1-50)

Metered Volume Fixed Reallocation (MWh)

Metered Volume Percentage Reallocation (%)

Rejection Reason, including:

Invalid time stamp

Level 2 Credit Default

100% Total Exceeded

Notes:

i. For rejection of MVRNs on receipt, the MVRN Feedback (rejection) shall comprise the original details received in the MVRN (except the MVRNAA Key).

ii. For rejection of MVRN components during the half-hourly credit check process, the MVRN Feedback (rejection) shall comprise the single Settlement Period component from the original MVRN which is rejected.

iii. Each Party and their MVRNA receives feedback on Notifications as determined from the MVRNAA used in submission (subject to Reporting Options selected by the Party and MVRNA for that MVRNAA - see ECVAA-F004).

7.10 ECVAA-I013: (output) Authorisation Report

Interface ID:

ECVAA-I013

User:

BSC Party,

MVRNA,

ECVNA

Title:

Authorisation Report

BSC reference:

ECVAA IRR: E1, E2, P98

Mechanism:

Electronic Data File Transfer

Frequency:

Daily, on request

Volumes:

Low

Interface Requirement:

The ECVAA Service shall issue Authorisation Reports to BSC Parties, ECVNAs and MVRNAs once a day¹⁵.

Note: Reports will only be issued to those parties that have (manually) requested a report (covering a specified date range) to be sent on that day.

The Authorisation Report shall comprise:

Report Start Date

Report End Date

ECVNAA data:

Data same as ‘Confirmed ECVNAA’ described for requirement ECVAA-I007: Issue ECVNAA Feedback, except ECVNAA Key.

MVRNAA data:

Data same as ‘Confirmed MVRNAA’ described for requirement ECVAA-I008: Issue MVRNAA Feedback, except MVRNAA Key.

7.11 ECVAA-I014: (output) Notification Report

Interface ID:

ECVAA-I014

User:

MVRNA,

ECVNA,

BSC Party

Title:

Notification Report

BSC reference:

ECVAA IRR: E3, E4

CR 12, CP527, CP858, CP869, P98, P140, P215

Mechanism:

Electronic Data File Transfer

Frequency:

Daily and in support of disputes

Volumes:

Medium

Interface Requirement:

The ECVAA Service shall issue Notification Reports to BSC Parties, ECVNAs and MVRNAs once a day. At the end of each Settlement Date, the ECVAA shall report notifications which apply to that Settlement Date to all relevant parties. For the avoidance of doubt this is not notifications received on the relevant Settlement Date.

The ECVAA Service shall issue revised Notification Reports to the BSC Parties, ECVNAs and MVRNAs as a result of disputes. A revised report shall only be sent to parties affected by the dispute.

The Notification Report shall comprise:

Notification Data:

Settlement Date

ECVAA Run Number

Day Start Energy Indebtedness Data (to BSC Party Only):

Actual Energy Indebtedness (MWh) (Σ_d28AEI_pd)

Metered Energy Indebtedness (MWh) (Σ_d28MEI_pd)

Cumulative Credit Assessment Energy Indebtedness (MWh) (CCEI_pj)

Actual Energy Indebtedness Dates (identifies which date range(s) have AEI data)

From Settlement Date

To Settlement Date

Metered Energy Indebtedness Dates (identifies which date range(s) have MEI data)

From Settlement Date

To Settlement Date

Settlement Period Data

Settlement Period (1-50)

ECVN Data

ECVN ECVNAA ID

ECVN Reference Code

Energy Contract Volume (MWh)

ECVNA ID ++

ECVNAA ID ++

BSC Party 1 ID

BSC Party 1 Name

BSC Party 1 Energy Account Production/Consumption flag

BSC Party 2 ID

BSC Party 2 Name

BSC Party 2 Energy Account Production/Consumption flag

MVRN Data

MVRN MVRNAA ID

MVRN Reference Code

Metered Volume Fixed Reallocation (MWh)

Metered Volume Percentage Reallocation (%)

MVRNA ID ++

MVRNAA ID ++

BM Unit ID

Lead Party ID

Lead Party Name

Lead Party Energy Account Production/Consumption flag

Subsidiary Party ID

Subsidiary Party Name

Subsidiary Party Energy Account Production/Consumption flag

Indebtedness Data (to BSC Party Only)

Credit Assessment Credited Energy Volume (CAQCE_pj)

Aggregated Energy Contract Volume (QABC_pj)

Cumulative Credit Assessment Energy Indebtedness* (MWh) (CCEI_pj)

Energy Indebtedness* (MWh) (EI_pj)

Credit Cover Percentage (%)

Credit Limit

Credit Assessment Credited Energy Volume by BMU Type

FPN Derived Credit Assessment Credited Energy Volume (MWh)

Non FPN Derived Credit Assessment Credited Energy Volume (MWh)

Account Energy Data (to BSC Party Only)

Energy Account Production/Consumption flag

Account Period CA Credited Energy Volume (MWh) (CAQCE_aj)

Account Period Energy Contract Volume (MWh) (QABC_aj)

Account Cumulative CA Credited Energy Volume* (MWh) (CCAQCE_aj)

Account Cumulative Energy Contract Volume* (MWh) (CQABC_aj)

Account Energy Data by BMU Type

FPN Derived Account Period CA Credited Energy Volume (MWh)

FPN Derived Account Cumulative CA Credited Energy Volume* (MWh)

Non FPN Derived Account Period CA Credited Energy Volume (MWh)

Non FPN Derived Account Cumulative CA Credited Energy Volume* (MWh)

Credit Limit Warning Data

BSC Party Id

BSC Party Name

Notes:

1. The “Day Start Indebtedness Data” group will contain cumulative figures for the 28 days up to (but not including) period 1 of the reported Settlement Day as follows:

a. the sum of available Actual Energy Indebtedness;

b. the sum of Credit Assessment Energy Indebtedness for Settlement Days where Actual Energy indebtedness is not available.

2. Data items are marked with a ‘*’ to indicate that they are a “cumulative” figure. That is, the value is aggregated over the 29 days up to and including the reported settlement period.

3. Data items are marked with "++" to indicate that they contain the Agent and Authorisation relevant to the party/agent receiving the report.

7.12 ECVAA-I018: Receive Acknowledgement

See Section 2.2.7.

7.13 ECVAA-I019: Issue Acknowledgement

See Section 2.2.7.

7.14 ECVAA-I022: (output) Forward Contract Report

The Forward Contract Report is sent only to BSC Parties.

Notes:

The report transaction number given on the forward contract report provides a means for determining whether a particular notification was received and processed prior to generation of the report.

When a notification is loaded, the transaction is allocated a transaction number.
The Report Transaction Number is the highest transaction which had been applied when the report snapshot view was taken
The ECVAA-I028 or ECVAA-I029 acceptance feedback flow (which is issued for notifications which are effective within 72 periods of loading) includes the transaction number.

Contract volumes/Reallocation volumes & percentages for Settlement Periods prior to the Report Start Period shall not be included in the report (where this excludes all volumes for a notification, that notification will not appear). The following examples cover the case of a report generated starting on date D when the Report Start Period is P:

Notification Start date	Notification End date	Notification Period Data	What is reported
D	D	Includes volume for at least one period >= P	Periods >= P
D	D	No volumes for periods >= P, at least one volume for a period < P	Notification not reported
<D	D	Includes volume for at least one period >= P	Periods >= P
<D	D	No volumes for periods >= P, at least one volume for a period < P	Notification not reported
>D	>D	Volume for at least one period	All periods
D	>D	Volume for at least one period	All periods
<D	>D	Volume for at least one period	All periods
Any	Any	No volume for any period	Notification not reported

For regular reports, Report Start Period will be the first period for which the Submission Deadline has not occurred at report generation time.

For ad hoc reports, the operator may explicitly specify the Report Start Period to allow a report to include data for periods for which the Gate has closed.

BSC Parties may override the default or operator-specified Report Start Period by issuing a Forward Contract Report Start Period Override to the ECVAA as described by ECVAA-I035. If an override has been requested then the report to the specified Party will include data for all periods on the current day regardless of whether the Gate has closed for that period, i.e. the Report Start Period will be 1.

Data is generally reported using the same Effective From/Effective To date ranges as submitted by the Notification Agent. The exceptions to this are¹⁶:

where Notifications are split into two (Current Date and Future),
where a Notifications Effective From Date is changed from a past day to the Current Date (i.e. the Applied From Date),
where a Notification is truncated by a subsequently received Notification.
where a Dual Notification is split to be consistent with date ranges submitted by a counterparty’s appointed agent.

These cases are described in the Notification processing in ECVAA-F005 and ECVAA-F006 and in Section 7.24.3 which describes detailed aspects of Notification Storage and Reporting.

Only matched data is reported in the Forward Contract Report. For Single Notifications however, data is automatically matched and will always be available for reporting.

Interface ID:

ECVAA-I022

User:

BSC Party

Title:

Forward Contract Report

BSC reference:

CR 051

CR 085

P4, CP725, CP877, P110

Mechanism:

Electronic Data File Transfer

Frequency:

Daily

Volumes:

Medium

Interface Requirement:

The ECVAA Service shall issue Forward Contract Reports to BSC Parties once a day to report each party’s contractual position for the current day and the next 7 days. This report shall be based on a snapshot time of 18:30. The flow will not include any notifications which were rejected on receipt, but will include notification data for the current day which has been rejected by the credit check process. All BSC parties will be sent a forward contract report, even if they are not a party to any notifications in the period. A report covering a longer date range can be requested by a Party following receipt of ECVAA-I039.

The Forward Contract Report shall comprise:

Report Start Date

Report End Date

Report Snapshot Time

Report Transaction Number

Report Start Period

Energy Account data:

Production/Consumption flag

Originator Energy Contract Volume Notification Agent Authorisation data:

ECVNAA ID*

ECVNA ID*

ECVNAA BSC Party Sequence

Other BSC Party ID

Other BSC Party P/C Flag

ECVNAA Effective From Date

ECVNAA Effective To Date (optional)

Energy Contract Volume Notification data:

ECVN ECVNAA ID

ECVN Reference Code

ECVN Effective From Date

ECVN Effective To Date (optional)

ECVNA ID* (null if authorisation same as Originator record)

ECVNAA ID* (null if authorisation same as Originator record)

ECVNAA Effective From Date (null if authorisation same as Originator record)

ECVNAA Effective To Date (null if authorisation same as Originator record)

Settlement Period From

Settlement Period To (null if Volume applies to single period)

Energy Contract Volume (to other party)

Originator Meter Volume Reallocation Notification Agent Authorisation data:

MVRNAA ID*

MVRNA ID*

BM Unit ID

Lead or Subsidiary Party indicator

Other BSC Party ID

Other BSC Party P/C Flag

MVRNAA Effective From

MVRNAA Effective To (optional)

Meter Volume Reallocation Notification data:

MVRN MVRNAA ID

MVRN Reference Code

MVRN Effective From Date

MVRN Effective To Date (optional)

MVRNA ID* (null if authorisation same as Originator record)

MVRNAA ID* (null if authorisation same as Originator record)

MVRNAA Effective From Date (null if authorisation same as Originator record)

MVRNAA Effective To Date (null if authorisation same as Originator record)

Settlement Period From

Settlement Period To (null if Volume/Percentage apply to single period)

Metered Volume Fixed Reallocation (to Subsidiary party)

Metered Volume Percentage Reallocation (to Subsidiary party)

*- Data as relevant to the BSC Party receiving the report.

location (to Subsidiary party)

7.15 ECVAA-I024: (input) Credit Cover Minimum Eligible Amount Request

Interface ID:

ECVAA-I024

Source:

BSC Party

Title:

Credit Cover Minimum Eligible Amount Request

BSC reference:

CP519

Mechanism:

Manual

Frequency:

Ad hoc

Volumes:

Low

Interface Requirement:

The ECVAA shall receive Credit Cover Minimum Eligible Amount Requests from BSC Parties on an ad hoc basis.

The Credit Cover Minimum Eligible Amount Request data shall comprise:

BSC Party ID

7.16 ECVAA-I025: (output) Credit Cover Minimum Eligible Amount Report

Interface ID:

ECVAA-I025

User:

BSC Party, FAA, BSCCo Ltd

Title:

Credit Cover Minimum Eligible Amount Report

BSC reference:

CP519, CP1313

Mechanism:

Manual

Frequency:

Ad hoc, in response to Credit Cover Minimum Eligible Amount Requests

Volumes:

Low

Interface Requirement:

The ECVAA shall issue Credit Cover Minimum Eligible Amount Reports to the BSCCo Ltd, FAA and BSC Parties in response to Credit Cover Minimum Eligible Amount Requests.

The Credit Cover Minimum Eligible Amount Report data shall comprise:

BSC Party ID

Waiting Period Start Date

Waiting Period End Date

Minimum Eligible Amount Rule (75% or 80%)

Maximum Indebtedness Settlement Day

Maximum Indebtedness Settlement Period (1-50)

Minimum Eligible Amount (MWh)

Note: the Waiting Period Start Date is the date of receipt of the Credit Cover Minimum Eligible Amount Request by the ECVAA.

7.17 ECVAA-I028: (output) ECVN Acceptance Feedback

Several variants of the ECVAA-I028 ECVN Acceptance Feedback Report are supported. The variant received depends on whether the recipient is the submitting ECVNA or associated Party and what reporting option has been selected (see ECVAA-F003).

All variants of the report have the same basic structure but may contain differing sets of optional fields and require alternative interpretation of particular fields. The contents of the report depend on reporting option selected for each ECVNA or Party for the associated ECVNAA. The reporting options are:¹⁷

1. No Feedback; in this case no feedback report is sent to the ECVNA or Party specified for any ECVN submitted under the ECVNAA.

2. Feedback (Acceptance only); if a potential recipient has specified this option, a feedback report is sent only if the recipient is the submitting ECVNA or associated Party. The report contains details of data accepted from the submitted ECVN only.

3. Feedback (Matching); if a potential recipient has specified this option, a feedback report is sent to them if they are the submitting ECVNA or associated Party with full details of the submitted ECVN and matching data. They will also receive a feedback report if they are the non-submitting ECVNA or associated Party. In the latter case the report will contain basic details of the latest processed ECVN for the associated counterparty and matching data. The variant is only available after the P98 BSC Implementation Date. The table below details what will be provided to each interested Party or Agent.

The feedback report is only generated if the notification start date is within the next 72 periods. The feedback report will contain all Settlement Periods (i.e. from period 1) in each reported Settlement Day.

The table below lists all fields that could be contained in the report and the expected content for each reporting option (1, 2 or 3 above) where the recipient is the submitter (submitting ECVNA or associated Party) or non-submitter (non- submitting ECVNA or associated Party). Note that for a Single Notification, the ECVNA and both Parties are associated with submission and their reports will be generated as shown in the “Submitter” columns in the table below.

		Submitter		Non-submitter
	Reporting option / Report Field	Match (option 3)	Acceptance (option 2)	Match* (option 3)	Acceptance (option 2)
Header	ECVN Data (Group)				No Report
	ECVNA ID	Submitting ECVNA	Submitting ECVNA	Non-submitting ECVNA
	ECVNAA ID	Submitter’s ECVNAA ID	Submitter’s ECVNAA ID	Not Reported
	ECVN ID Originator’s ECVNAA ID	ECVN ECVNAA ID	ECVN ECVNAA ID	ECVN ECVNAA ID
	ECVN ID Reference Code	ECVN Reference	ECVN Reference	ECVN Reference
	Effective From Date	Submitted Date	Submitted Date	Submitted Date**
	Effective To Date	Submitted Date	Submitted Date	Submitted Date**
	First Effective Period	Applied from Period	Applied from Period	Applied from Period**
	ECVN Filename	Submitted Filename	Submitted Filename	Last Filename from non-submitter
	ECVN File Sequence Number	Submitted File Seq Number	Submitted File Seq Number	Last File Seq Num from non-submitter
	ECVAA Transaction Number	Loaded Tx for Submitted File	Loaded Tx for Submitted File	Loaded Tx for Submitted File
Acc. Feedback	Accepted ECVN Period Data (Group)	Optional – only if period data submitted	Optional – only if period data submitted	Not Reported
	Settlement Period	Settlement Period	Settlement Period
	Energy Contract Volume	Volume	Volume
Matching / No-match Report	Matched Contract Dates (Group)		Not Reported
	Settlement Date	Dates started or starting in the next 72 periods		Dates started or starting in the next 72 periods
	Matched Contract Volumes (Group)
	Settlement Period	From Period 1 of Current Day		From Period 1 of Current Day
	Recipient Energy Contract Volume	Latest Volume from Submitter		Latest Volume from Non-Submitter
	Other Party Energy Contract Volume	Latest Volume from Non-Submitter		Latest Volume from Submitter
	Matched Energy Contract Volume	Latest Matched Volume		Latest Matched Volume

* - Note that, in this case, a match report will only be sent to the non-submitter if they have already had a corresponding ECVN processed, and the start date of that ECVN is within the next 72 periods. Any report generated before this point would have contained only the other ECVNAs latest, unmatched position.

In summary, the 3 possible report variants are:

Submitter / No match; the basic Acceptance Feedback Report with no matching.
Submitter / Match; full acceptance feedback with matching report.
Non-Submitter / Match; essentially just a matching report.

** - Data reported in these fields is as reported to the submitting ECVNA and their associated Party. This gives the non-submitter information on how the position held on behalf of the counter party and consequently the matched position may have changed.

Interface ID:

ECVAA-I028

User:

BSC Party, ECVNA

Title:

Energy Contract Volume Notification (ECVN) Acceptance Feedback

BSC reference:

P4, CP725, P98

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous, for accepted ECVNs

Volumes:

High

Interface Requirement:

The ECVAA Service shall issue Energy Contract Volume Notification Acceptance Feedback to the submitting ECVNA and the associated Party (or Parties ) continuously to report the acceptance of ECVNs where settlement period 1 of the effective from date on the ECVN starts within a parameterised 36 hours (72 settlement periods) of receipt of the ECVN.

Where a position has already been received from the non-submitting ECVNA, the ECVAA Service shall also issue Energy Contract Volume Notification (ECVN) Acceptance Feedback reports to the non-submitting ECVNA and their associated BSC Party continuously to report the matching of ECVN period data where settlement period 1 of the settlement date for which the match occurs starts within a parameterised 36 hours (72 settlement periods) of the match being made.

The ECVN Acceptance Feedback shall comprise:

Accepted Energy Contract Volume Notification:

ECVNA ID

ECVNAA ID (optional)

ECVN ID - Originator’s ECVNAA ID

ECVN ID - Reference Code

Effective From Date

Effective To Date (optional)

First Effective Period

ECVN Filename

ECVN File Sequence Number

ECVAA Transaction Number

Energy Contract Volumes (optional)

Settlement Period (1-50)

Energy Contract Volume (MWh)

Matched Contract Dates (optional)

only for settlement dates within 72 settlement periods of receipt of notification

Settlement Date

Matched Contract Volumes (optional)

Settlement Period (1-50)

Recipient Party Energy Contract Volume (MWh)

Other Party Energy Contract Volume (MWh)

Matched Energy Contract Volume (MWh)

Notes:

The acceptance feedback message echoes back the data sent in the ECVN (with the exception of the key) with the following additions or modifications:

Effective From Date: This will contain the Applied From Date. This will be the later of the Effective From Date received in the notification and the Current Date. The Current Date is the earliest Settlement Date for which at least one Settlement Period has not passed the Submission Deadline at the time the ECVAA receives the notification.

First Effective Period: This will be set to the number of the first settlement period on the Applied From Date of the ECVN for which the Submission Deadline had not passed at the time of receipt of the ECVN. This value provides an indication of any period data in the ECVN which may have been ignored because the ECVN arrived after the Submission Deadline for some periods. The notification has been applied starting with <first effective period> on the <effective from date> reported here.

ECVAA Transaction Number: This value is the transaction number under which the ECVN was loaded. This can be compared to the transaction number provided in the Forward Contract Report to determine if an ECVN is included in the report. The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications from a single Agent have sequence numbers which follow the same order as the transaction numbers which they contain.

Where the recipient is the submitter of the ECVN triggering this report, the ECVNA Id and ECVNAA Id are those of the Agent associated with the recipient of the report. Where the recipient is the non-submitter, the ECVNAA Id is always null.

The Matched Contract Dates group will be reported for any Settlement Date where Settlement Period 1 of that date starts within a parameterised 36 hours (72 settlement periods) of receipt of the ECVN.

The Matched Contract Volumes group contains the latest received Energy Contract Volume for each Party from their nominated ECVNA and the latest matched Energy Contract Volume. Matched data is reported from Settlement Period 1 of the first day covered by the Notification, but only Settlement Periods for which an ECVNA has submitted data will be reported. The sign of matched volume values is consistent with that in the received ECVNs.

The ECVNA or BSC Party will only receive an Energy Contract Volume Notification Acceptance Feedback if they have opted to receive them in their Reporting Options (see ECVAA-F003) for the associated ECVNAA. Furthermore, the matched group will be reported only if the recipient has selected matched data in their Reporting Options

7.18 ECVAA-I029: (output) MVRN Acceptance Feedback

Several variants of the ECVAA-I029 MVRN Acceptance Feedback Report are supported. The variant received depends on whether the recipient is the submitting MVRNA or associated Party and what reporting option has been selected (see ECVAA-F004).

All variants of the report have the same basic structure but may contain differing sets of optional fields and require alternative interpretation of particular fields. The contents of the report depend on reporting option selected for each MVRNA or Party for the associated MVRNAA. The reporting options are:¹⁸

1. No Feedback; in this case no feedback report is sent to the MVRNA or Party specified for any MVRN submitted under the MVRNAA.

2. Feedback (Acceptance Only); if a potential recipient has specified this option, a feedback report is sent only if the recipient is the submitting MVRNA or associated Party. The report contains details of the submitted MVRN and no matching data.

3. Feedback (Matching); if a potential recipient has specified this option, a feedback report is sent them if they are the submitting MVRNA or associated Party with full details of the submitted MVRN and matching data. They will also receive a feedback report if they are the non-submitting MVRNA or associated Party. In the latter case the report will contain basic details of the latest processed MVRN for the associated counterparty and matching data. The variant is only available after the P98 Implementation Date. The table below details what will be provided to each interested Party or Agent.

The table below lists all fields that could be contained in the report and the expected content for each reporting option (1, 2 or 3 above) where the recipient is the submitter (submitting MVRNA or associated Party) or non-submitter (non- submitting MVRNA or associated Party). Note that for a Single Notification, the MVRNA and both Parties are associated with submission and their reports will be generated as shown in the “Submitter” columns in the table below.

		Submitter		Non-submitter
	Reporting option / Report Field	Match (option 3)	Acceptance (option 2)	Match* (option 3)	Acceptance (option 2)
Header	MVRN Data (Group)				No Report
	MVRNA ID	Submitting MVRNA	Submitting MVRNA	Non-submitting MVRNA
	MVRNAA ID	Submitter’s MVRNAA ID	Submitter’s MVRNAA ID	Not Reported
	MVRN ID Originator’s MVRNAA ID	MVRN MVRNAA ID	MVRN MVRNAA ID	MVRN MVRNAA ID
	MVRN ID Reference Code	MVRN Reference	MVRN Reference	MVRN Reference
	Effective From Date	Submitted Date	Submitted Date	Submitted Date**
	Effective To Date	Submitted Date	Submitted Date	Submitted Date**
	First Effective Period	Applied from Period	Applied from Period	Applied from Period**
	MVRN Filename	Submitted Filename	Submitted Filename	Last Filename from non-submitter
	MVRN File Sequence Number	Submitted File Seq Number	Submitted File Seq Number	Last File Seq Num from non-submitter
	MVRAA Transaction Number	Loaded Tx for Submitted File	Loaded Tx for Submitted File	Loaded Tx for Submitted File
Acc. Feedback	Accepted MVRN Period Data (Group)	Optional – only if period data submitted	Optional – only if period data submitted	Not Reported
	Settlement Period	Settlement Period	Settlement Period
	Meter Volume Fixed Reallocation	Volume	Volume
	Meter Volume Percentage Reallocation	Percentage	Percentage
Matching /No Match Report	Matched Reallocation Dates (Group)		Not Reported
	Settlement Date	Dates started or starting in the next 72 periods		Dates started or starting in the next 72 periods
	Matched Reallocations (Group)
	Settlement Period	From Period 1 of Current Day		From Period 1 of Current Day
	Recipient Metered Volume Fixed Reallocation	Latest Volume from Submitter		Latest Volume from Non-Submitter
	Recipient Metered Volume Percentage Reallocation	Latest Percentage from Submitter		Latest Percentage from Non-Submitter
	Other Party Metered Volume Percentage Reallocation	Latest Volume from Non-Submitter		Latest Volume from Submitter
	Other Party Metered Volume Percentage Reallocation	Latest Percentage from Non-submitter		Latest Percentage from Submitter
	Matched Metered Volume Percentage Reallocation	Latest Matched Volume		Latest Matched Volume
	Matched Metered Volume Percentage Reallocation	Latest Matched Percentage		Latest Matched Percentage

* - Note that, in this case, a match report will only be sent to the non-submitter if they have already had a corresponding MVRN processed, and the start date of that MVRN is within the next 72 periods. Any report generated before this point would have contained only the other MVRNA’s latest, unmatched position.

In summary, the 3 possible report variants are:

Submitter / No match; the basic Acceptance Feedback Report with no matching.
Submitter / Match; full acceptance feedback with matching report.
Non-Submitter / Match; essentially just a matching report.

** - Data reported in these fields is as reported to the submitting MVRNA and their associated Party. This gives the non-submitter information on how the position held on behalf of the counter party and consequently the matched position may have changed.

Interface ID:

ECVAA-I029

User:

BSC Party, MVRNA

Title:

Meter Volume Reallocation Notification (MVRN) Acceptance Feedback

BSC reference:

P4, CP725, P98

Mechanism:

Electronic Data File Transfer

Frequency:

Continuous, for accepted MVRNs

Volumes:

Medium

Interface Requirement:

The ECVAA Service shall issue Meter Volume Reallocation Notification Acceptance Feedback to the submitting MVRNA and the associated Party (or Parties) continuously to report the acceptance of MVRNs where settlement period 1 of the effective from date on the MVRN starts within a parameterised 36 hours (72 settlement periods) of receipt of the MVRN.

Where a position has already been received from the non-submitting MVRNA, the ECVAA Service shall also issue Meter Volume Reallocation Notification Acceptance Feedback reports to the non-submitting MVRNA and their associated BSC Party continuously to report the matching of MVRNs where settlement period 1 of the settlement date for which the match occurs starts within a parameterised 36 hours (72 settlement periods) of the match being made.

The Meter Volume Reallocation Notification Acceptance Feedback shall comprise:

Accepted Meter Volume Reallocation Notification:

MVRNA ID

MVRNAA ID (optional)

MVRN ID - Originator’s MVRNAA ID

MVRN ID - Reference Code

Effective From Date

Effective To Date (optional)

First Effective Period

MVRN Filename

MVRN File Sequence Number

ECVAA Transaction Number

MVR Reallocations (optional)

Settlement Period (1-50)

Metered Volume Fixed Reallocation (MWh)

Metered Volume Percentage Reallocation (%)

Matched Reallocation Dates (optional)

only for settlement dates within 72 settlement periods of receipt of matching notification

Settlement Date

Matched Reallocations (optional)

Settlement Period (1-50)

Recipient Metered Volume Fixed Reallocation (MWh)

Recipient Metered Volume Percentage Reallocation (%)

Other Party Metered Volume Fixed Reallocation (MWh)

Other Party Metered Volume Percentage Reallocation (%)

Matched Metered Volume Fixed Reallocation (MWh)

Matched Metered Volume Percentage Reallocation (%)

Notes:

The acceptance feedback message echoes back the data sent in the MVRN (with the exception of the key) with the following additions or modifications:

First Effective Period: This will be set to the number of the first settlement period on the Applied From Date of the MVRN for which the Submission Deadline had not passed at the time of receipt of the MVRN. The notification has been applied starting with <first effective period> on the <effective from date> reported here.

ECVAA Transaction Number: This value is the transaction number under which the MVRN was loaded. This can be compared to the transaction number provided in the Forward Contract Report to determine if an MVRN is included in the report. The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications from a single Agent have sequence numbers which follow the same order as the transaction numbers which they contain.

Where the recipient is the submitter of the MVRN triggering this report, the MVRNA Id and MVRNAA Id are those of the Agent associated with the recipient of the report. Where the recipient is the non-submitter, the MVRNAA Id is always null.

The Matched Reallocation Dates group will be reported for any Settlement Date where Settlement Period 1 of that date starts within a parameterised 36 hours (72 settlement periods) of receipt of the MVRN.

The Matched Reallocations group contains the latest received Metered Volume Reallocation for each Party from their nominated MVRNA and the latest matched Metered Volume Reallocation. Matched data is reported from Settlement Period 1 of the first day covered by the Notification, but only Settlement Periods for which a MVRNA has submitted data will be reported. The sign of matched volume values is consistent with that in the received MVRNs.

The MVRNA or BSC Party will only receive a Meter Volume Reallocation Notification Acceptance Feedback if they have opted to receive them in their Reporting Options (see ECVAA-F004) for the associated MVRNAA. Furthermore, the matched and unmatched groups will be reported only if the recipient has selected matched data in their Reporting Options.

7.19 Forward Contract Report Start Period Override

Interface ID:

ECVAA-I035

User:

BSC Party, ECVNA, MVRNA

Title:

Forward Contract Report Start Period Override

BSC reference:

P4, P17, CP877

Mechanism:

Manual

Frequency:

As required

Volumes:

Low

Interface Requirement:

The ECVAA Service shall receive Forward Contract Report Start Period Override requests from BSC Parties as required.

The Forward Contract Report Start Period Override request shall comprise:

Participant Id

Participant Name

Override Default Report Start Period (Y or N)

Notes:

i. The default Report Start Period for the Forward Contract Report (see ECVAA-I022: Issue Forward Contract Report) will be the first period for which the Submission Deadline has not occurred at report generation time.

ii. To override this default a participant should submit a request to the ECVAA with an Override Default Report Start Period value of Y.

iii. To cancel a previous override request, i.e. to revert to the default, a participant should submit a request to the ECVAA with an Override Default Report Start Period value of N.

iv. The override or cancellation request takes affect for all reports issued after the request has been processed by the ECVAA.

7.20 ECVAA-I021: (output) Credit Limit Warning

Interface ID:

ECVAA-I021

User:

BSC Party, BSCCo Ltd

Title:

Credit Limit Warning

BSC reference:

CR 12, CP703

Mechanism:

Manual

Frequency:

Ad hoc, when credit usage at warning level

Volumes:

Interface Requirement:

The ECVAA Service shall issue a Credit Limit Warning to BSCCo Ltd and the relevant BSC Party on an ad hoc basis, when a BSC Party’s credit usage reaches warning level.

The Party Credit Limit Warning shall comprise:

Credit Limit Warning

BSC Party Id

BSC Party Name

Credit Cover Percentage (%)

Credit Limit (MWh)

7.21 ECVAA-I037: (input) Receive Volume Notification Nullification Request

Interface ID:

ECVAA-I037

Source:

BSC Party

Title:

Receive Volume Notification Nullification Request (VNNR)

BSC reference:

P110

Mechanism:

Manual

Frequency:

Ad hoc

Volumes:

Low

Interface Requirement:

The ECVAA Service shall receive VNNR data from BSC Parties as required. Each request shall provide the name, password and signature of an appropriate Authorised Signatory.

The VNNR data shall comprise:

Party ID

Party Name

Party Energy Account Production/Consumption Flag

Party Contact Email Address

Party Contact Telephone No.

Counter-Party ID

Counter-Party Name

Counter-Party Energy Account Production/Consumption Flag

Requested Nullification Effective Date and Period

Associated Authorisation Termination Indicator

Party VNNR Reference

Amendment Flag

Note: The Associated Authorisation Termination Indicator is used to inform the ECVAA that there are Authorisation Termination Requests associated with this VNNR, and that these should be processed prior to processing the VNNR.

Physical Interface Issues:

7.22 ECVAA-I038: (output) Issue Volume Notification Nullification Confirmation Report

Interface ID:

ECVAA-I038

User:

BSC Party

Title:

Issue Volume Notification Nullification Confirmation Report (VNNCR)

BSC reference:

P110 CP1169

Mechanism:

Manual - via email

Frequency:

As Required

Volumes:

Low

Interface Requirement:

The ECVAA Service shall issue VNNCRs in the following circumstances:

i. To confirm an accepted VNNR - issued to both the requesting party and counter-party

ii. In response to a received BSC Panel authorised Section H Volume Notification Nullification – issued to both Parties to the nullified Notification.

iii. To confirm a rejected VNNR - issued to the requesting party only, in response to a BSC Party raised VNNR.

The VNNCR shall comprise:

Party ID

Party Name

Party Energy Account Production/Consumption Flag

Counter-Party ID

Counter-Party Name

Counter-Party Energy Account Production/Consumption Flag

Nullification Effective Date and Period (if VNNR is accepted)

Party VNNR Reference or the words ‘SECTION H’ in the case of a BSC Panel authorised Volume Notification Nullifications for a Section H Default.

ECVAA Reference

Acceptance / Rejection Flag

Rejection Reason (if VNNR is rejected)

Rejection Details (if VNNR is rejected)

Physical Interface Details:

Rejection Details may include, for example, a list of outstanding authorisations.

VNNCRs shall be issued as emails during Business Hours only, where for the purposes of this requirement, Business Hours are defined as 9am-5pm on a Business Day. Furthermore, the ECVAA Service shall issue VNNCRs within 1 hour from receipt of the associated Volume Notification Nullification, where the hour is measured only during Business Hours. On receipt of a valid amendment VNNR from a Party, the hour will be re-started from the time of receipt of the amendment.

The ECVAA operator shall inform the requesting Party and Counter-Party by telephone that a VNNCR has been issued. Failure to make telephone contact with either the requesting Party or Counter-Party will not delay nullification processing.

7.23 ECVAA-I039: (output) Issue Nullification Completion Report

Interface ID:

ECVAA-I039

User:

BSC Party

Title:

Issue Nullification Completion Report

BSC reference:

P110 CP1169

Mechanism:

Manual - via email

Frequency:

As required

Volumes:

Low

Interface Requirement:

The ECVAA Service shall issue a Nullification Completion Report to BSC Parties.

The Nullification Completion Report shall comprise:

Party ID

Party Name

Party Energy Account Production/Consumption Flag

Counter-Party ID

Counter-Party Name

Counter-Party Energy Account Production/Consumption Flag

Nullification Effective Date and Period

Party VNNR Reference or the words ‘SECTION H’ in the case of a BSC Panel authorised Volume Notification Nullifications for a Section H Default.

ECVAA Reference

Completion date and time (GMT)

Physical Interface Details:

The ECVAA systems shall generate and send the Nullification Completion Report as emails.

7.24 Additional Clarification on ECVAA Interfaces

7.24.1 Sign Convention

This section clarifies the notes given in the spreadsheets regarding the sign conventions used for Energy Contract Volume Notifications (ECVAA-I004) and the reporting of this data in the subsequent Notification Reports (ECVAA-I014) and Forward Contract Reports (ECVAA-I022). The table below details the Sign Convention where Party 1 is selling and Party 2 is buying and then vice versa.

Party	Buying / Selling	I004	I014	I022
1	Selling	Positive	Positive	Positive
2	Buying	Positive	Positive	Negative
1	Buying	Negative	Negative	Negative
2	Selling	Negative	Negative	Positive

In summary the ECVAA-I004 flows and ECVAA-I014 reports always use the sign relative to Party 1, but the ECVAA-I022 report uses the sign specific to the Party who is receiving the report.

7.24.2 Notes on functionality

The following text is provided for additional clarification. It is included in the IDD for convenience. However, this information is outside the scope of the IDD and the IDD is not the definitive location for such functional detail. For definitive information on functionality, the reader is referred to the ECVAA URS, and in the event of inconsistency between the text here and the URS, it is the URS that prevails.

This section explains how the ECVN interface is used, with examples.

ECVN Ids:

1) Each Notification (ECVN) will include the ECVNA Id (in the header record), ECVNAA Id, ECVNAA Key, and ECVN Id (ECVNAA Id + reference code).

2) The ECVNAA Id exists twice in each Notification - once to determine the Agent and Parties to this Notification, and then again within the ECVN Id to enable the uniqueness of a Notification for a given pair of trading Parties.

3) The ECVN Id is unique across all Agents. It is a combination of 2 attributes - the ECVNAA Id of the Agent, followed by a reference code.

4) The ECVNAA Id within the ECVN Id has restrictions applied to it. It must either be the ECVNAA Id of the Agent submitting the ECVN, or the ECVNAA Id of an Agent whose ECVNAA has now expired and who once submitted ECVNs for the same pair of trading Parties.

5) The reference code should be unique within an ECVNAA Id to ensure that the ECVN Id is unique and is hence processed as an Additional Notification. If the reference code is not unique within the ECVNAA Id then the ECVN will be processed as a Replacement Notification.

6) Where the ECVN Amendment Type is set to ‘Additional’ or ‘Replacement’, the ECVAA shall reject any notifications that do not follow the appropriate conventions as described in 5) above. For example, if an ECVN is submitted with a unique reference code within an ECVNAA Id, implying that an Additional Notification is intended, and the ECVN Amendment Type is set to ‘Replacement’, the ECVAA shall reject the notification.

EXAMPLE:

Consider trading relationships between Party A and Party B, and Party B and Party C.

Party A and B use both ECVNA1 and ECVNA2 (ECVNAA Id 101 and ECVNAA Id 102)

Party B and C use ECVNA1 (ECVNAA Id 103)

Notification

Here ‘ECV’ followed by a 6 character integer is being used as the reference code.

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000001 is an Additional notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000001 is an Additional notification for Party A and B

- Agent ECVNA1, ECVNAA Id 103, ECVN Id 103 ECV000001 is an Additional notification for Party B and C

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000002 is an Additional notification for Party A and B

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000001 is a Replacement notification for Party A and B

- Agent ECVNA2, ECVNAA Id 101, ECVN Id 101 ECV000001 is rejected as ECVNAA Id 101 belongs to another active Agent

The Parties are responsible for ensuring their other agents are able to maintain their Notifications. If ECVNAA Id 101 is then terminated (i.e. Agent ECVNA1 no longer acts on behalf of Parties A and B), then the Parties must inform another agent of their Notifications. The following Notification could then be submitted:

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 101 ECV000001 is a Replacement notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000002 is an Additional notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000002 is a Replacement notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 101 ECV000005 is rejected as this does not exist to be overwritten

7.24.3 Notes on Notification Processing and Reporting

In general Notifications are stored (and reported in the ECVAA-I022) using the same date range as Notified. There are some exceptions to this, and this section describes the circumstances. This processing applies equally to ECVNs and MVRNs.

Note that the Current Date is the earliest date for which not all Settlement Periods in the day have passed the Submission Deadline and the Applied From Date (as reported in the ECVAA-I028/ECVAA-I029) is the later of the Current Date and the Effective From Date in a received Notification.

Data for the Current Date is never changed for those periods where the Submission Deadline has already passed.

To determine the date range(s) stored (and reported):

If Effective From = Effective To, the Notification will be stored as received (Multi‑Day flag = "S").
Otherwise (the Notification spans multiple dates):

For Notification with Effective From Date > Current Date: the Notification will be stored as received (Multi‑Day flag = "M")
Otherwise (For a Notification with Applied From Date = Current Date):

If there is an exact match between the Notification and the data already held by ECVAA for the notification (including the case where there is currently no data on the database) for all periods for which the Submission Deadline has passed, then the Notification is stored as a single date range from the Applied From Date to the specified Effective To Date (Multi‑Day flag = "M").
Otherwise, the Notification is stored as two records, a single day for the Current Date (Multi‑Day flag = "M" unless Current Date is a Clock Change Day, in which case the Periods are converted to 46/50 period day and Multi‑Day = "S") and the remainder from Current Date+1 to specified Effective To Date (Multi‑Day flag = "M")

The following table shows how Notifications are stored (and subsequently reported) in various scenarios. Note that the “Multi‑Day” flag is not reported, but is shown here for clarity.

From ECVN/MRVN			As stored on the database
Notification Start date	Notification End date	Ref / Notes	Multi-Day Flag	Effective From date	Effective To Date	Period Data
Current Date	Current Date	A	S	Current Date	Current Date	As held pre-Submission Deadline, as notification after the Submission Deadline
Future Date	Future Date	B	S	Future Date	Future Date	As notification
Future Date	Future Date + n (>0)	C	M	Future Date	Future Date + n (>0)	As notification
Past Date or Current Date	Future Date	D**	S	Current Date	Current Date	As held pre-Submission Deadline, as notification after the Submission Deadline
			M	Current Date + 1	Future Date	As notification
		E*	M	Current Date	Future Date	As notification
Past Date	Current Date	F**	S	Current Date	Current Date	As held pre-Submission Deadline, as notification after the Submission Deadline
Past Date	Current Date	G*	M	Current Date	Current Date	As notification

* - Only where period data exactly matches previously held pre-Submission Deadline period data for Current Date and the Current Date is not a clock change day.

** - Where period data does not exactly match previously held pre-Submission Deadline data for the Current Date, or the Current Date is a clock change day. In these cases, the Current Date part will be mapped into a clock change day (46/50 periods) if appropriate.

An existing Multi‑Day Notification which starts before and ends on or after the Applied From Date of a received Notification which replaces it will have its Effective To date set to Applied From Date minus one. the “Multi‑Day” flag will remain “M”. For example,

an existing notification with Effective From Date D and Effective To Date D+5 is overwritten by a Notification with Applied From Date D+3; here the existing Notification’s Effective To Date is set to D+2, with the new Notification starting at D+3.
an existing notification with Effective From Date D and Effective To Date D+5 is overwritten by a Notification Applied From Date D+1; here the existing Notification’s Effective To Date is set to D, with the new Notification starting at D+1.

Note that in this second example, if D is a clock change day, the data will be correctly converted from 48 to 46/50 periods due to the Multi‑Day flag being set to “M”

Any Notifications stored with a single day range and the “Multi‑Day” flag set to “M” are processed by the ECVAA-I022 Forward Contract Report such that the reported data is mapped into a clock change day (46/50 periods) if appropriate.

The following examples illustrate some of these scenarios and how received Notification data is reported in the ECVAA-I022 report; in each case the current date is the 29^th March 2003, and the 30^th March 2003 is a short clock change day. In each case the “Ref” refers to the table above, but it is not intended that every case should be covered:

7.24.3.1 Multi‑Day Notification Received in-day before a Clock Change (Ref D)

Received as:

Effective From Date: 26^th March 2003

Effective To Date: 30^th March 2003

Period Data: 48 Periods

Reported as:

Effective From Date: 29^th March 2003 (note the Applied From Date is Current Date)

Effective To Date: 29^th March 2003

Period Data: 48 Periods; 0 up to the Submission Deadline, as received after that

Effective From Date: 30^th March 2003

Effective To Date: 30^th March 2003

Period Data: 46 Periods; 1,2,5-48 mapped to short clock change day Periods 1-46 (stored as 48 periods with Multi-Day flag set to “M”)

7.24.3.2 Multi‑Day Notification Received in-day before a Clock Change (Replacement Notification received in 7.24.3.1) (Ref E)

Received as:

Effective From Date: 26^th March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods (data same as 7.24.3.1 up to the Submission Deadline)

Reported as:

Effective From Date: 29^th March 2003 (note the Applied From Date is Current Date)

Effective To Date: NULL

Period Data: 48 Periods as received in 7.24.3.2.

7.24.3.3 Future Multi‑Day Notification starting on Clock Change day (Ref C)

Received as:

Effective From Date: 30^th March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods

Reported as:

Effective From Date: 30^th March 2003

Effective To Date: NULL

Period Data: 48 Periods as received

7.24.3.4 Future Multi‑Day Notification (Replacement Notification received in 7.24.3.3) (Ref C)

Received as:

Effective From Date: 31^st March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods

Reported as:

Effective From Date: 30^th March 2003

Effective To Date: 30^th March 2003

Period Data: 46 Periods; 1,2,5-48 as received in 7.24.3.3, but mapped to short clock change day Periods 1-46 (stored as 48 periods with Multi-Day flag set to “M”)

Effective From Date: 31^st March 2003

Effective To Date: NULL

Period Data: 48 Periods as received in 7.24.3.4

7.25 ECVAA-I042: Banning/Unbannimg Individual User Access to the ECVAA Web Service

Interface ID:

ECVAA-I042

User:

BSC Party

ECVNA

MVRNA

Title:

Banning/Unbanning Individual User Access to the ECVAA Web Service

BSC reference:

P98

Mechanism:

Manual

Frequency:

As Required

Volumes:

Low

Interface Requirement:

The ECVAA Service shall receive and action, from time to time, requests to ban and unban specific credentials files.

This flow is composed of;

Participant Name

Credentials File ID

Participant Role

Party or Party Agent ID

Name of Sender

Contact email address

Sender reference

Contact Tel. No

Action required

Other details.

Where a participant is unable to ban / un-ban one of its users itself, then the Participant may submit a I042 form requesting that the ECVAA ban or unban a specific credentials file. Such a request must be sanctioned by a category ‘Z’ signatory. This manual process is available only within business hours.

7.26 ECVAA-I043: ECVAA Web Service – BSC Party View ECVNs

Interface ID:

ECVAA-I043

Status:

Mandatory

Title:

ECVAA Web Service – BSC Party View ECVNs

BSC reference:

P98

Mechanism:

Automatic

Frequency:

As Required

Volumes:

Low

1. Common Page items.

All pages shall display the following;

The BSC Party name of the logged in BSC Party;

The role of the logged in BSC Party;

The username of the logged in user;

Date and time of the last data refresh;

2. ECVN Position Page (Home page).

This page shall display two tables, one for the logged in BSC Party’s Production Account and the second for the logged in party’s Consumption Account. Each table shall display the following data:

For each counterparty by matching window date;

Counterparty Name;

Counterparty Account (P or C – Production or Consumption);

Total net matched position for each day in the matching window;

Totals for the total net matched positions (above) for each day in the matching window.

The following information shall be made available for the latest transaction for the Party:

Latest transaction Number

ECVNAA ID / ECVN reference code

Counterparty ID

Effective From Date

Effective To Date

This information is for the latest ECVN processed and may not directly relate to other data displayed.

3. ECVN Party / Counterparty Summary Page

This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page.

The table shall display the following data:

Settlement Day

Counterparty Name

Counterparty Account (P or C –Production or Consumption)

ECVN reference

Notification Type (D or S – dual or single notification)

Logged in BSC Party Volume (MWh)

Counterparty Volume (MWh)

Matched Volume (MWh)

4. ECVN Party / Settlement Day Summary Page

This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page.

The table shall display the following data:

Settlement Day

Counterparty Name

Counterparty Account (P or C –Production or Consumption)

ECVN reference

Notification Type (D or S – dual or single notification)

Logged in BSC Party Volume (MWh)

Counterparty Volume (MWh)

Matched Volume (MWh)

A total for each Counterparty’s matched volume (MWh)

5. ECVN Party / Settlement Period Summary Page

This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page.

The table shall display the following data:

Counterparty Name

Counterparty Account (P or C –Production or Consumption)

Settlement Period

Logged in BSC Party Volume (MWh)

Counterparty Volume (MWh)

Matched Volume (MWh)

6. ECVN Detail Viewer Page

This page shall display a single table for the logged in BSC Party for an individual notification for a single Settlement Date.

The table shall display the following data:

Settlement Period

Logged in BSC Party Volume (MWh)

Counterparty Volume (MWh)

Matched Volume (MWh)

This page will also display the following data about the notification displayed;

Authorisation ID

Authorisation Effective From

Authorisation Effective To

Notification Reference Code

Settlement Date

Party 1Name

Account

Agent Name

Party 2 Name

Account

Agent Name

Latest transaction panel will be displayed;

Logged in Party Name

Latest Transaction Number

Logged in Party’s Agents Name

Logged in Party’s Account

Latest Web Sequence Number

Latest File Sequence Number

Counterparty Name

Counterparty’s Agents Name

Counterparty’s Account

7.27 ECVAA-I044: ECVAA Web Service – BSC Party View MVRNs

Interface ID:

ECVAA-I044

Status:

Mandatory

Title:

ECVAA Web Service – BSC Party View MVRNs

BSC reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low

1. Common Page items.

All pages will display the following;

The Party name of the logged in BSC Party;

The role of the logged in BSC Party;

The username of the logged in user;

Date and time of the last data refresh;

2. BSC Party MVRNAA Selection Page

This page shall display a single table displaying each authorisation that the logged in BSC Party is a party to.

The table shall display the following data:

Authorisation Id

Type (D or S – dual or single notification)

BM Unit ID

Lead Party Name

Lead Account (P or C –production or consumption)

Lead Agent Name

Subsidiary Party

Subsidiary Party Account (P or C –production or consumption)

Subsidiary Agent Name

Effective from

Effective to

Notification Count

3. BSC Party MVRN Selection Page

For the single Authorisation selected in the BSC Party MVRNA Authorisations view.

This page shall display two tables for the logged in BSC Party.

The first table shall display the following data:

Authorisation Id

Type (D or S – dual or single notification)

BM Unit ID

Lead Party Name

Lead Account (P or C –production or consumption)

Lead Agent Name

Subsidiary Party

Sub Account (P or C –production or consumption)

Subsidiary Agent Name

Effective from

Effective to

For the authorisation detailed in the first table, the second table will display the following Notification information;

Settlement Date

Reference Code

4. BSC Party MVRN Detail Page

This page shall display the following details about the MVRN Notification selected from the BSC Party MVR Notification Page;

Authorisation Id

BM Unit ID

Reference Code

Notification Effective from

Notification Effective To

Lead Party Name

Subsidiary Party Name

Lead Party Agent Name

Subsidiary Party Agent Name

For these Notification Details, the page shall display the following data in a tabular format;

Settlement Period

Lead Party Percentage Reallocation

Subsidiary Party Percentage Reallocation

Matched Percentage Reallocation

Lead Party Fixed Reallocation

Subsidiary Party Fixed Reallocation

Matched Fixed Reallocation

Latest transaction panel will be displayed;

Logged in Party Name

Latest Transaction Number

Logged in Party’s Agents Name

Logged in Party’s Account

Latest Web Sequence Number

Latest File Sequence Number

Counterparty Name

Counterparty’s Agents Name

Counterparty’s Account

7.28 7ECVAA-I045: ECVAA Web Service – ECVNA View ECVNs.

Interface ID:

ECVAA-I045

Status:

Mandatory

Title:

ECVAA Web Service - ECVNA View ECVNs.

BSC reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low.

1. Common Page items.

All pages shall display the following;

The Agent name of the logged in Agent;

The role of the logged in Agent;

The username of the logged in user;

Date and time of the last data refresh;

The BSC Party Name of the BSC Party selected by the user to represent;

2. BSC Party and ECVNAA Selection Page

This page shall allow the logged in agent to select the BSC Party to represent from a list of parties that the agent has a current authorisation under.

This page shall display a single table for the logged in Agent.

For each authorisation that the logged in Agent is a appointed for, filtered by the BSC party selected, the table shall display the following data:

Authorisation Id

Type (D or S – dual or single notification)

Party 1 Name

Party 1 Account (P or C –production or consumption)

Party 1 Agent Name

Party 2 Name

Party 2 Account (P or C –production or consumption)

Party 2 Agent name

Effective from

Effective to

Notification Count

3. ECVN Selection Page

For the single Authorisation selected in the ECVNAA page, this page shall display two tables for the logged in Agent. The first table shall display the following data;

Authorisation Id

Type (D or S – dual or single notification)

Party 1 Name

Party 1 Account (P or C –production or consumption)

Party 1 Agent Name

Party 2 Name

Party 2 Account (P or C –production or consumption)

Party 2 Agent Name

Effective from

Effective to

For the Authorisation detailed in the first table, the second table shall display the following Notification information;

Settlement Date

Reference Code

Party 1 Volume (MWh)

Party 2 Volume (MWh)

Matched Volume (MWh)

4. ECVN Editor Page

This page shall display the following details about the ECVN selected from the ECVN Page;

Field	State
Authorisation Id	Non-editable, from the ECVN Selection Page.
Reference Code		Blank For new notifications or Non-editable values from the ECVN Selection Page for own submission edits and counterparty copies.
Notification Effective from*		Blank For new notifications or editable values from the ECVN Selection Page for own submission edits and counterparty copies.
Notification Effective To*		Blank For new notifications or editable values from the ECVN Selection Page for own submission edits and counterparty copies.
Party 1 Name		Non-editable, from the ECVN Selection Page.
Party 2 name		Non-editable, from the ECVN Selection Page.
Party 1 Agent Name		Non-editable, from the ECVN Selection Page.
Party 2 Agent name		Non-editable, from the ECVN Selection Page.

*Dates as notified by the submitting ECVNAA(s), subject to the storage and reporting requirements described in section 5.16

For these Notification Details, the page shall display the following data in a tabular format;

Field	State
Settlement Period	Non-editable, period numbers.
Party 1 volume	Non-editable, Party 1 current submission for each period.
Party 2 volume	Non-editable, Party 2 current submission for each period.
Matched volume	Non-editable, current matched submission for each period.
Submission volume	Editable, blank for new submissions, populated with users existing values for own submission edits, populated with Counterparties values for copy Counterparty edits.

The latest transaction panel will be displayed;

Logged in Agents Party Name

Latest Transaction Number

Logged in Agent’s Name

Logged in Agent’s Party’s Account

Latest Web Sequence Number

Latest File Sequence Number

Counterparty Name

Counterparty’s Agents Name

Counterparty’s Account

5. ECVAA Notification Submission/Confirmation Page

The Confirmation page shall contain the following information:

Reference Code	ECV Notification Reference Code
Submission date and time	Blank before confirmation
Sequence Number	The Web submission Sequence Number
Effective from	Notification Start Date
Effective to	Notification End Date [May be NULL]
Submission Volume for Period [x]	Period Volume [One line for each period]

7.29 ECVAA-I046: ECVAA Web Service – MVRNA View MVRNs.

Interface ID:

ECVAA-I046

Status:

Mandatory

Title:

ECVAA Web Service – MVRNA View MVRNs

BSC reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low

1. Common Page items.

All pages shall display the following;

The Agent name of the logged in Agent;

The role of the logged in Agent;

The username of the logged in user;

Date and time of the last data refresh;

The BSC Party Name of the BSC Party selected by the user to represent;

2. BSC Party and MVRNAA Selection Page

This page shall allow the logged in agent to select the BSC Party to represent from a list of parties that the agent has a current authorisation under.

This page shall display a single table for the logged in Agent.

For each authorisation that the logged in Agent is a appointed for, filtered by the selected BSC Party, the table shall display the following data:

Authorisation Id

Type (D or S – dual or single notification)

BM Unit Id

Lead Party Name

Lead Party Account (P or C –production or consumption)

Lead Party Agent Name

Subsidiary Party name

Subsidiary Party Account (P or C –production or consumption)

Subsidiary Party Agent name

Effective from

Effective to

Notification Count

3. MVRN Selection Page

For the single Authorisation selected in the MVRNAA Selection Page. This page shall display two tables for the logged in Agent, the first table shall display the following data:

Authorisation Id

Type (D or S – dual or single notification)

BM Unit ID

Lead Party Name

Lead Party Account (P or C –production or consumption)

Lead Party Agent Name

Subsidiary Party Name

Subsidiary Party Account (P or C –production or consumption)

Subsidiary Party Agent Name

Effective from

Effective to

For the Authorisation detailed in the first table, the second table shall display the following Notification information;

Settlement Date

Reference Code.

4. MVRN Editor Page

This page shall display the following details about the MVRN selected from the MVRN Selection Page;

Field	State
Authorisation Id	Non-editable, from the MVRNAA Selection Page.
BM Unit	Non-editable, from the MVRNAA Selection Page.
Reference Code	Blank For new notifications or Non-editable values from the MVRN Selection Page for own submission edits and counterparty copies.
Notification Effective from*	Blank For new notifications or editable values from the MVRN Selection Page for own submission edits and counterparty copies.
Notification Effective To*	Blank For new notifications or editable values from the MVRN Selection Page for own submission edits and counterparty copies.
Lead Party Name	Non-editable, from the MVRNAA Selection Page.
Subsidiary Party name	Non-editable, from the MVRNAA Selection Page.
Agent 1 Name	Non-editable, from the MVRNAA Selection Page.
Agent 2 name	Non-editable, from the MVRNAA Selection Page.

*Dates as notified by the submitting ECVNAA(s), subject to the storage and reporting requirements described in section 5.15

For these Notification Details, the page shall display the following data in a tabular format;

Field	State
Settlement Period	Non-editable, period numbers.
Lead Party Percentage Reallocation	Non-editable, Lead Party current percentage submission for each period.
Subsidiary Party Percentage Reallocation	Non-editable, Subsidiary Party current percentage submission for each period.
Matched Percentage Reallocation	Non-editable, current matched percentage submission for each period.
Submission Percentage	Editable, blank for new submissions, populated with users existing values for own submission edits, populated with counterparty’s values for copy Counterparty edits.
Lead Party Fixed Reallocation	Non-editable, Lead Party current fixed submission for each period
Subsidiary Party Fixed Reallocation	Non-editable, Subsidiary Party current fixed submission for each period.
Matched Fixed Reallocation	Non-editable, current matched fixed submission for each period.
Submission Volume	Editable, blank for new submissions, populated with users existing values for own submission edits, populated with counterparties values for copy Counterparty edits.

Latest transaction panel will be displayed;

Logged in Agent Name

Latest Transaction Number

Logged in Agent’s Party Name

Logged in Agent’s Party’s Account

Latest Web Sequence Number

Latest File Sequence Number

Counterparty Name

Counterparty’s Agents Name

Counterparty’s Account

5. MVRN Submission Confirmation Page

The Submission/Confirmation shall contain the following information:

Reference Code	MVR Notification Reference Code
Submission date and time	Blank before confirmation
Sequence Number	The Web submission Sequence Number
Effective from	Notification Start Date
Effective to	Notification End Date [May be NULL]
Submission Percentage for Period [x]	Period Percentage Reallocation [One line for each period]
Submission Volume for Period [x]	Period Volume Reallocation [One line for each period]

8 SAA External Inputs and Outputs

8.1 SAA Flow Overview

8.2 SAA-I006: (input) BM Unit Metered Volumes for Interconnector Users

Interface ID:

SAA-I006

Source:

Title:

BM Unit Metered Volumes for Interconnector Users

BSC reference:

RETA SCH: 4, B, 2.4.1

SAA SD: 2.4, A1, CP555

Mechanism

Electronic data file transfer

Frequency:

Daily

Volumes:

Interface Requirement:

The SAA Service shall receive BM Unit Metered Volumes for Interconnector Users once a day from Interconnector Administrators.

The BM Unit Metered Volumes for Interconnector Users data shall include:

Interconnector ID

Settlement Date

BM Unit ID

Settlement Period (1-50)

Energy Volume Reading (MWh)

8.3 SAA-I012: (input) Dispute Notification

Interface ID:

SAA-I012

Source:

BSC Party,

BSCCo Ltd

NETSO

Title:

Dispute Notification

BSC reference:

RETA SCH: 4, B, 2.4.1

SAA SD: 2.9, 5.1.2

SAA BPM: 3.18, 4.16

Mechanism:

Manual

Frequency:

Ad-hoc

Volumes:

Interface Requirement:

The SAA Service shall receive Dispute Notifications from BSC Parties, BSCCo Ltd and the NETSO on an ad-hoc basis.

The contents of these notifications are likely to vary according to the nature of the individual dispute, but as a minimum shall include:

BSC Party raising dispute
The BSC Party’s unique reference for the dispute
Settlement Dates and Periods under dispute
Optionally and if appropriate, the reported values which are under dispute
The reason why the values are under dispute
The estimated total materiality of the dispute (e.g. the BSC Party believes that the report is in error by 100MW)
The identity of any other parties involved in the dispute.

8.4 SAA-I014: (output) Settlement Reports

Interface ID:

SAA-I014

User:

BSC Party,

BSCCo Ltd,

BMRA,

NETSO,

EMR Settlement Services Provider

Title:

Settlement Reports

BSC reference:

RETA SCH: 4, B, 2.2.1

SAA SD: 3.54, 4.1, 4.2, A2

SAA BPM: 3.19, 4.41

SAA IRR: SAA5, SAA7, SAA8, SAA9, P8, P18A, CP527, CP597, P78, P194, P217, CP1397, EMR, P305, CP1517

Mechanism:

Electronic data file transfer

Frequency:

Daily

Volumes:

Interface Requirement:

The SAA Service shall issue Settlement Reports to BSC Parties (including Virtual Lead Parties), BSCCo Ltd, the BMRA, EMR Settlement Services Provider and the NETSO once a day.

The contents of the Settlement Reports sent to the NETSO, BSCCo Ltd, EMR Settlement Services Provider and the BMRA are listed in Part 2 of the IDD.

This Part 1 of the IDD lists the Settlement Reports issued to BSC Parties and Virtual Lead Parties.

Note that within the reports, data for BM Units includes Secondary BM Units, data for Parties includes Virtual Lead Parties, and data for Energy Accounts includes Virtual Balancing Accounts.

Settlement Reports to a BSC Party shall include:

Settlement Date information:

Settlement Date

Settlement Run Type

SAA Run Number

SAA CDCA Settlement Run number

SVAA CDCA Settlement Date

SVAA CDCA Settlement Run Number

SVAA SSR Run Number

BSC Party Id

Aggregate Party Day Charges (see below)

Settlement Period Information:

Settlement Period (1-50) (j)

Aggregate Party Period Charges (see below)

System Period Data (see below)

System Quarter Hour Data (see below)

Market Index Information:

Market Index Data (see below)

Balancing Services Adjustment Action Information (post-P217 only):

Balancing Services Adjustment Action Data (see below)

Account Period Information:

Production/Consumption Flag (a)

Account Period Data (see below)

Account Period BMU Information:

BM Unit ID (i)

Account Period BMU Data (see below)

BM Unit Period Information:

BM Unit ID

BM Unit Period Data (see below)

Trading Unit Name

Total Trading Unit Metered Volume (MWh)

BM Unit RR Data (see below)

Supplier BM Unit Non BM ABSVD Data

BM Unit Period FPN Spot Points (^fFPN_it):

Time from

FPN Value from

Time to

FPN Value to

BM Unit Period Bid-Offer Information:

Bid-Offer pair number (n)

Bid-Offer Data (see below)

BM Unit Period Bid-Offer Spot Points (^fQBOⁿ_ij):

Time from

Bid-Offer Value from

Time to

Bid-Offer Value to

BM Unit Period Bid-Offer Acceptance (for all Settlement Dates):

Bid-Offer Acceptance number

CADL Flag

BM Unit Period Bid-Offer Acceptance (for post P217 Settlement Dates):

SO-Flag

BM Unit Period Bid-Offer Acceptance (for post P305 Settlement Dates):

Acceptance STOR Provider Flag

Reserve Scarcity Price Flag

Nb the STOR Provider Flag and RSP Flag will be null for pre-P305 Settlement Dates.

BM Unit Period Bid-Offer Acceptance (for Effective Dates after the TERRE P344 Final Implementation Date):

Acceptance Time

RR Instruction Flag

RR Schedule Flag

BM Unit Period Bid-Offer Acceptance Spot Points (qA^k_it):

Time from

Bid-Offer Acceptance Level from

Time to

Bid-Offer Acceptance Level to

BM Unit Bid-Offer Pair Acceptance Volume Data (post P217 only):

Bid-Offer Pair Number

Bid-Offer Pair Acceptance Bid Volume

Bid-Offer Pair Acceptance Offer Volume

BM Unit MVR Information:

Subsidiary Party ID and Production/Consumption Flag (a)

MVR Data (see below)

Settlement Reports to a VLP shall include:

Settlement Date Information

Settlement Date

Settlement Run Type

SAA Run Number

SAA CDCA Settlement Run number

SVAA CDCA Settlement Date

SVAA CDCA Settlement Run Number

SVAA SSR Run Number

BSC Party Id

Aggregate VLP Day Charges (see below)

Settlement Period Information:

Settlement Period (1-50) (j)

Aggregate VLP Period Charges

VLP System Period Data (see below)

Market Index Information:

Market Index Data (see below)

System Quarter Hour Information

System Quarter Hour Data (see below)

Balancing Services Adjustment Action Information:

Balancing Services Adjustment Action Data (see below)

Virtual Balancing Account Period Information:

Virtual Balancing Account Period Data (see below)

BM Unit Period Information:

BM Unit ID

Secondary BM Unit Period Data (see below)

BM Unit Period FPN Spot Points (^fFPN_it):

Time from

FPN Value from

Time to

FPN Value to

BM Unit Period Bid-Offer Information:

Bid-Offer pair number (n)

Bid-Offer Data (see below)

BM Unit Period Bid-Offer Spot Points (^fQBOⁿ_ij):

Time from

Bid-Offer Value from

Time to

Bid-Offer Value to

BM Unit Period Bid-Offer Acceptance:

Bid-Offer Acceptance number

SO-Flag

Acceptance STOR Provider Flag

Reserve Scarcity Price Flag

Acceptance Time

RR Instruction Flag

RR Schedule Flag

BM Unit Period Bid-Offer Acceptance Spot Points (qA^k_it):

Time from

Bid-Offer Acceptance Level from

Time to

Bid-Offer Acceptance Level to

BM Unit Bid-Offer Pair Acceptance Volume Data (post P217 only):

Bid-Offer Pair Number

Bid-Offer Pair Acceptance Bid Volume

Bid-Offer Pair Acceptance Offer Volume

Physical Interface Details:

Settlement Reports issued to BSC Parties are delivered in sub-flow 1, file id S0141. Settlement Reports issued to Virtual Lead Parties are delivered in sub-flow 4, file id S0144.

Refer to the IDD spreadsheet for the detailed definition of physical file structure.

Note:

SAA CDCA Settlement Run Number

Identifies the CDCA run which generated volumes used directly by SAA in the settlement calculations

For all settlement runs, other than Interim Initial for Settlement Dates prior to the P253 effective date:

SVAA CDCA Settlement Date

SVAA CDCA Settlement Run Number

Identify the CDCA run for Settlement Date which generated the GSP Group Take volumes which were allocated by the SVAA

SVAA SSR Run Number

Identifies the SVAA Run for Settlement Date which generated the SVA BM Unit volumes

For Interim Initial Settlement Runs for Settlement Dates prior to the P253 effective date:

SVAA CDCA Settlement Date

SVAA SSR Run Number

Identify the Settlement Date and Initial Settlement (SF) SVAA Run from which SVA volumes are derived

SVAA CDCA Run Number

Will be zero

The intention of this report is to provide all information necessary for calculating charges.

The following types of data are not included in the settlement report as currently defined:

minute-by-minute data such as FPN_ij(t), which can be derived from the spot point data.
intermediate data on bid-offer acceptance such as QAB^kn_ij which can be derived from the bid-offer and acceptance spot point data.

In the following descriptions, a definition of the data item is given which is consistent with that used in the SAA URS. The following exceptions to this are noted:

1. TCBSCCO_j is used to represent the BSCCo Ltd Costs allocated to the settlement period as a whole

2. CBSCCO_aj is used to represent the allocation of TCBSCCO_j to a particular energy account.

Variables (with their subscripts as appropriate) are as defined in the SAA URS. For a definition of what the variables mean and their derivation, refer to the URS.

8.4.1 Aggregate Party Day Charges

This data consists of the following for each settlement run:

Data Item	Definition
BSCCo Ltd Cost Allocation	Σ_aj CBSCCO_aj
BM Unit Cashflow	Σ_ij CBM_ij
Energy Imbalance Cashflow	Σ_aj CAEI_aj
Information Imbalance Cashflow	Σ_aj CII_aj
Non-Delivery Charge	Σ_aj CND_aj
Residual Cashflow Reallocation Charge	Σ_aj RCRC_aj
System Operator Charge	Σ_j CSO_j
RR Cashflow	CCRR_p
RR Instructed Deviation Cashflow	CDR_p

8.4.2 Aggregate VLP Day Charges¹⁹

This data consists of the following for each settlement run:

Data Item	Definition
BM Unit Cashflow	Σ_ij CBM_ij
Energy Imbalance Cashflow	Σ_aj CAEI_aj
Information Imbalance Cashflow	Σ_aj CII_aj
Non-Delivery Charge	Σ_aj CND_aj
Residual Cashflow Reallocation Charge	Σ_aj RCRC_aj
System Operator Charge	Σ_j CSO_j
RR Cashflow	CCRR_p
RR Instructed Deviation Cashflow	CDR_p

8.4.3 Aggregate Party Period Charges

This data consists of the following for each settlement period:

Data Item	Definition
BSCCo Ltd Cost Allocation	Σ_a CBSCCO_aj
BM Unit Cashflow	Σ_i CBM_ij
Energy Imbalance Cashflow	Σ_a CAEI_aj
Information Imbalance Cashflow	Σ_a CII_aj
Non-Delivery Charge	Σ_a CND_aj
Residual Cashflow Reallocation Charge	Σ_a RCRC_aj
RR Cashflow	∑_iεp CRR_ij
RR Instructed Deviation Cashflow	∑_iεp CDR_ij

8.4.4 Aggregate VLP Period Charges²⁰

This data consists of the following for each settlement period:

Data Item	Definition
BM Unit Cashflow	Σ_i CBM_ij
Energy Imbalance Cashflow	Σ_a CAEI_aj
Information Imbalance Cashflow	Σ_a CII_aj
Non-Delivery Charge	Σ_a CND_aj
Residual Cashflow Reallocation Charge	Σ_a RCRC_aj
RR Cashflow	∑_iεp CRR_ij
RR Instructed Deviation Cashflow	∑_iεp CDR_ij

8.4.5 System Period Data

This data includes the following for each settlement period for all Settlement Dates reported:

Data Item	Definition
Period BSCCo Ltd Costs	TCBSCCO_j
System Operator Cashflow	CSO_j
Information Imbalance Price 1	IIP1_j
Information Imbalance Price 2	IIP2_j
System Buy Price	SBP_j
System Sell Price	SSP_j
Price Derivation Code	PDC_j
Total System BM Cashflow	TCBM_j
Total System Energy Imbalance Cashflow	TCEI_j
Total System Non-Delivery Charge	TCND_j
Total System Accepted Bid Volume	TQAB_j
System Total Priced Accepted Bid Volume	TQPAB_j
Total System Energy Contract Volume	Σ_a \|QABC_aj\|
Total System Accepted Offer Volume	TQAO_j
System Total Priced Accepted Offer Volume	TQPAO_j
Total System Energy Imbalance Volume	TQEI_j
Residual Cashflow Reallocation Denominator	RCRD_j
Total System Residual Cashflow	TRC_j
Total System Information Imbalance Charge	TCII_j
Sell Price Price Adjustment	SPA_j
Buy Price Price Adjustment	BPAj
Total Period Applicable Balancing Services Volume	TQAS_j
System Operator Production Imbalance [redundant]	QAEI_aj
System Operator Consumption Imbalance [redundant]	QAEI_aj
Net Imbalance Volume	NIV_j
Total NIV Tagged Volume	TCQ_j

For Settlement Dates prior to the P217 effective date the following data items will also be reported:

Data Item	Definition
System Total Unpriced Accepted Bid Volume	TQUAB_j
System Total Unpriced Accepted Offer Volume	TQUAO_j
NIV Tagged System Total Unpriced Bid Volume	TTQUAB_j
NIV Tagged System Total Unpriced Offer Volume	TTQUAO_j
Net Energy Sell Price Cost Adjustment	ESCA_j
Net Energy Buy Price Cost Adjustment	EBCA_j
Net Energy Sell Price Volume Adjustment	ESVA_j
Net Energy Buy Price Volume Adjustment	EBVA_j
Net System Sell Price Volume Adjustment	SSVA_j
Net System Buy Price Volume Adjustment	SBVA_j
NIV Tagged System Total Unpriced Bid Volume	TTQUAB_j
NIV Tagged System Total Unpriced Offer Volume	TTQUAO_j
NIV Tagged SBVA	TSBVA_j
NIV Tagged SSVA	TSSVA_j
NIV Tagged Energy Buy Volume Adjustment	NTEBVA_j
NIV Tagged Energy Sell Volume Adjustment	NTESVA_j
PAR Tagged Energy Buy Volume Adjustment	PTEBVA_j
PAR Tagged Energy Sell Volume Adjustment	PTESVA_j
Untagged EBCA	UEBCA_j
Untagged EBVA	UEBVA_j
Untagged ESCA	UESCA_j
Untagged ESVA	UESVA_j

For Settlement Dates after, and including, the P217 effective date the following data items will also be reported:

Data Item	Definition
Total System Tagged Accepted Bid Volume	TQTAB_j
Total System Tagged Accepted Offer Volume	TQTAO_j
Total System Repriced Accepted Bid Volume	TQRAB_j
Total System Repriced Accepted Offer Volume	TQRAO_j
Total System Originally-priced Accepted Bid Volume	TQOAB_j
Total System Originally-priced Accepted Offer Volume	TQOAO_j
Total System Adjustment Sell Volume	TSVA_j
Total System Adjustment Buy Volume	TBVA_j
Total System Tagged Adjustment Sell Volume	TSTVA_j
Total System Tagged Adjustment Buy Volume	TBTVA_j
Total System Repriced Adjustment Sell Volume	TSRVA_j
Total System Repriced Adjustment Buy Volume	TBRVA_j
Total System Originally-priced Adjustment Sell Volume	TSOVA_j
Total System Originally-priced Adjustment Buy Volume	TBOVA_j
Replacement Price	RP_j
Replacement Price Calculation Volume	RPV_j

For Settlement Dates after, and including, the P217 effective date the following data items will also be reported and will be null fields for pre-P305 Settlement Dates:

Data Item	Definition
STOR Availability Window Flag
Loss of Load Probability	LoLP_j
De-rated Margin
Value of Lost Load	VoLL
Reserve Scarcity Price	RSVP_j

For Settlement Dates after, and including, the TERRE P344 Final Implementation Date the following data items will also be reported:

Data Item	Definition
GBP EUR Settlement Exchange Rate	EXC_p
Balancing Energy Deviation Price	BEDP_j
Total System RR Cashflow	TCRR_j
RR Aggregated Unpriced System Buy Action Volume	RRAUSB_j
RR Aggregated Unpriced System Sell Action Volume	RRAUSS_j
Period RR Accepted Offer Volume	∑_n ∑_i RRAO_nij
Period RR Accepted Bid Volume	∑_n ∑_i RRAB_nij

8.4.6 VLP²¹ System Period Data

This data includes the following for each settlement period for all Settlement Dates reported:

	Data Item	Definition
	System Operator Cashflow	CSO_j
	Information Imbalance Price 1	IIP1_j
	Information Imbalance Price 2	IIP2_j
	System Buy Price	SBP_j
	System Sell Price	SSP_j
	Price Derivation Code	PDC_j
	Total System BM Cashflow	TCBM_j
	Total System Energy Imbalance Cashflow	TCEI_j
	Total System Non-Delivery Charge	TCND_j
	Total System Accepted Bid Volume	TQAB_j
	System Total Priced Accepted Bid Volume	TQPAB_j
	Total System Energy Contract Volume	Σ_a \|QABC_aj\|
	Total System Accepted Offer Volume	TQAO_j
	System Total Priced Accepted Offer Volume	TQPAO_j
	Total System Energy Imbalance Volume	TQEI_j
	Residual Cashflow Reallocation Denominator	RCRD_j
	Total System Residual Cashflow	TRC_j
	Total System Information Imbalance Charge	TCII_j
	Sell Price Price Adjustment	SPA_j
	Buy Price Price Adjustment	BPA_j
	Total Period Applicable Balancing Services Volume	TQAS_j
	System Operator Production Imbalance	QAEI_aj
	System Operator Consumption Imbalance	QAEI_aj
	Net Imbalance Volume	NIV_j
	Total NIV Tagged Volume	TCQ_j
	STOR Availability Window Flag
	Loss of Load Probability	LoLP_j
	De-rated Margin
	Value of Lost Load	VoLL
	Reserve Scarcity Price	RSVP_j
GBP EUR Settlement Exchange Rate		EXC_p
Balancing Energy Deviation Price		BEDP_j
Total System RR Cashflow		TCRR_j
RR Aggregated Unpriced System Buy Action Volume		RRAUSB_j
RR Aggregated Unpriced System Sell Action Volume		RRAUSS_j
Period RR Accepted Offer Volume		∑_n ∑_i RRAO_nij
Period RR Accepted Bid Volume		∑_n ∑_i RRAB_nij

8.4.7 System Quarter Hour Data (following the TERRE P344 Final Implementation Date)

Data Item

Definition

Quarter Hour Period

Volume of GB Need Met

VGB_J

RR Interconnector Schedule Volume

∑I VI_J

TERRE Clearing Price

RRAP_J

8.4.8 Account Period Data

Provided for both of the party’s accounts, for each period:

Data Item	Definition
BSCCo Ltd Cost Allocation	CBSCCO_aj
Energy Imbalance Charge	CAEI_aj
Information Imbalance Charge	CII_aj
Residual Cashflow Reallocation Charge	RCRC_aj
Account Bilateral Contract Volume	QABC_aj
Account Period Balancing Services Volume	QABS_aj
Account Energy Imbalance Volume	QAEI_aj
Account Credited Energy Volume	QACE_aj
Residual Cashflow Reallocation Proportion	RCRP_aj

8.4.9 Virtual Balancing Account Period Data

Provided for both of the VLP’²²s accounts, for each period:

Data Item	Definition
Energy Imbalance Charge	CAEI_aj
Information Imbalance Charge	CII_aj
Account Period Balancing Services Volume	QABS_aj
Account Energy Imbalance Volume	QAEI_aj

8.4.10 Account Period BMU Data

Provided for all BM Units for which the party is a subsidiary party:

Data Item	Definition
Credited Energy Volume	QCE_iaj
Fixed Metered Volume Reallocation	QMFR_iaj
Percentage Metered Volume Reallocation	QMPR_iaj

8.4.11 BM Unit Period Data

Provided for all BM Units for which the party is the lead party:

Data Item	Definition
Information Imbalance Cashflow	CII_ij
BM Unit Period Non-Delivery Charge	CND_ij
Period FPN	FPN_ij
Period BM Unit Balancing Services Volume	QBS_ij
Period Information Imbalance Volume	QII_ij
Period Expected Metered Volume	QME_ij
BM Unit Metered Volume	QM_ij
Period BM Unit Non-Delivered Bid Volume	QNDB_ij
Period BM Unit Non-Delivered Offer Volume	QNDO_ij
Transmission Loss Factor	TLF_ij
Transmission Loss Multiplier	TLM_ij
BM Unit Applicable Balancing Services Volume	QAS_ij
Period Supplier BM Unit Delivered Volume	QBSD_ij
Period Supplier BM Unit Non BM ABSVD Volume	SNBABSVDij
Run Up Rate Export
Run Up Rate Import
Run Down Rate Export
Run Down Rate Import

8.4.12 Secondary BM Unit Period Data

Provided for all Secondary BM Units associated with the VLP²³:

Data Item	Definition
Information Imbalance Cashflow	CII_ij
BM Unit Period Non-Delivery Charge	CND_ij
Period FPN	FPN_ij
Period BM Unit Balancing Services Volume	QBS_ij
Period Information Imbalance Volume	QII_ij
Period Expected Metered Volume	QME_ij
BM Unit Metered Volume	QM_ij
Period BM Unit Non-Delivered Bid Volume	QNDB_ij
Period BM Unit Non-Delivered Offer Volume	QNDO_ij
Transmission Loss Factor	TLF_ij
Transmission Loss Multiplier	TLM_ij
Run Up Rate Export
Run Up Rate Import
Run Down Rate Export
Run Down Rate Import

8.4.13 BM Unit Period RR Data

Data Item	Definition
Period RR Accepted Offer Volume	∑_nRRAOn_ij
Period RR Accepted Bid Volume	∑_n RRABn_ij
Period RR Instructed Offer Deviation Volume	IOD_ij
Period RR Instructed Bid Deviation Volume	IBD_ij
RR Cashflow	CRR_ij
RR Instructed Deviation Cashflow	CDR_ij
Deemed Standard Product Offer Volume	∑^J DSPO^J_ij
Deemed Standard Product Bid Volume	∑^J DSPB^J_ij

8.4.14 BM Unit Quarter Hour RR Data

Data Item	Definition
Quarter Hour Period	J
RR Activation Volume	RRAV_iJ
RR Cashflow	CRR_iJ

8.4.15 Replacement Reserve Bid

Data Item	Definition
RR MRID	MRID_b
RR Divisible	DIV_b
RR Linked Bid Id	LINK_b
RR Multipart Bid Id	MULT_b
RR Exclusive Bid Id	EXCL_b
RR Status	STA_b
RR Flow Direction	FDIR_b
RR Auction MRID	AMRID_b

8.4.16 RR Auction Period

Data Item	Definition
Time Interval Start Time	TINTST_ab
Time Interval End Time	TINTET_ab
RR Bid Resolution	RES_ab

8.4.17 RR Auction Point

Data Item	Definition
RR Position	POS_pab
RR Quantity Offered	QOFF_pab
RR Minimum Quantity	MINQ_pab
RR Price	PRC_pab

8.4.18 RR Activation

Data Item	Definition
RR MRID	MRID_d
RR Auction MRID	AMRID_d
RR Flow Direction	FDIR_d

8.4.19 RR Activation Point

Data Item	Definition
RR Position	POS_pad
RR Activation Price	PRC_pad
RR Quantity Activated	ACTQ_pad

8.4.20 Bid-Offer Data

Provided for all bid-offer pairs which were submitted for the period for the BM Unit.

For all Settlement Dates the following data items will be reported:

Data Item	Definition
Bid Price	Pbⁿ_ij
Offer Price	Poⁿ_ij
Period BM Unit Total Accepted Bid Volume	QABⁿ_ij
Period BM Unit Total Accepted Offer Volume	QAOⁿ_ij
Period BM Unit Bid Cashflow	CBⁿ_ij
Period BM Unit Offer Cashflow	COⁿ_ij

For Settlement Dates prior to the P217 effective date the following data items will also be reported:

Data Item	Definition
Period BM Unit Total Priced Accepted Bid Volume	QAPBⁿ_ij
Period BM Unit Total Priced Accepted Offer Volume	QAPOⁿ_ij

For Settlement Dates after, and including, the P217 effective date the following data items will also be reported:

Data Item	Definition
Period BM Unit Tagged Bid Volume	QTABⁿ_ij
Period BM Unit Tagged Offer Volume	QTAOⁿ_ij
Period BM Unit Repriced Bid Volume	QRABⁿ_ij
Period BM Unit Repriced Offer Volume	QRAOⁿ_ij
Period BM Unit Originally-Priced Bid Volume	QOABⁿ_ij
Period BM Unit Originally-Priced Offer Volume	QOAOⁿ_ij

8.4.21 MVR Data

For all BM Units for which the party is the lead party, information is provided on the Metered Volume Reallocation to any subsidiary parties in the period as follows:

Data Item	Definition
Credited Energy Volume	QCE_iaj
Fixed Metered Volume Reallocation	QMFR_iaj
Percentage Metered Volume Reallocation	QMPR_iaj

8.4.22 Market Index Data

This data includes the following for each Settlement Period:

Data Item	Definition
Market Index Data Provider	s
Individual Liquidity Threshold	n/a
Market Index Price	PXP_sj
Market Index Volume	QXP_sj

8.4.23 Balancing Services Adjustment Action Data

Provided for all Settlement Dates after, and including, the P217 effective date:

Data Item	Definition
Balancing Services Adjustment Action Id
Balancing Services Adjustment Action Cost	BSAC^m_j
Balancing Services Adjustment Action Volume	QBSA^m_j
Tagged Balancing Services Adjustment Action Volume	TQBSA^m_j
Repriced Balancing Services Adjustment Action Volume	RQBSA^m_j
Originally-Priced Balancing Services Adjustment Action Volume	OQBSA^m_j
Balancing Services Adjustment Action SO-Flag

For Settlement Dates after, and including, the P217 effective date the following data items will also be reported and will be null for pre-P305 Settlement Dates:

Data Item	Definition
Balancing Services Adjustment Action STOR Provider Flag
Reserve Scarcity Price Flag

8.4.24 BM Unit Bid-Offer Pair Acceptance Volume Data

Provided for all Settlement Dates after, and including, the P217 effective date:

Data Item	Definition
Bid-Offer Pair Number
Bid-Offer Pair Acceptance Bid Volume	QAB^kn_ij
Bid-Offer Pair Acceptance Offer Volume	QAO^kn_ij

8.5 SAA-I016: (output) Settlement Calendar

Interface ID:

From: SAA-I016

To: CDCA-I034

User:

BSC Party,

BSC Party Agent, SVAA, BSCCo Ltd, CDCA

Title:

Settlement Calendar

BSC reference:

RETA SCH: 4, B, 2.1.1, 2.2.1

SAA SD: 5.2.1, A2

SAA BPM: 3.2, 4.40, CP1222

Mechanism:

Manual, in normal NETA file format, but without header and trailer records, probably as an email attachment

Frequency:

Annual

Volumes:

Interface Requirement:

The SAA Service shall publish the Settlement Calendar once a year to all BSC Parties and Agents, SVAA, BSCCo Ltd and CDCA.

The Settlement Calendar shall include the publication date/time of the calendar, and then the following details for each Settlement Date / Settlement Run Type

Settlement Date

Settlement Run Type (II/SF/R1/R2/R3/RF/D/DF)

CVA run date (CDCA)⁺⁺

SVA run date (SVAA, n/a for II for Settlement Days prior to the P253 effective date)⁺⁺

Settlement Run date (SAA)⁺⁺

Notification Date (date credit/debit report must reach FAA)^**

Payment Date (date money changes hands)^**

Notification Period (days between Settlement Date and Notification Date)^**

Payment Period (days between Settlement Date and Payment Date)^**

Elapsed Days SAA after Settlement

Working Days SAA after Settlement

Working Days SAA before Notification

^** indicates fields copied from payment calendar

⁺⁺ nominal date for runs. Run is any time after 9:00 a.m. on the scheduled date; results to be delivered to next service provider by 9:00 a.m. the next working day.

Physical Interface Details:

The physical structure is included in the SAA tab of the IDD spreadsheet, although the file is not sent over the network as a NETA format file.

8.6 SAA-I017: (output) SAA Data Exception Report

Interface ID:

From: SAA-I017

To: CRA-I030

To: CDCA-I050

To: ECVAA-I020

User:

IAs

ECVAA

CDCA

CRA

NETSO

SVAA

MIDP

Title:

SAA Data Exception Report

BSC reference:

SAA IRR: SAA1, SAA4, CP595, P78

Mechanism:

Electronic data file transfer, unless stated below as Manual (phone call and / or fax)

Frequency:

As required

Volumes:

Interface Requirement:

If an exception occurs while processing a received file, the SAA Service shall issue Exception Report to the sender of the file, one of the following:

ECVAA

CDCA

CRA

NETSO

SVAA (Manual)

MIDP

The Exception Reports shall include:

File Header of file being processed

Exception Type

Exception Description

8.7 SAA-I018: (output) Dispute Reports

Interface ID:

SAA-I018

User:

BSC Party, BSCCo Ltd, NETSO

Title:

Dispute Reports

BSC reference:

SAA SD: 5.1.4

SAA IRR: SAA10

Mechanism:

Manual

Frequency:

Ad-hoc

Volumes:

Interface Requirement:

The SAA Service shall issue Dispute Reports to BSC Parties, BSCCo Ltd and the NETSO on an ad-hoc basis.

The contents of these reports to BSC Parties are likely to be defined on an ad hoc basis.

Summary reports to BSCCo Ltd are likely to include the following data:

Number of Disputes in Month, by status

Total Materiality, by status

For each dispute:

Dispute Reference

BSC Parties Involved

Dispute Status

Settlement Period Involved

Materiality

Nature of Dispute

Actions Taken

Outstanding Actions

Expected Resolution Date

8.8 SAA-I021: Receive Acknowledgement of SAA Messages

See Section 2.2.7.

8.9 SAA-I022: Issue SAA Acknowledgement of Messages

See Section 2.2.7.

8.10 SAA-I030: (input) Receive Market Index Data

Interface ID:

SAA-I030

Source:

MIDPs

Title:

Receive Market Index Data

BSC reference:

P78

Mechanism:

Automatic

Frequency:

Daily

Volumes:

Interface Requirement:

The SAA shall receive Market Index Data, from Market Index Data Providers, for each Settlement Day.

The flow shall include:

Market Index Data Provider Identifier

Settlement Date

Period Data (46/48/50)

Settlement Period

Market Index Price

Market Index Volume

Traded Price (to be ignored)

Traded Volume (to be ignored)

8.11 SAA-I058: (output) Aggregated Non-Chargeable Demand Report

Interface ID:

SAA-I058

User:

BSC Parties

Title:

Aggregated Non-Chargeable Demand Report

BSC reference:

P395

Mechanism:

Elexon Portal

Frequency:

Monthly

Volumes:

Six per month - one Report per Settlement Run Type

Interface Requirement:

The Elexon Portal shall publish on the sixth working day of each calendar month the Aggregated Non-Chargeable Demand Report calculated by the SAA for a specific Settlement Run Type during the previous calendar month.

The flow shall include:

Month/Year

Settlement Run Type

Settlement Date

Settlement Period

GSP Group Id

GSP Group Aggregated SVA and Embedded CVA TLM-Adjusted Non-Chargeable Demand

Aggregated Directly-Connected CVA TLM-Adjusted Non-Chargeable Demand

9 SVAA External Inputs and Outputs

9.1 P0282: Delivered Volume Notification

Interface ID:

P0282

Source:

VLP, AMVLP

Title:

Delivered Volume Notification

BSC reference:

CP1517, P375

Mechanism:

Automatic

Frequency:

Daily

Volumes:

High

Interface Requirement:

The SVAA shall receive Delivered Volumes for:

MSID Pairs from Virtual Lead Parties and AMVLPs’ and
AMSID Pairs from AMVLPs;

each Settlement Day.

The flow shall include:

Settlement Date

GSP Group Id

Secondary BM Unit Id

MSID Pair Details

Import MSID

Export MSID

Secondary BM Unit Data

Settlement Period Id

Delivered Volume

AMSID Pair Details

Import AMSID

Export AMSID

Secondary BM Unit Data

Settlement Period Id

Delivered Volume

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

AMVLPs should submit AMSID Pair Delivered Volumes for AMSID Pairs that are used for Asset Metering and MSID Pair Delivered Volumes for AMSID Pairs that are used for Differencing.

9.2 P0283: Rejection of Delivered Volume Notification

Interface ID:

P0283

User:

VLP, AMVLP

Title:

Rejection of Delivered Volume

BSC reference:

CP1517, P375

Mechanism:

Automatic

Frequency:

Ad hoc

Volumes:

Medium

Interface Requirement:

The SVAA shall issue notifications of rejection to Virtual Lead Parties or AMVLPs where incoming P0282 Delivered Volume Notifications fail business validation.

The flow shall include:

Settlement Date

GSP Group Id

Secondary BM Unit Id

Import MSID

Export MSID

Import AMSID

Export AMSID

Settlement Period Id

Delivered Volume

Delivered Volume Rejection Reason

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

The data included in the P0283 will be as received in the P0282, plus the Delivered Volume Rejection Reason.

9.3 P0284: Confirmation of Delivered Volume

Interface ID:

P0284

User:

VLP, AMVLP

Title:

Confirmation of Delivered Volume

BSC reference:

CP1517, P375

Mechanism:

Automatic

Frequency:

Daily

Volumes:

High

Interface Requirement:

The SVAA shall issue notifications of confirmation to Virtual Lead Parties VLPs or AMVLPs where incoming P0282 Delivered Volume Notifications are validated successfully.

The flow shall include:

Settlement Date

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

9.4 P0285: Delivered Volume Exception Report

Interface ID:

P0285

User:

VLP, AMVLP

Title:

Delivered Volume Exception Report

BSC reference:

CP1517, P375

Mechanism:

Automatic

Frequency:

Ad hoc

Volumes:

Low

Interface Requirement:

The SVAA shall issue notifications to Virtual Lead Parties VLPs or AMVLPs where Delivered Volumes received via the P0282 cannot be apportioned successfully to the correct Supplier.

The flow shall include:

Settlement Date

GSP Group Id

Secondary BM Unit Id

MSID Details

Import MSID

Export MSID

Secondary BM Unit Period Data – Exception

Settlement Period Id

Delivered Volume

Delivered Volume Exception Reason

AMSID Details

Import AMSID

Export AMSID

Secondary BM Unit Data – Exception

Settlement Period Id

Delivered Volume

Delivered Volume Exception Reason

Physical Interface Details:

The physical structure is included in the IDD spreadsheet and referenced in the SVA Data Catalogue.

9.5 P0287: Metering System Half Hourly Volume Adjustments

Interface ID:

P0287

User:

Supplier

Title:

Metering System Half Hourly Volume Adjustments

BSC reference:

CP1517

Mechanism:

Automatic

Frequency:

Daily

Volumes:

Medium

Interface Requirement:

The SVAA shall report values to Suppliers calculated from the delivered volumes and other adjustments during the main calculation to determine the BM Unit position.

The flow shall include:

Settlement Date

Settlement Run Type

Settlement Run Number

Supplier Id

BM Unit Id

MPAN Cores

MPAN Core

GSP Group Id

Distributor Id

Line Loss Factor Class Id

Settlement Period Id

Metering System Half Hourly Volume Adjustments

Consumption Component Class Id

Secondary HH Delivered Volumes (non-losses)

MSID Applicable Balancing Services Volume Data (non-losses)

Secondary HH Delivered Volumes (losses)

MSID Applicable Balancing Services Volume Data (losses)

Physical Interface Details:

The physical structure is included in the IDD spreadsheet and referenced in the SVA Data Catalogue.

9.6 P0288: Secondary Half Hourly Consumption Volumes

Interface ID:

P0288

User:

VLP, AMVLP.

Title:

Secondary Half Hourly Consumption Volumes

BSC reference:

CP1517, P375

Mechanism:

Automatic

Frequency:

Daily

Volumes:

Medium

Interface Requirement:

The SVAA shall report Metering System Half Hourly Volume Adjustments to VLPs and AMVLPs.

The flow shall include:

Settlement Date

Settlement Run Type

Supplier Id

BM Unit

BM Unit Id

MSID Details

MSID

Metering System Half Hourly Volume Adjustments

Settlement Period

Consumption Component Class Id (non-losses)

Secondary Half Hourly Consumption (non-losses)

Consumption Component Class Id (losses)

Secondary Half Hourly Consumption (losses)

AMSID Details

AMSID

Asset Metering System Half Hourly Volume Adjustments

Settlement Period

Consumption Component Class Id (non-losses)

Secondary HH Delivered Volumes (non-losses)

Consumption Component Class Id (losses)

Secondary Half Hourly Consumption (losses)

Physical Interface Details:

The physical structure is included in the IDD spreadsheet and referenced in the SVA Data Catalogue.

9.7 P0297: Asset Registration

Interface ID:

P0297

User:

AMVLP

Supplier

Title:

Asset Registration

BSC reference:

P375

P395

Mechanism:

Manual Entry or file upload into the Self-Service Gateway or email to the BSC Service Desk

Frequency:

As required

Volumes:

Medium

Interface Requirement:

AMVLPs or Suppliers are required to submit these data items to the SVAA in order to register an Asset as the first stage of the three-stage process for the registration of an Asset Metering System set out in BSCP602:

Asset Details

Asset Registration Id

AMVLP Id

Address Line 1

Address Line 2

Address Line 3

Address Line 4

Address Line 5

Address Line 6

Postcode

GSP Group Id

BM Unit Id

Export AMSID required indicator

Asset type

Asset Voltage

Measurement Transformer Indicator

Asset Capacity

Import AMSID

Export AMSID

AMSID Pair EFD

AMSID Pair ETD

Measurement Class

Action Indicator

Associated MSID Pairs (not required for new submissions)

Import MSID

Export MSID

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

The valid set for the “Action Indicator” is:

New

Update

Change of Registrant

Delete

9.8 P0298: Rejection of Asset Registration

Interface ID:

P0298

User:

AMVLP

Supplier

Title:

Rejection of Asset Registration

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0297 received

Volumes:

Medium

Interface Requirement:

Where a P0297 fails business validation, the SVAA shall make a P0298 available to the registrant AMVLP or Supplier.

The data items included in the P0298 will be as received in the P0297, plus the Rejection Reason.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0297 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier the P0298 will be available to download from the Self Service Gateway. Where the P0297 was emailed to the BSC Service Desk, the P0298 will be emailed to the AMVLP or Supplier.

9.9 P0299: Confirmation of Asset Registration

Interface ID:

P0299

User:

AMVLP

Supplier

Title:

Confirmation of Asset Registration

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0297 received

Volumes:

Medium

Interface Requirement:

Where a P0297 passes business validation, the SVAA shall make a P0299 available to the registrant AMVLP or Supplier to confirm that the Asset has been registered successfully and to notify the AMSID Pair Details to the AMVLP or Supplier.

The data items included in the P0299 will be as received in the P0297 and – for New Registrations - the Import AMSID and, where applicable, the Export AMSID.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0297 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier, the P0299 will be available to download from the Self Service Gateway. Where the P0297 was emailed to the BSC Service Desk, the P0299 will be emailed to the AMVLP or Supplier.

9.10 P0300: Registration of Asset Metering Agents

Interface ID:

P0300

User:

AMVLP

Supplier

Title:

Registration of Asset Metering Agents

BSC reference:

P375

P395

Mechanism:

Manual Entry, File upload into the Self-Service Gateway or email to the BSC Service Desk

Frequency:

As required

Volumes:

Medium

Interface Requirement:

AMVLPs or Suppliers are required to submit these data items to the SVAA in order to register Asset Metering Agents as the second stage of the three-stage process for the registration of an Asset Metering System set out in BSCP602:

AMSID Pair Details

AMVLP Id

Import AMSID

Export AMSID

Action Indicator

HHDC Details

HHDC Id

HHDC Effective From Date

AMHHDC Details

AMHHDC Id

AMHHDC Effective From Date

AMHHDC Effective To Date

MOA/AMMOA Details

MOA Id/AMMOA Id

MOA/AMMOA Effective From Date

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

The valid set for the “Action Indicator” is:

New
Update

9.11 P0301: Rejection of Asset Metering Agents

Interface ID:

P0301

User:

AMVLP

Supplier

Title:

Rejection of Asset Metering Agents

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0300 received

Volumes:

Medium

Interface Requirement:

Where a P0300 fails business validation, the SVAA shall make a P0301 available to the registrant AMVLP or Supplier.

The data items included in the P0301 will be as received in the P0300, plus the Rejection Reason.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0300 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier the P0301 will be available to download from the Self Service Gateway. Where the P0300 was emailed to the BSC Service Desk, the P0301 will be emailed to the AMVLP or Supplier.

9.12 P0302: Confirmation of Registration of Asset Metering Agents

Interface ID:

P0302

User:

AMVLP

Supplier

Title:

Confirmation of Registration of Asset Metering Agents

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0300 received

Volumes:

Medium

Interface Requirement:

Where a P0300 passes business validation, the SVAA shall make a P0302 available to the registrant AMVLP or Supplier to confirm that the Asset Metering Agents have.

The data items included in the P0300 will be as received in the P0302.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0300 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier, the P0302 will be available to download from the Self Service Gateway. Where the P0300 was emailed to the BSC Service Desk, the P0302 will be emailed to the AMVLP or Supplier.

9.13 P0303: Asset Meter Registration

Interface ID:

P0303

User:

AMVLP

Supplier

Title:

Asset Meter Registration

BSC reference:

P375

P395

Mechanism:

Manual Entry, File upload into the Self-Service Gateway or email to the BSC Service Desk

Frequency:

As required

Volumes:

Medium

Interface Requirement:

AMVLPs or Suppliers are required to submit these data items to the SVAA in order to register of Asset Meters as the third stage of the three-stage process for the registration of an Asset Metering System set out in BSCP602:

AMVLP Details

AMVLP Id

Import Meter(s)

Import AMSID

Asset Meter Serial Number

Outstation Type

Asset Meter make and model

Asset Meter Effective From Date

Asset Meter Effective To Date

Asset Metering Type

Export Meter(s)

Export AMSID

Asset Meter Serial Number

Outstation Type

Asset Meter make and model

Asset Meter Effective From Date

Asset Meter Effective To Date

Asset Metering Type

Action Indicator

Action Indicator

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

The valid set for the “Action Indicator” is:

New
Update

9.14 P0304: Rejection of Asset Meter Registration

Interface ID:

P0304

User:

AMVLP

Supplier

Title:

Rejection of Asset Meter Registration

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0303 received

Volumes:

Medium

Interface Requirement:

Where a P0303 fails business validation, the SVAA shall make a P0304 available to the registrant AMVLP or Supplier.

The data items included in the P0304 will be as received in the P0303, plus the Rejection Reason.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0303 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier, the P0304 will be available to download from the Self Service Gateway. Where the P0303 was emailed to the BSC Service Desk, the P0304 will be emailed to the AMVLP or Supplier.

9.15 P0305: Confirmation of Asset Meter Registration

Interface ID:

P0305

User:

AMVLP

Supplier

Title:

Confirmation of Asset Meter Registration

BSC reference:

P375

P395

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0303 received

Volumes:

Medium

Interface Requirement:

Where a P0303 passes business validation, the SVAA shall make a P0305 available to the registrant AMVLP or Supplier to confirm that the Asset Meter(s) has been registered successfully.

The data items included in the P0305 will be as received in the P0303.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0303 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP or Supplier, the P0305 will be available to download from the Self Service Gateway. Where the P0303 was emailed to the BSC Service Desk, the P0305 will be emailed to the AMVLP or Supplier.

9.16 P0306: AMSID Pair Allocation to a Secondary BM Unit

Interface ID:

P0306

User:

AMVLP

Title:

AMSID Pair Allocation to a Secondary BM Unit

BSC reference:

P375

Mechanism:

Manual Entry, File upload into the Self-Service Gateway or email to the BSC Service Desk

Frequency:

As required

Volumes:

Medium

Interface Requirement:

AMVLPs may allocate an AMSID Pair to a Secondary BM Unit, as set out in BSCP602:

AMVLP and BM Unit Details

AMVLP Id

BM Unit Id

AMSID Pair Details

Import AMSID

Export AMSID

AMSID Pair Differencing Indicator

AMSID Pair in Secondary BM Unit EFD

AMSID Pair in Secondary BM Unit ETD

Associated MSID Pairs

Import MSID

Export MSID

MSID Pair Indicator

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

9.17 P0307: Confirmation of AMSID Pair Allocation to a Secondary BM Unit

Interface ID:

P0307

User:

AMVLP

Title:

Confirmation of AMSID Pair Allocation to a Secondary BM Unit

BSC reference:

P375

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P0306 received

Volumes:

Medium

Interface Requirement:

Where a P0306 passes business validation, the SVAA shall make a P0307 available to the registrant AMVLP to confirm that the AMSID Pair Allocation to a Secondary BM Unit has been successful.

The data items included in the P0307 will be as received in the P0306.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0306 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP, the P0307 will be available to download from the Self Service Gateway. Where the P0306 was emailed to the BSC Service Desk, the P0307 will be emailed to the AMVLP.

9.18 P0308: Rejection of AMSID Pair Allocation to a Secondary BM Unit

Interface ID:

P0308

User:

AMVLP

Title:

Rejection of Asset Meter Registration

BSC reference:

P375

Mechanism:

Self Service Gateway or Email

Frequency:

In response to a P03036 received

Volumes:

Medium

Interface Requirement:

Where a P0306 fails business validation, the SVAA shall make a P0308 available to the registrant AMVLP to notify them that the AMSID Pair Allocation to a Secondary BM Unit has been unsuccessful.

The data items included in the P0308 will be as received in the P0306, plus the Rejection Reason.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

Where the P0306 was submitted by manual entry or by file upload into the Self Service Gateway by an AMVLP, the P0308 will be available to download from the Self Service Gateway. Where the P0306 was emailed to the BSC Service Desk, the P0308 will be emailed to the AMVLP.

9.19 P0309: Notification of use of AMSID Pair by another AMVLP

Interface ID:

P0309

User:

AMVLP

Title:

Notification of use of AMSID Pair by another AMVLP

BSC reference:

P375

Mechanism:

Frequency:

As required

Volumes:

Medium

Interface Requirement:

Where an AMVLP has successfully allocated an AMSID Pair for which it is not the Registrant to one of its Secondary BM Units, and this has not resulted in a Loss of AMSID Pair for the registrant AMVLP (in accordance with BSCP602), the SVAA shall issue a P0309 to the registrant AMVLP to notify them that another AMVLP is also using the AMSID Pair Allocation.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

9.20 P0310: Missing Metering System Data

Interface ID:

P0310

User:

Half Hourly Data Aggregator, Half Hourly Data Collector, AMVLP, Supplier

Title:

Missing Metering System Data

BSC reference:

P375

P395

Mechanism:

Automatic

Frequency:

As required

Volumes:

Interface Requirement:

Where a HHDA has not provided HH Metering System Metered Data (‘D0385’) for a MSID or a HHDC has not provided Actual HH Asset Metering System Metered Data (D0390) for an AMSID when required by the SVAA in accordance with BSCP508, the SVAA shall issue a P0310 to the HHDA or to the HHDC and the AMVLP or the Supplier.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

9.21 P0311: Invalid Metering System Data

Interface ID:

P0311

User:

Half Hourly Data Aggregator, Half Hourly Data Collector, AMVLP,

Supplier

Title:

Invalid Metering System Data

BSC reference:

P375

P395

Mechanism:

Automatic

Frequency:

As required

Volumes:

Interface Requirement:

Where a HHDA has provided HH Metering System Metered Data (‘D0385’) for a MSID or a HHDC has provided HH Asset Metering System Metered Data (D0390) for an AMSID - which has failed technical and / or business validation, the SVAA shall issue a P0311 to the HHDA or to the HHDC and the AMVLP or the Supplier.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

9.22 P0320: Loss of AMSID Pair Allocation

Interface ID:

P0320

User:

AMVLP

Title:

Notification of use of AMSID Pair by another AMVLP

BSC reference:

P375

Mechanism:

Frequency:

As required

Volumes:

Medium

Interface Requirement:

Where an AMVLP has successfully allocated an AMSID Pair for which it is not the Registrant to one of its Secondary BM Units, and this has resulted in a Loss of AMSID Pair for the registrant AMVLP in accordance with BSCP602, the SVAA shall issue a P0320 to the registrant AMVLP to notify them that they have the AMSID Pair Allocation to their Secondary BM Unit.

Physical Interface Details:

The physical structure is included in the IDD Part 1 spreadsheet and referenced in the SVA Data Catalogue.

1 TLFA functionality was added for the Introduction of Zonal Transmission Losses on an Average Basis (P82), but will not be used.

2 The Omitted Data functionality has been developed, but is disabled.

3No licence is required to download the SAA-I058.

4 Note that the DF flow ceases publication in Q1/2009

5 Note that the DF flow ceases publication in Q1/2009

6 Where OCNMFD is referred to throughout this document, it should be interpreted as being equivalent to SPLD.

7 Where OCNMFW is referred to throughout this document, it should be interpreted as being equivalent to SPLW.

8 Note that the Contact Name is not included in the CRA-I014 (sub flow 1) sent in response to new and amended data.

9 Note that the Contact Name is not reported in the CRA-I014

10 With the exception that any WDCALF value exceeding ±9.9999999 shall be capped and reported as ±9.9999999 in the CRA-I014. The values of WDBMCAIC and WDBMCAEC reported in the CRA-I014 will still be derived using the ‘real’ uncapped WDCALF value.

11 With the exception that any NWDCALF value exceeding ±9.9999999 shall be capped and reported as ±9.9999999 in the CRA-I014. The values of NWDBMCAIC and NWDBMCAEC reported in the CRA-I014 will still be derived using the ‘real’ uncapped NWDCALF value.

12 With the exception that any SECALF value exceeding ±9.9999999 shall be capped and reported as ±9.9999999 in the CRA-I014. The values of WDBMCAEC and NWDBMCAEC reported in the CRA-I014 will still be derived using the ‘real’ uncapped SECALF value.

13 The Omitted Data functionality has been developed, but is disabled.

14 The Omitted Data functionality has been developed, but is disabled.

15 P98: Note that because the format of the ECVAA-I007 and ECVAA-I008 flows is changing, this flow will also change. The detail of the change will be contained in the IDD where a new version of the flow will be added. The default version of this report will remain the pre-P98 version (i.e. with no report requirements) until further notice.

16 Variation 43

17 Note that flexible reporting preferences for version numbers overrule specific report requirements. For example, in order to receive Matching Data in the ECVAA-I028 a Party must elect to receive V002 of the flow (V001 will be the default) and specify that it wishes to receive Matching Data via a Report Requirement Change Request (ECVAA-I002); a subsequent reversion to V001 of the ECVAA-I028, effected through flexible reporting would negate the Report Requirement Change Request.

18 Note that flexible reporting preferences for version numbers overrule specific report requirements. For example, in order to receive Matching Data in the ECVAA-I029 a Party must elect to receive V002 of the flow (V001 will be the default) and specify that it wishes to receive Matching Data via a Report Requirement Change Request (ECVAA-I003); a subsequent reversion to V001 of the ECVAA-I029, effected through flexible reporting would negate the Report Requirement Change Request.

19 Applies to AMVLPs as well as to VLPs

20 Applies to AMVLPs as well as to VLPs

21 Applies to AMVLPs as well as to VLPs

22 Applies to AMVLPs as well as to VLPs

23 Applies to AMVLPs as well as to VLPs

CONTENTS

NETA Interface Definition and Design Document Part 1 – Interfaces with BSC Parties and their Agents

1 Introduction

1.1 Purpose

1.1.1 Summary

1.2 Scope

1.2.1 The Scope of this Document

1.2.2 Types of Interface

1.3 NETA Interface Overview

1.3.1 Introduction

1.3.2 The Business Process Level

1.3.3 Logical Message Definition

1.3.4 Physical Message Definition

1.3.5 Data Transfer Protocols

1.4 Summary

1.5 References

1.5.1 BSC Documents

1.6 Abbreviations

2 Common Interface Conventions

2.1 Interface Mechanisms

2.1.1 Manual

2.1.2 Electronic Data File Transfer

2.1.3 Meter System Interface

2.1.4 BMRA Publishing Interface

2.2 Data File Format

2.2.1 File Header

2.2.2 File Footer

2.2.3 Record Formats

2.2.4 File Types, Record Types and Repeating Structure

2.2.4.1 The Tabs of the Spreadsheet

2.2.5 File names

2.2.6 Unstructured File Format

2.2.7 Response Messages

2.2.7.1 Positive Acknowledgement (ACK Message)

2.2.7.2 Negative Acknowledgement (NACK Message)

2.2.7.3 Response to response messages

2.2.7.4 Application Rejection and Acceptance

2.2.8 Use of Sequence Numbers

2.2.9 Time

2.2.10 The CRA Encryption Key

2.2.11 Valid Sets

2.2.11.1 Action Code

2.2.11.2 Action Indicator

2.2.11.3 Activity

2.2.11.4 Alarm Code

2.2.11.5 AMSID Pair Differencing Indicator

2.2.11.6 Asset Metering Type

2.2.11.10 BM Unit Type

2.2.11.11 Certification/Accreditation Status

2.2.11.12 Estimation method

2.2.11.14 I/E Flag

2.2.11.15 L/S Flag

2.2.11.16 Main / Check Indicator

2.2.11.17 Measurement Class Id

2.2.11.18 Measurement Quantity

2.2.11.19 Meter Reading Status

2.2.11.20 MSID Pair Indicator

2.2.11.21 Multi-day Flag

2.2.11.22 Organisation Type

2.2.11.23 Party Sequence

2.2.11.24 P/C Flag

2.2.11.25 P/C Status

2.2.11.26 Point Type

2.2.11.27 Price Derivation Code

2.2.11.28 Registration Status

2.2.11.29 Registration Type

2.2.11.30 Run Type

2.2.12 Example File Formats

3 External Interface Summary

3.1 Interfaces by BSC Agent

3.1.1 BMRA Interfaces

3.1.2 CDCA Interfaces

3.1.3 CRA Interfaces

3.1.4 ECVAA Interfaces

3.1.5 SAA Interfaces

3.1.6 SVAA Interfaces

3.2 Interfaces by Corresponding Party

3.2.1 BSC Party Interfaces

3.2.2 BSC Party Agent Interfaces

3.2.3 Market Index Data Provider Interfaces