Synopsis	This document describes the user requirements for the Central Registration Agent (CRA) service.
Version	Version 23.0
Effective date	1 September 2021
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.

1 Management Summary

The Central Registration Agent (CRA) is one of the suite of seven services that support the operation of the Balancing and Settlement Code (BSC).

The role of the CRA is to maintain a master register of information relating to the registration of participants, trading units and physical plant such as Boundary Points and interconnectors. The principal business processes involved may be summarised as:

The registration and Qualification of BSC Parties;
The registration and maintenance of BM Unit and Trading Unit details received from the BSC Party as well as Credit Assessment details from the Settlement Administration Agent (SAA);
The registration of CRA Boundary Points, System Connection Points and Metering Systems received from the BSC Party;
The reception and maintenance of requests for Agent Qualification; together with a list of Agents who have passed all Qualification processes and can support BSC Parties obligations.
The validation and correlation of these individual Registration instructions to ensure accuracy, completeness and consistency within the system;
The distribution of Registration reports to the BSC Parties on the occurrence of processing of requests and registration information;
The distribution of Registration details to other components of the BSC central system services either on demand or as batch processing;
The monitoring of BM Units’ Metered Volumes to identify GC or DC breaches¹ (GC and DC Breach Monitoring) and the subsequent estimation of BM Unit Metered Volumes (CRA-Estimated GC or DC Amounts) to update BM Units GC or DC.

The purpose of this document is to provide a complete specification of the set of business requirements that the CRA Service must satisfy for all of its various User types. These range from the BSC Parties, to BSCCo Ltd and its various Agents, including the operators of the CRA itself and the other BSC Services. Similar documents define the requirements for the other Services.

A convention has therefore been used for uniquely identifying the requirements in each document. This ensures that the fulfilment of each requirement can be unambiguously traced through the subsequent functional specification, design and implementation. This is of particular importance for the implementation of the SAA, CRA and CDCA services, which will use a single integrated computer system. This document does not, however, attempt to describe the integration of those services, which would be inappropriate for this CRA User Requirement Specification (URS).

The requirements that have been identified have been divided into four categories:

Functional (F), a specific business requirement of the service.
Non-functional (N), which includes auditing, security, resilience etc. The majority of these will probably be associated with the General (GEN) service.
Service (S), which includes all time-related service delivery requirements, including performance and volumetrics.
Interface (I), a requirement for data exchange between services or to / from external parties.

These requirements are catalogued in sections 5 to 8 respectively with the common requirements placed in appendices of this document

2 Introduction

This document is the User Requirements Specification (URS) for the Central Registration Agent role within the Balancing and Settlement Code Services. It is one of a set of documents forming the baseline for requirements of seven BSC central system services. This document set comprises (but does not exclude further Services):

BMRA URS;
CRA URS;
SAA URS;
TAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
Interface Definition and Design (IDD).

The objective of this document is to provide a complete specification of the requirements that the CRA Service must meet, from the users’ point of view. For this purpose, the “users” include BSCCo Ltd, Ofgem, the National Electricity Transmission System Operator (NETSO) as the Balancing Mechanism Operator, other Service Providers, BSC Parties, and the CRA Service Provider’s own user Operators.

Note that the current solution for the BSC central systems involves a bundled approach where the requirements of the SAA, CRA and CDCA Services are met within the same computer system. Additionally, the Self-Service Gateway will provide an online portal, accessible through the BSC Website, that allows authorised users to provide and maintain registration data. This will be the master source of registration data, interfacing in the short term with the legacy shared SAA, CRA and CDCA database. The Self-Service Gateway will be available to authorised users including BSC Parties, CRA Agent Operators and BSCCo. As this URS is describing the requirements of the CRA service in isolation, this document does not attempt to identify in detail where common requirements of these Services will be met by a shared function in the solution.

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

This document refers to a “Supplier BM Unit”, which means a BM Unit with a BM Unit Type of ‘G’ or ‘S’, as stated by the Lead Party on the ‘Registration of BM Unit’ form in BSCP15.

2.1 Amendment History

Date	Issue	Description of Change	Reference
28/01/10	15.0	Issued
23/02/12	16.0	Document rebadged and amended for February 2012 Release (P268 & P269)	ISG130/08
25/06/15	17.0	Modification P310; June 2015 Release	ISG169/05
23/02/17	18.0	CP1471	ISG185/03
		P326 Self-Governance	ISG188/05, ISG191/01
29/06/17	19.0	P350 for the June 17 Release	ISG194/02
28/02/19	20.0	P344 – February 2019 Release	P284C/01
		CP1510 – February 2019 Release	ISG211/06 SVG214/02
		P359 – February 2019 Release	ISG212/03
29/03/19	21.0	P369 – March 2019 Standalone Release	P285/12
27/02/20	22.0	P394 February 2020 Release – Self-Governance	P297/07
01/09/21	23.0	P420 – 1 September 2021 Non-Standard Release	P316/05

Further details of this document’s amendment history are available from BSCCo on request.

2.2 References

CRA SD	Service Description for Central Registration Agent (NETA Programme)
TAA SD	Service Description for Technical Assurance Agent (NETA Programme)
CDCA SD	Service Description for Central Data Collection Agent (NETA Programme)
SAA SD	Service Description for Settlement Agent (NETA Programme)
CRA BPM	RETA Business Process Models [CRA] - (NETA Programme)
NETA SCH	NETA Service Agreement (NETA Programme)
CRAWS	CRA Workshop held on 01/02/2000
DID-2	Data Items Definition Design Clarification version 2 (NETA Programme) 17/02/2000
PPR	Program Progress Report (01/03/2000)
IDD	Interface Definition and Design (Parts 1 & 2)

2.3 Acronyms

See Appendix for the full glossary of terms.

3 Scope of Specification

This document provides a complete specification of the requirements for the Central Registration Agent (CRA) Service within the NETA programme. The requirements are described from the point of view of the CRA Service Users.

The document is divided into the following chapters.

Chapter 4, Business and System Overview - describes the business context of the CRA Service. It includes a definition of the CRA Service User population.
Chapter 5, Description of Requirements - describes the functional requirements of the Service from the point of view of the Service users.
Chapter 6, External Interfaces - describes the interfaces with the external users of the Service.
Chapter 7, Non Functional Requirements - describes the non-functional requirements of the Service.
Chapter 8, Service Requirements - describes the service requirements for the Service.
Chapter 9, User Roles and Activities - describes the users of the system and their interaction with the CRA.
Chapter 10, Future Enhancements - describes potential functional enhancements.
Appendix A - presents a Requirements Compliance Matrix against the CRA Service Description documentation.
Appendix B - presents the Logical data model as it relates to the CRA system.
Appendix C presents the provided Business Process Model
Appendix D presents the Common User Requirements for the Non Functional Requirements.
Appendix E presents the Common User Requirements for the Service Requirements.
Appendix F presents the Common Future Requirements for the Service Requirements.
Appendix G presents the Glossary of Terminology used within the whole BSC Central Systems Specifications².
This format is as specified in section 5 of our proposal.

4 Business and System Overview

This section provides an overview of the business and systems involved within the CRA system. The overview is for indicative purposes only. Section 5 and the requirements detailed therein form the definitive statement of requirements.

4.1 Summary of Business Requirements

The registration and Qualification of BSC Parties;
The registration and maintenance of BM Unit and Trading Unit details received from the BSC Party as well as Credit Assessment details from the Settlement Administration Agent (SAA);
The registration of CRA Boundary Points, System Connection Points and Metering Systems received from the BSC Party;
The reception and maintenance of requests for agent Qualification; together with a list of agents who have passed all Qualification processes and can support BSC Parties obligations.
The validation and correlation of these individual Registration instructions to ensure accuracy, completeness and consistency within the system;
The Generation Capacity (GC) / Demand Capacity (DC) breach monitoring and resultant adjustment of GC and/or DC values;
The distribution of Registration reports to the BSC Parties on the occurrence of processing of requests and registration information;
The distribution of registration details to other components of the NETA system either on demand or as batch processing.

4.1.1 Registration Process

With the exception of functionality concerning the calculation of credit assessment import and export capabilities, the bulk of the CRA functionality is to log, store and forward registration information. The CRA shall receive this information for a variety of object types, but the manner in which they are entered into the system is common across types.

Registration requests are sent to the CRA in either manual (paper based, e-mail) or electronic format from the relevant Party. An Operator (for definition of this term see Section 9) shall then be able to enter the details into the appropriate registration form, correlate that any supporting documentation has been received, and save the data. Alternatively requests may be made online via the Self-Service Gateway. The checking and authorisation of the data will be logged in the Self-Service Gateway by the BSCCo user or Operator, as appropriate.

Where the input data has been sent to the CRA through an automated electronic flow, the system shall present the Operator with a human readable version of the data from which the data may be “cut and pasted” from one screen to another.

Where the data has been sent to the CRA through a manual mechanism, the Operator shall enter the details from the original medium into the CRA.

This process, regardless of registration object, thus has a number of key, common features. These are detailed in CRA-N001 and summarised below prior to the individual functional requirements.

1. Where appropriate registration actions or changes to registered data shall require the prior approval of BSCCo Ltd. The approval process will be facilitated by the Self-Service Gateway. Where the Self-Service Gateway is not used for data entry by the BSC Party, BSC Party Agent or applicant, or where paper based supporting documentation is required, an Operator shall be expected to check that this authorisation has been received when processing the Registration request and supporting documentation. The Self-Service Gateway will provide facilities to

• allow for cross-referencing between paper and electronic registration information;

• log that all relevant checks have been completed

2. Should the data, once entered on the input form fail input validation, the Operator/Self-Service Gateway user will be presented with the failure reason. The Operator/Self-Service Gateway user shall then be presented with the ability to save the valid parts of the registration (subject to database constraints) in a “Pending” state rather than having to abort the entire update. While in this state, the data will be “invisible” to other parts of the BSC Central Systems. For instance it will not be issued to other Services (CDCA, SAA). At a later time, the Operator/Self-Service Gateway user shall be able to retrieve the partial update and complete the registration operation when the original failure has been corrected.

3. Certain registration items (such as BM Units) are expected to be registered from a limited sub-set of Party types. The CRA system shall ensure that a check against Party type is conducted on entry or amendment of registration details.

4. All registration entries/amendments shall be tagged with the date and time of the operation as well as the identifier (username) of the Operator/Self-Service Gateway user who entered the details.

5. Each registration operation may require a specific level of authorisation within the requesting Party. The CRA stores these levels of authorisation and shall validate that the requesting person has the authorisation to conduct the requested operation. Where this check fails the CRA shall reject the entire request. The Role-Based Access Control (RBAC) provided by the Self-Service Gateway will be used to authenticate online requests.

6. The CRA system shall (with exceptions such as on change of ownership of BM Units and Interconnector Error Administration responsibility) only accept registration amendments from the Party that sent in the original registration request.

7. Where data is to be input manually, the service shall use reasonable endeavours to ensure that the quality of the data is not compromised in any way.

4.2 Service Context

The following diagram illustrates the context of the CRA service within the wider market of the Balancing and Settlement Code. This is a simplified view for clarity; section 6 describes the interfaces from the CRA service to other Parties in detail.

Item	Description
Bank	A bank that receives debit and credit instructions from the Funds Administration Agent.
BMRA	Balancing Mechanism Reporting Agent.
BSC Party	Any user of Balancing and Settlement Code services.
BSCCo Ltd	The Balancing and Settlement Code Company.
CDCA	Central Data Collection Agent.
CRA	Central Registration Agent (including the Self-Service Gateway)
Credit Agency	A credit agency that provides credit cover data on Parties.
ECVAA	Energy Contract Volume Aggregation Agent.
ECVNA	Energy Contract Volume Notification Agent.
FAA	Funds Administration Agent.
IA	Interconnector Administrator.
IEA	Interconnector Error Administrator
Meter	A physical meter registered within the Balancing and Settlement Code arrangements.
MIDP	Market Index Data Provider
CVA MOA	Central Volume Allocation Meter Operation Agent.
MVRNA	Metered Volume Reallocation Notifications Agent
NETSO	National Electricity Transmission System Operator
Public	A member of the general public.
SAA	Settlement Administration Agent.
SVAA	Supplier Volume Aggregation Agent
TAA	Technical Assurance Agent.
Transfer Coordinator	A role undertaken by BSCCo Ltd to coordinate transfers of metering between CVA (CRA & CDCA) and SVA in order to address the risk that Metering Systems are ‘double counted’ or ‘omitted’ from Settlements’.

4.3 User Requirements Source Documents

In addition to our tender, the reference documents listed in section 1.5 have been used. The code listed in the first column is used as a cross reference in the detailed requirement specifications listed in section 5.

4.4 Numbering Scheme for Requirement Definitions

The present solution maps the requirements for the BSC Services across a number of computer systems plus a set of manual processes, so it is vital that each requirement across the set of services is uniquely identified. This allows us to trace through each individual requirement from URS to System Specification (i.e. functional specification) and then to Design Specification (technical specification).

In keeping with industry good practice, this URS adopts a requirements numbering system that works as follows:

1. Each requirement is associated with either an individual service, or is common to all services supported by our systems (i.e. TAA will typically be excluded from the latter). If a requirement applies to more than one service, but not all (e.g. two out of six), then the requirement is restated for each, i.e. there would be two separately numbered requirements (which happen to be the same) in this example.

Each requirement is prefaced by one of the following codes, as a clear indicator as to which service generates the business need:

CRA (Central Registration Agent);
SAA (Settlement Administration Agent);
CDCA (Central Data Collection Agent);
ECVAA (Energy Contract Volume Aggregation Agent);
BMRA (Balancing Mechanism Reporting Agent);
TAA (Technical Assurance Agent);
FAA (Funds Administration Agent);
GEN (General).

2. Requirements are categorised into the following headings:

Functional (F), a specific business requirement of the service.
Non-functional (N), which includes auditing, security, resilience, etc.
Service (S), which includes all time-related service delivery requirements, including performance and volumetrics.
Interface (I), a requirement for data exchange between services or to and from external parties.

3. Within a service, each requirement has a unique number in the range 001 to 999. Numbers are not unique across services. Leading zeroes are always included.

Combining 1, 2 and 3 thus gives the following format for numbering each requirement (including a separator character):

[Service]-[Category][Number]

For example:

• CRA-F001

• BMRA-S022

• GEN-N112

• SAA-I033

4.5 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: A unique identifier for the requirement, as described above.

Status: While the majority of CRA requirements will be mandatory for the Go Live date, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: A short descriptive title for the requirement.

BSC reference: A cross reference to the BSC section which is the original source of the business need. Note that there may be detailed requirements identified in the User Requirements Specification which are not individually described in the BSC; in this case this field is used to reference the alternative source of the requirement, for instance a specific workshop with the customer’s user community. The references shall use the abbreviations in section 1.5 above.

Man/Auto: This field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism. This is not however intended to be prescriptive, and the approach to supporting any individual requirement will be made definitively during the design phase.

Frequency: An indication of how often a business event will take place. Minimum, maximum and average frequencies, and any timing or scheduling requirements, are also identified here, as appropriate.

Volumes: Data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

The requirement is then described in detail, with any associated specific non-functional and interface requirements separately identified.

5 Functional Requirements

This section describes the detailed set of business requirements for the Central Registration Service. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is assigned a unique number, based on the convention described in section 4. The requirements have been constructed, at this version of the document from the documents referenced as in chapter 1.

5.1 CRA-F001: Register BSC Party

Requirement ID:

CRA-F001

Status:

Mandatory

Title:

BSC Reference:

CRA SD 4.1, CRA SD 4.2, CRA SD 4.3, CRABPM 3.1, CRAWS -20, CR_18_990909, P197

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Mostly at initial set-up

Functional Requirement:

The CRA shall allow an Operator or authorised Self-Service Gateway user to manually enter new BSC Party Registration Information into the CRA system.

The CRA system shall recognise a set of BSC Party types including (and not exclusively):

a) Transmission Owner,

b) NETSO,

c) Distribution Company,

d) Interconnector Administrator,

e) Trading Party

f) Interconnector Error Administrator (Note: These will be associated with pseudo-BM Units and will have Energy Accounts)

g) Virtual Lead Party

In addition, Trading Parties may have one or more of the following roles:

i) Generator

ii) Supplier

iii) Trader (Non Physical)

iv) Interconnector User

Each of the Party types and roles allow for a different set of registration requests to be processed by the system. (For instance a non-physical Trader should not in the main be allowed to register Interconnectors). Where an attempt is made and is not expected according to role, the CRA shall flag a warning. The following table illustrates these relationships.

	GSP Group	GSP	Interconnector	Trading Unit	Primary BM Unit	Secondary BM Unit	Boundary Point	Metering System
System Operator			X				X	X
Distribution Company	X	X	X				X	X
Trading Party				X	X			X
Virtual Lead Party						X

These registration requests shall subsequently be received by the CRA in accordance with the other requirements in this specification. None of these later requests shall be processed until the initial BSC Party Registration has been completed.

The BSC Party shall submit registration information to the CRA system including details of:

• An Action Description to specify the type of registration operation,

• the Party (name, contact details),

• the Party’s Stage 2 Names (where they exist).

• authorised signatories and individual contact details,

• settlement report distribution requirements,

• Party Agents that the Party shall use,

A detailed description of the interface content may be found in CRA-I001.

Along with the details of the registration request from the BSC Party, the CRA shall receive supporting information from BSCCo Ltd (via the Self-Service Gateway, as applicable). BSC Parties shall not be able to complete registration with the CRA before they have completed Qualification Processes. CRA will receive authorisation from BSCCo Ltd to register a particular party.

The input data shall be validated in accordance with the following rules:

1) The Party Types associated with the BSC Party Registration are valid according to the valid set of Party type standing data,

2) Each Interconnector that is used by the BSC Party conforms to a valid Interconnector ID stored within the system.

3) Where a BSC Party states a change to the usage of an Interconnector that these details match those received from the Interconnector Administrator (both in usage type and effective to and from dates).

4) That where the BSC Party is the Interconnector Error Administrator for an Interconnector, the details match those received from the Interconnector Administrator registration details (both in responsibility and effective to and from dates).

5) That the Party Agents that the Party shall use are registered for the period of the registration request.

6) That there is at least one authorised signatory sent to the CRA.

Where the data has passed validation the information shall be stored within the CRA system database after being authorised by a Supervisor. Any authentication details (authorised signatories) referenced within the message shall be stored according to the requirements of CRA-F002. The CRA system shall then allocate and return to the Operator a meaningful and unique BSC Party ID and two energy account identifiers (derived from the BSC Party ID) in accordance with CRA-F004 and CRA-F005.

The CRA system shall also provide the BSC Party with sufficient information for the authentication of future communications, electronic or otherwise.

Where the BSC Party is of a type “Supplier” the CRA system shall trigger the registration of one BM Unit registration request for each GSP group in accordance with the requirements of CRA-F013.

Non Functional Requirement:

Interfaces:

Input interfaces:

CRA-I001

Output Interfaces:

CRA-I014

CRA-I015

CRA-I013

CRA-I012

5.2 CRA-F002: Maintain Authentication Data

Requirement ID:

CRA-F002

Status:

Mandatory

Title:

Maintain Authentication Data

BSC Reference:

CRA BPM 3.1, CRA SD 4.2.2, CRA SD 4.1.7, CRAWS-21, CP756 CP1193

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low, a few 10’s per month after initial set-up.

Functional Requirement:

The CRA shall allow an Operator to enter and maintain authentication data against which incoming BSC party registration requests may be authenticated. The CRA will also obtain and maintain authentication information from BSCCo Ltd nominated signatories.

The authentication details (authorised signatory, password and optionally an e-mail address) will be stored within the system against the BSC Party along with the authentication key for the BSC Party.

Where the password for an authorised signatory is changed, the old password must be entered correctly in order for the update to take place. Only if the current password is entered correctly will the new password be accepted. The new password will then be effective for all authentication processes from the date and time at which the update was accepted.

In the special case where a BSC Party has no current authorised signatories, the first entrant shall be accepted without confirmation checks. Validation that this signatory’s name and password is correct shall be a manual process according to CRA-F001.

The new authentication details shall be distributed to the BSCCO, FAA, ECVAA and SAA systems according to the distribute register data requirement (CRA-I013) by 5.00pm on the day of update or additionally as necessary.

Where the Self-Service Gateway is used and the relevant operation is supported by the Self-Service Gateway, Role-Based Access Control (RBAC) will be used to authenticate online requests.

Non Functional Requirement:

Interfaces:

Output Interfaces:

CRA-I013

5.3 CRA-F003: Authenticate Party

Requirement ID:

CRA-F003

Status:

Mandatory

Title:

Authenticate Party

BSC Reference:

CRA BPM 3.1, CRA SD 4.1, CP756

Man/Auto:

Automatic/ Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall perform authentication validation between authentication data contained on incoming registration requests against that held within the system. The system authentication data will have been entered previously through process CRA-F002.

The authentication check shall consist of validating the password of the authorised signatory against that held within the system.

Where the request is received via e-mail, the authentication check will validate the password and the sender’s e-mail address against those held within the system for the authorised signatory. A request received via e-mail can only be authenticated if the signatory has a registered password.

The success / failure of all authentication checks will be maintained within the system along with the date and time of the request.

Where the Self-Service Gateway is used and the relevant operation is supported by the Self-Service Gateway, Role-Based Access Control (RBAC) will be used to authenticate online requests.

Non Functional Requirement:

Interfaces:

5.4 CRA-F004: Allocate BSC Party ID

Requirement ID:

CRA-F004

Status:

Mandatory

Title:

Allocate BSC Party ID

BSC Reference:

CRA BPM 3.1, CRA SD 4.1.2, CRAWS-24

Man/Auto:

Automatic

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall, on receipt of a new BSC Party Registration request, create a unique and meaningful party identifier irrespective of role. Self-Service Gateway users may choose their own identifier.

The CRA system shall perform a check against the name of the BSC Party and currently stored BSC Parties.

To avoid errors of duplication, should a potential duplicate BSC Party name be found, the system will issue a warning which must be overridden prior to allocation of a new identifier.

Non Functional Requirement:

Interfaces:

5.5 CRA-F005: Allocate BSC Party Energy Account

Requirement ID:

CRA-F005

Status:

Mandatory

Title:

Allocate BSC Party Energy Account

BSC Reference:

CRA BPM 3.1, CRA SD 4.1.2, CRAWS-25

Man/Auto:

Automatic

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall, on request, allocate energy account identifiers for a BSC Party. Two energy accounts must be allocated to any individual BSC Party (one for production, one for consumption), with the exception of Virtual Lead Parties who will be allocated a single Virtual Balancing Account. A standard convention will be used for identification of the account based upon the BSC Party Identifier. The effective start date of the energy account shall be provided to the CRA system and stored against the accounts.

Non Functional Requirement:

Interfaces:

5.6 CRA-F006: View / Maintain BSC Party Registration Details

Requirement ID:

CRA-F006

Status:

Mandatory

Title:

View / Maintain BSC Party Registration Details

BSC Reference:

CRA BPM 3.1, CRA SD 4.1.1, CRAWS-20, CRAWS-26, CP508

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low, expected rate to be a few 10’s per month.

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator of the system to view and amend the details of a BSC Party. Self-Service Gateway users shall be allowed to view and amend details of their own BSC Party. The CRA shall allow a BSC Party to change any part of its registration information as specified in CRA-I001 and CRA-F001.

In addition, the system shall provide functionality for the de-registering of a BSC Party in accordance with the specific functionality detailed in the deregistration requirement below:

The system shall validate the authentication details (signatory and password) contained within the message against those held currently against the BSC Party in accordance with requirement CRA-F004.

The input data shall be validated in accordance with the following rules:

1) Any change to the Party Types associated with the BSC Party Registration are valid according to the valid set of Party type standing data,

2) Any Interconnector usage specified by the BSC Party references a valid Interconnector ID stored within the system.

Changes, addition or amendment to authorisation data, shall be handled according to the requirements in CRA-F002.

Viewing of certain information, such as the authentication details for the Party, may be restricted to authorised personnel only.

BSC Party information may not be physically deleted from the system, it may only be logically deleted.

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.

Deregistration of BSC Party

In the special case where a BSC Party is de-registered, the CRA system shall check the validity of the termination request by ensuring that all sub-ordinate registrations for the Party (such as BM Units) have been de-registered prior to the request. Where this has not occurred, the CRA system shall inform the Operator of the fact and await confirmation of action.

The CRA shall require the explicit prior approval of the deregistration from BSCCo Ltd.

Non Functional Requirement:

If the Party sends a “CRA-I001 Receive BSC Party Registration Data” flow to CRA which requires authorisation by BSCCo Ltd as described above, then CRA will forward this directly to BSCCo Ltd. (Note: once the data has been forwarded to BSCCo Ltd, the flow processing has been completed. If BSCCo Ltd approve the change then BSCCo Ltd will submit a CRA-I001 to CRA containing the approved changes). The approval process will be carried out using the Self-Service Gateway, where applicable.

Interfaces:

Input interfaces:

CRA-I001

Output Interfaces triggered from this action:

CRA-I014

CRA-I015

CRA-I013

CRA-I028

5.7 CRA-F007: Register Interconnector Administrator

Requirement ID:

CRA-F007

Status:

Mandatory

Title:

BSC Reference:

CRA SD 4.1.3, CRAWS-20, CRAWS-27, CRAWS-28

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA shall allow an Operator or Self-Service Gateway user to enter registration details for an Interconnector Administrator. The details shall consist of:

• An Action Description

• Interconnector Administrator Identification and Authentication Data

• Contact Details

• Interconnector Details

• Interconnector Error Administrator Details

A detailed description may be found in the requirements for CRA-I002.

The CRA system shall validate incoming data according to the following rules:

1) That each of the Interconnectors specified in the details are registered within the system,

2) That no other Interconnector Administrator is assigned to the Interconnector.

Where an Interconnector Administrator is already specified for the Interconnector, the system shall only allow the request to proceed if the effective from date of the new Interconnector Administrator matches the effective to date of the currently stored record.

Where data is registered in respect of an Interconnector Error Administrator, the CRA shall require the explicit authorisation of BSCCo Ltd. The approval process will be carried out using the Self-Service Gateway, where applicable.

The CRA system shall accept registration requests as per CRA-I002 where no Interconnector Error Administrator is specified on initial registration. This condition will be reported to the Operator for confirmation on entry and subsequently reported in accordance with the requirements of CRA-F023. Assignment of an Interconnector Error Administrator may then be conducted at a later time through CRA-F008.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I002

Output Interfaces triggered from this action:

CRA-I014

CRA-I015

CRA-I019

CRA-I020

5.8 CRA-F008: View / Maintain Interconnector Administrator Data

Requirement ID:

CRA-F008

Status:

Mandatory

Title:

View / Maintain Interconnector Administrator Data

BSC Reference:

CRA SD 4.1.3, CRAWS-29

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to view / amend the details of an Interconnector Administrator registration.

The CRA system shall allow the Interconnector Administrator to change any details of the registration. The CRA will be sent any changes, including:

• An Action Description

• Interconnector Administrator Identification and Authentication Data

• Contact Details

• Interconnector Details

• Interconnector Error Administrator Details

A detailed description can be found in the requirements for CRA-I002.

Where the details state that the Interconnector Administrator is ceasing registration of the role, it is the responsibility of the Operator to ensure that this obligation has the agreement of BSCCo Ltd. This shall be conducted by review of supporting documentation from BSCCo Ltd and the fact that this check has been conducted shall be enterable against the transaction. The system shall then prompt the Operator to register the new Interconnector Administrator (through CRA-F007). If this cannot be entered, the fact that the Interconnector has no Administrator shall be flagged through CRA-F023 daily while this situation persists.

Where data is sent concerning a change of Interconnector Error Administrator, the data provided from the Interconnector Administrator shall require the explicit authorisation of BSCCo Ltd. The approval process will be carried out using the Self-Service Gateway, where applicable.

Non Functional Requirement:

Interfaces:

5.9 CRA-F009: Register BSC Party Agent

Requirement ID:

CRA-F009

Status:

Mandatory

Title:

BSC Reference:

CRA SD 4.2, CRA SD 5, CRA BPM 3.5, CRAWS-30, P197

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low, Few 10’s per month

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to enter the registration details for a BSC Party Agent.

The range of valid BSC Party Agent types shall be defined as (not exclusively):

a) Energy Contract Volume Notification Agents,

b) Metered Volume Reallocation Notification Agents

c) Half Hourly Data Collector Agents

d) Half Hourly Data Aggregator Agents

e) Non Half Hourly Data Collector Agents

f) Non Half Hourly Data Aggregator Agents

g) Meter Administration Agent

h) Supplier Meter Administration Agent

i) CVA Meter Operator Agents

The CRA shall receive the following information from BSCCo Ltd:

• Authentication Details

• BSC Party Agent Details

• Individual Authorisation Details and signatories

• Certification /Accreditation Details³

Full details of the flow may be found in CRA-I003.

It is expected that the initial Registration from BSCCo Ltd may consist of only the BSC Party Agent Details and Qualification Details. The remainder of the registration details (such as Authorised Signatories) would be sent later by either the BSC Party Agent or BSCCo Ltd.

It shall be the responsibility of an operator of the CRA system to validate the following data against paper documentation:

1) That the BSC Party Agent has been registered with BSCCo Ltd,

2) That the BSC Party Agent has been Qualified.

Confirmation that each of these checks has been conducted shall be enterable into the CRA system alongside the entering Operator’s identification details.

The system shall store the authentication data contained in the flow according to the requirements of CRA-F002.

The CRA shall only accept a registration where the BSC Party Agent has a valid Qualification status (where applicable). Where the Qualification status is not valid, the details may be entered into the system though the BSC Party Agent will not be regarded as Registered. The Qualification status may subsequently be amended through the View / Maintain BSC Party Agent Registration requirement, at which point the Registration of the Agent will be completed.

On successful registration of the BSC Party Agent, a report detailing the BSC Party Agent, Registration, and Qualification Details shall be triggered. (CRA-I024)

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I003

Output interfaces:

CRA-I013

CRA-I014

CRA-I024

5.10 CRA-F010: View / Maintain BSC Party Agent

Requirement ID: CRA-F010	Status: Mandatory	Title: View / Maintain BSC Party Agent	BSC Reference: CRA SD 4.2, CRAWS-30, CP503, P197
Functional Requirement:
The CRA system shall allow a Self-Service Gateway user or an Operator to view and maintain BSC Party Agent details. The BSC Party Agent Registration amendment will concern elements of the following data: • Authentication Details • BSC Party Agent Details • Individual Authorisation Details and signatories • Certification/Accreditation Details⁴ Full details of the flow may be found in CRA-I003. The system shall validate that: 1) In the case where the amendment is to de-register an ECVNA or MVRNA, that the agent has no authorisations registered with ECVAA beyond the agent termination date. This communication is described by the requirements CRA-I036 and CRA-I037. The system shall allow for the amendment of the Qualification and registration details as well as the details concerning the BSC Party Agent itself (such as address and contact data). The CRA shall provide a mechanism for the management and storage of re-Qualification data where re-Qualification becomes necessary. Where the registration update is to de-register a BSC Party Agent, the system shall inform all BSC Parties that have specified a use of the Agent. Affected Parties will continue to be flagged in the CRA system through CRA-F023.
Non Functional Requirement:

Interfaces:
Input Interfaces: CRA-I003 Output interfaces triggered from this activity: CRA-I013 CRA-I014 CRA-I024 ECVAA Validation interfaces: CRA-I036 CRA-I037

Requirement ID:

CRA-F010

Status:

Mandatory

Title:

View / Maintain BSC Party Agent

BSC Reference:

CRA SD 4.2, CRAWS-30, CP503, P197

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low, Few 10’s per month

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to view and maintain BSC Party Agent details.

The BSC Party Agent Registration amendment will concern elements of the following data:

• Authentication Details

• BSC Party Agent Details

• Individual Authorisation Details and signatories

• Certification/Accreditation Details⁴

Full details of the flow may be found in CRA-I003.

The system shall validate that:

1) In the case where the amendment is to de-register an ECVNA or MVRNA, that the agent has no authorisations registered with ECVAA beyond the agent termination date. This communication is described by the requirements CRA-I036 and CRA-I037.

The system shall allow for the amendment of the Qualification and registration details as well as the details concerning the BSC Party Agent itself (such as address and contact data).

The CRA shall provide a mechanism for the management and storage of re-Qualification data where re-Qualification becomes necessary.

Where the registration update is to de-register a BSC Party Agent, the system shall inform all BSC Parties that have specified a use of the Agent. Affected Parties will continue to be flagged in the CRA system through CRA-F023.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I003

Output interfaces triggered from this activity:

CRA-I013

CRA-I014

CRA-I024

ECVAA Validation interfaces:

CRA-I036

CRA-I037

5.11 CRA-F011: Register BSC Service Agent

Requirement ID:

CRA-F011

Status:

Mandatory

Title:

BSC Reference:

CRA SD 4.3, CRAWS-31, P82, P197

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to enter the registration details for the following BSC Service Agents, operating under the direct control of BSCCo Ltd. The list shall include:

1) Supplier Technical Assurance Agent

2) Supplier Teleswitch Support Agent

3) Supplier Volume Aggregation Agent

4) Settlement Administration Agent

5) Balancing Mechanism Reporting Agent

6) Energy Contract Volume Aggregation Agent

7) Funds Administration Agent

8) Supplier Volume Allocation Agent

9) Central Data Collection Agent

10) Central Registration Agent

The following information concerning the Service Agent is supplied by BSCCo Ltd:

• Name

• Type

• Contact Details

Full details of the interface may be found in CRA-I004.

The system shall validate that:

1) The name entered against the Service Agent is not already contained within the database.

2) The Agent Type is compliant with one of the agent types described above.

It shall be the responsibility of an Operator of the CRA system to validate the following data against paper documentation:

• That the BSC Service Agent has been registered with BSCCo Ltd

Non Functional Requirement:

Interfaces:

Input Interfaces:

CR-I004

Output Interfaces triggered by this activity:

CR-I013

CR-I014

CR-I021

5.12 CRA-F012: View / Maintain BSC Service Agent

Requirement ID:

CRA-F012

Status:

Optional

Title:

View / Maintain BSC Service Agent

BSC Reference:

CRA SD 4.3, CRAWS-31

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service user or an Operator to view and maintain BSC Service Agent details.

The following information is presented from BSCCo Ltd concerning the Service Agent:

• Name

• Type

• Contact Details

Any change to the BSC Service Agent details that results in a change of the registration state shall trigger the production of a registration report.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CR-I004

Output Interfaces triggered by this activity:

CR-I013

CR-I014

CR-I020

CR-I021

5.13 CRA-F013: BM Unit Registration

Requirement ID:

CRA-F013

Status:

Mandatory

Title:

BM Unit Registration

BSC Reference:

CRA SD 6.1, CRA BPM 3.2, NGC VAL 3.0, CRAWS-32, DID-2, CP753, CP775, P100, P215, P268, P269

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service user or an Operator to enter details of a BM Unit registration into the system. BM Units may be of 6 principal (though not exclusively limited to these) types:

i) Directly Connected BM Unit

ii) Supplier BM Unit (Base and Additional)

iii) Embedded site within GSP Group

iv) Interconnector Error Administrator BM Unit

v) Interconnector User BM Unit

vi) Secondary BM Unit

With the exception of Secondary BM units, only Trading Parties should in the main be allowed to register BM Units though other Parties shall be allowed to register them, as per CRA-N001. Only Virtual Lead Parties may register a Secondary BM Unit.

BM Units are related to GSP Groups, Interconnectors and Boundary Points dependent upon the type of the BM Unit. The CRA system shall maintain the relationship between a BM Unit and either a GSP Group or Interconnector, but not a Boundary Point. The following table illustrates which BM Unit types require an association to a GSP Group / Interconnector to be specified.

	GSP Group	Interconnector
Directly Connected
Supplier	X
Embedded Site within GSP Group	X
Interconnector Error Administrator		X
Interconnector Usage		X
Secondary BM Unit	X

A BM Unit registration request shall contain the following information:

• An Action Description

• The BM Unit Registration Details (including type, production / consumption flag and whether an NETSO defined name is contained within the flow)

• Generation Capacity and Demand Capacity (not required for Secondary BM Units)

• Details of the GSP group associated with the BM Unit (if appropriate)

• Details of the Interconnector associated with the BM Unit (if appropriate)

• Mapping Details defining the relationships between SVA MSIDs and the BM Unit

• FPN Flag for the BM Unit

• Base TU Flag

A detailed description of the interface content may be found in CRA-I005.

The CRA shall accept updated details of the registration from BSCCo Ltd including:

• Exempt Export Flag (not applicable to Secondary BM Units)

A detailed description of the interface content may be found in CRA-I043.

The system shall validate the following details:

1) That the referenced lead Party is contained within the system and is a currently valid BSC Party and not a Party Agent

2) That the GSP Group referenced is contained within the system (where appropriate for type)

3) That the Interconnector referenced is contained within the system (where appropriate for type)

4) That the name provided for the BM unit is not duplicated within the system

5) That the sending BSC Party is of a type able to register a BM Unit as specified in the mapping between BSC Party types and Registration operations

6) That a valid (not null) WDCALF and NWDCALF value has been received (see CRA-F020) and entered, with the exception of Secondary BM Units for which these values do not apply

7) That if the BM Unit is a “Supplier BM Unit”, then a valid (not null) SECALF value has been received (see CRA-F020) and entered

8) That if the BM Unit is a “Supplier BM Unit”, then the Effective To Date for the BM Unit is open ended.

Where a duplicate name is found, the system shall warn the Operator of the fact and ask for confirmation before further processing. Where the last check is failed, the Operator shall be presented with a warning which must be explicitly overridden prior to acceptance of the data.

Production / Consumption Flag

Should the Production / Consumption flag be set within the flow, it is the responsibility of the Operator to ensure that an authorisation to support this has been received from BSCCo Ltd. The CRA system shall not allow the Production / Consumption Flag to be set for a non-Exempt Export BM Unit (unless it is an Interconnector User BM Unit or Secondary BM Unit, in which case the flag must be set).

In the case of an Exempt Export BM Unit, the Production / Consumption flag shall always be set to either “Production” or “Consumption” and shall never be cleared by the Operator while the BM Unit has Exempt Export status.

Exempt Export Flag⁵

On registration, the Exempt Export Flag shall be unset by default for all BM Units. The Exempt Export Flag will remain unset for all Secondary BM Units.

Base TU Flag

On registration, the Base TU Flag shall be set by default for all Base Supplier BM Units and Additional Supplier BM Units to indicate that the BM Unit is allocated to the GSP Group Base Trading Unit. The Base TU Flag shall be unset by default for all non-Exempt Export Embedded BM Units. The CRA system shall not allow the Base TU flag to be set for Directly Connected or Interconnector User BM Units.

A Secondary BM Unit cannot be in a Trading Unit; however, for the purposes of determining the relevant Transmission Loss Multiplier (TLMij), the Trading Unit Delivery Mode of the Base Trading Unit shall be used based on the GSP Group Id of that Secondary BM Unit).

After all validation has been completed, the system shall return a new unique, meaningful identifier for the BM Unit on completion of storing the registration data. Self-Service Gateway users may select a BM Unit identifier, subject to a uniqueness check. Where an NGC BM Unit name is supplied, this shall be stored against the BM Unit, though the name shall not be considered when generating the NETA BM Unit Identifier. In addition, the event shall trigger the creation of a Trading Unit for the BM Unit in accordance with the requirement of CRA-F015.

Where registration is accepted, the system shall calculate the WDBMCAEC, NWDBMCAEC, WDBMCAIC, NWDBMCAIC and Production / Consumption status (except for Secondary BM Units) and trigger the sending of a BM Unit, Interconnector and GSP Group Data (CRA-I015) report and a Registration Report (CRA-I014).

The CRA may from time to time issue the Credit Assessment Capability (CRA-I017) report to the SAA and ECVAA.

The calculation of the Production / Consumption status will only be conducted where the Production / Consumption flag is not set on reception from the BSC Party. Where the Base TU Flag is set and the Production / Consumption flag is null, the Production / Consumption status of a BM Unit shall be set to “Consumption” by default. Note that the Production / Consumption flag cannot be set to null for an Exempt Export BM Unit.

Where the requirement functionality has been triggered from CRA-F001 or CRA-F030 in order to create a “Supplier BM Unit”, a subset of the CRA-I015 output data flow shall be sent to the SVAA.

Where the input details state a relationship between a BM Unit and one or many SVA MSIDs, the system shall store the relationship and issue a report on the mapping to the SMRA through CRA-I023.

Where the registration is indicated as part of a transfer to or from SMRA, then

• If confirmation of the transfer has been received from the transfer coordinator:

- Enter the data ensuring the confirmed date is used as this may differ from that originally submitted.

- Send an extract of the entered data to the transfer coordinator.

• Where confirmation has not been received:

- Carry out validation but do not enter the data.

- Send a copy of the request to the transfer coordinator.

A BM Unit, other than a Secondary BM Unit, will be considered as having a Credit Qualifying Status of “True” for those effective Settlement Dates where it meets the following conditions:

• It is not an Interconnector BM Unit; and

• Its FPN Flag set as “True”; and

• Either:

1. It is an Exempt Export BM Unit; or

2. It has a Production/Consumption Flag set as “Production”; or

For all other effective Settlement Dates a BM Unit will be considered as having a Credit Qualifying Status of “False”.

A BM Unit will have its Demand-in-Production Flag set as “True” for those effective Settlement Dates where it meets the following conditions:

• It is not an Exempt Export BM Unit; and

• It has a Credit Qualifying Status of “False”; and

• It has a Production/Consumption Flag set as “Production”; and

• Its Relevant Capacity is not greater than zero (i.e. GC_i + DC_i <= 0).

For all other effective Settlement Dates a BM Unit’s Demand-in-Production Flag set as “False”.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I005

Output interfaces:

CRA-I014

CRA-I015

CRA-I017

CRA-I019

CRA-I020

CRA-I023

CRA-I028

5.14 CRA-F014: View / Maintain BM Unit Registration

Requirement ID:

CRA-F014

Status:

Mandatory

Title:

View / Maintain BM Unit Registration

BSC Reference:

CRA SD 6.1, CRA BPM 3.2, NGC VAL 3.0, CRAWS-34, CRAWS‑37, DID‑2, CP775, P100, P215, P268, P269

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low (A few per month)

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to view and amend the details of a BM Unit registration within the system.

The CRA shall accept updated details of the registration from the BSC Party or BSCCo (as set out in CRA-F041 & CRA-F043) including:

• The BM Unit Registration Details (including type, production / consumption flag and whether an NETSO defined name is contained within the flow)

• Positive QMij-(for conversion to Generation Capacity) and Negative QMij (for conversion to Demand Capacity) (not required for Secondary BM Units)

• Details of the GSP group associated with the BM Unit (if appropriate)

• Details of the Interconnector associated with the BM Unit (if appropriate)

• Whether the BM Unit is part of a group of related BM Units and, where appropriate, the other BM Units in the group.

• MPAN - BM Unit mapping Details

• BM Unit FPN Flag

• Base TU Flag

A detailed description of the interface content may be found in CRA-I005.

The CRA shall accept updated details of the registration from BSCCo Ltd including:

• Exempt Export Flag (not applicable to Secondary BM Units)

A detailed description of the interface content may be found in CRA-I043.

The Operator shall be able to:

1) Amend the details of the BM Unit - type (production / consumption), generation capacity, location and name,

2) Change the lead Party for the BM unit,

3) Amend the list of MPANs associated with the BM Unit.

The following sections detail the constraints under which each of the operations may be conducted.

Where the NGC BM Unit Name is changed, the system shall update the BM Unit with the new name, and the date of the change.

Where Generation Capacity is decreased or Demand Capacity is increased within a BSC Season, the CRA system shall issue a warning to the Operator and ask for explicit confirmation of the change. This would be allowed only if authorisation for the change has been received from BSCCo Ltd. Generation Capacity and Demand Capacity are not applicable for Secondary BM Units).

The WDCALF, NWDCALF and SECALF values (see CRA-F020) cannot be set to NULL for a current BM Unit, except for Secondary BM Units, to which these values do not apply.

If the BM Unit is a “Supplier BM Unit” that was originally created as a result of a trigger from CRA-F001 or CRA-F030 (i.e. it is a “Base BM Unit”), the CRA system will ensure that the Effective Date Range of the BM Unit is contiguous and open ended. If it is not, then the CRA system shall issue a warning to the Operator to ask for explicit confirmation of the change. This should generally be allowed only if:

1. the BM Unit is being de-registered as a result de-registration of the associated BSC Party or GSP Group, i.e. the Effective To Date is changed from open ended to a specified date,

2. the BM Unit is being re-registered following de-registration, i.e. the Effective From Date of the new record is after the Effective To Date of an existing record.

Where the Lead Party is being changed, that the referenced lead Party is contained within the system and is a currently valid BSC Party and not a Party Agent. The ownership of a Secondary BM Unit may not be transferred to another Lead Party.

Where the generation capacity or demand capacity of the BM Unit is changed the system shall calculate the WDBMCAEC, NWDBMCAEC, WDBMCAIC and NWDBMCAIC, and trigger the sending of a BM Unit, Interconnector and GSP Group Data (CRA-I015) report and a Registration Report (CRA-I014)

The CRA may from time to time issue the Credit Assessment Capability (CRA-I017) report to the SAA and ECVAA.

Generation Capacity and Demand Capacity data, and Production / Consumption information may be resubmitted to the CRA at any time by the relevant Parties. However, it will be necessary for the Parties to submit the information at least one working day in advance of when the change will take effect.

Should the Production / Consumption flag be set within the flow, it is the responsibility of the Operator to ensure that an authorisation to support this has been received from BSCCo Ltd. The CRA system shall allow the Production / Consumption Flag to be changed for any Exempt Export BM Unit. The CRA system shall not allow the Production / Consumption Flag to be set for a non-Exempt Export BM Unit (unless it is an Interconnector User BM Unit or Secondary BM Unit, in which case the flag must be set).

Subsequently, this information shall be issued through interface CRA-I017.

The CRA system shall allow an Operator to view and update the Exempt Export Flag for a BM Unit.

The CRA system shall only allow the Exempt Export Flag to be changed for Base Supplier BM Units, Additional Supplier BM Units, Embedded BM Units and Directly Connected BM Units. The CRA system shall not allow the Exempt Export Flag to be changed for any other type of BM Unit.

Where a request to change the Exempt Export Flag of a Base Supplier BM Unit or Additional Supplier BM Unit indicates that the BM Unit is to be non-Exempt Export (and therefore, re-allocated to the GSP Group Base Trading Unit), the CRA shall validate that the BM Unit does not belong to an explicit Trading Unit already. If it does, the request shall be rejected.

Where a valid request to change the Exempt Export Flag indicates that the BM Unit is to be Exempt Export, the CRA shall set the Exempt Export Flag.

Where a valid request to change the Exempt Export Flag indicates that the BM Unit is to be non-Exempt Export, the CRA shall:

1. clear the Production / Consumption Flag to indicate that Production / Consumption Status is derived dynamically

2. for Base Supplier BM Units and Additional Supplier BM Units, set the Base TU Flag to indicate that the BM Unit is allocated to the GSP Group Base Trading Unit

3. for all other BM Units, unset the Base TU Flag and allocate the BM Unit to its own (default) Trading Unit

4. unset the Exempt Export Flag.

The new Exempt Export Flag shall subsequently be distributed as per the requirements of CRA-I014 and CRA-I020.

The CRA system shall allow for the transfer of responsibility of a BM Unit, with the exception of Secondary BM Units, from one lead Party to another. However, if the BM Unit is of a Supplier BM Unit, a warning shall be issued to the Operator.

The process of responsibility transference shall be a multi-step process conducted in the following manner:

Where a Party informs the CRA of responsibility for a BM Unit currently allocated to another Party, the CRA shall inform the Operator of this fact. The Operator must acknowledge this warning, upon which, the details of the registration change shall be stored within the system in a pending state. Should the effective start date by sooner than a predefined, system defined time limit [28 days]. The Operator shall also be warned of the fact.

On completion of the update an acknowledgement of the registration request will be sent to both the new and old Parties.

Where subsequently, a confirmation of the transference is sent from the old Party, the CRA system shall validate that the effective to date from the new Party is consistent with that received from the new Party. Where this occurs, the system shall update both the pending registration and the new registration.

Where the confirmation of responsibility is received after the effective start date of the new registration, the system shall present the Operator with a warning. This must be explicitly overridden by a Supervisor prior to the update being conducted. Where the Supervisor decides that the update cannot take place, the new registration request may also be put in a pending state for later resolution.

The change of BM Unit responsibility shall not require a change in BM Unit name.

Where the input details state a change to the relationship between a BM Unit and one or many Stage 2 MPAN’s, the system shall store the amended relationship and issue a report on the mapping to the SMRA through CRA-I023.

Where a request to change the Base TU Flag is received the CRA shall validate that the BM Unit is Exempt Export and, if not, the request shall be rejected.

The CRA system shall not allow the Base TU Flag to be changed for Directly Connected or Interconnector User BM Units.

Where a request to change the Base TU Flag indicates that the BM Unit is to be allocated to the GSP Group Base Trading Unit, the CRA shall validate that the BM Unit does not belong to an explicit Trading Unit already. If it does, the request shall be rejected.

Where a valid request to change the Base TU Flag indicates that the BM Unit is to be added to the GSP Group Base Trading Unit, the CRA shall re-allocate the BM Unit from its own (default) Trading Unit to the GSP Group Base Trading Unit.

Where a valid request to change the Base TU Flag indicates that the BM Unit is to be removed from the GSP Group Base Trading Unit, the CRA shall re-allocate the BM Unit to its own (default) Trading Unit.

Allocations and de-allocations to/from a GSP Group Base Trading Unit shall be made via the Base TU Flag only.

The Production / Consumption Status of the Base Trading Unit and its components shall be re‑computed for each change to a Base TU Flag. Where the Base TU Flag is set and the Production / Consumption flag is null, the Production / Consumption status of a BM Unit shall be set to “Consumption” by default. Note that the Production / Consumption flag cannot be set to null for an Exempt Export BM Unit.

A BM Unit will be considered as having a Credit Qualifying Status of “True” for those effective Settlement Dates where it meets the following conditions:

• It is not an Interconnector BM Unit; and

• Its FPN Flag set as “True”; and

• Either:

1. It is an Exempt Export BM Unit; or

2. It has a Production/Consumption Flag set as “Production”; or

For all other effective Settlement Dates a BM Unit will be considered as having a Credit Qualifying Status of “False”.

A BM Unit will have its Demand-in-Production Flag set as “True” for those effective Settlement Dates where it meets the following conditions:

• It is not an Exempt Export BM Unit; and

• It has a Credit Qualifying Status of “False”; and

• It has a Production/Consumption Flag set as “Production”; and

• Its Relevant Capacity is not greater than zero (i.e. GC_i + DC_i <= 0).

For all other effective Settlement Dates a BM Unit’s Demand-in-Production Flag set as “False”.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I005

CRA-I009

CRA-I043

Output interfaces:

CRA-I014

CRA-I015

CRA-I017

CRA-I019

CRA-I020

CRA-I023

CRA-I028

5.15 CRA-F015: Trading Unit Registration

Requirement ID:

CRA-F015

Status:

Mandatory

Title:

Trading Unit Registration

BSC Reference:

CRA SD 6.2, CRA BPM 3.2, CRAWS-35, P100

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to enter details of a Trading Unit registration into the system (excluding Base Trading Units). The information for the definition of the Trading Unit shall be composed of:

• An Action Description

• Trading Unit Details (name, registration dates)

• Component BM Units

The definition of a Trading Unit requires the explicit authorisation of BSCCo Ltd. It shall be the responsibility of the Operator to ensure that supporting documentation from BSCCo Ltd has been received and are consistent with the Trading Unit registration request.

Trading Units should only be created by BSC Traders though other Parties shall not be restricted in their creation as per CRA-N001.

The system shall validate the following details:

1) That each of the BM Units acceptance of commercial responsibility is registered and recorded within the CRA system.

2) That at least one BM Unit is listed as a component of the Trading Unit (by default, on creation of a BM Unit, a Trading Unit is defined for the BM Unit).

3) That Base Supplier BM Units and Additional Supplier BM Units are Exempt Export.

4) That Secondary BM Units may not be allocated to a Trading Unit

After all validation has been completed, the system shall return a new unique identifier for the Trading Unit on completion of storing the registration data.

Where a BM Unit is associated with a Trading Unit explicitly, any previous association with a Trading Unit will be removed. This includes removal from a GSP Group Base Trading Unit, which the CRA shall perform according to requirement CRA-F014.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I006

Output Interfaces:

CRA-014

CRA-I015

CRA-I019

CRA-I020

5.16 CRA-F016: View / Maintain Trading Unit Registration Details

Requirement ID:

CRA-F016

Status:

Mandatory

Title:

View / Maintain Trading Unit Registration Details

BSC Reference:

CRA SD 6.2, CRA BPM 3.2, CRAWS-35, CRAWS-39

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to enter details of Trading Unit registration changes into the system. The information for the amendment of the Trading Unit shall be composed of:

• An Action Description

• Trading Unit Details (name, registration dates)

• Component BM Units

Any change to a Trading Unit registration requires the explicit authorisation of BSCCo Ltd

The system shall validate that each of the BM Units’ acceptance of commercial responsibility is registered and recorded within the CRA system.

Where a BM Unit is removed from a Trading Unit, it shall be reassigned to its own (default) Trading Unit after completion of the operation. Where a BM Unit is added to a Trading Unit, it shall be removed from its (default) Trading Unit.

Where a change to the scope of the component BM Units (either through addition or subtraction) fails validation, the Trading Unit registration request will be held as pending subject to resolution.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I006

Output Interfaces:

CRA-I014

CRA-I015

CRA-I019

CRA-I020

5.17 CRA-F017: Register CRA Boundary Points and System Connection Points Details

Requirement ID:

CRA-F017

Status:

Mandatory

Title:

BSC Reference:

CRA SD 6.4, CRA BPM 3.3, CR_990813_07, CRAWS-36, CRAWS-39, CP615, CP1301

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

1. The CRA or Self-Service Gateway user shall register data relating to all Boundary Points and System Connection Points. These are registered by either the NETSO or a Distribution System Operator using flow CRA-I007 at least 20 WD before the Effective From date. The BSCP form on which this flow is based contains additional information which is not captured in the database, but which is used by other recipients of the form.

a. A Boundary Point is a point at which any Plant or Apparatus not forming part of the Total System is connected to the Total System (Total System means the Transmission System and each Distribution System)

Boundary Points Registered By NETSO are:

• Gensets directly connected to the Transmission Network

• Station Transformers directly connected to the Transmission Network

• Demand sites directly connected to the Transmission Network

• Interconnectors with other Transmission Systems

Boundary Points Registered by the Distribution Business are:

• Embedded sites, under the direct control of the NETSO, that form an individual BM Unit. (These are sites over 50 MW or those being despatched by the NETSO).

• Other Embedded sites.

• Interconnectors with other Transmission Systems (where these connect to a distribution system)

b. A System Connection Point is a point at which two or more Systems are connected, including a connection between Distribution Systems in different GSP Groups (but excluding a connection between Distribution Systems in the same GSP Group).

System Connection Points Registered By NETSO are:

• Grid Supply Points (including Offshore Transmission Connection Points)

• An Offshore Transmission Connection Point is a point where a Distribution System connects to an Offshore Transmission System and will be registered by the NETSO as a Grid Supply Point.

System Connection Points Registered By Distribution Business are:

• Interconnectors Between Distribution Networks

2. In each case CRA shall maintain the following information:

• Boundary Point, or System Connection Point Identifier;

• Boundary Point or System Connection Point Type

• Effective From Date

• Effective To Date

3. Where a request is received to create a Boundary Point or System Connection Point then CRA shall inform BSCCo Ltd by forwarding a copy of the information provided. BSCCo Ltd will be notified of any changes input using the Self-Service Gateway.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I007

Output Interfaces:

CRA-I007

CRA-I014

CRA-I019

CRA-I028

Issues:

5.18 CRA-F034: Register Metering System Details

Requirement ID:

CRA-F034

Status:

Mandatory

Title:

BSC Reference:

CRA SD 6.4, CRA BPM 3.3, CR_990813_07, CRAWS-36, CRAWS-39, CP569, CP753, P55, CP1301

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA shall receive the following information concerning the registration of Boundary Points and Metering Systems.

• An Action Description

• Authentication Details

• Metering System Details (including the CVA Meter Operator Agent for the Metering System)

Metering Systems should only be registered by certain types of BSC Parties. The following table illustrates which type of BSC Party should register a Metering System(See CRA-N001)

complex image of process

The NETSO shall register Metering System details for Offshore Transmission Connection Points only. All other Metering Systems for Grid Supply Points shall be registered by the Distribution Company.

It shall be the responsibility of the Operator to ensure that the type of the meter specified on the incoming flow is correct against any supporting paper based documentation.

Where metering system details are registered, the CRA shall validate that the CVA Meter Operator Agent specified against the metering system is registered with the CRA.

Where a Metering System is attempted to be registered but already exists within the system, the Operator shall be informed of the event and may, instead, enter the new details as an amendment to the current details through the View / Maintain Metering Systems functionality.

For each new Metering System registration, the CRA shall ensure that the registrant has confirmed that either:

• the Registrant is the Equipment Owner, or

• the Registrant has obtained the Equipment Owner’s consent for the appointment.

Where the registration is indicated as part of a transfer to or from SMRA, then

• If confirmation of the transfer has been received from the transfer coordinator:

- Enter the data ensuring the confirmed date is used as this may differ from that originally submitted.

- Send an extract of the entered data to the transfer coordinator.

• Where confirmation has not been received:

- Carry out validation but do not enter the data. If necessary allocate a Metering System Identifier and inform the registrant.

- Send a copy of the request, including any allocated metering system id, to the transfer coordinator.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I031

Output Interfaces:

CRA-I014

CRA-I019

CRA-I022

CRA-I028

Issues:

5.19 CRA-F018: View / Maintain Boundary Point and System Connection Point Details

Requirement ID: CRA-F018	Status: Mandatory	Title: View / Maintain Boundary Points Details	BSC Reference: CRA SD 6.4, CRA BPM 3.3, CRAWS-36, CRAWS-37, CRAWS-39
Functional Requirement:
The CRA shall receive changes to the registration of Boundary Points and System Connection Points. Changes may also be made using the Self-Service Gateway. Where a request is received to decommission a Boundary Point or System Connection Point then CRA shall inform BSCCo Ltd by forwarding a copy of the information provided. BSCCo Ltd will be notified of any changes input using the Self-Service Gateway.
Non Functional Requirement:

Interfaces:
Input Interfaces: CRA-I007 Output Interfaces: CRA-I014 CRA-I019 CRA-I028

Requirement ID:

CRA-F018

Status:

Mandatory

Title:

View / Maintain Boundary Points Details

BSC Reference:

CRA SD 6.4, CRA BPM 3.3, CRAWS-36, CRAWS-37, CRAWS-39

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA shall receive changes to the registration of Boundary Points and System Connection Points. Changes may also be made using the Self-Service Gateway.

Where a request is received to decommission a Boundary Point or System Connection Point then CRA shall inform BSCCo Ltd by forwarding a copy of the information provided. BSCCo Ltd will be notified of any changes input using the Self-Service Gateway.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I007

Output Interfaces:

CRA-I014

CRA-I019

CRA-I028

5.20 CRA-F019: View / Maintain Interconnector Registration

Requirement ID:

CRA-F019

Status:

Mandatory

Title:

View / Maintain Interconnector Registration

BSC Reference:

CRA SD 6.3, CRA BPM 3.6, CRAWS-38, CRAWS-39

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to register Interconnector Registration details. The details of an Interconnector shall be composed of:

• Action Description

• Authentication Details

• Interconnector Details (including GSP group where appropriate)

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I008

Output Interfaces:

CRA-I014

CRA-I015

CRA-I020

5.21 CRA-F020: Maintain Credit Assessment Load Factor

Requirement ID:

CRA-F020

Status:

Mandatory

Title:

Maintain Credit Assessment Load Factor

BSC Reference:

CRA SD 7.1, CRA SD 7.2, CRA BPM 2, CR012, CP775, P310

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to view and update the Working Day Credit Assessment Load Factor (WDCALF_i), Non-Working Day Credit Assessment Load Factor (NWDCALF_i) and Supplier Export Credit Assessment Load Factor (SECALF_i) values for a BM Unit other than a Secondary BM Unit. The Working Day Credit Assessment Load Factor (WDCALF_i), Non-Working Day Credit Assessment Load Factor (NWDCALF_i) and SECALF_i are each single values per BM Unit that may be changed from time to time. SECALF_i values are only relevant for Supplier BM Units; for all other BM Units a zero value of SECALF_i shall be entered.

The interface contains the following information:

• Action Description

• Authentication Details

• WDCALF_iand date from which it is effective.

• NWDCALF_i and date from which it is effective.

• SECALF_i and date from which it is effective.

The WDCALF_i, NWDCALF_i and SECALF_i values cannot be set to NULL for a current BM Unit, other than a Secondary BM Unit.

At the effective commencement date of the new BM Unit, other than a Secondary BM Unit, WDCALF_i, NWDCALF_i or SECALF_i, the CRA shall recalculate the Working Day BM Unit Credit Assessment Export Capability (WDBMCAEC_i) , the Non-Working Day BM Unit Credit Assessment Export Capability (NWDBMCAEC_i), the Working Day BM Unit Credit Assessment Import Capability (WDBMCAIC_i) and the Non-Working Day BM Unit Credit Assessment Import Capability (NWDBMCAIC_i) in accordance with the following formula for all registered BM Units:

WDBMCAIC_i = WDCALF_i*DC_i

NWDBMCAIC_i = NWDCALF_i*DC_i

If Supplier BM Unit,

If DC_i=0 and GC_i>0, then

WDBMCAEC_i = SECALF_i*GC_i

NWDBMCAEC_i = SECALF_i*GC_i

Else

WDBMCAEC_i = WDCALF_i*GC_i

NWDBMCAEC_i = NWDCALF_i*GC_i

The new WDBMCAEC_i, NWDBMCAEC_i, WDBMCAIC_i and NWDBMCAIC_i for all BM Units, other than Secondary BM Units, shall subsequently be distributed as per the requirements of CRA-F013 and CRA-F014.

The CRA may from time to time issue the Credit Assessment Capability Report (CRA-I017) to the SAA and ECVAA Services.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I011

Output Interfaces:

CRA-I014

CRA-I015

CRA-I017

5.22 CRA-F021: Requirement not currently used

Requirement ID:

CRA-F021

Status:

Title:

Requirement not currently used

BSC Reference:

Man/Auto:

Frequency:

Volumes:

Functional Requirement:

Non Functional Requirement:

Interfaces:

5.23 CRA-F022: Issue Credit Assessment Capability

Requirement ID:

CRA-F022

Status:

Mandatory

Title:

Issue Credit Assessment Capability

BSC Reference:

CRA SD 7.1, CRA SD 7.2, CRA BPM 2, CR012, P100, P310

Man/Auto:

Automatic

Frequency:

Monthly or Ad-hoc

Volumes:

Low

Functional Requirement:

The CRA shall recalculate and store the Working Day BM Unit Credit Assessment Export Capability (WDBMCAEC_i), the Non-Working Day BM Unit Credit Assessment Export Capability (NWDBMCAEC_i), the Working Day BM Unit Credit Assessment Import Capability (WDBMCAIC_i) and the Non-Working Day BM Unit Credit Assessment Import Capability (NWDBMCAIC_i) in accordance with the following formula for all registered BM Units, other than Secondary BM Units, once per month or for individual BM Units, other than Secondary BM Units, when triggered as a result of the:

• redefinition of a Trading Unit;

• registration of a new BM Unit;

• change in the Generation or Demand Capacity for a BM Unit

• change in the WDCALF_i, NWDCALF_i or SECALF_i for a BM Unit

The CRA shall calculate the Credit Assessment Capability values as:

WDBMCAIC_i = WDCALF_i*DC_i

NWDBMCAIC_i = NWDCALF_i*DC_i

If Supplier BM Unit,

If DC_i=0 and GC_i>0, then

WDBMCAEC_i = WDSECALF_i*GC_i

NWDBMCAEC_i = SECALF_i*GC_i

Else

WDBMCAEC_i = CALF_i*GC_i

NWDBMCAEC_i = NWDCALF_i*GC_i

The system shall not overwrite the previous values of the WDBMCAEC_i, NWDBMCAEC_i, WDBMCAIC_i or NWDBMCAIC_i, but log the new data with the date from which it is effective.

The CRA shall also recalculate the Production / Consumption Status for the affected BM Units if the BM Unit is defined to have a non-fixed Production / Consumption Status, as follows:

If DC_i >= GC_i, then

the Relevant Capacity is DC_i.

Else

the Relevant Capacity is GC_i.

The Trading Unit Production / Consumption Status is determined by summing the Relevant Capacities for all BM Units in the Trading Unit.

If the sum of the Relevant Capacities is <= 0, then

the Trading Unit Status is Consumption

else

the Trading Unit Status is Production.

Each BM Unit shall be assigned the same (Production / Consumption) Status as the relevant Trading Unit, except in the case where the Flag has been notified by the Party. In this case, the BM Unit Production/Consumption Status is as notified by the Party (Production / Consumption Flag set).

The CRA will distribute the new WDBMCAEC_i, NWDBMCAEC_i, WDBMCAIC_i and NWDBMCAIC_i for all BM Units, other than Secondary BM Units, as per the requirements of CRA-F013 and CRA-F014.

Non Functional Requirement:

Interfaces:

Output Interfaces:

CRA-I014

CRA-I015

CRA-I017

5.24 CRA-F023: Validate Registrations

Requirement ID:

CRA-F023

Status:

Mandatory

Title:

Validate Registrations

BSC Reference:

CRA SD 8, CRA BPM 3.4, CRAWS-40, P100

Man/Auto:

Automatic

Frequency:

Daily

Volumes:

Low

Functional Requirement:

The CRA system shall on a daily basis, perform a validation check to ensure the consistency of all data that has been changed over the course of the day. This check shall highlight conditions in two states - Error and Warning and shall validate that:

1) All BM Units, other than Secondary BM Units, are associated with a Trading Unit, (Error)

2) All Interconnectors have a defined Interconnector Error Administrator. In addition that the BSC Party statement of Error Administrator registration matches that received through the Interconnector Administrator registration data. (Warning / Error)

3) That all BM Units have a defined lead Party (Error)

4) That no BM unit responsibility registration requests are pending (Warning)

5) That all BSC Party and Service Agents are outside of a system wide time prior to the end of their certification period [28 days] (Warning)

6) That there are no unconfirmed change of BM Unit responsibility requests within a system wide period of the date of change. [28 days] (Warning)

7) All Base Supplier BM Units and Additional Supplier BM Units that are not Exempt Export, are allocated to the Base Trading Unit of the appropriate GSP Group (Warning).

In addition, the CRA system shall list all registration changes that are pending or failed along with the date at which they entered such states.

The system shall present each validation warning / failure to the Operator through an online screen on demand for subsequent rectification through View / Maintain functionality described in previous appropriate requirements.

The CRA system shall allow an Operator to search through the highlighted information by failure type, BSC Party and effective to / from dates to limit the amount of information presented at any one time.

Non Functional Requirement:

Interfaces:

5.25 CRA-F024: Report Registration Details

Requirement ID:

CRA-F024

Status:

Mandatory

Title:

Report Registration Details

BSC Reference:

CRA SD 10, CRA BPM 3.7, CRAWS-41

Man/Auto:

Automatic

Frequency:

Daily

Volumes:

Low

Functional Requirement:

The CRA shall produce a report, daily, on all registration details that have changed over the course of the day to the relevant BSC Parties.

The system shall maintain a log of all information distributed on each occurrence.

Non Functional Requirement:

Interfaces:

Output Interfaces:

CRA-I014

5.26 CRA-F025: Distribute Register Data

Requirement ID:

CRA-F025

Status:

Mandatory

Title:

Distribute Register Data

BSC Reference:

CRA SD 10, CRA SD 11, CRA BPM 3.8, CRAWS-42, CR_991027_06a, CP753, CP551, CP642, P197

Man/Auto:

Automatic

Frequency:

See Text

Volumes:

Low

Functional Requirement:

The CRA shall, daily (or more frequently if multiple changes occur), distribute changes to centrally held register data within the system on a pre-defined schedule. The following data shall be distributed daily as a result of a change to the base data as highlighted in prior requirements:

CRA-I013 - Issue Authentication Report

CRA-I014 - Issue Registration Report

CRA-I015 - Issue BM Unit & Energy Account Registration Data (See Note 1)

CRA-I017 - Issue Credit Assessment Capability

CRA-I020 - Issue Operations Registration Report (Incremental Report)

CRA-I022 - Issue Metering System Details

CRA-I024 - Issue Certification & Accreditation Status Report⁶

CRA-I028 - Issue NGC Standing Data Report

The following data shall be distributed monthly irrespective of whether the data has changed over the previous month.

CRA-I013 - Issue Authentication Report

CRA-I017 - Issue Credit Assessment Capability

The following data shall be sent to the BSCCo weekly irrespective of whether the data has changed over the previous week:

CRA-I020 - Issue Operations Registration Report (Full Refresh Report)

Each report shall also be able to be distributed on request through an Operator entering the distribution details.

Note 1: The BM Unit and Energy Account Registration report (CRA-I015, subflow 2) generated for SVAA will only be sent if the report itself differs from the previously generated report.

Non Functional Requirement:

Interfaces:

Output Interfaces:

CRA-I013

CRA-I014

CRA-I015

CRA-I017

CRA-I020

CRA-I022

CRA-I024

CRA-I028

5.27 CRA-F026: Maintain Reference Data

Requirement ID:

CRA-F026

Status:

Mandatory

Title:

Maintain Reference Data

BSC Reference:

CRA SD 8, CR_990813_07, CRAWS-43

Man/Auto:

Manual

Frequency:

Daily

Volumes:

Low

Functional Requirement:

The CRA system shall provide facilities for the maintenance of reference data used within the system. The following data shall be maintained (though additional requirements may be found during detailed design):

a) BSC Party Types,

b) BSC Party Agent Types,

c) BSC Service Agent Types,

d) Settlement Report Distribution Methods,

e) Point Types,

f) BM Unit Types.

Non Functional Requirement:

Interfaces:

The information is expected to be presented to the CRA system in low volume on paper.

5.28 CRA-F027: SLA Reporting

Requirement ID:

CRA-F027

Status:

Mandatory

Title:

SLA Reporting

BSC Reference:

CRA SD Appendix B, CRAWS-45, P197, P310

Man/Auto:

Manual

Frequency:

Monthly

Volumes:

Low

Functional Requirement:

The CRA shall produce reports monthly detailing the level of service provided by the Service to the BSCCo Ltd. The reports shall detail the response times in delivering various aspects of the system as detailed below. The Service level for each of the activities is contained within the brackets in each case.

Other General requirements are described within the Common requirement GEN-N005

1) Process New BSC Party registrations - Validate data, authenticate registration application and update registration system with new registration data on the Working Day received (100%).

2) Process Change to BSC Party Standing Data - Validate changes to data and update registration system with new data on the Working Day received (100%)

3) Provide BSC Party Registration report - Registration reports produced and despatched to recipient on the Working Day received (100%)

4) BSC Party Authentication Details - Reports produced and despatched to recipient on the Working Day received (100%)

5) Qualify new BSC Party Agent - Complete Qualification Report returned on the Working Day received (100%)

6) Credit Assessment Import/Export Capability re-set on a monthly basis or within [1 Working Day] of change to WDCALF, NWDCALF or SECALF or DC or GC (100%)

Non Functional Requirement:

Interfaces:

BSCCo Ltd

5.29 CRA-F028: Requirement not currently used

Requirement ID:

CRA-F028

Status:

Title:

Requirement not currently used

BSC Reference:

Man/Auto:

Frequency:

Volumes:

Functional Requirement:

Non Functional Requirement:

Interfaces:

5.30 CRA-F029: Register Interconnector

Requirement ID:

CRA-F029

Status:

Mandatory

Title:

BSC Reference:

CRA SD 6.3, CRA BPM 3.6, CRAWS-38

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall allow a Self-Service Gateway user or an Operator to register Interconnector Registration details. The details of an Interconnector shall be composed of:

• Action Description

• Authentication Details

• Interconnector Details (including GSP group where appropriate)

Interconnectors should only be registered by a limited sub-set of BSC Parties (the Transmission Owner / Distribution Company) though other BSC Party types may register them in accordance with CRA-N001.

Interconnectors may only be registered after endorsement from BSCCo Ltd. It shall thus be the responsibility of the Operator to ensure that supporting documentation has been received and checked prior to registration.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I008

Output Interfaces triggered from this activity:

CRA-I014

CRA-I015

CRA-I020

5.31 CRA-F030: Register GSP Group and GSP Details

Requirement ID:

CRA-F030

Status:

Mandatory

Title:

BSC Reference:

CRAWS-44, P100

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall allow an Operator to register GSP Groups. The CRA system shall allow a Self-Service Gateway user or an Operator to register GSP and Distribution Systems Connection Point (DSCP) Registration details. The details of a GSP Group shall be composed of:

• Action Description,

• Authentication Details,

• GSP Group Details,

• GSP Details,

GSP Groups should only be registered by a limited sub-set of BSC Parties (The Distribution Companies) though other Party types may register in accordance with CRA-N001.

GSP Groups may only be registered after endorsement from BSCCo Ltd. It shall thus be the responsibility of the Operator to ensure that supporting documentation has been received and checked prior to registration. The CRA system shall allow the Operator to enter details that these checks have been conducted.

On successful registration of a GSP Group, the CRA shall register a Base Trading Unit for that GSP Group (with CRA as the registrant). Each BSC Party of type “Supplier” shall be returned a BM Unit of type “Base Supplier BM Unit” in accordance with the requirements of CRA-F013. Each Base Supplier BM Unit created in this way shall, by default, be allocated to the GSP Group Base Trading Unit, in accordance with the requirements of CRA-F013.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I027

Output Interfaces:

CRA-I014

CRA-I028

5.32 CRA-F031: View / Maintain GSP Group Registrations

Requirement ID:

CRA-F031

Status:

Mandatory

Title:

View Maintain GSP Group and GSP Registrations

BSC Reference:

CRAWS-44

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall allow an Operator to register changes to the GSP Group Registration details. The details of a GSP Group shall be composed of:

• Action Description,

• Authentication Details,

• GSP Group Details,

• GSP Details,

• GSP Registrant.

Changes to GSP Groups may only be registered after endorsement from BSCCo Ltd. It shall thus be the responsibility of the Operator to ensure that supporting documentation has been received and checked prior to registration. The CRA system shall allow the Operator to enter details that these checks have been conducted.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I027

Output Interfaces:

CRA-I014

CRA-I019

CRA-I028

5.33 CRA-F032: Maintain Transmission Loss Factors

Requirement ID:

CRA-F032

Status:

Mandatory

Title:

Maintain Transmission Loss Factors

BSC Reference:

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall allow an Operator to update the Transmission Loss Factors for a BM Unit when instructed from BSCCo Ltd.

BSCCo Ltd shall provide the following information:

• The Proportion of Losses (alpha)

• The Transmission Loss Factors for individual BM Units for each Settlement Day.

The CRA system shall validate that each BM Unit detailed is registered for the range of effect of the Transmission Loss Factor Update. Where a discrepancy is found, the system shall issue a warning to the Operator.

The Transmission Loss Factors shall be issued via the CRA-I015.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I029

Output Interfaces:

CRA-I015

5.34 CRA-F033: Receive Registration Exception Reports

Requirement ID:

CRA-F033

Status:

Mandatory

Title:

Receive Registration Exception Reports

BSC Reference:

Man/Auto:

Automatic

Frequency:

As Necessary

Volumes:

Infrequent

Functional Requirement:

The CRA system shall receive Exception reports from the SAA, BMRA and ECVAA systems where Registration data sent to these systems has been rejected.

The CRA system shall receive exception data including:

• Sending Agent

• Exception Type

• Exception Description

The CRA system shall receive the exceptions automatically and allow an Operator to view the nature and description of the Exception. It is subsequently the responsibility of the Operator or a Supervisor to communicate with the sending Agent and resolve the discrepancy.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I030

Output Interfaces:

CRA-I015

5.35 CRA-F035: View / Maintain Metering System Details

Requirement ID:

CRA-F035

Status:

Mandatory

Title:

View / Maintain Metering System Details

BSC Reference:

CRA SD 6.4, CRA BPM 3.3, CRAWS-36, CRAWS-37, CRAWS-39

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA shall receive the following information about changes to the registration of the Metering Systems.

• An Action Description

• Authentication Details

• Metering System Details (including the CVA Meter Operator Agent for the metering system).

The CRA system shall allow the amendment of individual Metering System details;

The following validation shall be conducted:

1) That the effective from date of the change shall be no sooner than a pre-defined system wide duration [28 days] from the date of the registration request.

2) That the CVA Meter Operator Agent specified against a metering system is registered with the CRA.

Failure of the validation rule shall be flagged to the Operator who must subsequently acknowledge that the request is valid after consultation with interested Parties.

Non Functional Requirement:

Interfaces:

Input Interfaces:

CRA-I031

Output Interfaces:

CRA-I014

CRA-I019

CRA-I022

CRA-I028

5.36 CRA-F036: Maintain Flexible Reporting Requirements

Requirement ID:

CRA-F036

Status:

Mandatory

Title:

Maintain Flexible Reporting Requirements

BSC Reference:

CR 53, P8

Mechanism:

Manual

Frequency:

As Necessary

Volumes:

Low

Functional Requirement:

The CRA shall allow a Self-Service Gateway user or an Operator to update the set of flexible reporting requests currently in force. Each request is for a BSC Party role to receive a copy of a specific report destined for another BSC Party role, for BSCCo Ltd. to receive a copy of a specific report destined for another BSC Party role or for a specific version of a report to be generated for a BSC Party.

Batches of flexible reporting requests shall be received according to interface CRA-I034.

While a copy request is in force the system shall automatically distribute a copy of the report to the requesting BSC Party (or BSCCo Ltd.). The version copied will be that generated for the original organisation.

While a version request is in force, the system shall automatically generate the requested version of the report for the requesting organisation.

Non Functional Requirement:

Interfaces:

Input Interfaces

CRA-I034

5.37 CRA-F037: Transfer from SMRS

Requirement ID:

CRA-F037

Status:

Title:

Transfer from SMRS

BSC Reference:

CP753

Man/Auto:

Manual

Frequency:

As necessary

Volumes:

Low

Functional Requirement:

A. When a new transfer notification is initiated, CRA will receive three flows.

• Meter Registration for the new metering system(s) (CRA-I031)

• BM Unit Registration for the new BM Unit(s) (CRA-I005)

• Transfer from SMRS details (CRA I038)

1. Process the Meter Registration according to CRA-F034, including allocation of a Metering System Identifier, but do not enter the data.

2. Send a copy of the received details (including allocated Metering System identifier) to the Transfer Coordinator.

3. Process the BM Unit registration according to CRA-F013, but do not enter the data. Send a copy of the received details to the Transfer Coordinator.

4. Check that the registrant named on the transfer initiation is a BSC Party

5. Confirm that BM Unit details have been submitted for the BM Unit(s) indicated on the transfer initiation

6. Confirm that the stated effective from date is possible

7. Confirm that the CVA MOA in the metering systems registration is valid

8. Send a report to the transfer coordinator (CRA-I039)

B. The Transfer coordinator will subsequently submit a CRA-I038 to confirm the transfer. This flow will contain the confirmed effective from date.

1. apply the changes (as received and validated above) using the confirmed effective from date.

2. send a Transfer Summary Report (CRA-I023) to the transfer coordinator and to the new CVA registrant(s)

C. If the Transfer coordinator submits a CRA-I038 rejecting the transfer, the process is abandoned (at this stage no changes have been made).

D. If the transfer coordinator submits a CRA-I038 to confirm progress, the CRA shall respond with information regarding the progress of the transfer including completed and outstanding operations

Non Functional Requirement:

Interfaces:

The CRA shall receive notification of transfer using flow CRA-I038

The CRA shall issue transfer reports using flow CRA-I039

Issues:

5.38 CRA-F038: Transfer to SMRS

Requirement ID:

CRA-F038

Status:

Title:

Transfer to SMRS

BSC Reference:

CP753

Man/Auto:

Manual

Frequency:

Volumes:

Functional Requirement:

A. When a new transfer notification is initiated, CRA will receive:

• Transfer to SMRS details (CRA I040)

1. Check that the Metering System is registered in CRA

2. Check that the BM Unit(s) are registered in CRA

3. Confirm that the effective to date is possible

4. Confirm that the BM Unit is ready for deregistration

5. Check whether the BM Unit is part of a Trading Unit registered using CRA-F015

6. Send a report to the transfer coordinator (CRA-I041)

B. The Transfer coordinator will subsequently submit a CRA-I040 to confirm the transfer. This flow will contain the confirmed effective from date.

1. record the effective to date

2. on receipt of deregistration requests for the Metering systems and/or BM Units, apply the changes using the confirmed effective to date

3. send a Transfer Summary Report (CRA-I023) to the transfer coordinator and to the affected PDSO

C. If the Transfer coordinator submits a CRA-I040 rejecting the transfer, the process is abandoned (at this stage no changes have been made).

D. If the transfer coordinator submits a CRA-I040 to confirm progress, the CRA shall respond with information regarding the progress of the transfer including completed and outstanding operations.

Non Functional Requirement:

If deregistrations of all Metering Systems and BM Units have not been received by 20 working days before the confirmed effective to date, then contact the registrant.

Interfaces:

The CRA shall receive notification of transfer using flow CRA-I040

The CRA shall issue transfer reports using flow CRA-I041

Issues:

5.39 CRA-F039: Register / View / Maintain Market Index Data Provider

Requirement ID:

CRA-F039

Status:

Mandatory

Title:

BSC Reference:

P78

Man/Auto:

Manual

Frequency:

As Necessary

Volumes:

Mostly at initial set-up

Functional Requirement:

1. The CRA shall allow an Operator to manually enter new Market Index Data Provider (MIDP) Registration Information into the CRA system.

The BSSCo Ltd shall submit registration information to the CRA system including details of:

• An Action Description to specify the type of registration operation,

• the MIDP (name, contact details),

A detailed description of the interface content may be found in CRA-I042.

Where the data has passed validation the information shall be stored within the CRA system database after being authorised by a Supervisor. The CRA system shall then allocate and return to the Operator a meaningful and unique MIDP ID.

The CRA system shall also provide the MIDP with sufficient information for the authentication of future communications, electronic or otherwise.

2. The CRA system shall, on receipt of a new Market Index Data Provider Registration request, create a unique and meaningful party identifier.

The CRA system shall perform a check against the name of the MIDP and currently stored MIDP.

To avoid errors of duplication, should a potential duplicate MIDP name be found, the system will issue a warning which must be overridden prior to allocation of a new identifier

3. The CRA system shall allow an Operator to view and maintain Market Index Data Provider details.

Full details of the flow may be found in CRA-I042.

Non Functional Requirement:

Interfaces:

Input interfaces:

CRA-I042

Output Interfaces:

CRA-I014

5.40 CRA-F040: Provide BSCCo with Withdrawals Checklist

Requirement ID:

CRA-F040

Status:

Mandatory

Title:

Provide BSCCo with Withdrawals Checklist

BSC Reference:

CP974, P152

Man/Auto:

Manual

Frequency:

On request

Volumes:

Low

Functional Requirement:

The CRA shall collate registration and trading details relating to a BSC Party / BSC Party Agent in response to a request for the Withdrawals Checklist received from BSCCo Ltd (via Interface Requirement CRA-I044).

1. The registration details shall be matched to the request by means of the participant id and / or participant name registered in CRA.

2. Details of BSC Party / BSC Party Agent registrations shall be provided. Where a registration has ceased to be effective, the latest Effective To date shall be provided.

3. The CRA shall obtain the trading details relating to a BSC Party by requesting information from the ECVAA (Interface Requirement CRA-I045) and the SAA (Interface Requirement CRA-I046).

4. The last day of trading for the BSC Party shall be the date of the last non-zero metered volumes held by the SAA, or the date of the last non-zero notifications held by the ECVAA, whichever is the later. Where the BSC Party has no metered volumes recorded for any settlement day then the date of the last non-zero notifications shall be used. Where the date of the last non-zero notification is "evergreen", the last day of trading for the BSC Party shall also be "evergreen".

5. The payment date of the Final Reconciliation Run for the Party's last day of trading shall be determined from the Settlement Calendar. Note that the payment date may not be known if the last day of trading is recent (within the last 14 months).

Non Functional Requirement:

Interfaces:

CRA-I044: Receive Withdrawals Checklist Request

CRA-I045: Receive Withdrawing Party Authorisation and Notification Details

CRA-I046: Receive Withdrawing Party Settlement Details

CRA-I047: Issue Withdrawals Checklist

5.41 CRA-F041: GC and DC Breach Monitoring

Requirement ID:

CRA-F041

Status:

Mandatory

Title:

GC and DC Breach Monitoring

BSC Reference:

P359

Man/Auto:

Automatic

Frequency:

Weekly

Volumes:

Low

Functional Requirement:

The CRA shall monitor BM Unit Metered Volumes to identify where a BM Unit has exceeded its Generation Capacity (GC) by more than the GC Limit (a GC breach) and/or has exceeded its Demand Capacity (DC) by more than the DC Limit (a DC breach).

On a periodic basis (schedule to be agreed with and changed, from time to time, by BSCCo) in the current BSC Season, the CRA shall, for each BM Unit other than a Secondary BM Unit or a BM Unit undergoing a GC or DC Estimation Challenge in accordance with BSC K3.4.7J:

derive the GC Limits and DC Limits for each eligible BM Unit in the current BSC Season, where GC/DC Limits are set by the Panel in accordance with the Demand Capacity and Generation Capacity Limit Review and Determination document and published on the BSC website;

retrieve the BM Unit Metered Volumes (QM_ij) for each Settlement Day and Settlement Period in the current BSC Season (except those Metered Volumes for BMUs that occurred on Settlement Days prior to the latest effective DC in accordance with BSC K3.4.2A, i.e. a downward declaration), and ensure Metered Volumes for any Emergency Instruction (EI) that occurred during the BSC Season are subtracted from the relevant BM Unit(s) QM_ij;

determine for all eligible BM Units and every Settlement Period in the current BSC Season that has been the subject of at least the II Settlement Run if a ‘GC Breach’ and/or ‘DC Breach’ has occurred, where a GC Breach for a BM Unit is where any of its positive values of QMij (excluding any EI volumes) exceed the GC by more than the GC Limits, and a DC Breach for a BM Unit is if any negative value of QMij exceeds the DC by more than the DC Limits.

Non Functional Requirement:

Interfaces:

5.42 CRA-F042: Identify CRA-estimated GC and DC amounts

Requirement ID:

CRA-F042

Status:

Mandatory

Title:

Identify CRA-estimated GC and DC amounts

BSC Reference:

P359

Man/Auto:

Automatic

Frequency:

As required

Volumes:

Low

Functional Requirement:

This is a description of the BM Unit Volume Estimation Methodology published on the BSC Website.⁷

1. Where a GC Breach or a DC Breach has been identified for a BM Unit, the CRA shall, for that BM Unit, estimate a replacement GC or DCQMij value (CRA-estimated GC and DC amounts) as follows, and in all cases before 1400 on the day the breach is identified:

a. Depending on whether responding to a GC breach and / or a DC breach, identify all positive QMij and/or negative QMij values for that BM Unit from the most recent Settlement Run for each Settlement Day and Settlement Period from the current BSC Season and the corresponding BSC Season in the previous BSC Year;

b. subtract from QMij any related Period Accepted Offer Volume(s) and/or Period Accepted Bid Volume(s) relating to Emergency Instructions that occurred on the same Settlement Day(s) and Settlement Period(s) as QMij identified in (a) above;

c. find the maximum positive QMij, which will be the CRA-estimated GC Amount; and

d. find the minimum negative QMij, which will be the CRA-estimated DC Amount.

2. Upon determining the CRA-estimated GC Amount and/or the CRA-estimated DC Amount, as applicable, the CRA will ensure the GC and/or DC for the BM Unit is updated, per CRA-F014, to reflect the CRA-estimated GC Amount and/or the CRA-estimated DC Amount. The new GC and / or DC should take effect at 00:00 on the next working day.

3. Not later than 15:00 on the day that the GC Breach or DC Breach is identified, the CRA shall notify the Lead Party of the BM Unit that the BM Unit is in GC Breach or DC Breach and will provide supporting information:

whether the BM Unit is in GC Breach or in DC Breach;
the Settlement Day and Settlement Period to which the Breach applies;
the relevant CRA-estimated GC or DC Amount:
the date on which the CRA-Estimated GC or DC Amounts will take effect⁸;
any other information deemed by BSCCo to be relevant; and
a statement to the effect that this notification will also be published on the BSC Website.

Note that, if a BM Unit is found to be in a GC Breach and DC Breach in the same Breach Monitoring run, separate notices will be issued for the GC Breach and the DC Breach.

4. The notice sent pursuant to 2.should also be sent to BSCCo, the CM Settlement Services Provider and the CFD Settlement Services Provider.

5. The means of communication will be agreed between the CRA and BSCCo, the CM Settlement Services Provider and the CfD Settlement Services Provider, and may change from time to time.

Non Functional Requirement:

Interfaces:

CRA-I049 ‘Notification of a GC Breach or a DC Breach”

5.43 CRA-F043: Manage GC and DC Breach Challenges

Requirement ID:

CRA-F043

Status:

Mandatory

Title:

Manage GC or DC Estimation Challenges

BSC Reference:

P359

Man/Auto:

Automatic

Frequency:

As required

Volumes:

Low

Functional Requirement:

Where a Lead Party has been notified of a BM Unit which is in GC Breach or DC Breach, and believes that the CRA-Estimated GC or DC Amounts were calculated incorrectly (i.e. because either the CRA has not followed the BM Unit Volume Estimation Methodology correctly or the Settlement Data used is incorrect, the Lead Party may challenge the estimate(s).

A challenge will only be valid if submitted within 2 full Working Days of the Lead Party being notified (starting from the beginning of the Working Day following the deemed receipt of the notification); the CRA will not allow a challenge to be raised after this deadline.

The CRA must enable a Lead Party to submit a GC or DC Estimation Challenge online in respect of a BM Unit which is in GC Breach or DC Breach. The CRA must allow the Lead Party to provide it with the following details (the challenge details):

The relevant BM Unit;
The Settlement Date and Settlement Period relating to the GC Breach or DC Breach;
Evidence that the relevant positive or negative QMij was erroneous;
An alternative value of positive or negative QMij.

Where the CRA receives details of a challenge from the Lead Party, pursuant to 2 above, it shall immediately set the Appeal Status for the BM Unit to “Appealed”

The CRA must allow BSCCo to change the Appeal Status of any breach.

Where the CRA receives a GC or DC Estimation Challenge, pursuant to 2 above, it must immediately send the challenge details to BSCCo.

The means of communication will be agreed, and changed from time to time, between CRA and BSCCo

The CRA shall receive a decision from BSCCo on a GC Breach or DC Breach Challenge within 2 full Working Days of receipt of Appeal notification, which shall include.

The relevant BM Unit;
The Settlement Date and Settlement Period relating to the GC Breach or DC Breach; and
Whether the decision is “Upheld” or “Rejected”;
For an “Upheld” decision:

The new value of positive QM_ij or negative QM_ij to be assigned to the BM Unit; and
The Effective From Date for the new value of GC or DC.

Following 6 above, the CRA shall set the Appeal Status for the BM Unit to “Upheld” or “Rejected”, as appropriate, and subject to the rule set out in CRA-F044.

Non Functional Requirement:

Interfaces:

CRA-I050 “ GC Breach or a DC Breach Appeal”

CRA-I051 ‘GC or DC Breach Appeal Decision’

5.44 CRA-F044: Manage Conflicting GC/DC Submissions

Requirement ID:

CRA-F044

Status:

Mandatory

Title:

Manage Conflicting GC/DC Submissions

BSC Reference:

P359

Man/Auto:

Manual

Frequency:

As required

Volumes:

Low

Functional Requirement:

The CRA may receive up to three distinct types of request to update GC and/or DC values which could have the same Effective From Date. Where the Effective From Dates are the same, the CRA shall prioritise the requests according to the order shown below, where 1 is the highest priority and 3 the lowest:

A value submitted by BSCCo following the conclusion of an appeal;

A value estimated by CRA following the identification of a breach;

A value submitted by the Lead Party (not as a consequence of an appeal, but in accordance with K3.4.2 and K3.4.2A).

N.b. where two or more of these requests are received with different Effective From Dates, the CRA shall process each request individually.

Non Functional Requirement:

Interfaces:

CRA-I050 “ GC Breach or a DC Breach Appeal”

CRA-I051 ‘GC or DC Breach Appeal Decision’

5.45 CRA-F045: Publish GC and DC Breach data

Requirement ID:

CRA-F045

Status:

Mandatory

Title:

Publish GC and DC Breach data

BSC Reference:

P359

Man/Auto:

Automatic

Frequency:

As required

Volumes:

Low

Functional 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 for the relevant BM Unit will be entitled to see the above details.

Non Functional Requirement:

Interfaces:

6 Interface Requirements

Overview

The CRA Service shall provide an interface to the following parties.

Other Service Providers:

• Settlement Administration Agent (SAA)

• Central Data Collection Agent (CDCA)

• Balancing Mechanism Reporting Agent (BMRA)

• Energy Contract Volume Aggregation Agent (ECVAA)

• Technical Assurance Agent (TAA)

• Funds Administration Agent (FAA)

• Market Index Data Provider (MIDP)

Other external parties:

• BSC Party

• BSCCo Ltd

• The NETSO

• Interconnector Administrator (IA)

• Interconnector Error Administrator (IEA)

• Supplier Meter Registration Agent (SMRA)

The CRA Service shall provide inbound and outbound interfaces as summarised in the following table. In addition to these defined flows, the CRA system (though screen printing facilities) shall be able to issue ad-hoc reports when requested to from BSCCo Ltd. These will be paper based and sent in manual form to the designated recipient. Where the information is available using the Self-Service Gateway, BSCCo Ltd users will be able to access the reports directly.

Each interface requirement is described in detail below.

Details of the contents of interfaces relevant to the CRA are contained in the Interface Definition and Design (IDD). In the event of discrepancies between the URS and IDD, the interface document takes precedence.

A mechanism of ‘Online’ refers to the use of the Self-Service Gateway.

Req. No.	Interface Requirement	I/O	Interface User	Mechanism
CRA-I001	Receive BSC Party Registration Data	I	BSC Party, BSCCo Ltd	Manual / Online
CRA-I001	Receive BSC Party Registration Data	O	BSCCo Ltd	Manual / Online
CRA-I002	Receive Interconnector Admin. Registration Data	I	BSC Party	Manual / Online
CRA-I003	Receive BSC Party Agent Data	I	BSC Party BSCCo Ltd	Manual / Online
CRA-I004	Receive BSC Service Agent Data	I	BSCCo Ltd	Manual / Online
CRA-I005	Receive BM Unit Registration	I	BSC Party	Manual / Online
CRA-I006	Receive Trading Unit Registration	I	BSC Party	Manual / Online
CRA-I007	Receive Boundary Point and System Connection Point Data	I	BSC Party, NETSO	Manual / Online
CRA-I007	Receive Boundary Point and System Connection Point Data	O	BSCCo Ltd	Manual / Online
CRA-I008	Receive Interconnector Registration Details	I	NETSO	Manual / Online
CRA-I009	Receive BM Unit Manual Credit Qualifying Flag (Redundant)	I	BSCCo Ltd	Manual / Online
CRA-I010	No longer used
CRA-I011	Receive Credit Assessment Load Factors	I	BSCCo Ltd.	Manual / Online
CRA-I012	Issue CRA Encryption Key	O	BSC Party, MIDP & other Agents	Automatic
CRA-I013	Issue Authentication Details Report	O	FAA ECVAA BMRA SAA NETSO BSCCo Ltd	Automatic
CRA-I014	Issue Registration Report	O	BSC Party, NETSO & BSC Party Agents	Automatic/Manual
CRA-I015	Issue BM Unit Registration Data	O	SAA, SVAA BMRA, ECVAA, FAA	Shared Database / Automatic
CRA-I016	No longer used
CRA-I017	Issue Credit Assessment Export Capability	O	SAA ECVAA	Shared Database
CRA-I018	No longer used
CRA-I019	Issue CRA Registered Meter Data	O	CDCA	Shared Database
CRA-I020	Issue Operations Registration Report	O	NETSO BSCCo Ltd	Automatic
CRA-I021	Issue Registered Service List	O	BSC Parties & public	Automatic
CRA-I022	Issue Metering System Details	O	Technical Assurance Agent	Manual
CRA-I023	Issue Registration Transfer Report	O	Transfer Coordinator, BSC Parties, PDSO	Manual
CRA-I024	Issue Certification & accreditation Status Report	O	BSC Parties BSC Party Agents BSC Service Agents	Automatic/Manual
CRA-I025	Receive Acknowledgement	I	All automatic outbound systems	Automatic
CRA-I026	Send Acknowledgement	O	All automatic inbound systems	Automatic
CRA-I027	Receive GSP Group Registration Details	I	BSC Party (Distributor)	Automatic
CRA-I028	Issue NGC Standing Data Report	O	NETSO	Automatic
CRA-I029	Receive Transmission Loss Factors	I	BSCCo Ltd	Manual / Online
CRA-I030	Receive Exception Report	I	SAA ECVAA BMRA	Automatic
CRA-I031	Receive Metering System Data	I	BSC Party	Manual
CRA-I033	Requirement not currently used
CRA-I034	Flexible Reporting Request	I	All automatic outbound systems	Manual / Online
CRA-I035	CRA BSC Section D Charging Data	O	BSCCo Ltd	Manual / Online
CRA-I036	Send Notification Agent Termination Request	O	ECVAA	Manual / Online
CRA-I037	Receive Notification Agent Termination Feedback	I	ECVAA	Manual / Online
CRA‑I038	Transfer from SMRS information	I	Transfer Coordinator, BSC Party	Manual
CRA‑I039	Transfer from SMRS report	O	Transfer Coordinator	Manual
CRA‑I040	Transfer to SMRS information	I	Transfer Coordinator, BSC Party	Manual
CRA‑I041	Transfer to SMRS report	O	Transfer Coordinator	Manual
CRA-I042	Receive Market Index Data Provider Registration Data	I	BSCCo Ltd	Manual / Online
CRA-I043	Receive Exempt Export Registration Data	I	BSCCo Ltd	Manual / Online
CRA-I044	Receive Withdrawals Checklist Request	I	BSCCo Ltd	Manual / Online
CRA-I045	Receive Withdrawing Party Authorisation and Notification Details	I	ECVAA	Manual / Online
CRA-I046	Receive Withdrawing Party Settlement Details	I	SAA	Shared Database
CRA-I047	Issue Withdrawals Checklist	O	BSCCo Ltd	Manual / Online

The following diagrams illustrate these interface requirements.

CRA Service: Inbound Interface Requirements

CRA Service: Outbound Interface Requirements⁹

CRA Service: Outbound Interface Requirements

7 Non Functional Requirements

This section specifies non-functional requirements of the CRA Service.

7.1 CRA-N001: Input Interface Requirements

Requirement ID:

CRA-N001

Status:

Title:

Input Interface Requirements

BSC Reference:

CRAWS-40, CN122

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Low

Non Functional Requirement:

1. The CRA system shall provide manual input mechanisms for the insertion of data into the system from external parties where stated.

2. The CRA service shall provide a mechanism for the decoding of electronically transferred data so that an operator may enter the details contained in the messages.

3. The CRA service shall provide functionality for a user to select an electronic data notification from a list of outstanding input messages and display the contents in a human readable form. Data items shall be listed alongside a label describing individual fields in the input data flow.

4. Where appropriate, the CRA system shall allow an Operator to ‘cut and paste’ the information in these messages into the relevant input screens.

5. The CRA service shall carry out validation of all data input so as to ensure that the data is, as far as is practicable, complete and consistent.

6. Where data is to be input manually, the service shall use reasonable endeavours to ensure that the quality of the data is not compromised in any way. The exact mechanism to ensure this is conducted will be developed in detail within the System and Detailed Design Specification.

7. Where relevant, registration actions or changes to registered data shall require the approval of BSCCo Ltd. The approval process will be facilitated by the Self-Service Gateway. Where the Self-Service Gateway is not used for data entry by the BSC Party, BSC Party Agent or applicant, paper based supporting documentation is required,. an Operator shall be expected to check that this authorisation has been received when processing the Registration request and supporting documentation. The Self-Service Gateway will provide facilities to:

• allow for cross-referencing between paper and electronic registration information.

• log that all relevant checks have been completed.

8. Should the data, once entered on the input form pass input validation but require confirmation from either a second Party or BSCCo Ltd, the Operator/Self-Service Gateway user shall then be presented with the ability to save the valid parts of the registration (subject to database constraints) in a “Pending” state rather than having to abort the entire update. While in this state, the data will be “invisible” to other parts of the BSC Central Systems. For instance it will not be issued to other Services (CDCA, SAA). At a later time, the Operator/Self-Service Gateway user shall be able to retrieve the partial update and complete when the original failure has been corrected.

9. Certain registration items (such as BM Units) are expected to be registered from a limited sub-set of Party types. The CRA system shall ensure that a check against Party type is conducted on entry or amendment of registration details.

10.. All registration entries / amendments will be tagged with the date and time of the operation as well as the identifier (username) of the Operator/Self-Service Gateway user who entered the details.

11.. Each registration operation may require a specific level of authorisation within the requesting Party. The CRA stores these levels of authorisation and shall validate that the requesting person has the authorisation to conduct the requested operation. Where this check fails the CRA shall reject the entire request. The Role-Based Access Control (RBAC) provided by the Self-Service Gateway will be used to authenticate online requests.

12. The CRA system shall (with exceptions such as on change of ownership of BM Units and Interconnector Error Administration responsibility) only accept registration amendments from the Party that sent in the original registration request.

13. The CRA Service shall undertake Interface Tests for all Parties wishing to register within the CRA. The interface tests will cover the following services (as appropriate to the applicant):

• BMRA;

• CDCA;

• CRA;

• FAA and

• SAA.

14. Where Validation errors occur within the system as either a result of individual data entry or through the daily validation check (CRA-F023) the system shall allow the failures to be viewed and searched for by an Operator in accordance with the following:

• The system shall present each validation warning / failure to the Operator through an online screen on demand for subsequent rectification through View / Maintain functionality described in previous appropriate requirements in Section 5.

• The CRA system shall allow an Operator to search through the highlighted information by failure type, BSC Party and effective to / from dates to limit the amount of information presented at any one time.

8 Service Requirements

This section details the Service Requirements for the CRA system. General requirements can be found in Appendix E

8.1 CRA-S001: Message Security and Encryption

Requirement ID:

CRA-S001

Status:

Mandatory

Title:

Message Security and Encryption

BSC Reference:

CRAWS-55

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Low

Non Functional Requirement:

The CRA system shall receive electronic data in either encrypted or non-encrypted format. Each Party may exchange data with the CRA system using one or more encryption public keys. BSC Party information shall always be received using a notified encryption key, whereas Service Agents shall not be required to use encryption.

The CRA system shall communicate back to Parties using the encryption public key supplied from the party where supplied and the use mandated.

8.2 CRA-S002: Data Migration Requirements

Requirement ID:

CRA-S002

Status:

Mandatory

Title:

Data Migration Requirements

BSC Reference:

CR990813_07, CRAWS-56

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

Detailed Data Migration requirements will be established during the detailed design phase.

Issues:

Data Migration requirements need to be discussed with the Customer in detail and will be documented separately outside of the scope of the URS.

8.3 CRA-S003: Archiving Requirements

Requirement ID:

CRA-S003

Status:

Title:

Archiving Requirements

BSC Reference:

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

The CRA shall provide a suitably secure repository for any documents or paper based information provided by BSC Parties in connection with their Registration or generated by the CRA in connection with the operation of their registration service.

This requirement is in addition to all general archiving requirements as stated in GEN-S004.

Issues:

9 User Roles and Activities

The following table describes the user roles which will support the day to day operation of the CRA service.

Role

Activities

System Administrator

Database management

Specific aspects of system configuration

User account and security management

Supervisor

Management of Operators

Management of standing data updates

Management of planned operational and service level requirements

Creation of management information reports

Support for communication with external parties

Operator

Performance of procedures to monitor receipt and processing of information from external parties.

Second level support for ad hoc queries raised by external parties

Help Desk Operator

First level support for ad hoc queries raised by external parties.

Auditor

There shall be a specific user security configuration which allows an external auditor to review data within the system, but prevents the initiation of batch processes or logical edits to business data.

Market Index Data Provider

Market Index Data Providers are registered by BSCCo Ltd, and their details are passed on by CRA to SAA and BMRA.

The following parties are defined as users of the service. The detailed functional requirements and data interfaces necessary to support these parties are described earlier in section 6 of this URS.

Role

Summary of Activities related to CRA

BSCCo Ltd.

Receives summary settlement reports from CRA at periodic intervals (daily, weekly, monthly) as well as CRA performance reports.

Balancing Mechanism Operator (NETSO)

Reports are produced to NETSO on Standing data held within the system.

BSC Party

BSC Parties register information (such as their own registration) as well as registration details of BM Units, Trading Units, etc. They also receive confirmation that these registrations have been either successful applied or failed for some reason.

SAA

The SAA is sent authentication and registration details by the CRA. In addition, the CRA informs the ECVAA of the WDBMCAIC and NWDBMCAIC.

ECVAA

The ECVAA is sent authentication and registration details by the CRA. .

CDCA

The CDCA is sent authentication and registration details by the CRA..

SMRA

The SMRA is sent details of the Boundary Points registered within the CRA system. The CRA also receives back a subset of this list if they are registered within the SMRA.

Interconnector Administrator

The Interconnector Administrator arbitrates when a change of Interconnector Error Administrator event occurs.

Funds Administration Agent (FAA)

The FAA is sent registration details by the CRA.

Public

The Public are entitled to view the list of Registered Service Providers.

TAA

The TAA is sent a list of the registered Boundary Points and Metering Systems.

10 Future enhancements

No future enhancements to the CRA service have been identified at this stage.

Please refer to Appendix F for common future requirements.

Appendix A Requirements Compliance Matrix

The following table shows the mapping of requirements defined in this URS document to the requirements set out in the Service Description for Central Registration [CRA SD].

Service Description Requirement Number or CR Number	URS Requirement Reference Number	Notes
4.1.1	CRA-F001 CRA-F002 CRA-F006 CRA-I001
4.1.2	CRA-F004 CRA-F005 CRA-I014
4.1.3	CRA-F007 CRA-F008 CRA-I002 CRA-I014
4.1.4	CRA-F001 CRA-F006
4.1.5	GEN-S003
4.1.6	CRA-F002 CRA-F003 CRA-I001
4.1.7	CRA-F002 CRA-F003 CRA-I001 CRA-I011
4.2.1	CRA-F009 CRA-F010 CRA-I003
4.2.2	CRA-F009 CRA-F010 CRA-I003
4.3.1	CRA-F011 CRA-F012 CRA-I004
4.3.2	CRA-F011 CRA-F012 CRA-I004
5.1	CRA-F011 CRA-F012
5.2	CRA-F011
5.3	CRA-I021 CRA-I024
6.1.1	CRA-F013 CRA-F014 CRA-I005
6.1.2	CRA-F013
6.2.1	CRA-F015 CRA-F016 CRA-I006
6.2.2	CRA-F015
6.2.3	CRA-F015 CRA-F016
6.3.1	CRA-F019
6.4.1	CRA-F017 CRA-F018 CRA-I007
6.4.2	CRA-F017 CRA-F018 CRA-I007
7.1.1		BMCAIC now calculated in CRA
7.1.2	CRA-I017
7.2.1	CRA-F013 CRA-F014 CRA-F022 CRA-I017
7.2.2	CRA-F020 CRA-I011 CRA-I017
8.1	CRA-F023	Validation rules may be found in all requirements as well as the central validation check.
9.1	CRA-I014
9.2	GEN-N002
9.3	GEN-N002 GEN-N003 GEN-S004
10.1	CRA-I014
10.2	CRA-I014
10.3	CRA-I022
10.4	CRA-I013
10.5	CRA-I015
10.6	CRA-I013
11.1	CRA-I019
11.2	CRA-I023
11.3	CRA-I015	Due to the nature of the shared database, the CDCA would not need to request a refresh since the data is always up to date
12	GEN-S006

CR 53	CRA-F036 CRA-I034
CR 65	CRA-I035
CP503	CRA-F010 CRA-I036 CRA-I037
CP508	CRA-F006 CRA-I001
CP569	CRA-F034 CRA-I031
P8	CRA-F036 CRA-I034
CP753/P55	CRA-F013 CRA-F034 CRA-F025 CRA-F037 CRA-F038 CRA-I005 CRA-I031 CRA-I023 CRA-I038 CRA-I039 CRA-I040 CRA-I041
P78	CRA-F039 CRA-I012 CRA-I013 CRA-I014 CRA-I042
CP975	CRA-I013
CP974	CRA-F040 CRA-I044 CRA-I045 CRA-I046 CRA-I047
P197	CRA-F001 CRA-F009 CRA-F010 CRA-F011 CRA-F025 CRA-F027 CRA-I003 CRA-I019 CRA-I021 CRA-I024
CP1193	CRA-F002 CRA-I013
P215	CRA-F013 CRA-F014 CRA-I009 CRA-I014 CRA-I015 CRA-I020
P268	CRA-F013 CRA-F014
P269	CRA-F013 CRA-F014
P310	CRA-F020 CRA-F022 CRA-F027 CRA-I014 CRA-I020 CRA-I011
P359	CRA-F041 CRA-F042 CRA-F043 CRA-F044

Appendix B Logical Data Model

The Logical Data Model is maintained separately by BSCCo and is available on request.

Appendix C Business Process Model

Below is reprinted the business process model as provided within the CRA BPM. The requirements in this document, in places map directly to process blocks within the BPM. In other cases, and specifically where a requirement has been found within the SD and not mentioned within the BPM, additional processes have been created. As such, the model is provided for reference and information only, though all requirements in the main section of the document supersede the processes below. Please note SO equals NETSO.

Appendix D NETA Central Service Common Non Functional Requirements

This section details the non-functional requirements common to the entire suite of User Requirements Specifications. Only common requirements are detailed within this section - e.g. where a requirement is specific to a given sub-system it is detailed within the individual URS only.

D-1 GEN-N001: Audit Requirements

Requirement ID:

GEN-N001

Status:

Title:

Audit Requirements

BSC Reference:

Schedule 3 Part B

Man/Auto:

Automatic

Frequency:

All business transactions (including manual filing)

Volumes:

Audit information shall be associated with each set of data created by any business transaction. Volumes will be established during detailed design.

Non Functional Requirement:

1. All business data received by the Service Provider from external sources shall be retained and not physically deleted, subject to the retention durations described in GEN-S004. Multiple versions of the data shall be supported, for instance so that both the original information and any subsequent corrections are separately stored. Business data shall have an associated effectiveness date range which identifies the trading dates to which it is applicable.

2. The Service Provider shall maintain an audit trail of when information from external sources was received, from whom, and when the information was processed.

3. All business data transmitted to external parties by the Service Provider shall be retained and not deleted, subject to the retention durations described in this document. Multiple versions of the data shall be supported, for instance so that the results of settlement calculations in successive settlement runs for the same trading day are available individually.

4. Any changes made to business data by operators of the service shall be retained as a new data version, i.e. data may only be ‘logically’ modified, not physically modified thus retaining a copy of the previously un-modified business data. It shall not be possible for Operators to physically delete business data, though it shall be possible to ‘logically’ delete data such that it is not included within any subsequent computation or reporting process. Any business data which is entered, logically modified or logically deleted by Operators of the service shall be time stamped to record the time the transaction occurred, and the identity of the Operator who performed the transaction shall be recorded. This audit information shall be available for inspection by a suitably authorised party.

5. The Service Provider shall ensure that all output files and reports produced are uniquely identifiable and time stamped.

6. The Service Provider shall arrange for all printed reports that are no longer required for the provision of Services or for audit to be securely destroyed.

7. The Service Provider shall arrange for the removal from machine-readable media and subsequent secure destruction of all data that is no longer required.

8. The Service Provider shall facilitate the following specific requirements of the BSCCo Ltd appointed Auditor. The Service Provider shall facilitate any reasonable audit requirements to ensure:

• The Service is being run in accordance with BSC rules.

• Validation of Service providers’ performance (service credits, etc.)

• Any modification to the Service is carried out in accordance with the BSC modifications rules.

D-2 GEN-N002: Security Requirements

Requirement ID:

GEN-N002

Status:

Title:

Security Requirements

BSC Reference:

Schedule 3 Part B Section 4

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

N/A

Non Functional Requirement:

The Service security procedures shall be created in accordance with BS7799. These procedures will be fully defined in the Operational Services Manual.

Procedures are likely to include the following.

1. All buildings used by the Service Provider in connection with provision of the service shall be made secure in that only suitably authorised persons may obtain entry. This shall include the use of keycard, numeric keypad or other physical barriers which prevent casual entry to the premises. Visitors to the premises shall undergo a procedure which ensures that their entry to the premises is suitably authorised and their access to the parts of the site controlled thereafter. Both the normal and disaster recovery sites shall have sufficient provision to ensure that the security of the buildings is not compromised outside standard working hours.

2. Key elements of the infrastructure used to support the service such as computer server hardware, power supplies and other essential physical equipment shall be subject to further physical restrictions such that they are only accessible to suitably authorised personnel, and not to other operational staff or visitors. Such hardware shall be protected by specialist mechanisms such as a gas flooding capability in order to reduce the impact on the service of accidents such as fire or flooding.

3. The bespoke computer applications used to support the service shall be subject to entry of a secure username and non-displayed password before access to any data or function relevant to the service is possible by an operator. Passwords will be updated through procedural means on a regular basis, users shall be forced to change passwords on a periodic cycle (maximum of 2/3 months). Users shall also be prevented from using easily guessed passwords and refused the reuse of their most recently used passwords.

4. The bespoke systems supporting the service shall be configurable such that individual functions are available only to authorised categories of user. It shall be possible furthermore to configure the systems such that a user interface function which accesses business data can be made available only in a read-only mode to those categories of user with restricted security privileges. Categories of user with higher levels of security privilege shall be able to enter, logically modify and logically delete data using the same facilities. If a user has read access to a function, they may review all data accessible using that function.

5. The Service Provider shall monitor any attempts to breach the physical and logical security of the System and report any such occurrences to the Customer. When any such attempt is discovered, the Service Provider shall use all reasonable endeavours to identify the cause of the breach and to ascertain whether the existing controls are adequate.

6. All user workstations should provide a password controlled screen time out facility. This may be provided through the use of standard facilities included in the workstation operating system, or other commercially available tools.

7. The Service Provider shall use a secure communications infrastructure for transfer of data to another person / system and for receipt of data from the NETSO and other Parties. The infrastructure must support the following:

• authentication: a mechanism to verify that the parties on either side of the data link are who they claim to be;

• privacy: a mechanism to ensure that transmitted content is not read or intercepted by unauthorised recipients;

• integrity: a mechanism to verify that transmitted data is received in an unchanged state.

D-3 GEN-N003: Operational Control

Requirement ID:

GEN-N003

Status:

Title:

Operational Control

BSC Reference:

Service Agreement Schedules

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

The operational procedures will be fully defined in the Operational Services Manual.

Procedures are likely to include the following.

1. It shall be possible for Operators of the service to have control over the loading of data files from external parties. This will include the ability to turn on and off file loading selectively, based on file type and sender.

2. The contents of an inbound data file shall be viewable by an Operator either before or after the file has been loaded into the system.

3. In the event of data loading errors caused by problems with standing data (e.g. registration data) it shall be possible to re-load the information once these errors have been corrected (e.g. after consultation with the CRA Service Provider).

4. The systems supporting the service shall be configurable such that the recipients of each type of individual report process can be defined.

5. It shall be possible to configure the system such that reports are either automatically scheduled for release to their recipient destinations, or else are released only by specific intervention of an Operator.

6. Any report file shall be inspectable by a suitably privileged Operator either before or after it has been made available to its recipient.

7. It shall be possible to cause individual batch and report processes to be initiated either on demand, at a pre-scheduled date and time, or to repeat automatically at a periodic interval.

8. It shall be possible for an Operator to monitor the progress of any individual batch or report process, for instance to review any informational or warning logs generated so far by the running process.

9. It shall be possible for Operators to cancel any scheduled batch or report process, or kill any individual process while it is running, such that updates to the business data are rolled back and not committed.

10. The initiation of a batch or report process shall not prevent Operators from performing other tasks within the system using the same workstation, i.e. they are not required to wait for the batch or report process to complete before they can proceed to use other system functions.

11. It shall be possible to configure the system such that individual batch or report processes run automatically as a result of successful completion of other automated tasks. For instance, the successful completion of one batch process could automatically trigger a report based on data created by that batch process.

12. Reports containing data shall be made available in a machine readable format, with individual data fields separated by a delimiter character, and numeric fields being represented in a specified format, including the explicit use of decimal points where required. A definition of a standard physical file convention shall be established in the Design Phase as part of the Interface Definition and Design Specification, and be made available to BSCCo Ltd for distribution to relevant parties.

13. Suitably authorised Operators of the system shall be able to obtain printed copies of any report.

14. Operators of the system shall be able to obtain printed copies of any data which they are able to display via the user interface, given their security privileges. This includes snapshots of the current status of system management monitoring functions to which they have access, and a print of business data which they may have selected via a query on a data maintenance screen.

15. Operators of the system shall be able to save to a text file copies of any business data which they may have selected via a query on a data maintenance screen, given their security privileges. This text file should include the data in a simple comma-separated format compatible with standard desktop tools such as spreadsheets and word processors.

D-4 GEN-N004: Euro Compliance

Requirement ID:

GEN-N004

Status:

Mandatory

Title:

Euro Compliance

BSC Reference:

PPR- Action 3.2

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

N/A

Non Functional Requirement:

The Trading Arrangements on Day 1 of Trading shall be in Sterling and Trading in Euros shall not be permitted.

The NETA system and services shall not preclude being Euro Compliant in accordance with legal requirements applicable in England at a later date and after “Euro Compliancy” is further defined.

Also refer to Appendix F - Common Future Requirements.

D-5 GEN-N005: Help Desk Queries

Requirement ID:

GEN-N005

Status:

Mandatory

Title:

Help Desk Queries

BSC Reference:

Schedule 3 part 2

Man/Auto:

Manual

Frequency:

As required

Volumes:

Non Functional Requirement:

The system shall respond to queries within the timescales set out below:

1. For FAX and e-mail queries, the Operator shall register the query into the system within 15 minutes of receipt.

2. For Postal queries, the Operator shall register the query into the system within 4 hours of receipt.

3. For telephone queries, the Operator shall register the query immediately.

4. The system shall provide a 24hr help-desk facility.

The system shall allocate an appropriate severity level and respond to the query within the following timescales at a service level of greater than 95%.

Type of Incident	Severity Level	1st Call Back to caller	Follow-up Calls to caller	Escalation to the Customer
Immediate or sustained threat to the settlement timetable and output to Funds Administrator.	1	10 minutes	every 20 minutes	1 hour elapsed
Potential impact on settlement timetable or major problems for Participants with reports.	2	10 minutes	every 20 minutes	4 working hours
Severe impact on the accuracy of settlement data.	3	30 minutes	every 1 hour	8 working hours
Minor data error.	4	4 hours	every 8 hours	2 working days
General enquiries.	5	24 hours	every 24 hours	7 elapsed days

Reports against the service level requirements shall be produced as per URS specific Reporting functionality.

D-6 GEN-N006: Help Desk SLA Reporting

Requirement ID:

GEN-N006

Status:

Mandatory

Title:

Help Desk SLA Reporting

BSC Reference:

ITT Schedule 2 2.8

Man/Auto:

Manual

Frequency:

As required

Volumes:

Non Functional Requirement:

The Services shall produce reports monthly detailing the level of service provided by the agency to the BSCCo Ltd. The reports shall detail the response times in delivering various aspects of the system as detailed below. The Service level for each of the activities is contained within the braces in each case.

1) Register fax and e-mail queries into system within 15 minutes of receipt (100%)

2) Register postal query into system within 4 hours of receipt (100%)

3) Register telephone query immediately upon receipt (100%)

4) Query calls allocated an appropriate severity level and responded to within the timescales prescribed in GEN-N004. (95%)

5) Reports produced detailing Problems logged by Severity Level, total calls, calls answered in 10 seconds, confirmation of calls within response time, call sign off date outstanding problems that are outside the time-scale. (100%)

6) First reply to user in time-scale by Severity Level, second reply to user in time-scale by Severity Level, third reply to user in time-scale by Severity Level, subsequent replies to user in time-scale by Severity Level; (95% of calls for each severity level responded to within prescribed timescales)

7) Totals of problems solved within the agreed response times, those calls escalated and any outside the time-scales

8) Summary of all outstanding problems and their status including a copy of the current Help Desk Service Log

D-7 GEN-N007: Input Interface Requirements

Requirement ID:

GEN-N007

Status:

Mandatory

Title:

Input Interface Requirements

BSC Reference:

Man/Auto:

Manual

Frequency:

As required

Volumes:

Non Functional Requirement:

The Services shall carry out validation of all data input so as to ensure that the data is, as far as is practicable, complete and consistent.

Where data is to be input manually, the service shall use reasonable endeavours to ensure that the quality of the data is not compromised in any way. Data will be input in line with agreed service level agreements. The exact mechanism to ensure this is conducted will be developed in detail within the System and Detailed Design Specification.

Appendix E NETA Central Services Common Service Requirements

This section details the Service Requirements common to the entire suite of User Requirements Specifications. Only common requirements are detailed within this section - e.g. where a requirement is specific to a given sub-system it is detailed within the individual URS only.

E-1 GEN-S001: Volumetric Requirements

Requirement ID:

GEN-S001

Status:

Title:

Volumetric Requirements

BSC Reference:

Schedule 4 Part C Section 4

RETA ITT: A3

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

The following tables give indicative volumetric details and are for information only.

Assumption		Volumes
	Low	Average	High
BM Units		1,000	5,000
BSC Parties	100	200	300
Settlement Periods	46	48	50
Energy Accounts per BSC Party	2	2	2
Metering Systems	4,000	5,000	10,000

Transaction	Explanation		Volumes
		Low	Average	High
Aggregated Debits/Credits per day	BSC Service User * 5 Settlement Runs * 1 Settlement Day	500	1,000	1,500
	(3 after Bank Holidays, etc.)	(1,500)	(3,000)	(4,500)
Disputes resolved per week	Expected number of disputes	10	30	50
Reports produced per day	Assumed 5-20-45 Reports per BSC Service User per day	500	4,000	13,500

E-2 GEN-S002: Resilience and Availability Requirements

Requirement ID:

GEN-S002

Status:

Title:

Resilience and Availability Requirements

BSC Reference:

Schedule 4 Part C Section 1

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

Software and Data must be allocated over the Hardware configuration such as to ensure that agreed service levels are met.

The Service Provider shall ensure that no more than one day’s on-line Data is lost as a result of any failure of the System or Services. Any known lost Data will be recreated.

The Service Provider shall ensure that there is no permanent loss of Data.

E-3 GEN-S003: Backup and Recovery Requirements

Requirement ID:

GEN-S003

Status:

Title:

Backup and Recovery Requirements

BSC Reference:

Schedule 3 Part B Section 5

Man/Auto:

Manual & Automatic

Frequency:

As below.

Volumes:

As below.

Non Functional Requirement:

1. The Service Provider shall run, and record successful completion of, daily backup procedures for all on-line databases and maintain a documented backup log. The Customer shall be entitled to check on a random basis that all back-ups are completed and that a backup log is being maintained.

2. The Service Provider shall identify each backup and ensure that all backups are held on appropriate media, labelled accurately and clearly.

3. The Service Provider shall ensure that all backups are secured in two locations (one off-site) in fire proof and flood proof, safe environments, appropriate to the type of backup, as recommended by the media manufacturer.

4. The Service Provider shall ensure that backup and recovery procedures do not prejudice scheduled operations and are timed to minimise the risks of loss of data.

5. The Service Provider shall ensure that back up recovery times are compatible with service availability requirements.

6. The Service Provider shall ensure that all Data and Software necessary to support the Services are backed up at regular intervals in accordance with the timetable and procedure set out in the Operational Services Manual.

7. The Service Provider shall, at regular intervals not exceeding three months, ensure that the backup files could be restored if required.

E-4 GEN-S004: Archiving Requirements

Requirement ID:

GEN-S004

Status:

Title:

Archiving Requirements

BSC Reference:

Schedule 3 Part B Section 6

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

1. The Service Provider shall identify each archive and ensure that all archives are held on appropriate media, labelled accurately and clearly, in line with media manufacturer’s recommendations. All items should contain their original creation (or received) date and the date of archive.

2. The Service Provider shall ensure that all archives are secured in one or more offsite locations in fire proof and flood proof, safe environments, appropriate to the type of archive media, as recommended by the media manufacturer.

3. The Service Provider shall ensure that all archived material is retained and retrievable, in accordance with the following (unless specified otherwise in the individual URSs):

• on-line access must be available within 5 minutes for Data up to one month old;

• on-line access must be available within 24 hours for Data up to one year old;

• on-line access must be available within one week for Data up to seven years old.

4. The specific user identified archive requirements shall be detailed within the individual URS and System Specifications.

5. A document proposing archive strategy for the database shall be provided once the physical data model has been constructed and archive requirements for the URS’s have been agreed.

Issues:

Full archiving requirements will be detailed outside the scope of this document.

E-5 GEN-S005: Synchronise System Time

Requirement ID:

GEN-S005

Status:

Mandatory

Title:

Synchronise System Time

BSC Reference:

CRA SD 12

Man/Auto:

Manual

Frequency:

Daily

Volumes:

Non Functional Requirement:

The Service Provider shall ensure its systems are set in accordance with the Universal Time Clock (UTC), adjusting the time as necessary, at least once every 24 hours.

E-6 GEN-S006: Query Resolution

Requirement ID:

GEN-S006

Status:

Mandatory

Title:

Query Resolution

BSC Reference:

CRA Appendix B

Man/Auto:

Manual

Frequency:

Daily

Volumes:

Non Functional Requirement:

The Services shall provide facilities for the logging of queries from external agencies. The Service shall allow an Operator to enter details of the query into the system including the date / time of query incidence, the originating person / system, contact name (where appropriate) and the nature of the query.

Each query shall be assigned a severity level on the basis of the nature of the query in accordance with the requirements of GEN-N005. The severity level may be subsequently changed only be suitably authorised personnel.

The system shall require authentication details to be received prior to query functionality where mandated by the nature of the query.

The system shall log details of the query and return a unique query reference number to the originating party.

The system shall allow a query to be progressed through a number of states, depending upon the nature of the query, through to resolution. At each stage in this process, the actions of the Operator in advancing the query shall be logged against the user ID and date of time of advancement. Queries may only be ‘signed off’ by suitably authorised personnel.

Details of all queries entered into the system shall be maintained within the system subsequent to sign off.

The system shall provide reporting facilities on the range and resolution of problems:

1) Daily, A report shall be produced detailing Problems logged by Severity Level, total calls, calls answered in 10 seconds, confirmation of calls within response time, call sign off date.

2) Daily, a summary of all outstanding problems and their status

Issues:

A number of the service levels do not currently have an agreed timescales against which the service level percentage shall be judged. These shall be considered during the detailed design

E-7 GEN-S007: Performance Requirements

Requirement ID:

GEN-S007

Status:

Mandatory

Title:

Performance Requirements

BSC Reference:

Schedule 4 Part C Section 3

Man/Auto:

Manual & Automatic

Frequency:

Daily

Volumes:

Non Functional Requirement:

The Service Provider shall ensure that during Normal Operation,

• on-line access is achieved in accordance with agreed service levels

• all batch processes execute in time to meet agreed service levels

Normal Operation includes any commonly predictable periods of peak transaction rates.

Relevant service level agreements will be detailed outside the scope of this document.

Issues:

E-8 GEN-S008: Data Retention Requirements

Requirement ID:

GEN-S008

Status:

Mandatory

Title:

Data Retention Requirements

BSC Reference:

P107

Man/Auto:

Automatic

Frequency:

Ongoing

Volumes:

N/A

Non Functional Requirement:

The CRA, CDCA, SAA and ECVAA shall retain a minimum of 40 months of Settlement Data to support the Trading Disputes process. The latest 28 months of Settlement Data shall be retained on-line such that Settlement Runs or Volume Allocation Runs can be supported. A further 12 months Settlement Data shall be retained such that queries can be made to support Extra‑Settlement Determinations.

Issues:

Appendix F NETA Central Services Common Future Requirements

F-1 GEN-EURO: Euro Compliance

Requirement ID:

GEN-EURO

Status:

Mandatory

Title:

Euro Compliance

BSC Reference:

PPR- Action 3.2

Man/Auto:

Manual & Automatic

Frequency:

As required

Volumes:

N/A

Functional Requirement:

The Service Provider Hardware, Software and System will operate using financial data expressed in both the original currency and euros.

Appropriate modifications will be made in the data structure and relevant software programs and interfaces in order to accommodate the above requirement. This will include, but will not be limited to, the following:

– Systems analysis.

– Data conversion and changes to the data structure.

– Changes to the relevant interfaces.

– Modification of the relevant data validation engines.

– Reception, processing and presentation of original currency and euros.

– Testing, trialling and implementation.

The ability of the Hardware, Software and System to meet the agreed Service Levels will not be impaired by the above changes.

Appendix G Glossary

G-1 Glossary of acronyms:

WDBMCAEC_i MW	Working Day BM Unit Credit Assessment Export Capability
NWDBMCAEC_i MW	Non-Working Day BM Unit Credit Assessment Export Capability
WDBMCAIC_i MW	Working Day BM Unit Credit Assessment Import Capability
NWDBMCAIC_i MW	Non-Working Day BM Unit Credit Assessment Import Capability
BOLRⁿ_ij(t) MW	Bid-Offer Lower Range
BOURⁿ_ij(t) MW	Bid-Offer Upper Range
BSAP^m_j	Balancing Services Adjustment Price
CAB^kn_ij £	Period Acceptance Bid Cashflow
CAEI_aj £	Account Energy Imbalance Cashflow
WDCALF_i	Working Day Credit Assessment Load Factor
NWDCALF_i	Non-Working Day Credit Assessment Load Factor
CAO^kn_ij £	Period Acceptance Offer Cashflow
CAO^kn_ij £	Period Acceptance Offer Cashflow
CAPP (£/MWh)	Credit Assessment Purchase Price
CASP (£/MWh)	Credit Assessment Sale Price
CBM_ij £	Period BM Unit Cashflow
CBⁿ_ij £	Period BM Unit Bid Cashflow
CEP_aij %	Credited Energy Percentage
CII_ij £	Information Imbalance Charge
CNDBⁿ_ij £	Non-Delivered Bid Charge
CND_ij £	BM Unit Period Non-Delivery Charge
CNDOⁿ_ij £	Non-Delivered Offer Charge
COⁿ_ij £	Period BM Unit Offer Cashflow
CSOBM_j £	System Operator BM Charge
d	Settlement Day
ECQ_zabj MWh	Energy Contract Volume Notification Data
f	Point Value
FPN_ij MWh	Period FPN
FPN_ij(t) MW	Final Physical Notification
^fFPN_ijt MW	Point FPN
g	Ramp Rate
GC	Generation Capacity
i	BM Unit
IIP_j £/MWh	Information Imbalance Price
j	Settlement Period
k	Bid-Offer Acceptance
m	Balancing Services Adjustment Action
MDP_i Minutes	Maximum Delivery Period
MDV_i MW	Maximum Delivery Volume
MEL_i(t) MW	Maximum Export Limit
^fMEL_it MW	Point Maximum Export Limit
^fMIL_it MW	Point Maximum Import Limit
MIL_ij(t) MW	Maximum Import Limit
MNZT_i Minutes	Minimum Non-Zero Time
MP_j	Market Price
MZT_i Minutes	Minimum Zero Time
n	Bid
NDZ_i Minutes	Notice to Deviate from Zero
NTB_i Minutes	Notice to Deliver Bids
NTO_i Minutes	Notice to Deliver Offers
p	BSC Party
PAR_d	Price Average Reference Volume
PCL_p MW	Purchase Credit Limit
PBⁿ_ij £/MWh	Bid Price
POⁿ_ij £/MWh	Offer Price
qA^k_ij(t)MW	Acceptance Volume
qA^k_it MW	Point Acceptance Volume
qAB^kn_ij(t) MW	Accepted Bid Volume
qABO^kn_ij(t) MW	Accepted Bid-Offer Volume
qAO^kn_ij(t)MW	Accepted Offer Volume
qBOⁿ_ijt MW	Bid-Offer Volume
^fqBOⁿ_ijt MW	Point Bid-Offer Volume
QAB^kn_ij MWh	Period Accepted Bid Volume
QAO^kn_ij MWh	Period Accepted Offer Volume
QABⁿ_ij MWh	Period BM Unit Total Accepted Bid Volume
QABC_aj MWh	Account Bilateral Contract Volume
QABO_aj MWh	Account Period Bid-Offer Volume
QACE_aj MWh	Account Credited Energy Volume
QAEI_aj MWh	Account Energy Imbalance Volume
QBSAB^m_j	Balancing Services Adjustment Buy Volume
QBSAS^m_j	Balancing Services Adjustment Sell Volume
QBO_ij MWh	Period BM Unit Bid-Offer Volume
QCE_aij MWh	Credited Energy Volume
QFPN_ij(t) MW	Quiescent FPN
^fQFPN_ijt MW	Point Quiescent FPN
QII_ij MWh	Period Information Imbalance Volume
QM_ij MWh	BM Unit Metered Volume
QME_ij MWh	Period Expected Metered Volume
QNDB_ij MWh	Period BM Unit Non-Delivered Bid Volume
QNDBⁿ_ij MWh	Bid Non-Delivery Volume
QNDO_ij MWh	Period BM Unit Non-Delivered Offer Volume
QNDOⁿ_ij MWh	Offer Non-Delivery Volume
QSB^w_j	System Buy Action
QSS^w_j	System Sell Action
RCRC_aj £	Residual Cashflow Reallocation Cashflow
RCRP_aj No Units	Residual Cashflow Reallocation Proportion
RCC £	Required Credit Cover
^gRDE_i MW	Run-Down Elbow(s)
^gRDR_i MW/Minute	Run-Down Rate(s)
RPAR_d	Replacement Price Average Reference Volume
RQNDB^u_ij MWh	Remaining Period BM Unit Non-Delivered Bid Volume
RQNDO^u_ij MWh	Remaining Period BM Unit Non-Delivered Offer Volume
^gRUE_i MW	Run-Up Elbow(s)
^gRUR_i MW/Minute	Run-Up Rate(s)
SAP^w_j	System Action Price
SBP_j £/MWh	System Buy Price
SECALF_i	Supplier Export Credit Assessment Load Factor
SEL_i MW	Stable Export Limit
SCL_p MW	Sale Credit Limit
SIL_i MW	Stable Import Limit
SSP_j £/MWh	System Sell Price
TCBM_j £	Total System BM Cashflow
TCEI_j £	Total System Energy Imbalance Cashflow
TCII_j £/MWh	Total System Information Imbalance Charge
TCND_j £/MWh	Total System Non-Delivery Charge
T^k_it	Bid-Offer Acceptance Time
TLM_ij No Units	Transmission Loss Multiplier
TQAB_j MWh	System Total Accepted Bid Volume
TQAO_j MWh	System Total Accepted Offer Volume
TRC_j £	Total System Residual Cashflow
u	Non-Delivery Order Number
w	System Action
z	Energy Contract Volume Notification Agent

G-2 Glossary of terms:

Acceptance Volume (qA^k_ij(t)) MW

The Acceptance Volume (qA^k_ij(t)) is the absolute level of operation at time t implied as a result of Bid-Offer Acceptance k, for BM Unit i in Settlement Period j.

Accepted Bid Volume (qAB^kn_ij(t)) MW

The Accepted Bid Volume (qAB^kn_ij (t)) is the volume of Bid n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j.

Accepted Bid-Offer Volume (qABO^kn_ij(t)) MW

The Accepted Bid-Offer Volume (qABO^kn_ij (t)) is the volume of Bid or Offer from Bid-Offer Pair n accepted as a result of Bid-Offer Acceptance k in Settlement Period j from BM Unit i.

Accepted Offer Volume (qAO^kn_ij(t)) MW

The Accepted Offer Volume (qAO^kn_ij (t)) is the volume of Offer n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j.

Account Bilateral Contract Volume (QABC_aj) MWh

The Account Bilateral Contract Volume (QABC_aj) is the sum of all notified (and accepted) Bilateral Total Energy Contract Volumes for Energy Account a in Settlement Period j

Account Credited Energy Volume (QACE_aj) MWh

The Account Credited Energy Volume (QACE_aj) is the aggregate of the BM Unit Metered Volumes allocated to Energy Account a in Settlement Period j.

Account Energy Imbalance Cashflow (CAEI_aj) £

The Account Energy Imbalance Cashflow (CAEI_aj) is the total cashflow resulting from the Energy Imbalance of Energy Account a in Settlement Period j.

Account Energy Imbalance Volume (QAEI_aj) MWh

The Account Energy Imbalance Volume (QAEI_aj) is the volume of Energy Imbalance for Energy Account a in Settlement Period j.

Account Period Bid-Offer Volume (QABO_aj) MWh

The Account Period Bid-Offer Volume (QABO_aj) is the sum of the volume of all accepted Bids and Offers from all BM Units for which Energy Account a is the Lead Energy Account in Settlement Period j.

Accreditation

Accreditation has been replaced by Qualification, please refer to Qualification in this glossary. This term is retained to maintain compatibility with the IDD flow definitions.

Advice Note and Statement

Statements produced by the FAA advising BSC Parties of their debits/credits.

Aggregation

The process used by the CDCA to produce aggregated energy volumes for Settlement.

Aggregation Rules

The rules governing the aggregation of Metering System data to produce total aggregated volumes for transfer to Settlement. An Aggregation Rule may be defined at Metering System, Boundary Point BM Unit and Trading Unit levels.

Ancillary Services

Services required to ensure the stable and secure operation of the Transmission Network. These services include the provision of frequency, response, reserve, reactive power and black start.

Applicable Dispensation

A Dispensation or a Generic Dispensation which has been granted by the Customer and is applicable to a particular Metering Equipment.

Auditor

The organisation appointed by the Customer to provide assurance on the operation of Settlement and correctness of the allocation of Credits and Debits.

Authentication

A process performed by the CRA to determine the validity of the originator or recipient of data.

Balancing and Settlement Code

The rules, systems and processes underpinning the new balancing and settlement arrangements.

Balancing and Settlement Code Service Agent

An Agent that acts on behalf of the Balancing and Settlement Code Company to operate Balancing and Settlement Code processes.

Balancing and Settlement Code Company Costs

The costs associated with all of the agency functions that are operated on behalf of the Balancing and Settlement Code Company, and of other Balancing and Settlement Code Company activities.

Balancing and Settlement Code Start Date

The first Settlement Day for which electricity over the Total System is settled under the terms of the Balancing and Settlement Code.

Balancing and Settlement Code Panel

A panel to supervise proposed modifications to the BSC.

Balancing Mechanism Report

A report produced by the Settlement Administration Agent after each Settlement Day, detailing activities on the Balancing Mechanism and estimated imbalance Prices.

Balancing Mechanism Reporting Agent

A Balancing and Settlement Code Company Service Agent responsible for relaying to Parties information about the Balancing Mechanism.

Balancing Mechanism Reporting Service

The service carried out by the Balancing Mechanism Reporting Agent in capturing system related status information and Balancing Mechanism data and publishing this to BSC Parties and the public in order to present a near to real-time representation of the electricity markets and the Balancing Mechanism.

Balancing Mechanism Reporting System

A system used by the Balancing Mechanism Reporting Agent to provide information about the Balancing Mechanism.

Balancing Mechanism Window Period

The Balancing Mechanism Window for any time, t, is a time period with a duration of the Gate Closure Period that starts at the end of the half hour period for which Gate Closure has most recently passed.

Bid

Refers to a submission indicating a willingness to decrease the volume of MW delivered in the Balancing Mechanism through a decrease in generation or an increase in demand.

Bid Non-Delivery Volume (QNDBⁿ_ij) MWh

The Bid Non-Delivery Volume (QNDBⁿ_ij) is the volume of non-delivery apportioned to Bid n from BM Unit i in Settlement Period j.

Bid Number (n)

A number identifying a particular Bid.

Bid Price (PBⁿ_ij) £/MWh

The Bid Price (PBⁿ_ij) is the Price at which a BSC Party is willing to buy an additional MWh of Bid n from BM Unit i in Settlement Period j.

Bid-Offer Acceptance

A Bid-Offer Acceptance is the purchase and/or sale of Offers and/or Bids by the NETSO in its operation of the Balancing Mechanism.

Bid-Offer Acceptance Data

Bid-Offer Acceptance Data is that data which is sent by the NETSO to a BSC Party in order to accept a Bid and/or Offer.

Bid-Offer Acceptance Number (k)

The Bid-Offer Acceptance Number (k) is a number identifying a particular set of Bid-Offer Acceptance Data.

Bid-Offer Acceptance Time (T^k_it)

The Bid-Offer Acceptance Time (T^k_it) is the time at which the NETSO issues Bid-Offer Acceptance k.

Bid-Offer Data

The Bid-Offer Data comprises is made up of a series of Bid-Offer Pairs and, if appropriate, associated information that links Bids and Offers from a particular BM Unit to those from other BM Units.

Bid-Offer Lower Range (BOLRⁿ_ij(t)) MW

The Bid-Offer Lower Range (BOLRⁿ_ij(t)) is calculated for Bid-Offer Pairs with negative Bid-Offer Pair Numbers. It is used to determine the operating range (in absolute MW) below FPN in which a particular Bid-Offer Pair applies.

Bid-Offer Pair

A Bid-Offer Pair comprises:

a set of Point Bid-Offer Volumes ^fqBOⁿ_ijt expressed in MW for spot times t falling within Settlement Period j.

an associated Offer Price POⁿ_ij and Bid Price PBⁿ_ij expressed in £/MWh.

an associated Bid-Offer Pair Number n. This is also set to be the Bid-Number of the Bid and the Offer Number of the Offer.

Bid-Offer Pair Number (n)

A number used to identify a particular Bid-Offer Pair. Values of n are negative for Bid-Offer Pairs that cover operating levels below FPN and positive for those that cover operating levels above FPN.

Bid-Offer Upper Range (BOURⁿ_ij(t)) MW

The Bid-Offer Upper Range (BOURⁿ_ij(t)) is calculated for Bid-Offer Pairs with positive Bid-Offer Pair Numbers. It is used to determine the operating range (in absolute MW) below FPN in which a particular Bid-Offer Pair applies.

Bid-Offer Volume (qBOⁿ_ij(t)) MW

The Bid-Offer Volume (qBOⁿ_ij(t)) is the volume available (relative to FPN) from Bid-Offer Pair n, in Settlement Period j for BM Unit i. Whilst it is, in theory a function of time and can vary across the Settlement Period, it is initially a fixed value.

Black Start

The procedure necessary for a recovery from a Total Shutdown or Partial Shutdown of the Total System.

Black Start Capability

The ability for at least one of a Power Station of Centrally Despatched Generating Units to start up for shutdown and to energise a part of the transmission system without an external electric power supply.

BM Unit

A BM Unit is a point of entry, or exit, to the transmission system where a Final Physical Notification will be required from a Party. For Demand this will normally be a Grid Supply Point Group except where there is a Trading Unit directly connected to the Transmission System. For generation it will normally be a Boundary Point for a single genset.

BM Unit Credit Assessment Export Capability (BMCAEC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access export rights of the BM Unit, GC_i, corrected by the Credit Assessment Load Factor.

Working Day BM Unit Credit Assessment Export Capability (WDBMCAEC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access export rights of the BM Unit, GC_i, corrected by the Credit Assessment Load Factor, for Working Days.

Non-Working Day BM Unit Credit Assessment Export Capability (NWDBMCAEC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access export rights of the BM Unit, GC_i, corrected by the Credit Assessment Load Factor, for non-Working Days.

BM Unit Credit Assessment Import Capability (BMCAIC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access import rights of the BM Unit, DC_i, corrected by the Credit Assessment Load Factor.

Working Day BM Unit Credit Assessment Import Capability (WDBMCAIC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access import rights of the BM Unit, DC_i, corrected by the Credit Assessment Load Factor, for Working Days.

Non-Working Day BM Unit Credit Assessment Import Capability (NWDBMCAIC_i) MW

A value maintained for credit assessment purposes reflecting the transmission access import rights of the BM Unit, DC_i, corrected by the Credit Assessment Load Factor, for non-Working Days.

BM Unit Identifier Number (i)

A unique identifier for each BM Unit, generally denoted by (i).

BM Unit Lead Party

The BM Unit Lead Party is responsible for submitting all Balancing Mechanism data for a specified BM Unit.

BM Unit Metered Volume (QM_ij) MWh

The BM Unit Metered Volume (QM_ij) is the metered generation or demand associated with BM Unit i in Settlement Period j.

BM Unit Period Non-Delivery Charge (CND_ij) £

The BM Unit Period Non-Delivery Charge (CND_ij) is the total non-delivery charge associated with the non-deliver of Bids or Offers for BM Unit i in Settlement Period j.

BM Unit Subsidiary Party

A number of parties (Lead and Subsidiary) may split the imbalance liabilities associated with a BM Unit. The BM Unit Subsidiary Party/Parties take a percentage of the imbalance liabilities but is/are not responsible for submitting Balancing Mechanism data for that BM Unit.

Boundary Point

A Meter Point is a single physical point of entry or exit to the Total System.

British Grid Systems Agreement

An agreement governing technical aspects of the interconnection between the transmission networks of the NETSO’s, Scottish Power and Scottish and Southern Energy.

BSC Panel Ruling

A ruling made by the Balancing and Settlement Code Panel in respect of a BSC Party in a Credit Default position.

Category 1 Revisit

A grade of Revisited Site categorised according to the degree of non-compliance for charging purposes.

Category 2 Revisit

A grade of Revisited Site categorised according to the degree of non-compliance for charging purposes.

Central Data Collection Agent

A Balancing and Settlement Code Service Agent responsible for the collection of metered data from Boundary Points that are registered under the Central Registration Agent.

Central Registration Agent

The Central Registration Agent will register Balancing and Settlement Code Parties, BM Units, Trading Units, and Boundary Points other than meters registered in Supplier Meter Registration systems.

Certificate of Competence

The certificate of competence required to be held by individual Technical Assurance Agent’s staff in order to comply with safety rules.

Certification

Certification has been replaced by Qualification, please refer to Qualification in this glossary. This term is retained to maintain compatibility with the IDD flow definitions.

Channel or Meter Number

A number allocated to a data stream from Metering Equipment.

A number allocated to an individual Meter within a Metering Equipment at an installation where there is more than one Meter installed.

Circuit Identifier

A name or number or combination of alpha-numeric characters which permit the unique identification of a circuit at a site.

Code of Practice (COP)

Codes of Practice issued by the Customer relating to Metering Equipment. Each Code of Practice specifies the set of measured quantities and accuracies that are required to be provided by the Metering System.

Commissioning Information

The programme performed on all new Metering Equipment, which is to provide metering data for Settlement, as defined in the relevant Code(s) of Practice.

Confirmation Notice

A notice sent to each BSC Party setting out (amongst other things) the total amount received into the FAA Clearing Account.

Contact Point

The single point of contact provided by the Technical Assurance Agent.

Credit Assessment Export Capability

A value maintained for credit assessment purposes reflecting the transmission access export rights of the BM Unit, GC_i, corrected by the Credit Assessment Load Factor.

Credit Assessment Import Capability (BMCAIC_i)

A value maintained for credit assessment purposes reflecting the transmission access import rights of the BM Unit, DC_i, corrected by the Credit Assessment Load Factor.

Working Day Credit Assessment Load Factor (WDCALF_i), Non-Working Day Credit Assessment Load Factor (NWDCALF_i) and Supplier Export Credit Assessment Load Factor (SECALF_i)

An administered load factor for a BM Unit under the control of the Balancing and Settlement Code Panel used to derive credit cover requirements from transmission access rights.

Credit Assessment Purchase Price CAPP (£/MWh)

An administered Price used to value the liabilities of a BSC Party in respect of a shortfall of energy or purchase from the system, for the purposes of calculating credit cover requirements. CAPP will be positive.

Credit Assessment Sale Price CASP (£/MWh)

An administered Price used to value the liabilities of a BSC Party in respect of an excess of energy or sale from the system, for the purposes of calculating credit cover requirements. CASP will be zero or negative.

Credit Cover

Credit Cover is required from all BSC Parties to a level consistent with an assessment of their possible liabilities to Balancing and Settlement Code Settlement.

Credit Cover Contract Duration (CCCD)

The number of days of potential exposure for which credit cover must be provided. CCCD will be set to 28 reflecting the lag between the Settlement Day and the Initial Payment Date.

Credit Cover Physical Duration (CCPD)

The number of days of potential exposure for which credit cover must be provided. CCCP will be set to 28 plus the number of days required to disconnect or transfer customers following a party’s default.

Credit Default

Credit Default arises where a BSC Party fails to provide the Credit Cover Required or, where the Credit Cover provided is not sufficient to cover any outstanding debt.

Credit Policy

The Credit Policy determined by the Customer that is required from all BSC Parties to a level that is consistent with an assessment of their possible liabilities.

Credited Energy Percentage (CEP_aij) %

The Credited Energy Percentage (CEP_aij) is the percentage allocation of the metered volume from BM Unit i (adjusted for Balancing Mechanism action) to be allocated to Energy Account a in Settlement Period j.

Credited Energy Percentage Authorisation

A Credited Energy Percentage Authorisation is required to permit the submission of Credited Energy Percentages by a Credited Energy Percentage Notification Agent, and for the validation of these data.

Credited Energy Percentage Notification

The notification of Credited Energy Percentages by a CEPNA to an ECVAA.

Credited Energy Percentage Notification Agent

Credited Energy Percentage Notification Agents will submit Credited Energy Percentages to the Energy Contract Volume Aggregation Agent, on behalf of the BM Unit Lead and Subsidiary Parties.

Credited Energy Volume (QCE_aij) MWh

The Credited Energy Volume (QCE_aij) is the allocation of the metered volume from BM Unit i (adjusted for Balancing Mechanism action) to be allocated to Energy Account a in Settlement Period j.

Current Transformer Ratio

The nominal turns ratio between the primary and secondary windings of a current transformer. (e.g. a 300 ampere primary and 5 ampere secondary windings would be shown as a ratio of 300/5).

Central Volume Allocation Meter Operator Agent

An organisation accredited to install, commission and maintain the physical meters and communications equipment compliant with Codes of Practice that comprises a CVA Metering System.

Data Collector ID

The unique identifier for a Data Collector.

Data Collector Instation

Electronic hardware and software or computer systems used to collect online data from remote Metering Equipment. Usually located at the Data Collectors offices.

Data Collector Outstation Type

Equipment which receives and stores data from a Meter(s) for the purpose of transfer of that metering data to the Central Data Collection Agent and which may perform some processing before such transfer. This equipment may be in one or more separate units or may be integral with the Meter.

Deemed Bid-Offer Flag

The Deemed Bid-Offer Flag is a flag that is activated if the Bid-Offer Acceptance issued by the NETSO is accepting Deemed Bids and/or Offers.

Deemed Bid

A Bid that utilises Default Data and which may only be accepted by the NETSO when relevant freely submitted Bids and/or Offers have been exhausted.

Deemed Data

Deemed Data includes Deemed Bids and Deemed Offers and associated Prices.

Deemed Offer

An Offer that utilises Default Data and which may only be accepted by the NETSO when relevant freely submitted Bids and/or Offers have been exhausted.

Default Data

Data items utilised in settlements, or in selecting Bid-Offer Acceptances where the data items have not been submitted, or have been submitted but rejected.

Demand Capacity (MW)

The maximum demand of MW and MVAr of electricity

Direct Connected Consumer Demand

Demand that is electrically connected to the distribution system of a Public Electricity Supplier and is not directly connected to the National Electricity Transmission System

Dispute

An objection raised by a BSC Party, the NETSO or by BSCCo Ltd if they object to the results of a Settlement when they believe that the calculation has been undertaken using the wrong data or the calculation does not follow the rules. The Settlement Administration Agent may also raise a dispute on behalf of BSC Parties if errors in calculations or data are detected or suspected.

Dispute Run

A re-run of the settlement process where a dispute has been resolved between parties or the Customer has decided the outcome.

Distribution

The distribution of electricity over the system of a Public Electricity Supplier.

Distribution Networks

The system consisting (wholly or mainly) of electric lines owned or operated by a Public Electricity Supplier (PES)and used for the distribution of electricity from Grid Supply Points or Generating Units or other entry points to the point of delivery to users, and operated by such Public Electricity Supplier excluding any part of the National Electricity Transmission System

Distribution System Operator

The Public Electricity Suppliers, as operators of a distribution network.

Dynamic Data

Dynamic Data is a collective term for the following parameters:

Run-Up Rate(s) ^gRUR_I;

Run-Up Elbow(s) ^gRUE_I;

Run-Down Rate(s) ^gRDR_I;

Run-Down Elbow(s) ^gRDE_I;

Maximum Export Limit MEL_j(t);

Maximum Import Limit MIL_j(t);

Notice to Deviate from Zero NDZ_I;

Notice to Deliver Offers NTO_I;

Notice to Deliver Bids NTB_i;

Minimum Zero Time MZT_I;

Minimum Non-Zero Time MNZT_I;

Maximum Delivery Volume MDV_I;

Maximum Delivery Period MDP_I;

Stable Export Limit SEL_I;

Stable Import Limit SIL_I.

Embedded Demand

Demand that is electrically connected to the distribution system of a Public Electricity Supplier and is not directly connected to the National Electricity Transmission System.

Embedded Generation

A generator that is electrically connected to the distribution system of a Public Electricity Supplier and is not directly connected to the National Electricity Transmission System.

Energy Account

BSC Parties will in general have two Energy Accounts, one for their Production Activity and one for their Consumption Activity. Each Energy Account will belong to a single BSC Party.

Energy Account Number a

Each Energy Account will have a unique Energy Account Number, generally denoted by the letter a or b.

Energy Contract Purchase Credit Limit ECPCL (MW)

For each BSC Party, purchase Energy Contract Volumes notified for Initial Settlement will be capped by its Energy Contract Purchase Credit Limit, applied over the daily average of gross Energy Contract Volumes.

Energy Contract Sales Credit Limit ECSCL (MW)

For each BSC Party, sales Energy Contract Volumes notified for Initial Settlement will be capped by its Energy Contract Sale Credit Limit, applied over the daily average of gross Energy Contract Volumes.

Energy Contract Volume

Energy Contract Volumes are data submitted to settlement to allow BSC Parties to offset imbalances and reflect bilateral trading of energy.

Energy Contract Volume Aggregation Agent

The Energy Contract Volume Aggregation Agent will receive, validate and aggregate notifications of Energy Contract Volumes, and provide the Settlement Administration Agent with the net aggregate position of each BSC Party for each Settlement Period.

Energy Contract Volume Authorisation

An Energy Contract Volume Authorisation is required to permit the submission of Energy Contract Volumes by an Energy Contract Volume Notification Agent, and for the validation of these data.

Energy Contract Volume Day Data

The Energy Contract Volumes in an Energy Contract Volume Day Notification.

Energy Contract Volume Day Notification

An Energy Contract Volume Day Notification will permit the submission in a single file of Energy Contract Volumes for each Settlement Period of a Settlement Day.

Energy Contract Volume Evergreen Flag

An element of an Energy Contract Volume Day Notification permitting the submission of a pattern Energy Contract Volumes that will be repeated for every Settlement Day until replaced by a new notification.

Energy Contract Volume Notification

An Energy Contract Volume Day Notification or an Energy Contract Volume Period Notification.

Energy Contract Volume Notification Agent

Energy Contract Volume Notification Agents will submit Energy Contract Volumes to the Energy Contract Volume Aggregation Agent, on behalf of the Energy Contract Volume Parties.

Energy Contract Volume Notification Agent Identifier

A unique identifier for each Energy Contract Volume Notification Agent.

Energy Contract Volume Party

The Energy Contract Volume Parties are the two BSC Parties which are the counter parties to an Energy Contract Volume.

Energy Contract Volume Period Data

The Energy Contract Volume in an Energy Contract Volume Period Notification.

Energy Contract Volume Period Notification

An Energy Contract Volume Period Notification will permit the submission of Energy Contract Volumes for a single Settlement Period.

Energy Imbalance Prices

The System Sell Price and the System Buy Price.

Export Active Energy

The electrical energy produced, flowing or supplied by an electric circuit during a time interval, and being the integral with respect to time of the instantaneous power, measured in units of watt-hours. In general terms Export Active Energy is deemed to flow towards the transmission system.

Export Reactive Energy

The product of voltage and current and the sine of the phase angle between them measured in units of volt-amperes reactive and standard multiples thereof as determined by the relevant Code of Practice.

Externally Interconnected System Operator

For each external Interconnector with the Total System, the system operator of the interconnected system will be known as an Externally Interconnected System Operator.

Final Physical Notification (FPN_ij(t)) MW

The Final Physical Notification for BM Unit is the level of generation or demand (as the case may be) that the BSC Party expects to generate or consume from BM Unit i, in the absence of any Balancing Mechanism Acceptances from the NETSO. The value of FPN_ij(t) is calculated for spot times t in Settlement Period by linear interpolation from the values of Point FPN.

Final Physical Notification Data

Final Physical Notification Data incorporates Point FPN Data and Point Quiescent FPN Data.

Funds Administration Agent

The Funds Administration Agent will effect the payments resulting from Settlement, maintain financial and tax documentation, and manage credit and default arrangements.

Gate Closure

Gate Closure for a particular Settlement Period is the spot time one Gate Closure Period in advance of the spot time at the start of that Settlement Period.

Gate Closure Period (Time)

The Gate Closure Period is the length of time between Gate Closure and the spot time at the start of the associated Settlement Period. It is set at 4 hours.

Generation

The production of electricity.

Generation Capacity (MW)

The normal full load capacity of a generating unit.

Generator

A person who generates electricity under licence or exemption under the Electricity Act 1989.

Genset

Plant or apparatus for the production of electricity.

Good Industry Practice

The exercise of that degree of skill, diligence, prudence and foresight, which would reasonably and ordinarily be expected from a skilled and experienced operator engaged in the provision of services similar to the Services.

Grid Entry Point

The point at which a Power Station which is not embedded connects to the National Electricity Transmission System.

Grid Operator

Operates the transmission system with the objective of providing a reliable supply and maintaining voltage and frequency within the standards laid down in the transmission licence. Using the generator’s offer data the GO schedules and despatches generating sets (gensets) to meet demand whilst attempting to ensure the security and integrity of the transmission system.

Grid Code

A code of that name established pursuant to the Transmission Licence.

Grid Supply Point

Any point where electricity is delivered from the transmission system to a distribution system.

Grid Supply Point Group

Several Grid Supply Points, usually within the geographical area of a Public Electricity Supplier, which are grouped together for Settlement purposes.

GSP Groups

A distinct electrical system, consisting of all or part of a distribution system (owned and operated by a Distributor) that is supplied by one or more GSPs for which total supply into the GSP Group can be determined for each half hour.

GSP Group Take

The total demand metered at Grid Supply Points net of 100k W supplies handled by the SMRA, Station Demand, Interconnector Demand and inter GSP Group metering.

Half Hourly Meter

A meter which provides measurements on a half hourly basis.

Half-Hour Data Aggregation Agent (HHDAA)

A party which aggregates data from half-hourly meters, under the Stage 2 Settlement process.

Half-Hour Data Collection Agent (HHDCA)

A party which collects data from half-hourly meters under the Stage 2 Settlement process.

Hand Held Unit (HHU)

Also known as an Interrogation Unit or Local Interrogation Unit LIU, or a portable computer, which can enter Metering Equipment parameters and extract information from the Metering Equipment and store this for later retrieval.

Host Public Electricity Supplier Distribution Business

See PES Distribution Business.

Import Active Energy

Import Reactive Energy

Information Imbalance Charge (CII_ij) £

The Information Imbalance Charge (CII_ij) is the charge applicable to the associated Lead Energy Account as a result of the Information Imbalance from BM Unit i in Settlement Period j.

Information Imbalance Price (IIP_j) £/MWh

The Information Imbalance Price (IIP_j) is the Price used to settle Information Imbalances. It is initially set to zero.

Initial Payment Date

The date at which the payments in respect of Initial Settlement for a Settlement Day are made, on average 28 days after the Settlement Day.

Initial Physical Notification (IPN)

The physical notification made to the NETSO on the day ahead probably at 15:00, which can be revised until Gate Closure (four hours before delivery) when it becomes a FPN.

Initial Settlement

The Initial Settlement Run will take place about 24 days after the Settlement Day, for payments to be effected about 28 days after the Settlement Day.

Initial Settlement Report

A report of data used in and created by Initial Settlement.

Initial Settlement Timescales

The timescales for the submission of data to the SAA for Initial Settlement purposes.

Inspection Schedule

The TAA Site Inspection Schedule.

Instation Universal Co-ordinated Time

The international time standard used by an Instation.

Interconnector

An Interconnector is an apparatus for the transmission of electricity to and from the National Electricity Transmission System or a Public Electricity supplier distribution system into or out of an external system.

Interconnector Administrator

The Interconnector Administrator administers Interconnector capacity entitlements and provides information for Settlement.

Interconnector Emergency Support

The procedures for system-to-system assistance across Interconnectors.

Interconnector Emergency Support Offer Price (IESOP_ij) £/MWh

A Price submitted by an Interconnector User and used to settle energy flows arising from Interconnector Emergency Support.

Interconnector Error Account

An Energy Account associated with an Interconnector Error Administrator.

Interconnector Error Account BM Unit

A BM Unit allocated to the relevant Interconnector Error Administrator in respect of each Interconnector.

Interconnector Error Administrator

The Interconnector Error Administrator is a BSC Party responsible for any difference between the Interconnector metered flow and the aggregated volumes of Interconnector Users.

Interconnector User

Any party that is able to notify flows across an Interconnector and have them deemed delivered is an Interconnector User for that Interconnector. Interconnector Users are required to be parties to the England & Wales Balancing and Settlement Code and to the arrangements governing Interconnector access.

Interim Initial Settlement

The Interim Initial Settlement Run will take place at about 4 days after the Settlement Day.

Keys

A system(s) or process(s) that enables the BSC Party or BSC Service Agent to authenticate the originator or recipient of data.

Kilowatt (kW)

1000 watt.

Kilowatt Hour (kWh)

The energy delivered by 1kW over 1 hour.

Lead Energy Account

The Lead Energy Account is the Energy Account of the Registrant of the Boundary Point associated with a particular BM Unit.

Lead Party

The BSC Party that is responsible for the Lead Energy Account of a particular BM Unit and who registers the Boundary Point(s) associated with a particular BM Unit.

Licensed Distribution System Operator (LDSO)

Generic term for any Party which operates an electricity distribution network.

Line Loss Class

A set of Metering Systems that are assigned the same Line Loss Factor.

Line Loss Factor (LLF)

A multiplier applied to correct metered volumes at embedded Boundary Points to a Grid Supply Point to account for electrical losses in the distribution system.

Line Loss Factor Class

A class of Line Loss which applies to a group of Metering Systems where a group may be one or more Metering Systems.

Market Domain Data

Data provided to all persons involved in settlements in accordance with the Balancing and Settlement Code.

Maximum Delivery Period (MDP_i(t)) Minutes

At any time t, the Maximum Delivery Period (MDP_i(t)) is the time period over which the Maximum Delivery Volume restriction applies for BM Unit i.

Maximum Delivery Volume (MDV_i(t)) MW

At any time t, the Maximum Delivery Volume (MDV_i(t)) is the maximum number of MWh of Offer (or Bid if negative), that a particular BM Unit i may deliver on a cumulative basis within the associated Maximum Delivery Period.

Maximum Export Limit (MEL _i(t)) MW

The Maximum Export Limit (MEL_i(t)) is the maximum power export that a BM Unit is capable of at time t.

Maximum Import Limit (MIL _ij(t)) MW

The Maximum Import Limit (MILi(t)) is the maximum power export that a BM Unit is capable of at time t.

Megawatt (MW)

1,000 kW.

Meter

A device for measuring active and/or reactive energy.

Meter Advance Reconciliation

The process of comparing physical meter register advances with electronically gathered half hourly consumption data over a defined period of time

Meter Commissioning Date

The date on which any Metering System or Metering Equipment is commissioned in accordance with the relevant Code of Practice.

Meter Constant

A multiplier or fraction, which is applied to the measurement quantities so as to obtain the real value of Energy measured.

Meter Manufacturer

The manufacturer of the Metering Equipment, usually recorded for the Meter only. The whole Metering Equipment may comprise components from a range of manufacturers.

CVA Meter Operator Agent Appointment Date

The date of appointment of a CVA Meter Operator Agent for a particular Metering System.

Meter Point

A Meter Point means the point at which a supply to (export) or from (import) a Distribution System is measured.

Meter Pulse Multiplier

A constant, multiplier or fraction, which is applied to pulsed outputs to derive an Energy value for each pulse. This value may also be used in conjunction with a Meter Constant.

Meter Reading Schedule

A schedule produced by the CDCA that details the timing and frequency of meter readings required for the Meter Advance Reconciliation (MAR) process.

Meter Serial Number

The serial number as shown on the nameplate on the front of a Meter.

Meter Test Certificate

A certificate recording the accuracy and calibration details of an individual Meter.

Meter Type

A Half Hourly or Non-half hourly Meter.

A Manufacturers model or identification markings.

Metered Volume Fixed Reallocation

A fixed allocation, specified in MWh, of a BM Unit Metered Volume, which is credited to the Energy Account of a Subsidiary Party from the Energy Account of the Lead party at the relevant BM Unit.

Metered Volume Percentage Reallocation

A percentage allocation of a BM Unit Metered Volume after the deduction of any Metered Volume Fixed Reallocations and Period Accepted Bid and Offer Volumes, which is credited to the Energy Account of a Subsidiary Party from the Energy Account of the Lead Party at the relevant BM Unit.

Metered Volume Reallocation Notification

A notification submitted by the Metered Volume Reallocation Agent on behalf of BM Unit Lead and Subsidiary Parties and compromising a set of Metered Volume Fixed Reallocations and a set of Metered Volume Percentage Reallocations (note that a Metered Volume Reallocation Agent is synonymous with and replaces the Credited Energy Percentage Notification Agent).

Metering Code of Practice

One of the documents of that name currently established pursuant to the Pooling and Settlement Agreement.

Metering Equipment

Meters, measurement transformers (voltage, current or combination units), metering protection equipment including alarms, circuitry, associated communications equipment and outstations and wiring, which are part of the Active Energy and/or Reactive Energy measuring and transmitting equipment for Settlement.

Metering Inside Settlement Timescales

Half-hourly metering such that data is available for Initial Settlement.

Metering Outside Settlement Timescales

Metering such that data is not available for Initial Settlement.

Metering System

All or that part of the commissioned Metering Equipment at or relating to a site linked to a single outstation at or relating to that site (including such outstation) which measures a trade in active energy, or as the case may be reactive energy. In this context metering equipment refers to the meters, measurement transformers (voltage, current or combination units), metering protection equipment including alarms, circuitry associated communications equipment and outstations and wiring which are part of the active energy and/or reactive energy measuring and transmitting equipment.

Minimum Non-Zero Time (MNZTi) Minutes

At any time t, the Minimum Non-Zero Time (MNZT_i) represents the minimum time that BM Unit i can operate at a non-zero level as a result of accepted Balancing Mechanism action.

Minimum Zero Time (MZTi) Minutes

At any time t, the Minimum Zero Time (MZT_i) is the minimum time that a BM Unit must operate at zero or import, before returning to export; whereas if it is importing, MZT indicates the minimum time that it must operate at zero or export before returning to import, if action by the NETSO places it at such a level.

NETSO

The entity that fulfils the role of operating the transmission system, including issuing instructions to generators or demand to change its level of output or take, and instructing the provision of Ancillary Services and other measures necessary to maintain a stable and secure system. This role in Great Britain is carried out by the NETSO under the terms of its Transmission Licence.

Non-Delivered Bid Charge (CNDBⁿ_ij) £

The Non-Delivered Bid Charge (CNDBⁿ_ij) is the charge associated with the non-delivery of Bid n in Settlement Period j from BM Unit i.

Non-Delivered Offer Charge (CNDOⁿ_ij) £

The Non-Delivered Offer Charge CNDOⁿ_ij is the charge associated with the non-delivery of Offer n in Settlement Period j from BM Unit i.

Non-Delivery Order Number (u)

The Non-Delivery Order Number (u) is an index used to rank non-delivered Offers or Bids from a BM Unit in a particular Settlement Period in order to determine the order of allocation the Period BM Unit Non-Delivered Offer Volume, or the Period BM Unit Non-Delivered Bid Volume.

Non-Half-Hour Data Aggregation Agent (NHHDAA)

A party which aggregates data from non-half-hourly meters, under the Stage 2 Settlement process.

Non-Half-Hour Data Collection Agent (NHHDCA)

A party which collects data from non-half-hourly meters, under the Stage 2 Settlement process.

Notice to Deliver Bids (NTB_i) Minutes

The Notice to Deliver Bids (NTB_i) is a Dynamic Data item that indicates the length of time between the issuing of a Bid-Offer Acceptance and the time when a BM Unit begins to deliver Bid volumes.

Notice to Deliver Offers (NTO_i) Minutes

The Notice to Deliver Offers (NTO_i) is a Dynamic Data item that indicates the length of time between the issuing of a Bid-Offer Acceptance and the time when a BM Unit begins to deliver Offer volumes.

Notice to Deviate from Zero (NDZ_i) Minutes

The Notice to Deviate from Zero (NDZ_i) expresses the notification time required for a BM Unit to change its consumption or production level from zero.

Notification Date

The dates by which the SAA shall deliver the Initial Debits/Credits for each of the Initial Settlement Runs to the FAA.

Offer

An Offer refers to a submission indicating a willingness to increase the volume of MW delivered in the Balancing Mechanism through an increase in generation or a decrease in demand.

Offer Non-Delivery Volume (QNDOⁿ_ij) MWh

The Offer Non-Delivery Volume (QNDOⁿ_ij) is the volume of non-delivery apportioned to Offer n from BM Unit i in Settlement Period j.

Offer Number (n)

A number identifying a particular Offer.

Offer Price (POⁿ_ij) £/MWh

The Offer Price (POⁿ_ij) is the Price at which a BSC Party is willing to sell an additional MWh of Offer n from BM Unit i in Settlement Period j.

On-Site Procedures

The procedural documentation and test sheets provided by the Technical Assurance Agent which details the on-site processes to be carried out during a site visit.

Outstation

Equipment that receives and stores metering data from meter(s), transfers this data to an instation or hand held device and may perform some processing before transfer. This equipment may be in one or more separate units or may be integral with the meter.

Over-The-Counter (OTC)

An OTC contract is one which has been negotiated between two parties directly or through a broker, rather than one where counter-party risk is taken by clearing house, such as a trade on a cleared Power Exchange.

BSC Party Identifier p

Each Balancing and Settlement Code Party will be given a unique Balancing and Settlement Code Party Identifier as part of the registration process. The Balancing and Settlement Code Party Identifier is generally denoted p.

Payment Calendar

A calendar maintained by the Funds Administration Agent, listing all Initial and Reconciliation Payment Dates for each Settlement Day.

Payment Date

Day on which money is transferred after an Initial of Reconciliation Settlement Run.

Period Accepted Bid Volume (QAB^kn_ij) MWh

The Period Accepted Bid Volume (QAB^kn_ij) is the Settlement Period integrated volume of Bid n, in MWh accepted as a result of Bid-Offer Acceptance k.

Period Accepted Offer Volume (QAO^kn_ij) MWh

The Period Accepted Offer Volume (QAO^kn_ij) is the Settlement Period integrated volume of Offer n, in MWh accepted as a result of Bid-Offer Acceptance k.

Period Acceptance Bid Cashflow (CAB^kn_ij) £

The Period Acceptance Bid Cashflow (CAB^kn_ij) is the Transmission Loss adjusted cashflow to BM Unit i for Balancing Mechanism action in Settlement Period j, allocated to Bid n, as a result of Bid-Offer Acceptance k.

Period Acceptance Offer Cashflow (CAO^kn_ij) £

The Period Acceptance Offer Cashflow (CAO^kn_ij) is the Transmission Loss adjusted cashflow to BM Unit i for Balancing Mechanism action in Settlement Period j, allocated to Offer n, as a result of Bid-Offer Acceptance k.

Period BM Unit Total Accepted Bid Volume (QABⁿ_ij) MWh

The Period BM Unit Total Accepted Bid Volume (QABⁿ_ij) is the total volume of Bid n accepted in Settlement Period j from BM Unit i, summed over all Bid-Offer Acceptances.

Period BM Unit Total Accepted Offer Volume (QAOⁿ_ij) MWh

The Period BM Unit Total Accepted Offer Volume (QAOⁿ_ij) is the total volume of Offer n accepted in Settlement Period j from BM Unit i, summed over all Bid-Offer Acceptances.

Period BM Unit Bid Cashflow (CBⁿ_ij) £

The Period BM Unit Bid Cashflow (CBⁿ_ij) is the total cashflow resulting from accepted volumes of Bid n from BM Unit i in Settlement Period j.

Period BM Unit Bid-Offer Volume (QBO_ij) MWh

The Period BM Unit Bid-Offer Volume (QBO_ij) is the volume of accepted Bids and Offers from BM Unit i, summed over Settlement Period j.

Period BM Unit Cashflow (CBM_ij) £

The Period BM Unit Cashflow (CBM_ij) is the total cashflow resulting from all accepted Bids and Offers from BM Unit i in Settlement Period j.

Period BM Unit Non-Delivered Bid Volume (QNDB_ij) MWh

The Period BM Unit Non-Delivered Bid Volume (QNDB_ij) is the volume of non-delivered Bids from BM Unit i in Settlement Period j.

Period BM Unit Non-Delivered Offer Volume (QNDO_ij) MWh

The Period BM Unit Non-Delivered Offer Volume (QNDO_ij) is the volume of non-delivered Offers from BM Unit i in Settlement Period j.

Period Expected Metered Volume (QME_ij) MWh

The Period Expected Metered Volume (QME_ij) is the volume of energy that a particular BM Unit is expected to deliver or consume in Settlement Period j

Period FPN (FPN_ij) MWh

The Period FPN (FPN_ij) is the integrated MWh of energy implied by integrating the Final Physical Notification for BM Unit i over Settlement Period d.

Period Information Imbalance Volume (QII_ij) MWh

The Period Information Imbalance Volume (QII_ij) is the volume of energy for BM Unit i, in Settlement Period j to which Information Imbalance charges apply.

Period BM Unit Offer Cashflow (COⁿij) £

The Period BM Unit Offer Cashflow (COⁿ_ij) is the total Cashflow resulting from accepted volumes of Offer n from BM Unit i in Settlement Period j.

PES Distribution Business

The Distribution Business of the relevant Public Electricity Supplier.

Point Acceptance Volume (qA^k_it) MW

The Point Acceptance Volume (qA^k_it) is part of the Bid-Offer Acceptance k. It specifies an absolute MW operating level for BM Unit i at spot time t.

Point Bid-Offer Volume (^fqBOⁿ_ijt) MW

The Point Bid-Offer Volume (^fqBOⁿ_ijt) is part of the Bid-Offer Data for Bid-Offer Pair n in Settlement Period j. It specifies the MW of Bid-Offer n available at spot time t for BM Unit i.

Initially only a single value of Point Bid-Offer Volume may be submitted for each Bid-Offer Pair n. If submitted, this value must be for the first spot time of the Settlement Period.

Point FPN (^fFPN_ijt) MW

Point FPN (^fFPN_ijt) data is a series of one or more MW spot values submitted for spot times t in Settlement Period j for BM Unit i. It is used to determine the values of Final Physical Notification.

Point Maximum Export Limit (^fMEL _it) MW

The Point Maximum Export Limit (^fMEL _it) is a positive MW value specifying the maximum export that is possible from BM Unit i at spot time t. It is treated as part of the Dynamic Data.

Point Maximum Import Limit (^fMIL _it) MW

The Point Maximum Import Limit (^fMIL_it) is a negative MW value specifying the maximum import that is possible from BM Unit i at spot time t. It is treated as part of the Dynamic Data.

Point Quiescent FPN fQFPNit (MW)

BSC Traders are permitted to submit values of Point Quiescent FPN, fQFPNit for certain BM Units. A Point Quiescent FPN is a spot value expressing the volume of generation or demand expected to be generated or consumed by an underlying process that forms part of the operation of particular BM Unit at any particular spot time.

Point Value Identification Number (f)

The Point Value Identification Number (f) is a number used to differentiate between two values of any point variable submitted for the same spot time.

Pooling and Settlement Agreement (PSA)

An agreement which determines the way in which electricity was bought and sold through the Electricity Pool.

Public Electricity Suppliers (PES)

Regional Companies that owned and operate the local distribution networks and operated as Suppliers.

Purchase Credit Limit (PCLp) MW

For each BSC Trader p, the amount of Energy Contract Volumes (for purchases of energy) and relevant Credited Energy Percentages that can be accepted in respect of its Energy Accounts is limited by its Purchase Credit Limit.

Qualification

The process to which BSC Parties and Party Agents (excluding SVA MOAs) will submit prior to becoming Qualified. Please refer to BSCP70 for all Parties and Party Agents except for CVA Meter Operator Agents where reference should additionally be made to BSCP537.

Qualified BSC Party Agent

A Qualified BSC Party Agent acts on behalf of BSC Parties, which are responsible for the performance of its function, but is Qualified and Registered under the Balancing and Settlement Code.

Quiescent FPN (QFPN_ij(t)) MW

The Quiescent FPN (QFPN_ij(t)) is a MW value expressing the volume of generation or demand expected to be generated or consumed by an underlying process that forms part of the operation of particular BM Unit at any particular time.

Ramp Rate Identification Number (g)

A number used to differentiate between Run-Up Rates and Run-Down Rates for a particular BM Unit.

Reactive Power

An Ancillary Service required to maintain voltages on the Total System within statutory limits.

Reconciliation Payment Date

The day at which payments in respect of a Reconciliation Settlement Run are made.

Reconciliation Settlement Report

Report of a Reconciliation Settlement Run, produced by the Settlement Administration Agent.

Reconciliation Settlement Run

A settlement run to account for data that has become available after Initial Settlement.

Registration Application

An application received by the CRA from a BSC Party or BSC Service Agent.

Remaining Period BM Unit Non-Delivered Bid Volume (RQNDB^u_ij) MWh

The Remaining Period BM Unit Non-Delivered Bid Volume (RQNDB^u_ij) is the amount of Non-Delivered Bid Volume remaining to be allocated to Bid u.

Remaining Period BM Unit Non-Delivered Offer Volume (RQNDO^u_ij) MWh

The Remaining Period BM Unit Non-Delivered Offer Volume (RQNDO^u_ij) is the amount of Non-Delivered Offer Volume remaining to be allocated to Offer u.

Required Credit Cover RCC £

For each participant, the Funds Administration Agent will calculate the Required Credit Cover for their Transmission Access Rights and Energy Contract Volume credit limits.

Reserve

Generating capacity that can deliver power at very short notice to meet sudden and unexpected increases in demand or loss of power from a generating unit. It is often provided in the form of generating units operating below their declared availability

Residual Cashflow Reallocation Cashflow (RCRC_aj) £

The Residual Cashflow Reallocation Cashflow (RCRC_aj) is the cashflow to Energy Account a in Settlement Period j resulting from the reallocation the Total System Residual Cashflow.

Residual Cashflow Reallocation Proportion (RCRP_aj) No Units

The Residual Cashflow Reallocation Proportion (RCRP_aj) is a fraction expressing the proportion of the Total System Residual Cashflow to be allocated to Energy Account a in Settlement Period j.

Revisited Sites

Sites selected for a subsequent inspection following identification of non-compliance.

Run-Down Elbow(s) (^gRDE_i) MW

The Run-Down Elbow (^gRDE_i) is a MW level used to define a range of operating output within which a particular Run-Down Rate applies. Values apply to BM Unit i. Different values may apply for different MW levels for the same BM Unit at any given time.

Run-Down Rate(s) (^gRDR_i) MW/Minute

The Run-Down Rate(s) (^gRDR_i) expresses the rate of decrease in active power production or the rate of increase of active power consumption for a particular BM Unit within a particular operating range.

Run-Up Elbow(s) (^gRDE_i) MW

The Run-Up Elbow (^gRDE_i) is a MW level used to define a range of operating output within which a particular Run-Up Rate applies. Values apply to BM Unit i. Different values may apply for different MW levels for the same BM Unit at any given time.

Run-Up Rate(s) (^gRUR_i) MW/Minute

The Run-Up Rate (^gRUR_i) expresses the rate of increase in active power production or the rate of decrease of active power consumption for a particular BM Unit within a particular operating range.

Sales Credit Limit (SCLp) MW

For each BSC Trader p, the amount of Energy Contract Volumes (for sales of energy) and relevant Credited Energy Percentages that can be accepted in respect of its Energy Accounts is limited by its Sale Credit Limit.

Secondary BM unit

A unit established and registered (or to be established and registered) by a Virtual Lead Party in accordance with BSC Section K8.

Sampled Sites

Sites selected for inspection by representative sampling from Metering Systems registered with the Central Registration Agency.

Settlement

The word Settlement encompasses all aspects of transactions from meter to bank, for all types of imbalances and Balancing Mechanism trades.

Settlement Administration Agent

A BSC Service Agent contracted to the BSCCo Ltd to operate the Settlement system.

Settlement Calendar

The Calendar created and published by the Settlement Administration Agent on an annual basis to ensure that all Settlement calculations and Runs are performed in a timely manner. The Settlement Calendar shall be derived from and consistent with the Payment Calendar published by the Funds Transfer Agent.

Settlement Day

The Settlement Day runs from midnight to midnight (BST during the summer and GMT during the winter).

Settlement Period j

A Settlement Period is the lowest possible resolution for the calculation of imbalances, lasting half an hour.

Settlement Report

The report issued to BSC Parties by the Settlement Administration Agent which relates to a particular Settlement Run.

Settlement Run

Initial and Reconciliation Settlement Runs are performed by the Settlement Administration Agent prior to each Initial or Reconciliation Payment Date, for each Settlement Day.

Stable Export Limit (SEL_i) MW

The Stable Export Limit (SEL_i) is a positive MW value, expressing the minimum stable export operating level for BM Unit i. It is part of the Dynamic Data.

Stable Import Limit (SIL_i) MW

The Stable Import Limit (SIL_i) is a negative MW value, expressing the minimum stable import operating level for BM Unit i. It is part of the Dynamic Data

Standards

British (BSI) and International (IEC) Standards as applicable to Metering Equipment.

Subsidiary Energy Account

A Subsidiary Energy Account is an Energy Account (other than the Lead Energy Account) for which a value of CEP has been submitted for a BM Unit.

Supplier

A supplier will be a company that provides electricity supplies to groups of customers based on geography and/or size. The company will be a Party of the Balancing and Settlement Code and will hold a second tier Supply licence unless they are licence exempt.

Supplier Half-Hourly Data Aggregation Agent

Supplier Half-Hourly Data Aggregation Agents will aggregate data provided by Supplier Half-Hourly Data Collection Agents and submit them to the Supplier Volume Allocation Agent.

Supplier Half-Hourly Data Collection Agent

Supplier Half-Hourly Data Collection Agents will collect data from half-hourly meters registered in the Supplier Meter Registration Agent system.

Supplier Meter Administration Agent

Supplier Meter Administration Agents will provide half-hourly deemed metered volumes for un-metered supplies and submit them to the Supplier Volume Allocation Agent.

Supplier Meter Registration Agent

For each Grid Supply Point Group, the Supplier Meter Registration Agent will provide a registration service.

Supplier Non-Half-Hourly Data Aggregation Agent

SNHHDAAs will aggregate data provided by a SNHHDCAs and submit them to the Supplier Volume Allocation Agent.

Supplier Non-Half-Hourly Data Collection Agent

SNHHDCAs will collect data from non-half-hourly meters registered in a Supplier Meter Registration Agent system.

Supplier Profile Administration Agent

The SPAA will maintain profiles for the purposes of determining half-hourly deemed metered amounts, and supply data to the Supplier Volume Allocation Agent.

Supplier Technical Assurance Agent

The STAA will ensure compliance with relevant standards for meters registered in a Supplier Meter Registration Agent system. It will also monitor Data Collection Agents.

Supplier Teleswitching Support Agent

The STSA will provide the Supplier Volume Allocation Agent with information about switching times for teleswitched non-half-hourly meters.

Supplier Volume Allocation Agent

The Supplier Volume Allocation Agent will calculate deemed metered amounts at Grid Supply Point Group level.

Supply Number

A Supply number consists of 21 digits that uniquely relate to a single physical metering system used for Settlement purposes. Suppliers use the Supply Number to register their interest in a particular metering system in a PES Supplier Meter Registration System.

System Buy Price (SBP_j) £/MWh

The System Buy Price (SBP_j) is the weighted average of accepted Offers in Settlement Period j.

System Marginal Price (SMP)

In the current arrangements, the offer Price of the highest Price station in operation at any time.

System Operator BM Charge (CSOBM_j) £

The System Operator BM Charge (CSOBM_j) is the amount paid by the System Operator in Settlement Period j.

System Sell Price (SSPj) £/MWh

The System Sell Price (SSP_j) is the weighted average of accepted Bids in Settlement Period j.

System Total Accepted Bid Volume (TQAB_j) MWh

The System Total Accepted Bid Volume (TQAB_j) is the sum over all BM Units of all accepted Bids in Settlement Period j.

System Total Accepted Offer Volume (TQAO_j) MWh

The System Total Accepted Offer Volume (TQAO_j) is the sum over all BM Units of all accepted Offers in Settlement Period j.

TAA Site Inspection Schedule

A form completed by the Technical Assurance Agent in connection with a site visit.

TAA Status Report

The monthly report provided by the Technical Assurance Agent to the Customer.

Targeted Sites

Sites selected for inspection by the Technical Assurance Agent following suspicion of non-compliance.

Technical Assurance Agent

The Technical Assurance Agent will ensure that meters associated with an Boundary Points registered under the Central Registration Agent conform to the relevant Codes of Practice.

Technical Circular (TC)

An authorised change or enhancement to a Code of Practice.

Total Energy Contract Volume

(QABC_aj) in MWh. The sum of all notified (and accepted) Contract Volumes for Energy Account a in Settlement Period j.

Total System

The collection of high voltage wires owned and operated by the NETSO and the Public Electricity Suppliers in Great Britain, within the geographical boundary of Great Britain.

Total System BM Cashflow (TCBM_j) £

The Total System BM Cashflow (TCBM_j) is the total cashflow summed over all BM Units resulting from the operation of the Balancing Mechanism in Settlement Period j.

Total System Energy Imbalance Cashflow (TCEI_j) £

The Total System Energy Imbalance Cashflow (TCEI_j) is the total cashflow resulting from the Settlement of Energy Imbalances, summed over all Energy Accounts in Settlement Period j.

Total System Information Imbalance Charge (TCII_j) £/MWh

The Total System Information Imbalance Charge (TCII_j) is the total charge for information imbalances, summed over all BM Units and Energy Accounts in Settlement Period j.

Total System Non-Delivery Charge (TCND_j) £/MWh

The Total System Non-Delivery Charge (TCND_j) is the total charge for non-delivered Bids and Offers summed over all BM Units in Settlement Period j.

Total System Residual Cashflow (TRC_j) £

The Total System Residual Cashflow (TRC_j) is the surplus or deficit of funds remaining to be reallocated after the Settlement of Energy Imbalances, Information Imbalances, the Balancing Mechanism (including non-delivery) and the System Operator BM Charge.

Trading Unit

A Trading Unit is a configuration of Boundary Points that are traded at net volume. Constituent Boundary Points must be materially interdependent, or must be linked via a contiguous path of connection assets associated with the parties registered against the Boundary Points.

Trading Unit Identification Number

A unique identifier for each Trading Unit.

Transmission Licence

Means a licence granted or treated as granted to the NETSO under section 6(l) (b) of the Act;

Transmission Loss Factor (TLFij) No Units

A factor used in the calculation of Transmission Loss Multipliers.

Transmission Loss Factor Agent

The Transmission Loss Factor Agent will derive Adjusted seasonal Zonal TLFs and BM Unit specific TLFs for use in the Settlement Calculations.

Transmission Loss Multiplier (TLMij)

The Transmission Loss Multiplier (TLM_ij) is the factor applied to BM Unit i in Settlement Period j in order to adjust for Transmission Losses.

Transmission System

That part of the Total System owned and operated by the holder of the Transmission Licence.

Unmetered Supply

A Boundary Point for which the volume of electricity supplied from the Total System is derived without reference to a meter.

Universal Co-ordinated Time

The international time standard.

Universal Time Clock (UTC)

The Universal Time based on atomic clocks rather than GMT.

Virtual Lead Party

A BSC Party that has registered with the Virtual Lead Party participation capacity.

Voltage Transformer Ratio

The nominal turns ratio between the primary and secondary windings of a voltage transformer. (e.g. a 11,000 volts primary and 110 volts secondary windings would be shown as a ratio of 11,000/110).

Watt (W)

A measure of rate of flow of electricity or power flow.

1 This does not apply to Secondary BM Units, as they do not have GC or DC values

2 A number of the change requests considered in the URS have required changes in terminology. These have not been updated in the Glossary at this issue.

3 The Accreditation/Certification details will report Qualification Details, but the name of the Data group is unchanged for IDD compatibility.

4 The Accreditation/Certification details will report Qualification Details, but the name of the Data group is unchanged for IDD compatibility.

5 A BM Unit must be registered in order to be assigned a BM Unit Identifier. Subsequently, BSCCo Ltd may register the BM Unit as Exempt Export. The two steps to this operation are represented by requirements CRA-I005/CRA-F013 and CRA-I043/CRA-F014 respectively, though logically, they can be considered to be parts of a single registration operation.

6 The Accreditation/Certification details will report Qualification Details, but the name of the Data group is unchanged for IDD compatibility.

7 For the avoidance of doubt, in the event of a discrepancy between this description and the methodology, the methodology shall prevail.

8 If the notification is sent by 15:00, this will be the next Working Day; otherwise it will be the Working Day after that.

9 Note that details of the CRA-I012 (Issue CRA Encryption Key) flow have not been included in this diagram, in order to avoid excessive clutter. Note also that interfaces shown as ‘manual’ on the diagram may also be ‘online’ where indicated in the table above.

User Requirements Specifications

CONTENTS

Central Registration Agent (CRA)

1 Management Summary

2 Introduction

2.1 Amendment History

2.2 References

2.3 Acronyms

3 Scope of Specification

4 Business and System Overview

4.1 Summary of Business Requirements

4.1.1 Registration Process

4.2 Service Context

4.3 User Requirements Source Documents

4.4 Numbering Scheme for Requirement Definitions

4.5 Attributes of Individual Requirements

5 Functional Requirements

5.1 CRA-F001: Register BSC Party

5.2 CRA-F002: Maintain Authentication Data

5.3 CRA-F003: Authenticate Party

5.4 CRA-F004: Allocate BSC Party ID

5.5 CRA-F005: Allocate BSC Party Energy Account

5.6 CRA-F006: View / Maintain BSC Party Registration Details

5.7 CRA-F007: Register Interconnector Administrator

5.8 CRA-F008: View / Maintain Interconnector Administrator Data

5.9 CRA-F009: Register BSC Party Agent

5.10 CRA-F010: View / Maintain BSC Party Agent

5.11 CRA-F011: Register BSC Service Agent

5.12 CRA-F012: View / Maintain BSC Service Agent

5.13 CRA-F013: BM Unit Registration

5.14 CRA-F014: View / Maintain BM Unit Registration

5.15 CRA-F015: Trading Unit Registration

5.16 CRA-F016: View / Maintain Trading Unit Registration Details

5.17 CRA-F017: Register CRA Boundary Points and System Connection Points Details

5.18 CRA-F034: Register Metering System Details

5.19 CRA-F018: View / Maintain Boundary Point and System Connection Point Details

5.20 CRA-F019: View / Maintain Interconnector Registration

5.21 CRA-F020: Maintain Credit Assessment Load Factor

5.22 CRA-F021: Requirement not currently used

5.23 CRA-F022: Issue Credit Assessment Capability

5.24 CRA-F023: Validate Registrations

5.25 CRA-F024: Report Registration Details

5.26 CRA-F025: Distribute Register Data

5.27 CRA-F026: Maintain Reference Data

5.28 CRA-F027: SLA Reporting

5.29 CRA-F028: Requirement not currently used

5.30 CRA-F029: Register Interconnector

5.31 CRA-F030: Register GSP Group and GSP Details

5.32 CRA-F031: View / Maintain GSP Group Registrations

5.33 CRA-F032: Maintain Transmission Loss Factors

5.34 CRA-F033: Receive Registration Exception Reports

5.35 CRA-F035: View / Maintain Metering System Details

5.36 CRA-F036: Maintain Flexible Reporting Requirements

5.37 CRA-F037: Transfer from SMRS

5.38 CRA-F038: Transfer to SMRS

5.39 CRA-F039: Register / View / Maintain Market Index Data Provider

5.40 CRA-F040: Provide BSCCo with Withdrawals Checklist

5.41 CRA-F041: GC and DC Breach Monitoring

5.42 CRA-F042: Identify CRA-estimated GC and DC amounts

5.43 CRA-F043: Manage GC and DC Breach Challenges

5.44 CRA-F044: Manage Conflicting GC/DC Submissions

5.45 CRA-F045: Publish GC and DC Breach data

6 Interface Requirements

7 Non Functional Requirements

7.1 CRA-N001: Input Interface Requirements

8 Service Requirements

8.1 CRA-S001: Message Security and Encryption

8.2 CRA-S002: Data Migration Requirements

8.3 CRA-S003: Archiving Requirements

9 User Roles and Activities

10 Future enhancements

Appendix A Requirements Compliance Matrix

Appendix B Logical Data Model

Appendix C Business Process Model

Appendix D NETA Central Service Common Non Functional Requirements

D-1 GEN-N001: Audit Requirements

D-2 GEN-N002: Security Requirements

D-3 GEN-N003: Operational Control

D-4 GEN-N004: Euro Compliance

D-5 GEN-N005: Help Desk Queries