My BSC Dashboard Subscriptions Kinnect Customer Solution

User Requirements Specifications

1 Management Summary

2 Introduction

3 Scope of Specification

4 Business and System Overview

5 Functional Requirements

6 Interface Requirements

7 Non-functional Requirements

8 Service Requirements

9 User Roles and Activities

Appendix A Glossary

Appendix B Requirements Compliance Matrix

Appendix C Logical Data Model

Appendix D Business Process Model

Appendix E Price Derivation Code Definitions

SAA: Settlement Administration Agent

v 30.0

02/11/2023

Download

Settlement Administration Agent User Requirements Specification

Synopsis	The Settlement Administration Agent is responsible for calculating payments resulting from trades in both the Balancing Mechanism and Imbalance Settlement processes. This document describes the detailed requirements of this service.
Version	Version 30.0
Effective date	02 November 2023

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

Amendment History

Date	Version	Description of Change	Mods /Panel/ Committee Refs
05/11/2009	13.0	P217, CP1283, CP1286	Change Implementation
03/11/2011	14.0	Document amended to remove details of interfaces included in the IDD Part 1 or Part 2, and to include changes for P253, as part of the November 2011 Release.	Change Implementation
29/11/2012	15.0	P278 for the November 2012 Release	ISG138/10
27/06/2013	16.0	P285 for the June 2013 Release	P206/07
01/08/14	17.0	ORD005	Directed by the Secretary of State
25/06/15	18.0	CP1435	ISG168/02
05/11/15	19/0	P305 for the November 2015 Release	ISG172/04
		P323 for the November 2015 Release	P245/06
12/04/16	20.0	CP1453 – Standalone Change	ISG178/04
29/06/17	21.0	P321 Self-Governance – 29 Jun 2017 Release	Panel 245/05
		P350 for the June 2017 Release	ISG194/02
29/03/19	22.0	P369: 29 March 2019 Standalone Release	P285/12
27/06/19	23.0	P367 Self-Governance – 27 June 2019 Release	SVG219/02 ISG216/01
11/12/19	24.0	11 December 2019 Standalone Release – CP1517	ISG220/01 ISG222/03
27/02/20	25.0	P394 Self-Governance - 27 February 2020 Release	P297/07
01/04/20	26.0	P354:1 April 2020 Standalone Release	ISG227/4
05/11/20	27.0	P396: 5 November 2020 Release	ISG233/04
07/12/22	28.0	P448 7 December 2022 Special Release	P332A/01
23/02/23	29.0	P376 23 February 2023 Standard Release	P312/04
02/11/23	30.0	P395 02 November 2023 Standard Release	SVG271/07 ISG269/03

1 Management Summary

The Settlement Administration Agent (SAA) is one of the suite of seven services that support the operation of the Balancing and Settlement Code (BSC). The SAA role is critical to the successful operation of the BSC, as it calculates the credit and debit payments resulting from trades made in the Balancing Mechanism (BM) and the Replacement Reserve (RR) EU market and from imbalances between contracted and actual generation or consumption. The principal business processes involved may be summarised as:

The capture of data relating to the operation of the BM and RR and the settlement of imbalances in each half hour, from a range of sources;
For each Settlement Day, execution of the BM and RR and imbalance calculations as dictated by the Settlement Calendar, so that a minimum of six Settlement and Reconciliation runs are carried out for each day over a period of 14 months following the Settlement Date;
Preparation and distribution of a series of Settlement reports to BSC Parties, the FAA and other parties, detailing the results of each day’s Settlement calculations; and
Support of the Disputes management process which enables BSC Parties to query the reported outcome of the Settlement and Reconciliation runs.

The purpose of this document is to provide a complete specification of the set of business requirements which the SAA 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 SAA itself and the other BSC services. Similar documents will be produced to define the requirements for the other services. A convention has therefore been used for uniquely identifying the requirements in each document, so as to ensure 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 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 SAA User Requirement Specification (URS).

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

Functional requirements - those requirements relating to a specific business activity, usually requiring some degree of automated support;
Interface requirements - the detailed requirements for the exchange of data between the SAA, the other BSC services shown above, and the external participants (and covered in more detail in the Interface Definition and Design (IDD) documents);
Non-functional requirements - those requirements relating to such activities as security (both physical and user access related), audit, and system housekeeping (systems backups and archiving etc.). It is anticipated that the majority of these will be common to all of the services to be provided;
Service requirements - the underlying service delivery requirements of the SAA service, including such as issues as performance, volumetrics, number of Settlement runs to be carried out.

These requirements are catalogued in sections 5 to 8 respectively.

2 Introduction

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

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS;
Interface Specification.

The objective of this document is to provide a complete specification of the requirements that the SAA service must meet, from the users’ point of view. For this purpose, the “users” include BSCCo Ltd, Ofgem, National Electricity Transmission System Operator (NETSO) as the balancing mechanism operator, other Service Providers, BSC Parties (including Distribution companies as parties), and the SAA Service Provider’s own operators.

This User Requirements Specification forms the input to the System Specification for the SAA Service. The System Specification constitutes the definition of the computer system requirements to be built in support of the SAA Services.

It should be noted that whereas this URS describes the requirements of the SAA Service in isolation, the computer system built to support these requirements will be a combined SAA, CRA and CDCA system.

3 Scope of Specification

This document provides a specification of the requirements for the Settlement Administration Agent (SAA) Service within the BSC Services Agreement. The requirements are described from the point of view of the SAA Service users.

The document is divided into the following chapters.

Chapter 4, Business and System Overview - describes the business context of the SAA Service;
Chapter 5, Functional Requirements - describes the functional requirements of the Service from the point of view of the Service users;
Chapter 6, Interfaces Requirements - describes the interfaces with the external users of the Service;
Chapter 7, Non-Functional Requirements - describes the non-functional requirements of the Service, such as auditing, security and resilience;
Chapter 8, Service Requirements - describes the service delivery requirements of the Service, such as performance and volumetrics;
Chapter 9, User Roles and Activities - describes the roles supporting day to day operation of the Service and external users of the Service, such as other Service Providers and BSCCo Ltd;
Appendix A: Glossary - includes a glossary of terms and acronyms;
Appendix B: Requirements Compliance Matrix - shows the mapping of requirements defined by this document to requirements set out in the Customer’s Tender Invitation documents;
Appendix C: Logical Data Model;
Chapter 14, Appendix D: Business Process Model.

4 Business and System Overview

This section provides an overview of the Settlement Administration Agent (SAA) business requirements and is for indicative purposes only. The definitive statement of requirements are given in the following chapters.

4.1 Summary of Business Requirements

The SAA will receive the inbound data, provided by other BSC Services, and perform calculations based on the validated data such that the financial debits and credits determined under the BSC of each BSC Party can be determined. The Funds Administration Agent will then be advised of the required financial transfers. This operation will be performed in accordance with the Settlement Timetable. The SAA service will also produce reports for distribution to BSC Parties and others, such as BSCCo Ltd and the NETSO.

The information the SAA service will calculate will include:

Balancing Mechanism accepted bid/offer volumes and prices,
Volumes and charges,
System Buy and System Sell price,
BM Unit Transmission Loss Multipliers,
Interconnector Error Administrator’s energy volumes,
Information Imbalance Charges,
Credited energy volumes,
Non-delivery volumes and charges,
Energy imbalance charges,
Other costs, including System Operator charge, BSCCo Ltd administration charge, and SAA administration charge and Residual cash-flow reallocation.

Services will be provided to support the Disputes Process, including re-runs of the Settlement calculations as required.

In addition, the SAA service will produce and publish the Settlement Calendar.

4.2 The Settlement Calendar

The settlement rules require the SAA to perform at least six standard settlement runs in respect of each settlement day, together with any dispute requested under the auspices of the BSC. The set of settlement runs to be carried out for each settlement day will consist of:

Interim Initial Settlement;
Initial Settlement;
Reconciliation Settlement (3 runs)
Final Reconciliation;
Settlement Dispute (runs as necessary).

The Settlement Calendar will be constructed so as to smooth the processing of these settlement runs, as necessary, across available working days with the aim of reducing the necessity of running more than ten settlements runs on any given working day and to meet the payment timetable as produced by the FAA.

The CDCA is required to supply the ECVAA with aggregated BM Unit Meter Volume data for Credit Cover purposes. Although not part of Settlement this 'Credit Cover Volume Allocation Run' will be scheduled from and be part of the Settlement Calendar.

4.3 Service Context

The following diagram illustrates the context of the SAA 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 SAA service to other parties in detail.

Item	Description
Bank	A bank which receives debit and credit instructions from the Funds Administration Agent.
BMRA	Balancing Mechanism Reporting Agent.
BSC Party	A signatory to the Balancing and Settlement Code
BSCCo Ltd	The Balancing and Settlement Code Company.
CDCA	Central Data Collection Agent.
CRA	Central Registration Agent
Credit Agency	A credit agency which provides credit rating data on BSC 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
MVRNA	Metered Volume Reallocation Notification Agent
NETSO	National Electricity Transmission System Operator as the holder of the Transmission Licence and any reference to "NETSO", "NGESO", "National Grid Company" or "NGC" in the Code or any Subsidiary Document shall have the same meaning.
MOA	Meter Operation Agent.
Public	A member of the general public.
SAA	Settlement Administration Agent.
SVAA	Supplier Volume Aggregation Agent, equivalent to the current Initial Settlement and Reconciliation Agent (ISRA).
TAA	Technical Assurance Agent.

4.4 Requirements Summary

The following table summarises the requirements of the SAA service. These are then described in detail in section 5, including the source reference for each requirement.

Requirement ID.	User Requirement
Functional
SAA-F001	Produce Settlement Calendar
SAA-F002	Validate settlement data
SAA-F003	Validate SVAA meter data
SAA-F004	Calculate Supplier BM Unit Metered Volumes
SAA-F005	Calculate balancing mechanism volumes and Replacement Reserve volumes
SAA-F006	Calculate BM unit transmission loss multipliers
SAA-F007	Calculate balancing mechanism cashflows
SAA-F008	Calculate Credited Energy Volumes
SAA-F009	Calculate energy imbalance prices
SAA-F010	Calculate interconnector error
SAA-F011	Calculate energy imbalance cashflows
SAA-F012	Validate Adjustment Data
SAA-F013	Calculate information imbalance charges
SAA-F014	Calculate non-delivery volumes
SAA-F015	Calculate non-delivery charges
SAA-F016	Calculate system operator BM cashflow
SAA-F017	Calculate residual cashflows
SAA-F018	Allocate BSCCo Ltd Costs (Redundant)
SAA-F019	Aggregate charges and payments
SAA-F020	Validate Market Index Data
SAA-F021	Manage settlement disputes
SAA-F022	Provide settlement reports
SAA-F023	Process Market Index Data Provider Liquidity Thresholds
SAA-F024	Daily Check for Missing Settlement Calculation Data Flows
SAA-F025	Process Withdrawals Party Settlement Details
SAA-F026	Process Emergency Acceptance Data
SAA-F027	Calculate BM Unit Gross Demand for EMR
SAA-F029	Calculate Trading Unit Data
SAA-F030	Determine Replacement Reserve Schedules
SAA-F031	Determine Deemed Standard Product Variables
SAA-F032	Determine Period Supplier BM Unit Delivered Volume for Secondary BM Units
SAA-F033	Calculate Deemed Standard Volumes and RR Instructed Deviation Volumes
Interface
SAA-I001	Receive Registration Data
SAA-I002	Receive Credit Assessment Load Factor
SAA-I003	Receive Balancing Mechanism Data
SAA-I004	Receive Period Meter Data
SAA-I005	Requirement not currently used
SAA-I006	Receive Interconnector User BM Unit Metered Volumes
SAA-I007	Receive BM Unit Allocated Demand Volume
SAA-I008	Receive Energy Contract Data
SAA-I009	Receive Transmission Loss Data
SAA-I010	Receive BSCCo Ltd Cost Data (Redundant)
SAA-I011	Receive Payment Calendar Data
SAA-I012	Receive Dispute Notification
SAA-I013	Issue Credit/Debit Reports (initial and revised)
SAA-I014	Issue Settlement Reports
SAA-I015	Issue BM Unit CAIC Data
SAA-I016	Publish Settlement Calendar
SAA-I017	Issue SAA Data Exception Reports
SAA-I018	Issue Dispute Reports
SAA-I019	Issue BSC Party Performance Reports (Redundant)
SAA-I020	Issue SAA Performance Reports
SAA-I021	Receive Acknowledgement of SAA Messages
SAA-I022	Issue SAA Acknowledgement of Messages
SAA-I023	Receive System Parameters
SAA-I025	SAA BSC Section D Charging Data
SAA-I026	Receive Balancing Services Adjustment Data
SAA-I027	Report pre-settlement run validation failure
SAA-I028	Receive settlement run decision
SAA-I029	Receive settlement run instructions
SAA-I030	Receive Market Index Data
SAA-I031	Receive Market Index Data Provider Thresholds
SAA-I032	Report Market Index Data Provider Thresholds
SAA-I033	Receive Request for Data Change
SAA-I034	Report Recommended Data Change
SAA-I035	Receive Instruction for Data Change
SAA-I036	Report Confirmation of Data Change
SAA-I037	Issue Withdrawing Party Settlement Details
SAA-I038	Receive Excluded Emergency Acceptance Pricing Information
SAA-I039	Send Excluded Emergency Acceptance Dry Run Results
SAA-I040	Receive Authorisation To Proceed With Full Settlement Run
SAA-I043	Demand Control Instructions to CDCA
SAA-I044	Aggregated BM Unit Disconnection Volumes
SAA-I049	Trading Unit Data
SAA-I057	Supplier BM Unit Period Non-chargeable Demand
SAA-I058	Aggregated TLM-Adjusted Non-Chargeable Demand
Non-Functional
SAA-N001	Audit Requirements
SAA-N002	Security Requirements
SAA-N003	Operational Control
SAA-N004	Euro Compliance

4.5 Numbering Scheme for Requirement Definitions

As described in section 2, the set of baseline requirement documents includes a User Requirements Specification for each of the services of the central BSC systems (except FAA - see footnote 1). Within these documents each requirement across the set of services is uniquely identified to provide traceability of each individual requirement from URS to System Specification (functional specification) and then to Design Specification (technical specification).

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

1. Each requirement is associated with either an individual service, or as common to all services supported by the central systems. (TAA is typically 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.
Interface (I), a requirement for data exchange between services or to external parties.
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.

3. Within a service, each requirement has 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.6 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 SAA 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 documentation which is the original source of the business need. In most cases this will include a reference to the relevant Service Description and where appropriate, any Change Proposals or Modifications that have affected a particular requirement.

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. For interface requirements an additional mechanism of ‘via shared database’ may be specified indicating that combined computer system will be built for the SAA, CRA and CDCA services. This mechanism statement 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. Any outstanding issues relating to the requirement definition are also identified.

5 Functional Requirements

This section describes the detailed set of business requirements for the Settlement Administration Service. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is uniquely numbered, based on the convention described in section 4.

5.1 SAA-F001: Produce Settlement Calendar

Requirement ID:

SAA-F001

Status:

Title:

Produce Settlement Calendar

BSC reference:

SAA SD 5.2, SAA BPM 3.2, CP555, P215

Man/auto:

Manual

Frequency:

On demand.

Volumes:

Functional Requirement:

The SAA shall produce a Settlement Calendar that is consistent with the Payment Calendar (published by the Funds Administration Agent) and defines when the Settlement runs should take place for each Settlement Day, taking account for bank holidays etc. (See NETA Clarification Note CR_99813_06b: 2.1)

The calendar shall also specify when data needs to be provided to the SAA from each party/agent providing data in order to enable the payment calendar to be complied with.

The calendar shall also specify when data needs to be provided to the ECVAA from each party/agent for the purposes of Credit Cover.

The Settlement Calendar shall be provided to all such parties/agents for comment and shall be approved by BSCCo Ltd.

Non Functional Requirement:

The Settlement Calendar shall cover the year starting 1^st April.

FAA will issue a draft Payment Calendar to SAA by January 15^th, and SAA shall respond with any comments to BSCCo Ltd within 5 working days of receipt. After resolution of any issues, FAA will issue the authorised Payment Calendar, by 31^st January.

On receipt of the authorised Payment Calendar from FAA, SAA shall prepare and issue a draft Settlement Calendar to BSCCo Ltd, CDCA and SVAA within 10 working days. On receipt of approval of the Settlement Calendar from BSCCo Ltd, SAA shall issue the approved Settlement Calendar to CDCA, SVAA and BSC Parties within two working days.

Interfaces:

Issues:

5.2 SAA-F002: Validate settlement data

Requirement ID:

SAA-F002

Status:

Title:

Validate settlement data

BSC reference:

SAA SD 2, CP598, CP639, P78, P305, P344

Man/auto:

Manual & Automatic

Frequency:

Once, on each settlement run & on demand.

Volumes:

Functional Requirement:

All received input data to the SAA shall be validated to confirm that it exists and is in the correct format to enable a settlement run to be executed.

If expected settlement data is not received or is invalid the SAA shall take remedial action to obtain complete and corrected data from the relevant service, e.g. CRA, CDCA, ECVAA, BMRA SVAA , NETSO or BSC party.

For all run types for the settlement day, the validation checks are:

check FPN data has been loaded for all settlement periods for BM Units that have their FPN flag set, or for which BOD data has been loaded;
check that Replacement Reserve Activation Data, GB Need Met Data and Interconnector Schedule Data, and Clearing Price has been loaded for all Quarter Hours from the NETSO.
check BSAD data has been loaded for all settlement periods;
check Bid/Offer data has been loaded for all settlement periods in which any BM Unit has a Bid Offer Acceptance;
check Interconnector User BM Unit metered volumes have been received for each Interconnector;
check Account Bilateral Contract Volumes and Metered Volume Reallocation Data have been received from the ECVAA;
check appropriate CDCA Aggregation Run has taken place;

For Interim Initial settlement runs for Settlement Dates prior to the P253 effective date, the following additional check is performed:

check that no data relating to this settlement day has been loaded from the SVAA.

In addition to the checks outlined above, the SAA will, on D+3, check that the required Market Index Data has been received.

For Interim Initial settlement runs for Settlement Dates on or after the P253 effective date, and for all Initial Settlement and Reconciliation runs, the following additional check is performed:

check that Demand Control Event details has been received from BMRA or the NETSO (where revisions are sent) and loaded;
check that Loss of Load Probability and De-rated Margin data has been loaded from BMRA or if revised data has been sent by the NETSO, that this is loaded;
check that BM Unit Allocated Demand Volume and any BM Unit Allocated Disconnected Demand Disconnection Volume data, Secondary BM Unit Demand Volume and the Secondary BM Unit Supplier Delivered Volume relating to this settlement day has been loaded from the SVAA; and
check that Period BM Unit Demand Disconnection Volume data relating to this settlement day has been loaded from the CDCA.

The SAA will report any failures of the above checks to BSCCo through manual flow SAA-I027 and await instruction on how to proceed. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed making use of default functionality in the system, or whether to suspend the run pending further instruction. Instruction on how to proceed other than by substituting system default data shall be received by SAA from BSCCo through SAA-I029.

Non Functional Requirement:

Interfaces:

See SAA-I027, SAA-I028, SAA-I029

Issues:

5.3 SAA-F003: Validate SVAA meter data

Requirement ID:

SAA-F003

Status:

Title:

Validate SVAA meter data

BSC reference:

SAA SD 2.5.1, CP639, P305, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirement:

For Settlement Dates prior to the P253 effective date, the following validation shall be performed on receipt of BM Unit Allocated Demand Volume and BM Unit (BMUADVij), SVA Gross Demand data at the Loader:

check that the Interim Initial Settlement Run has been performed for that settlement date.

If the above check fails, the entire flow shall be rejected and the SAA will report the failure of the above check to BSCCo through manual flow SAA-I027 but will not take any further action.

If the Interim Initial Settlement Run has been performed and/or the Settlement Date is on or after the P253 effective date, processing continues with the following:

the CDCA Run Number & Settlement Date received from the SVAA matches the CDCA Run Number and Settlement Date received from the CDCA;
the Aggregated Supplier Volume Allocation received from the SVAA matches the GSP Group Take provided by CDCA (accounting for tolerances);

The SAA will report the failure of the above check to BSCCo through manual flow SAA-I027 and await further instruction. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed with the settlement run, or whether to suspend the run pending further instruction. Instruction on how to proceed shall be received by SAA from BSCCo through SAA-I029.

all BM Unit identifiers reported in the BM Unit Allocated Demand Volume data (BMUADVij) (and any BM Unit Allocated Demand Disconnection Volume data) (BMUADDVij) shall be valid for the settlement day
all Secondary BM Unit identifiers reported in the Secondary BM Unit Demand Volume (VBMUDVi2j) for each Volume Allocation Run shall be valid for the settlement day.
all Secondary BM Unit Supplier Delivered Volume (VBMUSDVi2ji) for each Volume Allocation Run shall be valid for the settlement day.

Where this check fails, the metered volume shall be added into the Base BM Unit for the Supplier in the relevant GSP Group. The SAA will report the failure of the above check to BSCCo through manual flow SAA-I027 and await further instruction.

The SAA shall notify BSCCo that it has undertaken the above defaulting in time for BSCCo to instruct the SAA otherwise, if deemed appropriate by BSCCo. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed with the settlement run, or whether to suspend the run pending further instruction. Instruction on how to proceed shall be received by SAA from BSCCo through SAA-I029.

The following Pre-Run additional checks shall be performed:

BM Unit Allocated Demand Volume, Secondary BM Unit Demand Volume, Secondary BM Unit Supplier Delivered Volume and any BM Unit Allocated Demand Disconnection Volume data has been received from SVAA.

the SVAA has supplied data for all supplier BM Units and Secondary BM Units

The SAA will report any failure of the above checks to BSCCo through manual flow SAA-I027 and await instruction on how to proceed. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed with the settlement run, or whether to suspend the run pending further instruction. Instruction on how to proceed shall be received by SAA from BSCCo through SAA-I029.

CDCA Run Number & Settlement Date received from SVAA matches that from CDCA.

If there is a discrepancy, the SAA will check with the SVAA and CDCA. If the discrepancy cannot be resolved, the SAA will report the failure of the above check to BSCCo through manual flow SAA-I027 and await instruction on how to proceed. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed with the settlement run, or whether to suspend the run pending further instruction. Instruction on how to proceed shall be received by SAA from BSCCo through SAA-I029.

Note that where a volume is not specified for a Supplier BM Unit or Secondary BM Unit, no value is loaded. Where that volume is required in processing functions, a default value of zero is applied by the processing function.

Non Functional Requirement:

The SAA Service shall receive BM Unit Allocated Demand Volume, BM Unit Allocated Disconnection Demand Volume (where appropriate), Secondary BM Unit Demand Volume, Secondary BM Unit Supplier Delivered Volume and BM Unit and Secondary BM Units SVA Gross Demand in accordance with the Settlement Calendar.

Interfaces:

See SAA-I007, SAA-I027, SAA-I028, SAA-I029, SAA-I041

Issues:

5.4 SAA-F004: Calculate Supplier BM Unit Metered Volumes

Requirement ID:

SAA-F004

Status:

Title:

Calculate Supplier BM Unit Metered Volumes

BSC reference:

Modification P2, CP632, P344

Man/auto:

Automatic

Frequency:

Once on each Settlement Run

Volumes:

Functional Requirement:

For Interim Initial settlement runs for Settlement Dates on or after the P253 effective date, and for all Initial Settlement and subsequent Settlement Runs, the SAA shall use the BM Unit Allocated Demand Volume, Secondary BM Unit Demand Volume and Secondary BM Unit Supplier Delivered Volumes received from SVAA via interface SAA-I007, SAA-I051 and SAA-I051.

For Interim Initial Settlement Runs for Settlement Dates prior to the P253 effective date only, where this data is not available, the SAA shall calculate QM_ij for Supplier BM Units using data from previous Settlements Days and Periods, as follows.

1: Determine the previous Settlement Day d΄ to use in estimating the Supplier BM Unit Metered Volumes for Settlement Day d as follows:

Settlement Day d΄ shall be the most recent Settlement Day prior to d that is:

a) the same day of the week as day d,

b) not a clock change day, and

c) a day on which an Initial Settlement (SF) Run has taken place.

2: Determine the Settlement Period j΄ on Settlement Day d΄ to use in estimating the Supplier BM Unit Metered Volumes for Settlement Period j of Settlement Day d as follows:

a) If day d is not a clock change day, then j΄ = j

b) If day d is a short clock change day, then:

i) If j ≤ 2 then j΄ = j

ii) If j > 2 then j΄ = j +2

c) If day d is a long clock change day, then:

i) If j ≤ 4 then j΄ = j

ii) If j > 4 then j΄ = j – 2

3: Finally, having determined the variables j΄ and d΄, the BM Unit Metered Volume for Supplier BM Units in the Interim Initial Run shall be calculated as:

QM_ij = GSPGT_ij * QM_ij_΄ / GSPGT_ij

Where:

GSPGT_ij is the GSP Group Take for the GSP Group associated with BM Unit i in Settlement Period j on Settlement Day d

QM_ij_΄ is the BM Unit Metered Volume for BM Unit i in Settlement Period j΄ on Settlement Day d΄

GSPGT_ij_΄ is the GSP Group Take for the GSP Group associated with BM Unit i in Settlement Period j΄ on Settlement Day d΄

If there is no BM Unit Metered Volume for BM Unit i in Settlement Period j΄ on Settlement Day d΄ (for example, because the BM Unit was not effective on that Day), then QM_ij shall be set to 0.

Non Functional Requirement:

Interfaces:

Issues:

5.5 SAA-F005: Calculate balancing mechanism and Replacement Reserve volumes

Requirement ID:

SAA-F005

Status:

Title:

Calculate balancing mechanism volumes and Replacement Reserve volumes

BSC reference:

SAA BPM 3.5 SAA SD 3.2.2-7, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.17.1, 3.18, 3.19, CP632, P71, CP754, P305, P344.

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A large number of intermediate calculations are required to produce the balancing mechanism volumes and RR Acceptance volumes. Note that balancing mechanism volumes and RR Acceptance volumes share processes till qAO^kn_ij(t) and qAB^kn_ij(t) are calculated and then subsequently diverge.

All calculation steps in this requirement are included here.

Whilst all half-hourly integrated MWh energy quantities should be explicitly calculated as part of the settlement process, it is not intended that these continuous functions of time should actually be calculated or reported. The variables to which this applies are as follows:

Final Physical Notification (FPN_ij(t))

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

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

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

Acceptance Volume (qA^k_ij(t))

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

Accepted Offer Volume (qAO^kn_ij(t))

Accepted Bid Volume (qAB^kn_ij(t))

1: The value of Final Physical Notification, FPN_ij(t) shall be defined for times, t, falling within Settlement Period j by linear interpolation from the values of Point FPN (^fFPN_it), submitted for that Settlement Period j, for BM Unit i.

2: For any value of Bid-Offer Number, n, the Bid-Offer Volume (qBOⁿ_ij(t)) at any time t shall be defined by linear interpolation from the values of Point Bid-Offer Volume (^fqBOⁿ_it) submitted for Settlement Period j for BM Unit i.

3: Define Bid-Offer Upper Range for Bid-Offer Pairs with positive Bid-Offer Pair Numbers, and define the Bid-Offer Lower Range for Bid-Offer Pairs with negative Bid-Offer Pair Numbers. The Bid-Offer Upper Range is defined as follows:

BOURⁿ_ij(t) = FPN_ij(t) + Σⁿ⁺qBOⁿ_ij(t); and

BOUR_ij⁰(t) = FPN_ij(t)

Where Σⁿ⁺ represents a sum over all positive Bid-Offer Pairs, 1 to n.

For Bid-Offer Pairs for which the associated Bid-Offer Pair Number n<0, the Bid-Offer Lower Range BOLRⁿ_ij(t) is defined for all times in Settlement Period j as:

BOLRⁿ_ij(t) = FPN_ij(t) + Σ^n-qBOⁿ_ij(t); and

BOLR_ij⁰(t) = FPN_ij(t)

Where Σ^n- represents a sum over all negative Bid-Offer Pairs, -1 to n.

On occasion, the NETSO may issue acceptances which exceed the Bid-Offer ranges:

In the following equations,

Σ⁺ represents a sum over all positive Bid-Offer Pairs (zero if there are none) Σ^- represents a sum over all negative Bid-Offer Pairs (zero if there are none) qA^k_ij(t) is the acceptance level for acceptance k

If, for any k, qA^k_ij(t) > FPN_ij(t) + Σ⁺qBOⁿ_ij(t)

then:

if FPN_ij(t) >= 0 and there is at least one positive bid-offer pair,

the highest numbered Bid-Offer pair is extended up to Max^k(qA^k_ij(t))

otherwise,

a new bid-offer pair is created with pair number one greater than the highest (or 1 if none exist) with:

BOURⁿ_ij(t) = Max{ FPN_ij(t) + Σ⁺qBOⁿ_ij(t), Max^k(qA^k_ij(t)) }

If, for any k, qA^k_ij(t) < FPN_ij(t) + Σ^-qBOⁿ_ij(t)

then:

if FPN_ij(t) <= 0 and there is at least one negative bid-offer pair,

the lowest numbered Bid-Offer pair is extended down to Min^k(qA^k_ij(t))

otherwise,

a new bid-offer pair is created with pair number one lower than the lowest (or -1 if none exist) with:

BOLRⁿ_ij(t) = Min{ FPN_ij(t) + Σ^-qBOⁿ_ij(t), Min^k(qA^k_ij(t)) }

4: The Acceptance Volume (qA^k_ij(t)) attributable to each Bid-Offer Acceptance, including RR Schedule flagged Acceptances, shall be defined. This is undertaken through processing the Point Acceptance Volumes that define the MW output levels that the NETSO requested the BM Unit to operate for certain times within the Balancing Mechanism Window Period.

Linear interpolation shall be used to define the profile of power output in MW expected to be delivered in each Settlement Period within the Balancing Mechanism Window Period as a result of Bid-Offer Acceptance, k.

For times within the Balancing Mechanism Window Period prior to the first value Point Acceptance Volume for Bid-Offer Acceptance k, or after the last value, the value of the Acceptance Volume is set to the last calculated value of Acceptance Volume for those times. If no such previously calculated value of Acceptance Volume exists, then the Acceptance Volume will be set to the value of Final Physical Notification (FPN_ij(t)) for those times.

Acceptance Volumes are then ordered by reference to increasing values of k.

The diagram below shows a Bid-Offer Acceptance in relation to Point Acceptance Volumes and the Bid-Offer Upper and Lower Ranges.

complex image of process

5: The Accepted Bid-Offer Volumes (qABO^kn_ij (t)) shall be defined in MW of a Bid or Offer from Bid-Offer Pair n accepted as a result of Bid-Offer Acceptance k that is not flagged as relating to an RR Instruction in Settlement Period j from BM Unit i. This is determined as follows:

For n>0,

qABO^kn_ij(t) = Max{Min(qA^k_ij(t), BOURⁿ_ij(t)), BOUR^n-1_ij(t)}

- Max{Min(qA^k-_ij(t), BOURⁿ_ij(t)), BOUR^n-1_ij(t)}

For n<0,

qABO^kn_ij (t) = Min{Max(qA^k_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)}

- Min{Max(qA^k-_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)}

Where, from all Bid-Offer Acceptances for which an Acceptance Volume has been determined for Settlement Period j, k- represents the last Bid-Offer Acceptance preceding k which covers time t.

If there is no such Bid-Offer Acceptance, the value of qA^k-_ij(t) = FPN_ij(t) for each Acceptance k that is not flagged as relating to an RR Instruction.

6: The Accepted Offer Volume (qAO^kn_ij(t)) and Accepted Bid Volume qAB^kn_ij (t) shall be defined in MW by splitting the positive and negative parts of the Bid-Offer Acceptance Volume.

The Accepted Offer Volume (qAO^kn_ij(t)) represents the volume (in MW) of Offer n accepted as a result of Bid-Offer Acceptance k from BM Unit i at times t within Settlement Period j. It is the positive part of the Bid-Offer Acceptance Volume, defined by:

qAO^kn_ij(t) = Max {qABO^kn_ij(t), 0}

Similarly, the Accepted Bid Volume (qAB^kn_ij(t)) represents the volume of Bid n accepted as a result of Bid-Offer Acceptance k from BM Unit i at times t within Settlement Period j. It is the negative part of the Bid-Offer Acceptance Volume, defined by:

qAB^kn_ij (t) = Min {qABO^kn_ij(t), 0}

The diagram below represents the volumes of Bids and Offers bought or sold as a result of a Bid-Offer Acceptance.

complex image of process

7: The Period Accepted Offer Volume (QAO^kn_ij) and Period Accepted Bid Volume (QAB^kn_ij) shall be calculated by integrating the Accepted Offer Volume and Accepted Bid Volume over all times in the Settlement Period, for each Acceptance k that is not flagged as relating to an RR Schedule.

The Period Accepted Offer Volume (QAO^kn_ij) is determined by integrating the Accepted Offer Volume over all spot times t in Settlement Period j, for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Offer n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Period Accepted Bid Volume (QAB^kn_ij) is determined by integrating the Accepted Bid Volume over spot all times, t, in Settlement Period, j for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Bid n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Period RR Accepted Offer Volume (RRAO^knij) is established by integrating the Accepted Offer Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

The Period RR Accepted Bid Volume (RRAB^kn_ij) is established by integrating the Accepted Bid Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

8: The Period BM Unit Total Accepted Offer Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QAOⁿ_ij = Σ^kQAO^kn_ij

The Period BM Unit Total Accepted Bid Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QABⁿ_ij = Σ^kQAB^kn_ij

This is the total MWh volume of Offer or Bid n accepted from all Bid-Offer Acceptances.

Where either of QAOⁿ_ij or QABⁿ_ij is non-zero, a flag (NZⁿ_i) is set to record that a non-zero value has been calculated for the Settlement Period [see SAA‑I014 sub flow 2 in IDD part 2].

The Period RR Total Accepted Offer Volume, for all Acceptances that are flagged as relating to an RR Schedule, and shall be established as follows:

RRAOⁿij = Σ^k RRAO^knij

The Period RR Total Accepted Bid Volume, for all Acceptances that are flagged as relating to an RR Schedule shall be established as follows:

RRABⁿij = Σ^k RRAB^knij

Where Σ^k represents the sum over all Acceptances within the Settlement Period for RRABⁿij and RRAOⁿij.

9: The Period BM Unit Balancing Services Volume shall be calculated as follows:

QBS_ij = Σⁿ (QAOⁿ_ij + QABⁿ_ij) + Σⁿ (RRAOⁿ_ij + RRABⁿ_ij) + QAS_ij + BMUADDV_ij – QDD_ij+ QBSD_ij+ SNBABSVD_ij

where

Σⁿrepresents the sum over all Bid-Offer Pair numbers for the BM Unit

QAS_ij is the BM Unit Applicable Balancing Services Volume

BMUADDV_ij is the BM Unit Allocated Demand Disconnection Volume

QDD_ij is the Period BM Unit Demand Disconnection Volume

RRAOⁿ_ijis the Period BM Unit RR Total Accepted Offer Volume

RRABⁿ_ijis the Period BM Unit RR Total Accepted Bid Volume

QBSD_ij represents the Period Supplier Primary BM Unit Delivered Volume

SNBABSVD_ij is the Supplier BM Unit Non BM ABSVD

This represents the net volume of Balancing Services accepted in Settlement Period j for BM Unit i and the Period Supplier Primary BM Unit Delivered Volume (QBSD_ij).

10: The Period FPN (FPN_ij) shall be calculated for each BM Unit i, by integrating the value of Final Physical Notification FPN_ij(t) across all times t, falling within Settlement Period j. The Period FPN is quoted in MWh.

11: The Reserve Scarcity Price (RSVP_j) shall be the value reported to the SAA by the BMRA. Only if the SAA receives updated/amended LoLP data from the NETSO for a Settlement Period, the RSVP_j is calculated as:

RSVP_j = LoLP_j * VoLL

where LoLPj is the Final or latest Indicative Loss of Load Probability for the Settlement Period and VoLL is the Value of Lost Load system parameter.

Until 1 November 2018, if the NETSO does not report there is no Final or Indicative Loss of Load Probability (or it is reported as ‘null’) available for the Settlement Period, then:

RSVP_j = 0.

From 1 November 2018, if the NETSO does not report a Final Loss of Load Probability (or it is reported as ‘null’) for the Settlement Period, then the BMRA will use the most recent Indicative LoLP as though it were the Final LoLP, else if no Indicative LoLP is available then:

RSVPj = 0.

If the BMRA uses an Indicative LoLP in the absence of a Final LoLP provided to it by the NETSO, then the BMRA will set the Default LoLP Flag to ‘True’.

12: The STOR Instructed Volume (QSIV^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer or BSAA that is a STOR Action, the STOR Instructed Volume (QSIV^t_j) shall be equal to the Period Accepted Offer Volume derived from an accepted Offer that is STOR Flagged.

13: The STOR Action Price (STAP^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer that is a STOR action:

STAP^t_j = max(POⁿ_ij, RSVP_j).

In respect of each Settlement Period, for each Balancing Services Adjustment Action that is a STOR action:

STAP^t_j = max(BSAP^m_j, RSVP_j).

14: The Demand Control Volumes shall be calculated as follows:

The SAA shall receive, from the BMRA or the NETSO, and maintain Demand Control Event details. The SAA shall share these details with the CDCA via it shared database.

The Start Point Demand Control level and End Point Demand Control Level shall be the Demand Control Event Estimates determined at the relevant times and dates notified by the NETSO.

In respect of each Settlement Period, the Demand Control Volume for each Demand Control Event Stage shall be established by linear interpolation from the values of the Start Point Demand Control Level and End Point Demand Control Level.

The System Demand Control Volume (QSDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘Yes’.

The Balancing Demand Control Volume (QBDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘No’.

Special cases:

Acceptances are processed in the order in which they are issued, with the exception of Acceptances that are flagged as relating to an RR Schedule, which shall be treated as issued at the Gate Closure time of the Replacement Reserve Auction Period to which they relate.

No Acceptance Volume (qA^k_ij(t)) shall be calculated for any spot times, t. where the following criteria are met:

- qA^k_ij(t) is not flagged as relating to a RR Schedule or a RR Instruction; and

- there exists a qA^k*_ij(t) flagged as relating to a RR Schedule; and

- BEGCT < qA^k_ij(t) Bid-Offer Acceptance Time < qA^k*_ij(t) associated Replacement Reserve Activation Time; and

- either:

qA^k-_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k*_ij(t) (MW)

qA^k*_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k-_ij(t) (MW)

where qA^k-_ij(t) represents the latest Acceptance Volume relating to the latest Acceptance issued prior to Gate Closure of the relevant Replacement Reserve Auction Period (BEGCT). If no such previously calculated value of Acceptance Volume qA^k-_ij(t) exists, then the Acceptance Volume shall be set to the value of FPN_ij(t) for those spot times; and

where qA^k_ij(t) (MW), qA^k-_ij(t) (MW) and qA^k*_ij(t) (MW) represent the associated spot time MW values.

In the example below, a BOA, qA^k-_ij, is requested after BEGCT by the TSO. The BOA falls between an existing BOA, qA^k_ij’ which is equal to the FPN as it was sent prior to BEGCT, and an RR Activation qAk^*_ij.

complex image of process

Non-Functional Requirement:

Interfaces:

Issues:

5.6 SAA-F006: Calculate BM unit transmission loss multipliers

Requirement ID:

SAA-F006

Status:

Title:

Calculate BM unit transmission loss multipliers

BSC reference:

SAA SD 3.1, SAA BPM 3.6, SAA WS1 Action 24

CP1222, P278, P350, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the transmission loss multipliers.

All calculation steps in this requirement are included here.

1: All BM unit, other than Secondary BM Units, metered volumes shall be summed over their associated Trading Units to determine the net Import or Export meter volumes for each Trading Unit. Where the total Trading Unit meter volume is positive, all BM Units, other than Secondary BM Units, associated with this Trading Unit shall be classified as delivering to the Total System. Where the total Trading Unit meter volume is negative, all BM Units, other than Secondary BM Units, associated with this Trading Unit shall be classified as offtaking from the Total System.

Note that, by default, a BM Unit not comprising a Trading Unit with other BM Units shall be considered to be a ‘Sole Trading Unit’ for the purposes of these calculations. The “delivering” and “offtaking” status of such a Trading Unit shall therefore be determined using the metered volume of the single BM Unit comprising that Trading Unit.

This calculation takes place in each Settlement Period.

2: The Transmission Loss Multipliers (TLMO⁺_j and TLMO^-_j) shall be calculated for the Settlement Period j. These are calculated as follows:

TLMO⁺_j = – {α(Σ⁺QM_ij + Σ^-QM_ij) + Σ⁺_(non-I) (QM_ij * TLF_ij)} / Σ⁺_(non-I) QM_ij;

TLMO^-_j = {(α–1)(Σ⁺QM_ij + Σ^-QM_ij) – Σ^-_(non-I) (QM_ij * TLF_ij)} / Σ^-_(non-I) QM_ij;

Where:

Σ⁺ represents a sum over all BM Units in Trading Units other than Secondary BM Units that are net deliverers of energy in Settlement Period j;

Σ^- represents a sum over all BM Units in Trading Units other than Secondary BM Units that are net offtakers of energy in Settlement Period j;

Σ⁺_(non-I) represents a sum over all BM Units other than Interconnector BM Units and Secondary BM Units in Trading Units that are net deliverers of energy in Settlement Period j; and

Σ^-_(non-I) represents a sum over all BM Units other than Interconnector BM Units and Secondary BM Units in Trading Units that are net offtakers of energy in Settlement Period j.

3: The BM Unit Transmission Loss Multiplier shall be calculated for each BM Unit in each settlement period. This shall be calculated as:

TLM_ij = 1 + TLF_ij + TLMO⁺_j for all non-Interconnector BM Units that are in Trading Units that are net deliverers of energy in Settlement Period j,

TLM_ij = 1 + TLF_ij + TLMO^-_j for all non-Interconnector BM Units that are in Trading Units that are net offtakers of energy in Settlement Period j,

TLM_ij = 1 for all Interconnector BM Units irrespective of whether they are in Trading Units that are net deliverers or offtakers of energy in Settlement Period j.

Where TLF_ij is the Transmission Loss Factor assigned to each BM Unit. This will allow imports and exports volumes to be scaled by location, as well as for adjusting the relative contributions to the total cost of losses from imports and exports. The values of α and TLF_ij will, in general be determined by the BSC. The value of αis 0.45 and TLF_ij is calculated in accordance with Annex T-2 of the BSC. It should be noted that TLMs and TLFs are BM Unit specific variables.

In respect of each Settlement Period, for each Secondary BM Unit, the Transmission Loss Multiplier shall be calculated as follows:

TLM_ij = TLM_ij(Base)

where TLM_ij(Base)means the value of TLM_ij calculated in the Settlement Period for BM Units belonging to the Base Trading Unit in the same GSP Group as the Secondary BM Unit.

Non-Functional Requirement:

Interfaces:

Issues:

5.7 SAA-F007: Calculate balancing mechanism Replacement Reserve cashflows

Requirement ID:

SAA-F007

Status:

Title:

Calculate balancing mechanism and Replacement Reserve cashflows

BSC reference:

SAA SD 3.13, 3.14, 3.15, 3.16, 3.2.1, 3.2.8, SAA BPM 3.7, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the balancing mechanism cashflows. All calculation steps in this requirement are included here.

1: The Period Acceptance Offer Cashflow CAO^kn_ij shall be calculated as:

CAO^kn_ij = QAO^kn_ij * POⁿ_ij * TLM_ij.

The Period Acceptance Bid Cashflow CAB^kn_ij shall be calculated as:

CAB^kn_ij = QAB^kn_ij * PBⁿ_ij * TLM_ij

Where QAB^kn_ijis the Period Accepted Bid Volume; QAO^kn_ijis the Period Accepted Offer Volume; PBⁿ_ijis the Bid Price for the corresponding Bid; POⁿ_ijis the Offer Price for the corresponding Offer; and TLM_ijis the Transmission Loss Multiplier for BM Unit i and Settlement Period j.

The Period Acceptance Bid Cashflow (CAB^kn_ij) and Period Acceptance Offer Cashflow (CAO^kn_ij) represent the Transmission Loss adjusted cashflow relating to BM Unit I for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n, as a result of Bid-Offer Acceptance k. Under normal circumstances, the Period Acceptance Bid Cashflow will be negative as QAB^kn_ij is negative and PBⁿ_ij is normally positive.

The Period Acceptance Bid Cashflow and the Period Acceptance Offer Cashflow need to be stored if required for reporting purposes.

2: The Period BM Unit Offer Cashflow (COⁿ_ij ) shall be calculated as:

COⁿ_ij = QAOⁿ_ij * POⁿ_ij * TLM_ij (=Σ^kCAO^kn_ij)

The Period BM Unit Bid Cashflow (CBⁿ_ij) shall be calculated as:

CBⁿ_ij = QABⁿ_ij * PBⁿ_ij * TLM_ij (=Σ^kCAB^kn_ij)

These represent the Transmission Loss adjusted cashflows relating to BM Unit i for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n. Under normal circumstances the Period BM Unit Bid Cashflow will be negative.

3: The Period BM Unit Cashflow (CBM_ij).shall be calculated as:

CBM_ij = ΣⁿCOⁿ_ij + Σⁿ CBⁿ_ij

This represents the total payment to BM Unit i as a result of accepted Balancing Mechanism action in Settlement Period j

4: The Total System BM Cashflow (TCBM_j) shall be calculated as:

TCBM_j = Σ_i CBM_ij

This represents the total payments and charges in respect of Balancing Mechanism action for all BM Units (excluding any non-delivery adjustments) in Settlement Period j.

5: The Quarter Hour RR Cashflow for a BM Unit (CCR_iJ) is defined as:

CCR_iJ = RRAV_iJ * RRAP_J

where RRAP_J represents the Quarter Hour RR Activation Price and RRAV_iJis the RR Activation Volume established as follows:

RRAViJ = Quarter Hour RR Activated Quantity * 0.25

6: The Period RR BM Unit Cashflow (CRR_ij) for a BM unit is calculated as:

CRR_ij = Σ_JCCR_iJ

where Σ_J is the sum over all Quarter Hours J within Settlement Period j.

7:The Daily Party RR Cashflow (CRR_p) is calculated as:

CRR_p = Σ_j Σ_iϵp CRR_ij

where Σ_j is the sum over all Settlement Periods and Σ_iϵp is the sum of all BM Units for which Party p is the Lead Party in that day.

8: The Replacement Reserve Instructed Offer Deviation Cashflow (CDOij) and the Replacement Reserve Instructed Bid Deviation Cashflow (CDBij) for a BM Unit in a settlement period is the payment that results from a deviation from the Deemed Standard Product Shape and is determined as follows:

CDOij = IODij * BEDPj

CDBij = IBDij * BEDPj

Where BEDP_j is the Balancing Energy Deviation Price and is equal to zero.

9: The Replacement Reserve Period Instruction Deviation Cashflow (CDR_ij) is the payment in respect of a BM Unit, as a result of deviation from the TERRE Standard Product Shape in the Settlement Period shall be and shall be determined as follows:

CDR_ij = CDO_ij + CDB_ij

10: The Daily Party RR Instruction Deviation Cashflow is determined as:

CDR_p = Σ_j Σ_iϵp CDR_ij

where Σ_j is the sum over all Settlement Periods and Σ_iϵp is the sum of all BM Units for which Party p is the Lead Party in that day.

11: The Total System RR Cashflow (TCRR_j) for all BM units is calculated as:

TCRR_j= Σ_ij CRR_ij + Σ_ij CDR_ij

where Σ_ij is the sum over all BM Units i and Settlement Period j.

Non-Functional Requirement:

Interfaces:

Issues:

5.8 SAA-F008: Calculate Credited Energy Volumes

Requirement ID:

SAA-F008

Status:

Title:

Calculate Credited Energy Volumes

BSC reference:

RETA CR 005, RETA ERR 1, SAA SD 3.31, 3.32.1, SAA BPM 3.8, P71, P269, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the Credited Energy Volumes. All calculation steps in this requirement are included here.

1: When allocating the BM Unit Metered Volume (QM_ij) and the Period BM Unit Balancing Services Volume (QBS_ij) to Energy Account a for each Settlement Period j, under steps 2 and 3 below:

Where BM Unit i is a Primary Production BM Unit (has a P/C Status of Production) for that Settlement Period j, then Energy Account a shall be the Production Energy Account

Otherwise,

Where BM Unit i is a Primary Consumption BM Unit (has a P/C Status of Consumption) for that Settlement Period j, then Energy Account a shall be the Consumption Energy Account

For each Settlement Period j, the SAA shall determine the P/C Status of BM Unit i according to the rules applied by the CRA¹ for the corresponding Settlement Day.

The SAA shall retain a record of the P/C Status applied in the Credited Energy Volume calculation for each BM Unit i and Settlement Period j.

2: The Credited Energy Volume QCE_iaj from each Primary BM Unit i, shall be allocated to each Energy Account a of each Subsidiary Energy Account for each Settlement Period j, as follows:

QCE_iaj = {(QM_ij - QBS_ij)*(QMPR_iaj/100) + QMFR_iaj}*TLM_ij ,

Where

a≠A, and A is the Lead Energy Account for BM Unit i;

QMFR_iaj is the Metered Volume Fixed Reallocation, a fixed volume in MWh, assigned to Energy Account a from BM Unit i in Settlement Period j;

QMPR_iaj is the Metered Volume Percentage Reallocation, the percentage of the BM Unit Metered Volume that remains after Balancing Actions have been deducted, which is allocated to Energy Account a from BM Unit i in Settlement Period j; and

QM_ij is the Primary BM Unit Metered Volume.”

QCE_iajare rounded down to the nearest kWh.

where “i” in relation to QMij and QBSij represents Primary BM Units only

3: The Lead Party Credited Energy Volume shall be calculated for the Lead Energy Account, for each Primary BM Unit i, in each Settlement Period j, as follows:

QCE_iAj = (QM_ij * TLM_ij) - Σ_a_≠_A QCE_iaj

Where Σ_a_≠_A represents a sum over all Energy Accounts, other than the Lead Energy Account and “i” in relation to QMij and QBSij represents Primary BM Units only.

This allocates any residual metered volume, including any Balancing Mechanism action to the Lead Energy Account. This ensures that all the BM Unit Metered Volume flow is always allocated in full.

3: The Account Credited Energy Volume (QACE_aj).shall be calculated for each Energy Account a, as follows:

QACE_aj = Σ_i QCE_iaj

where Σi represents the sum over all Primary BM Units.

Non-Functional Requirement:

Interfaces:

Issues:

5.9 SAA-F009: Calculate energy imbalance prices

Requirement ID:

SAA-F009

Status:

Title:

Calculate energy imbalance prices

BSC reference:

SAA SD 3.24.1, 3.24.2, 3.26, 3.27, 3.28, 3.29, SAA BPM 3.9, CR003, P8, P10, P18A, CP598, P71, P72, P78, P194, P217, P305.

Man/auto:

Automatic

Frequency:

Once, on each Settlement Run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the energy imbalance prices. All calculation steps in this requirement are included here.

(Note: In order that Energy Imbalance Prices may be calculated as soon as possible after a particular Settlement Period has ended, Energy Imbalance Prices will not be adjusted in order to account for volumes of non-delivered Bids and/or Offers.)

For Settlement Days before the P217 effective date apply PAR Tagging in addition to NIV Tagging, as defined in SAA-F009a. For Settlement Days after, and including, the P217 effective date apply Replacement Price Classification, as defined in SAA-F009b.

Non-Functional Requirement:

5.9.1 SAA-F009a: Apply Net Imbalance Volume and Price Averaging Reference Tagging

This section is no longer used.

5.9.2 SAA-F009b: Calculate Imbalance Prices post P217

Requirement ID:

SAA-F009b

Status:

Title:

Apply Replacement Price Classification

BSC reference:

P217, P305, P344.

Man/auto:

Automatic

Frequency:

Once, on each Settlement Run.

Volumes:

Functional Requirements:

1: Identify Short-Duration Acceptances.

The rules for identifying Short-Duration Acceptances are:

a. Acceptances for each BM Unit are grouped into sets of overlapping acceptances (for the avoidance of doubt, if two acceptances are contiguous, i.e. the last spot time of one acceptance matches the first of another, then the two are considered to overlap).

b. The overall duration of the group is computed (earliest spot time of any acceptance in a group to latest spot time of any acceptance in a group).

c. In relation to any Demand Control Volume, the Continuous Acceptance Duration shall be the duration of the period commencing at the Demand Control Event Start Point and ending at the Demand Control Event End Point.

d. If the overall duration is less than the Continuous Acceptance Duration Limit, CADL_dthen the Short Duration Acceptance flag for each acceptance in the group is set to show that it is a Short-Duration Acceptance. If CADL_d= 0 then no acceptances are “Short-Duration Acceptances”. CADL_d will be an integer number of minutes from 0 to 30.

Short-Duration Acceptances will be considered to be “CADL Flagged” for the purposes of the System Price Calculation process.

2: Compute Total Volumes:

a. Total Volume of Offers

TQAO_j = Σ_iΣⁿQAOⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Offers

b. Total Volume of Bids

TQAB_j = Σ_iΣⁿQABⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Bids

c. Total Period Applicable Balancing Services Volume

TQAS_j = Σ_iQAS_ij

where: Σ_i represents the sum over all BM Units;

d. Total Balancing Services Adjustment Buy Volume

TBVA_j = Σ^mQBSAB^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Buy Actions.

e. Total Balancing Services Adjustment Sell Volume

TSVA_j = Σ^mQBSAS^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Sell Actions

f. TQSIV_j = Σ^tQSIV^t_j

where: Σ^t represents the sum over all STOR Actions.

g. TQSDC_j = ΣQSDC_j

where: Σ represents the sum over all System Demand Control Volumes.

h. TQBDC_j = ΣQBDC_j

where: Σ represents the sum over all Balancing Demand Control Volumes.

3: Identify “De Minimis Acceptance Volumes” (De Minimis Tagging).

Acceptances (including those that are STOR Flagged) with a Total Accepted Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QAOⁿ_ij| < DMAT_d or |QABⁿ_ij| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Balancing Services Adjustment Actions (including those that are STOR Flagged) with a Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QBSAB^m_j| < DMAT_d or |QBSAS^m_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Demand Control Volumes with a volume less than the De Minimis Acceptance Threshold (i.e. where values of |QSDC_j| < DMAT_d or |QBDC_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

De Minimis Tagged System Actions are excluded from the price calculations as they may distort the results.

If DMAT_d is set to 0, then no volumes will be tagged in this way. DMAT_d will always be a positive number or 0.

4: Build Buy and Sell Stacks.

Buy System Actions (QSB^w_j) are considered to be:

i. All those Accepted Offers (QAO^kn_ij) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

ii. All Balancing Services Adjustment Buy Actions (QBSAB^m_j) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

iii. in relation to each STOR Action, the STOR Instructed Volume (QSIV^t_j) which are not “De Minimis Acceptance Volumes”:

iv. in relation to each Demand Control Impacted Settlement Period, the System Demand Control Volume (QSDC_j) which are not “De Minimis Acceptance Volumes”

v. in relation to each Demand Control Impacted Settlement Period, the Balancing Demand Control Volume (QBDC_j) which are not “De Minimis Acceptance Volumes”.

vi) in relation to Replacement Reserve Auction Results, the positive values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

(vii) in relation to Replacement Reserve Auction Results, Replacement Reserve Aggregated Unpriced System Buy Actions (RRAUSB_j) determined by the SAA for each Settlement Period as below:

RRAUSB_j = max {(∑ⁿ_i RRAOⁿ_ij + ∑ⁿ_i RRABⁿ_ij ), 0}

+ max (∑^J VIⁿ_j , 0) – max (∑^JVGB^J_j, 0)

where VI^J represents the Quarter Hour Volume Interconnector Schedule to be determined from the Quarter Hour Interconnector Schedule (I^J) as below;

VI^J = I^J * 0.25

where I^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour Interconnector Schedule for Quarter Hour ‘J’

Sell System Actions (QSS^w_j) are considered to be:

i. All those Accepted Bids (QAB^kn_ij) which are not “De Minimis Acceptance Volumes”; and

ii. All Balancing Services Adjustment Sell Actions (QBSAS^m_j) which are not “De Minimis Acceptance Volumes”.

(iii) in relation to Replacement Reserve Auction Results, the negative values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

(iv) in relation to Replacement Reserve Auction Results, Replacement Reserve Aggregated Unpriced System Sell Actions (RRAUSS_j) determined by the SAA for each Settlement Period as below:

RRAUSSj = min {(∑ⁿ_i RRAOⁿ_ij + ∑ⁿ_i RRABⁿ_ij ), 0}

+ min (∑^J VIⁿ_j , 0) – min (∑^JVGB^J_j, 0)

The price of a System Action is considered to be (SAP^w_j):

i. In the case of an accepted Offer that is not a STOR Action, the Offer Price POⁿ_ij;

ii. In the case of an accepted Bid, the Bid Price PBⁿ_ij;

iii. In the case of Balancing Services Adjustment Actions that are not STOR Actions, Balancing Services Adjustment Price BSAP^m_j(derived from Cost/Volume, i.e. a £/MWh price);

iv. In the case of a STOR Action, the STOR Action Price (STAP^t_j); or

v. In the case of a System Demand Control Volume or a Balancing Demand Control Volume, the VoLL.

(vi) In the case of Quarter Hour Volume GB Need Met, the associated Quarter Hour Replacement Reserve Activation Price (QHRRAP^J); and

(vii) In the case of Replacement Reserve Aggregated Unpriced System Actions, the price shall be equal to zero.

For each Settlement Period, all System Actions are listed in descending order of price, within the relevant Stack. Unpriced Balancing Services Adjustment Actions are placed at the top of the Buy Stack (as if most expensive) or the bottom of the Sell Stack (as if least expensive), as appropriate. For example:

Buy Stack		Sell Stack
Vol(QSB^w_j)	Price(SAP^w_j)	Vol(QSS^w_j)	Price(SAP^w_j)
12	-	7	25
24	45	15	8
15	40	5	7
50	10	5	4
20	10	10	-

5: Apply Arbitrage Tagging.

Starting from the most expensive Sell Action and least expensive Buy Action, each System Action is inspected for arbitrage, i.e. where the Sell Action’s price exceeds or is equal to the Buy Action’s price. Where arbitrage exists then equivalent amounts of volume are tagged out from both stacks until arbitrage no longer exists.

Actions with the same price which are on the same stack are combined into a single item for the purpose of Arbitrage inspection. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all.

Extending the example from above:

Buy Stack		Sell Stack
Vol(QSB^w_j)	Price(SAP^w_j)	Vol(QSS^w_j)	Price(SAP^w_j)
12	-	7	25
24	45	15	8
15	40	5	7
50 45	10	5	4
20 18	10	10	-

In this example there are two Buy Actions (total volume = 70 MWh, price = £10) matched to a single Sell Action (volume = 7 MWh, price = £25). The two Buy Actions therefore have an amount tagged equal to 7/70 times their volume ( 5 and 2 MWh respectively, for a total of 7 MWh tagged volume)

Unpriced Balancing Services Adjustment Actions are ignored for the purposes of Arbitrage – i.e. once all Priced Actions on a Stack have been Arbitrage tagged then no further Arbitrage tagging can occur.

The process of Arbitrage Tagging will only be carried out for Settlement Dates where the Arbitrage Flag (a dated system parameter) is set.

6: Determine System Action Classification

For each Settlement Period, the Buy and Sell Stacks are then updated by applying the following algorithm:

All the First-Stage Flagged and Unflagged System Actions are identified on each Stack. A First-Stage Flagged System Action is one which is either:

a) A Short-Duration (CADL Flagged) Acceptance;

b) A SO-Flagged Acceptance;

c) A SO-Flagged Balancing Services Adjustment Action; or

d) A System Demand Control Volume.

A First-Stage Unflagged System Action is one which is not a First-Stage Flagged System Action.

Then, for the Buy Stack, all First-Stage Flagged System Actions with a price which is higher than the most expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions. And, for the Sell Stack, all First-Stage Flagged System Actions with a price which is lower than the least expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions.

All Second-Stage Flagged System Actions are considered to be unpriced.

For example:

Buy Stack

complex image of process

Sell Stack

complex image of process

Note that unpriced Balancing Services Adjustment Actions are always classified as Second-Stage Flagged System Actions and therefore always remain unpriced.

7: Apply NIV Tagging

Starting from the least expensive Sell Action and most expensive Buy Action, Actions from the two stacks are matched and tagged until the smaller (in total volume) of the two stacks is completely tagged. Unpriced Actions are included in NIV Tagging. Unpriced Sell Actions are considered to be the least expensive Sell Actions and Unpriced Buy Actions are considered to be the most expensive Buy Action – i.e. where present they are the first Actions to be considered during the NIV Tagging process.

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all. Unpriced items are considered to be at the same price for the purpose of NIV Tagging.

In the example from above the Buy Stack is the smaller (having only 70 MWh of total volume, as opposed to 100 MWh on the Sell Stack). The result of this process is that there will be, across the two stacks, a mixture of NIV Tagged and NIV Untagged stack items. Continuing the example from before:

Buy Stack			Sell Stack
Tagged Status	Price	Vol	Tagged Status	Price	Vol
Tagged	-	10	Untagged	15	15
Tagged	-	0	Untagged	10	15
Tagged	25	5	Tagged	10	29
Tagged	20	20	Tagged	5	5
Tagged	15	5	Tagged	-10	7
Tagged	10	30	Tagged	-	25
			Tagged	-	4

Note that for the £10 price range only 29 out of the 44 available MWh of Sell Actions at that price can be tagged. Therefore each Sell Action in that price range would be tagged by an amount equal to 29/44 of their entire volumes. Expanding the example, and assuming that there are three Sell Actions that make up the 44 MWh:

Sell Action	Volume	Tagged Volume	Untagged Volume
1	20	20 x 29/44 = 13.182	20 x 15/44 = 6.818
2	10	10 x 29/44 = 6.591	10 x 15/44 = 3.409
3	14	14 x 29/44 = 9.227	14 x 15/44 = 4.773

8: Calculate and Apply Replacement Price

The Replacement Price is calculated from a selection of those untagged items remaining after the NIV Tagging process which are priced System Actions (i.e. Unflagged Second-Stage System Actions). This selection is determined by the Replacement Price Average Reference (RPAR) Volume, and is defined as that volume of the most expensive priced System Action items remaining after NIV Tagging which is equivalent to the RPAR Volume (where necessary only part of an item’s volume will be considered selected in order that the total selected volume is equal to the RPAR Volume). Where the total remaining volume of untagged, priced System Action items is less than the RPAR Volume then all untagged, priced System Action items are selected.

The Replacement Price is calculated as the volume weighed average price of the selected items.

If NIV is positive then:

RP_j = ∑^w' (QSB^w'_j * SAP^w'_j) / ∑^w' QSB^w'_j

and if NIV is negative then:

RP_j = ∑^w' (QSS^w'_j * SAP^w'_j) / ∑^w' QSS^w'_j

Where ∑^w'is the sum over all RPAR Volume selected untagged, priced System Actions.

Where no priced System Action items remain after NIV Tagging then the Replacement Price is the Market Price. If the Market Price is undefined then the Replacement Price is zero.

The actual volume of Actions used to calculate the Replacement Price is defined as the Replacement Price Calculation Volume. If the Replacement Price is derived from the Market Price then Replacement Price Calculation Volume will be considered to be zero.

Once calculated the Replacement Price is assigned to those remaining untagged stack items which are classified as Second-Stage Flagged System Actions, All such affected System Actions are considered to be “Repriced” System Actions.

9: Apply PAR Tagging

Referencing the remaining Buy or Sell Stack (depending on whichever stack has untagged items remaining after NIV tagging), and starting from the most expensive Sell Stack item or least expensive Buy Stack item, Buy or Sell Stack items are tagged until the total remaining priced volume in the stack is not more than the Price Average Reference Volume (PAR_d).

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the entire set of combined Sell Actions (or Buy Actions) can be matched, then every Sell Action (or Buy Action) at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Sell Actions (or Buy Actions) entirely, and others not at all. For an example which demonstrates the principle of this mechanism see the section describing NIV tagging above.

Continuing the example from above: All items in the Buy Stack are NIV Tagged, and only two items remain untagged in the Sell Stack, leaving a total of 30 MWh untagged volume. For example, if PAR_d was defined to have a value of 20 MWh, this would mean that 10 of the remaining 30 MWh should be PAR Tagged (to leave us with the required 20 MWh), leaving the stacks as follows:

Buy Stack			Sell Stack
Tagged Status	Price	Vol	Tagged Status	Price	Vol
NIV Tagged	-	10	PAR Tagged	15	10
NIV Tagged	-	0	Untagged	15	5
NIV Tagged	25	5	Untagged	10	15
NIV Tagged	20	20	NIV Tagged	10	29
NIV Tagged	15	5	NIV Tagged	5	5
NIV Tagged	10	30	NIV Tagged	-10	7
			NIV Tagged	-	25
			NIV Tagged	-	4

Note that where, after NIV Tagging, the remaining volume is less than or equal to the PAR_d then no items will be PAR Tagged.

10. Calculate Reported Period BM Unit Volumes

It is now possible to calculate the following reported derived values:

a. Period BM Unit Tagged Volume of Offers (QTAOⁿ_ij) and Bids (QTABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

b. Period BM Unit Repriced Accepted Volume of Offers (QRAOⁿ_ij) and Bids (QRABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

c. Period BM Unit Originally-priced Accepted Volume of Offers (QOAOⁿ_ij) and Bids (QOABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

11. Calculate Reported Acceptance Volumes

It is now possible to calculate the following reported derived values:

a. The System Total Priced Accepted Volume of Offers (TQPAO_j) and Bids (TQPAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not Classified as Second-Stage Flagged.

b. System Total Tagged Accepted Volume of Offers (TQTAO_j) and Bids (TQTAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. System Total Repriced Accepted Volume of Offers (TQRAO_j) and Bids (TQRAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. System Total Originally-priced Accepted Volume of Offers (TQOAO_j) and Bids (TQOAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

12. Calculate Reported Adjustment Volumes

It is now possible to calculate the following reported derived values:

a. Total System Adjustment Volume of Buy Items (TSVA_j) and Sell Items (TBVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively.

b. Total System Tagged Adjustment Volume of Buy Items (TSTVA_j) and Sell Items (TBSVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. Total System Repriced Adjustment Volume of Buy Items (TSRVA_j) and Sell Items (TBRVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. Total System Originally-priced Adjustment Volume of Buy Items (TSOVA_j) and Sell Items (TBOVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

13. The Total NIV Tagged Volume for a Settlement Period can now be calculated as:

TCQ_j = {Σ_w QSB^w_j – Σ_w QSS^w_j} / 2

where

Σ_w represents the sum over all System Actions which are NIV Tagged.

14. The actual Net Imbalance Volume (NIV) for each Settlement Period can then be calculated as follows:

NIV_j = Σ_w QSB^w_j – Σ_w (-QSS^w_j)

where

Σ_w represents the sum over all System Actions that are not De Minimis Tagged System Actions, and not Arbitrage Tagged System Actions.

15. The remaining offers and bid volumes shall be used in the calculation of the System Buy Price (SBP_j) as follows:

In respect of each Settlement Period,

if the Net Imbalance Volume is not equal to zero and is a positive number, and

{Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m {QBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j}+ Σ^J {VGB_j^J} + {RRAUSB_j} is not equal to zero,

then the System Buy Price will be determined as follows:

SBP_j = {Σ_iΣⁿΣ^k {QAO^kn_ij * POⁿ_ij* TLM_ij} + Σ^m {QBSAB^m_j * BSAP^m_j} + Σ^t {QSIV^t_j * STAP^t_j} + {QSDC_j + QBDC_j} * VoLL} } + Σ^J {VGB^J * QHRRAP^J} + {RRAUSB_j * 0} _______________________________________________________________________________________________ + {BPA_j}

{Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m QBSAB^m_j + Σ^t QSIV^t_j + QSDC_j + QBDC_j } + Σ^J {VGB_j^J} + {RRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Offers that are not De Minimis Tagged and not Arbitrage Tagged Offers and not NIV Tagged Offers and not PAR Tagged Offers;

Σ^t represents the sum over all STOR actions

POⁿ_ij is the Price for the Offer acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price);

Σ^m represents the sum over those Balancing Services Adjustment Buy Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

Σ^J represents the sum over all Quarter Hour Volume GB Need Met in the Final Ranked Set of System Buy Actions; and

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price);

BPA_j is the Buy-Price Price Adjustment; and

The System Sell Price SSP_j = SBP_j.

16. The remaining offers and bid volumes shall be used in the calculation of the System Sell Price (SSP_j) as follows:

In respect of each Settlement Period,

if the Net Imbalance Volume is not equal to zero and is a negative number, and

{Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m {QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is not equal to zero,

then the System Sell Price will be determined as follows:

SSP_j = {SPA_j} +

{Σ_iΣⁿΣ^k {QAB^kn_ij * PBⁿ_ij* TLM_ij} + Σ^m {QBSAS^m_j * BSAP^m_j}} + Σ^J {VGB^J * QHRRAP^J} + {RRAUSB_j * 0}

___________ ___________________________________________________________________________________

{Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Bids that are not De Minimis Tagged and not Arbitrage Tagged Bids and not NIV Tagged Bids and not PAR Tagged Bids;

PBⁿ_ijis the Price for the Bid acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price):

Σ^m represents the sum over those Balancing Services Adjustment Sell Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price);

SPA_j is the Sell-Price Price Adjustment; and

The System Buy Price SBP_j = SSP_j.

16a. If, for any Settlement Period,
if the Net Imbalance Volume is equal to zero or is a positive number,

if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

16b. If, for any Settlement Period,
if the Net Imbalance Volume is equal to zero or is a negative number,

if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAB^m_j}+ Σ^J {VGB_j^J} + {RRAUSS_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

16c. If, for any Settlement Period,
Σ_sQXP_sj = 0,
where
Σ_s represents the sum over all Index Providers;
QXP_sj is the Market Index Volume for Index Providers and Settlement Period j
Then
if the Net Imbalance Volume is not equal to zero or is a positive number,
if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} is equal to zero,
then SBP_j = SSP_j = 0
if the Net Imbalance Volume is not equal to zero and is a negative number,
if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAS^m_j} is equal to zero,
then SBP_j = SSP_j = 0

17. The Price Adjustment parameters shall be set through the automatic interface SAA-I026, as directed by NETSO. Note that if no adjustment data has been provided for Settlement Period j then a value of zero will be used for both of the Price Adjustment parameters.

The system parameters like RPAR_d, PAR_d, Arbitrage Flag, DMAT_d, CADL_dand VoLL are received from BSCCo Ltd through the manual flow SAA-I023.

Market Index Data is received from Market Index Data Providers through the automatic flow SAA-I030.

The SAA shall, for the purposes of performance reporting, record details of those cases where:

1. A value of zero was used for Market Index Price and Volume are used for a Settlement Period, for the purposes of the Initial Interim Settlement Calculation

2. A Market Index Provider has failed to supply Market Index Data for any given Settlement Period, such that a default price and volume of zero are used for that Settlement Period, for the purposes of the Initial Interim Settlement Calculation.

The SAA shall for the purposes of reporting, record a Price Derivation Code (PDC_j) for each Settlement Period. This code will describe how the SBP and SSP were calculated. The possible values for the code, and their associated meaning, are defined in Appendix E.

Non-Functional Requirement:

5.10 SAA-F010: Calculate interconnector error

Requirement ID:

SAA-F010

Status:

Title:

Calculate interconnector error

BSC reference:

SAA BPM 3.10, RETA ERR 3, CP555, CP632

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the interconnector error. All calculation steps in this requirement are included here.

1: The BM Unit Metered Volumes for Interconnector Users (QM_ij) shall be summed by Interconnector. These values are received from the Interconnector Administrator.

Note that where a volume is not specified for an Interconnector User BM Unit, no value is loaded. Where that volume is required in processing functions, a default value of zero is applied by the processing function.

Where a revised, or late, flow is received from an External Interconnector Administrator after the Interim Information Settlement Run has been issued for the relevant Settlement Day (s), then the flow shall not be automatically loaded, but instead the SAA should contact BSCCo Ltd and ask what action should be taken. BSCCo Ltd will then indicate to SAA whether or not to load the data. The SAA must be able to manually load the data if instructed to do so by BSCCo Ltd.

2: The aggregated BM Unit Metered Volumes for Interconnector Users (ΣQM_ij) (obtained above) shall be compared with the aggregated meter reading (IMV_j) (obtained from the Interconnector Metered Flow from the CDCA). The difference is the Interconnector Error Administrator Volume (ErrorVol_j) which shall be allocated to the Interconnector Error Administrator BM Unit (or IEA BM unit).

A positive (or zero) Error Volume is assigned to the production IEA BM Unit with zero assigned to the consumption IEA BM Unit; a negative Error Volume is assigned to the consumption IEA BM Unit with zero is assigned to the production IEA BM Unit.

Formally:

ErrorVol_{j =}IMV_j - Σ_iQM_ij

where ErrorVol_j is the error volume for the Interconnector in period j

and Σ_i is the sum over all Interconnector User BM Units for the Interconnector

For the production IEA BM Unit for the Interconnector

QM_ij = Max (ErrorVol_j, 0)

For the consumption IEA BM Unit for the Interconnector

QM_ij = Min (ErrorVol_j, 0)

Note: All Interconnector Users will have 2 BMU Units i.e. One for Production and Consumption respectively.

Non-Functional Requirement:

Interfaces:

Issues:

5.11 SAA-F011: Calculate energy imbalance cashflows

Requirement ID:

SAA-F011

Status:

Title:

Calculate energy imbalance cashflows

BSC reference:

SAA SD 3.24.3, 3.30.1, 3.33, 3.34, 3.35, 3.36, 3.37, SAA BPM 3.11, CR028, P71, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the energy imbalance cashflows. All calculation steps in this requirement are included here.

The SAA shall exclude the System Operator Production and Consumption Imbalance Volumes from the calculations in steps 3, 4, and 5 below.

The System Operator Production Imbalance [redundant] and System Operator Consumption Imbalance [redundant] shall be reported to all parties on a Settlement Period basis.

1: The Account Period Balancing Services Volume, QABS_aj, for each Energy Account and Virtual Balancing Account, shall be calculated as follows:

QABS_aj = Σ_i_∈_a QBS_ij * TLM_ij+ (Σ_i2QSNDi_2j * TLM_i2j)

Where

Σ_i_∈_a in relation to QBS_ij represents a sum over all Primary BM Units i for which Energy Account a is the Lead Energy Account;

Σ_i2 in relation to QSND_i2j represents the sum over all Secondary BM Units for which such Energy Account or Virtual Balancing Account (as the case may be) is the corresponding Energy Account or Virtual Balancing Account of the Lead Party;

TLM_ij is the Transmission Loss Multiplier for Primary BM Unit i in Settlement Period j.

TLM_i2j is the Transmission Loss Multiplier for the Secondary BM Unit i2 in Settlement Period j.

The Account Period Bid-Offer Volume represents the net volume of accepted Balancing Mechanism Bids and Offers attributable to each Energy Account a, in Settlement Period j.

2: The Account Energy Imbalance, QAEI_aj, attributable to each Energy Account and Virtual Balancing Account in Settlement Period j, shall be calculated. This shall be determined by subtracting the Total Energy Contract Volume (QABC_aj) and Account Period Balancing Services Volume (QABS_ij) from the Account Credited Energy Volume (QACE_aj), as follows:

QAEI_aj = QACE_aj – QABS_aj – QABC_aj

Where the Total Energy Contract Volumes for each Energy Account and Virtual Balancing Account, is obtained from the Energy Contract Volume Aggregation Agent.

3: The Total System Energy Imbalance Volume TQEI_j (summed across all Energy Accounts a) shall be calculated as follows:

TQEI_j = Σ_a QAEI_aj

Where Σ_ais the sum of all Energy Accounts for Settlement Period j and a ≠ SO (NETSO) Energy Account(s).

4: The Energy Imbalance Cashflow (CAEI_aj).shall be calculated for each Energy Account a, in Settlement Period j as follows:

If QAEI_aj > 0, then

CAEI_aj = -QAEI_aj * SSP_{j ,}

Otherwise,

CAEI_aj = -QAEI_aj * SBP_{j ,}

Where SSP_jis the System Sell Price and SBP_jis the System Buy Price for Settlement Period j and a ≠ SO (NETSO) Energy Account(s).

Thus, the price that applies to the Energy Imbalance Volume of a particular Energy Account shall depend on the net Energy Imbalance Position of that that Energy Account.

5: The Total System Energy Imbalance Cashflow, TCEI_jshall be calculated as:

TCEI_j = Σ_a CAEI_aj

Where a ≠ SO (NETSO) Energy Account(s)

This represents the total cashflow relating to settlement of energy imbalances in Settlement Period j.

Non-Functional Requirement:

Interfaces:

Issues:

5.12 SAA-F012: Validate Adjustment Data

Requirement ID:

SAA-F012

Status:

Title:

Validate Adjustment Data

BSC reference:

P78

Man/auto:

Automatic

Frequency:

On demand

Volumes:

Functional Requirements:

The SAA shall validate Adjustment Data, on receipt, to ensure that:

One of Energy SVA and Energy BVA must be zero;
One of System SVA and System BVA must be zero.

Where this is not the case, then the SAA will generate an exception to the NETSO (via the SAA-I017) detailing the reason for the exception.

Non-Functional Requirement:

This function only applies to BSAD data for Settlement Days after, and including the P78 effective date.

Interfaces:

SAA-I026, SAA-I017

5.13 SAA-F013: Calculate information imbalance charges

Requirement ID:

SAA-F013

Status:

Title:

Calculate information imbalance charges

BSC reference:

SAA SD 3.17.2, 3.20, 3.21, 3.22, 3.23, SAA BPM 3.13, CP596, P71

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirements:

A number of intermediate calculations are required to produce the information imbalance charges.

All calculation steps in this requirement are included here.

1: The Period Expected Meter Volume shall be calculated for each BM Unit in each Settlement Period.

(i) For each BM Unit, which is not a Baselined BM Unit or for which SVAA has not provided the Settlement Expected Volume, the Period Expected Metered Volume will be calculated as follows:

QME_ij = FPN_ij + QBS_ij

Where

FPN_ij is the Period FPN and

QBS_ij is the Period BM Unit Balancing Services Volume.

(ii) For each Baselined BM Unit and for which SVAA has provided a Settlement Expected Volume, the Period Expected Metered Volume will be calculated as follows:

QME_ij = SEV_ij + QBS_ij

Where

SEV_ij is the Period Settlement Expected Volume and

QBS_ij is the Period BM Unit Balancing Services Volume.

This is the volume of energy that a particular BM Unit is expected to produce or consume in Settlement Period j.

2: The Period Information Imbalance Volume (QII_ij) shall be calculated for each BM Unit in each Settlement Period as follows:

QII_ij = | QM_ij - QME_ij |

This is the modulus of the difference between the Period Metered Volume (QM_ij) and the Period Expected Metered Volume QME_ij

3: The Information Imbalance Charge (CII_ij) shall be calculated for each BM Unit in each Settlement Period. CII_ij is calculated by multiplying the Information Imbalance Volume, QII_ij, by the appropriate Information Imbalance Price, (IIP1_ijor IIP2_ij).

FPN flags apply to BM Units, the Lead Party will identify BM Units for which the flag will be set to ‘N’, the default value will be ‘Y’. This flag will be used to indicate whether a Party is required to submit an accurate FPN for a particular BM Unit or not. The Lead Party will set these FPN flags through the CRA Interfaces.

The Information Imbalance Charge will be calculated as follows:

If FPN Flag is set to ‘Y’ then

CII_ij = QII_ij * IIP1_ij

Else

CII_ij = QII_ij * IIP2_ij

Endif

where

IIP1_ij is the Information Imbalance Price 1 and

IIP2_ij is the Information Imbalance Price 2.

These are both half-hourly variables, SAA will be notified by BSCCo Ltd. Both variables will initially be set to zero for all Settlement Periods.

4: The Total System Information Imbalance Charge, TCII_j. shall be calculated for each settlement period as:

TCII_j = Σ_i CII_ij

Where Σ_i is the sum over all values of BM Unit i.

Non-Functional Requirement:

Interfaces:

Issues:

5.14 SAA-F014: Calculate non-delivery volumes

Requirement ID:

SAA-F014

Status:

Title:

Calculate non-delivery volumes

BSC reference:

SAA SD 3.38, 3.39, 3.40, 3.41, 3.42, SAA BPM 3.14, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirement:

Non-delivery arises when there is a BM Unit imbalance in the opposite direction to the volume of accepted Offers and Bids, integrated over the Settlement Period. The following diagram illustrates a non-delivered volume.

BM / RR

complex image of process

A large number of intermediate calculations are required to produce the non delivery volumes. All calculation steps in this requirement are included here.

1: The Period BM Unit Non-Delivered Offer Volume (QNDO_ij) shall be calculated for each BM Unit i in each Settlement Period j by processing the Period Expected Metered Volume (QME_ij), Period Meter Volume (QM_ij), Period Accepted Offer Volume (ΣⁿQAOⁿ_ij) , and RR Accepted Offer Volumes (RRAOⁿ_ij), as follows:

QNDO_ij = Min{Max{QME_ij – QM_ij, 0}, ΣⁿQAOⁿ_ij}+ Σⁿ RRAOⁿ_ij)}

where Σⁿ, in relation to QAOⁿ_ij, represents the sum over all Bid-Offer Pair Numbers for the Accepted Offer Volumes and Σⁿ, in relation to RRAOⁿ_ij, represents the sum over all Bid-Offer Pair Numbers for the RR Accepted Offer Volumes, for the BM Unit.

2: The Period BM Unit Non-Delivered Bid Volume (QNDB_ij) shall be calculated for each BM Unit I in each Settlement Period j by processing the Expected Period Meter Volume (QME_ij), Period Meter Volume (QM_ij), and Period Accepted Bid Volume (ΣⁿQABⁿ_ij) , and RR Accepted Bid Volumes (RRABⁿ_ij), as follows:

QNDB_ij = Max {Min{QME_ij - QM_ij,0}, ΣⁿQABⁿ_ij }+ Σⁿ RRABⁿ_ij)

where Σⁿ, in relation to QABⁿ_ij, represents the sum over all Bid-Offer Pair Numbers for the Accepted Bid Volumes and Σⁿ, in relation to RRABⁿ_ij, represents the sum over all Bid-Offer Pair Numbers for the RR Accepted Bid Volumes, for the BM Unit.

Note that Bid volumes are negative, and so is the non-delivered Bid volume by this definition.

3: The Offer Non-Delivery Volume (QNDOⁿ_ij) shall be calculated as follows.

If QNDOij > 0, then the Period BM Unit Non-Delivered Offer Volume is apportioned across all accepted Offers (AOⁿ_ij), (being Accepted Offer Volumes (QAOⁿ_ij) and for upward RR Activations within the Settlement Period the associated Deemed Standard Product Offer Volume (DSPO^J_ij) and the Replacement Reserve Instructed Offer Deviation Volume (IOD_ij)), to determine values of Offer Non-Delivery Volume.

In each Settlement Period, the set of all accepted Offers (i.e. Offers for which AOⁿ_ij >0) is considered. This set of Offers is then ranked from highest price to lowest price. The Non-Delivery Order Number u is used for this purpose. The Offer with the highest price is allocated a Non-Delivery Order Number of u=1, the next highest priced Offer is allocated a Non-Delivery Order Number u=2 and so on until all Offers in the Settlement Period is allocated a Non-Delivery Order Number.

The set of Offers {AOⁿ¹_ij, AOⁿ²_ij, …….. AO^nu_ij} is therefore the ranked set of Offers.

The Offer Non-Delivery Volume is allocated to the highest priced Offers first. The apportionment continues until the Period BM Unit Non-Delivered Offer Volume is fully apportioned or all available Offer Volumes have been used up.

Thus, the Offer Non Delivery Volume for Offer n, is:

QNDOⁿ_ij = Min(AO^nu_ij,RQNDO^u-1_ij)

Where RQNDO^u-1_ij is the Remaining Period BM Unit Non-Delivered Offer Volume determined as:

RQNDO^u_ij = RQNDO^u-1_ij - QNDO^nu-1_ij

and RQNDO⁰_ij = QNDO_ij,

and QNDOⁿ⁰_ij = 0

4: The Bid Non-Delivery Volume (QNDBⁿ_ij) shall be calculated as follows

If QNDBij < 0, then the Period BM Unit Non-Delivered Bid Volume is apportioned across accepted Bids (ABⁿ_ij), (being Accepted Bids Volumes (QABⁿ_ij) and for downward RR Activations within the Settlement Period the associated Deemed Standard Product Bid Volume (DSPB^J_ij) and the Replacement Reserve Instructed Bid Deviation Volume (IBD_ij)), to determine values of Bid Non-Delivery Volume.

In each Settlement Period, the set of all accepted Bids (i.e. Bids for which ABⁿ_ij <0) is considered. This set of Bids is then ranked from lowest price to highest price. The Non-Delivery Order Number, u is used for this purpose. The Bid with the lowest price is allocated a Non-Delivery Order Number of u=1, the next lowest priced Offer is allocated a Non-Delivery Order Number u=2 and so on until all Bids in the Settlement Period are allocated a Non-Delivery Order Number.

The set of Bids {ABⁿ¹_ij, ABⁿ²_ij, …….. AB^nu_ij, } is therefore the ranked set of Bids.

The Bid Non-Delivery Volume is allocated to the lowest priced Bids first. The apportionment continues until the Period BM Unit Non-Delivered Bid Volume is fully apportioned or all available Bid Volumes have been used up.

Thus, the Bid Non Delivery Volume for Bid n, is:

QNDBⁿ_ij = Max(AB^nu_ij,RQNDB^u-1_ij)

Where RQNDB^u-1_ij is the Remaining Period BM Unit Non-Delivered Bid Volume determined as:

RQNDB^u_ij = RQNDB^u-1_ij - QNDB^nu-1_ij

and RQNDB⁰_ij = QNDB_ij

and QNDB^no_jj= 0

Non-Functional Requirement:

Interfaces:

Issues:

5.15 SAA-F015: Calculate non-delivery charges

Requirement ID:

SAA-F015

Status:

Title:

Calculate non-delivery charges

BSC reference:

SAA SD 3.43, 3.44, 3.45, 3.46, SAA BPM 3.14, SAA WK1 Action 30, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirement:

A number of intermediate calculations are required to produce the non delivery charges. All calculation steps in this requirement are included here.

1: The Non-Delivered Offer Charge (CNDOⁿ_ij) shall be calculated for the non-delivery of Offer n in Settlement Period j from BM Unit i, as follows:

CNDOⁿ_ij = QNDOⁿ_ij * Max {(NDPOⁿ_ij – SBP_j), 0}* TLM_ij

Where SBP_j is the System Buy Price, NDPOⁿ_ij is the Offer Price and TLM_ij is the Transmission Loss Multiplier for that BM Unit and Settlement Period.

NDPOⁿ_ijis the Non-Delivered Offer Price for each Accepted Offer allocated a Non-Delivery Volume and will vary depending on the following:

complex image of process

Where RRAP_J is the Replacement Reserve Activation Price associated to the Quarter Hour RR Activation.

2:The Non-Delivered Bid Charge (CNDBⁿ_ij) shall be calculated for the non-delivery of Bid n in Settlement Period j from BM Unit i, as follows:

CNDBⁿ_ij = QNDBⁿ_ij * Min{(NDPBⁿ_ij – SSP_j), 0} * TLM_ij

Where SSP_j is the System Sell Price, NDPBⁿ_ij is the Bid Price and TLM_ij is the Transmission Loss Multiplier for that BM Unit and Settlement Period.

NDPBⁿ_ijis the Non-Delivered Bid Price for each Accepted Bid allocated a Non-Delivery Volume and will vary depending on the following:

${N D P B}_{i j}^{n} = \{\begin{matrix} {P B}_{i j}^{n}, f o r A c c e p t e d B i d v o l u m e s \\ {R R A P}_{J}, f o r u p w a r d R R A c t i v a t i o n s \\ {B E D P}_{J}, f o r R R I n s t r u c t e d B i d D e v i a t i o n V o l u m e s ({I B D}_{i j}) \end{matrix}$

Where RRAP_J is the Replacement Reserve Activation Price associated to the Quarter Hour RR Activation and BEDP_ijis the Balancing Energy Deviation Price (BEDP_j) and shall be equal to zero.

Note that this is a product of two negative numbers that results in a positive charge (or zero).

3: The BM Unit Period Non-Delivery Charge (CND_ij).shall be calculated for the non-delivery of Bids and Offers in Settlement Period j from BM Unit i, as follows:

CND_ij = Σⁿ (CNDOⁿ_ij + CNDBⁿ_ij)

4: The Total System Non-Delivery Charge (TCND_j) shall be calculated for the non-delivery of Bids and Offers in Settlement Period j, summed across all BM Units, as follows:

TCND_j = Σ_i CND_ij

Non-Functional Requirement:

Interfaces:

Issues:

5.16 SAA-F016: Calculate system operator BM cashflow

Requirement ID: SAA-F016	Status: M	Title: Calculate system operator BM cashflow	BSC reference: SAA SD 3.48, SAA BPM 3.15, CP632, P344
Man/auto: Automatic	Frequency: Once, on each settlement run.	Volumes:
Functional Requirement:
The System Operator cashflow (CSO_j) shall be calculated by subtracting the Total System Non-Delivery Charge (TCND_j) from the Total System BM Cashflow (TCBM_j) for each Settlement Period. Specifically: CSO_j = (TCBM_j+ TCRR_j) – TCND_j
Non-Functional Requirement:

Interfaces:

Issues:

5.17 SAA-F017: Calculate residual cashflows

Requirement ID:

SAA-F017

Status:

Title:

Calculate residual cashflows

BSC reference:

SAA SD 3.49.1, 3.50, 3.51, 3.52, SAA BPM 3.16, CR016, CP632, CP532, CP1222, P285, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirement:

A number of intermediate calculations are required to produce the residual cashflows. All calculation steps in this requirement are included here.

1: The Total System Residual Cashflow (TRC_j) shall be calculated as follows:

TRC_j = TCII_j + CSO_j + TCND_j – TCBM_j- TCRR_j + TCEI_j

This represents any net difference between total payments and receipts to and from BSC Parties for a particular Settlement Period. It therefore considers the Total System Information Imbalance Charge (TCII_j), Total System Non-Delivery Charge (TCND_j), System Operator Cashflow (CSO_j), Total System BM Cashflow (TCBM_j) and Total System Energy Imbalance Cashflow (TCEI_j).

2: The Residual Cashflow Reallocation Proportion (RCRP_aj) to be allocated to each Energy Account (excluding the SO’s (NETSO’s) account) in each Settlement Period shall be calculated as follows:

RCRP_aj = {Σ⁺_(non-I) (QCE_aij) + Σ^-_(non-I) (-QCE_aij )} / Σ_a{Σ⁺_(non-I) (QCE_aij) + Σ^-_(non-I) (–QCE_aij)}

where Σ⁺_(non-I) is, for each Account a in Settlement Period j, the sum over all BM Units other than Interconnector BM Units that are in delivering Trading Units (i.e. every Trading Unit t where Σ_i_∈_t QM_ij >= 0) , and

Σ^-_(non-I) is, for each Account a in Settlement Period j, the sum over all BM Units other than Interconnector BM Units that are in offtaking Trading Units (i.e. every Trading Unit t where Σ_i_∈_t QM_ij < 0) is a Consumption Account.

Note that Σ_a RCRP_aj should be equal to one.

This represents the proportion of the Credited Energy Volume attributed to each Energy Account a for all BM Units i in each Settlement Period j divided by the Total Credited Energy across all Energy Accounts and all BM Units in that Settlement Period.

3: The Residual Cashflow Reallocation Denominator (RCRD_j) in each Settlement Period shall be defined as the denominator in the expression for RCRP_aj above.

4: The Residual Cashflow Reallocation Cashflow (RCRC_aj.) shall be calculated by multiplying the Residual Cashflow Reallocation Proportion with the Total System Residual Cashflow, as follows:

RCRC_aj = RCRP_aj * TRC_j

This represents the proportion of the Total System Residual Cashflow allocated to the Energy Account a.

Non-Functional Requirement:

Interfaces:

Issues:

5.18 SAA-F018: Allocate BSCCo Ltd Costs (Redundant)

Requirement ID: SAA-F018	Status: M	Title: Allocate BSCCo Ltd Costs	BSC reference: SAA SD 3.47, SAA BPM 3.16, CR016, CR028
Man/auto: Automatic	Frequency: Once, on each settlement run.	Volumes:
Functional Requirement:
A number of intermediate calculations are required to produce the allocation of BSCCo Ltd costs. All calculation steps in this requirement are included here.
1: The Balancing and Settlement Code Company (BSCCo Ltd) Costs shall be notified to the SAA by BSCCo Ltd.
2: A proportion of these BSC Co costs be charged out pro-rata as explained below, and the remaining proportion be charged out pro-rata on the modulus of all notified Energy Contract volumes (ECQ_zbaj). The NETSO’s (SO) Energy Contract Volumes and Credited Energy Volumes will be excluded from these calculations. (i) Σ⁺⁽QCE_aij,) where Σ⁺ is, for each Account a in Settlement Period j, the sum over all BM Units i that are in delivering Trading Units (i.e. each Trading Unit t where Σ_i_∈_t QM_ij >= 0); and (ii) Σ^-(-QCE_aij), where Σ^- is, for each Account a in Settlement Period j, the sum over all BM Units i that are in offtaking Trading Units (i.e. each Trading Unit t where Σ_i_∈_t QM_ij < 0)
3: BSCCo Ltd costs shall be recovered monthly, based on a cost forecast, and will reconcile this at year end to total actual costs.
Non-Functional Requirement:

Interfaces:

Issues:

5.19 SAA-F019: Aggregate charges and payments

Requirement ID:

SAA-F019

Status:

Title:

Aggregate charges and payments

BSC reference:

SAA 3.53, SAA BPM 3.17, CP632, P344

Man/auto:

Automatic

Frequency:

Once, on each settlement run.

Volumes:

Functional Requirement:

A number of intermediate calculations are required to produce the aggregated charges and payments. All calculation steps in this requirement are included here.

1: All separate charges and payments shall be aggregated by BSC Party, Settlement Day and charge type, including the following:

Balancing Mechanism Cashflows;

Replacement Reserve Cashflows;

Replacement Reserve Instruction Deviation Cashflow;

Residual Cashflow Reallocation Cashflows;

Non-Delivery Charges;

Information Imbalance Charges;

Energy Imbalance Cashflows;

System Operator BM Cashflow;

BSCCo Ltd Charges.

NB: These nine individual charges are calculated separately for each individual BSC Party for each Settlement Day.

2: In addition, the Total Account Charge/Payment shall be calculated by aggregating all the net cashflows for each charge type calculated above to produce a net charge/payment by BSC Party per Settlement Day

(This shall be calculated for reporting purposes only.)

Non-Functional Requirement:

Interfaces:

Issues:

5.20 SAA-F020: Validate Market Index Data

Requirement ID:

SAA-F020

Status:

Title:

Validate Market Index Data

BSC reference:

P78

Man/auto:

Automatic

Frequency:

On demand

Volumes:

Functional Requirement:

The SAA shall validate Market Index Data, on receipt, to ensure that the Market Index Volume is either zero, or it equals or exceeds the Liquidity Threshold for the relevant Market Index Data Provider, Settlement Day, and Settlement Period. If a non-zero Market Index Volume is below the defined threshold, then the SAA will default the invalid Market Index Volume and its associated Price to zero, for that Settlement Period.

The occurrence of below threshold, non-zero Market Index Volume is recorded by the SAA for the purposes of performance reporting.

Unless a specific clock change day Liquidity Threshold has been submitted, then, where an Liquidity Threshold is defined for a range of days that spans a ‘long’ or ‘short’ day, the following rules will be applied:

For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST):

Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day data;
Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data;
Settlement Periods 3 and 4 of the ‘normal’ day data are not used on a short day.

For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):

Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day data;
Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day data;
Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data.

Non-Functional Requirement:

Interfaces:

SAA-I030

Issues:

5.21 SAA-F021: Manage settlement disputes

Requirement ID: SAA-F021	Status: M	Title: Manage settlement disputes	BSC reference: SAA SD 5.1, SAA BPM 3.18
Man/auto: Manual & auto	Frequency: On demand.	Volumes:
Functional Requirement:
1: The SAA shall perform settlement runs in support of disputes, on instruction from BSCCo Ltd.
2: It shall be possible for SAA system operators to create new data or amend existing data for input to a dispute settlement run.
3: The dispute run shall invoke the required calculations for a specific Settlement Period to be re-run.
4: The output from any dispute run, shall be forwarded to the Funds Administration Agent for processing and funds transfer. The SAA provides only the new calculated values to the FAA; the SAA is not required to provide the difference between the new values and the original values.
5: Where the FPN is disputed, an Amended FPN shall be determined. The dispute run (and any future runs pertaining to the disputed Settlement Period) shall be performed against the amended FPN.
Non-Functional Requirement:
A Dispute may be 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 raise a dispute on behalf of BSC Parties if errors in calculations or data are detected or suspected. The Settlement Administration Agent shall be able to receive individual Dispute notifications from BSC Parties and shall take appropriate action to process the dispute. All dispute notifications shall be logged. The Settlement Administration Agent shall, when requested by the Customer, undertake evaluation, or analysis if requested, of a dispute to determine the facts and its materiality. The Settlement Administration Agent shall, when requested by the Balancing and Settlement Code Company or Panel submit written evidence concerning a particular Dispute, to the Balancing and Settlement Code Panel. The Settlement Administration Agent shall carry out actions in support of disputes within timescales agreed with BSCCo Ltd.
Interfaces:
The interface requirements SAA-I012 and SAA-I018 describe the Dispute Notifications received by SAA from external parties, and the Dispute Reports produced by the SAA.
Issues:

5.22 SAA-F022: Provide settlement reports

Requirement ID: SAA-F022	Status: M	Title: Provide settlement reports	BSC reference: SAA SD, SAA BPM 3.19
Man/auto: Manual & auto	Frequency: Once following each settlement run & on demand.	Volumes:
Functional Requirement:
1: The SAA shall produce all settlement reports in accordance with the Settlement Calendar, listed as external interfaces in section 6.
2: Reports shall be provided to all BSC Parties for general market information, and only to authorised BSC Parties where the information is party specific. The reporting requirements and access rights of each BSC party will be maintained to ensure that reports are only distributed to interested and authorised BSC parties.
3: The SAA shall support an interface to enable changes to reporting requirements and access rights to be administered.
4: Ad-hoc reports shall be supplied to the Customer or BSC Parties, as requested.
5. The SAA shall send the SVAA an aggregate report of all Quarter Hour RR Activation Data in respect of each Quarter Hour period within each Replacement Reserve Auction Period for such Settlement Day.
Non-Functional Requirement:

Interfaces:
The data requirements for settlement reports are described in SAA-I014. The physical format of externally distributed files is described in the NETA Central Systems Interface Specification.
Issues:

5.23 SAA-F023: Process Market Index Data Provider Liquidity Thresholds

Requirement ID:

SAA-F023

Status:

Title:

Process Market Index Data Provider Liquidity Thresholds

BSC reference:

P78

Man/auto:

Manual/ Automatic

Frequency:

On demand

Volumes:

Functional Requirement:

The SAA shall carry out the following validation on MIDP Liquidity Thresholds:

(a) Where the Action is ‘Insert’, then the effective date range of the Liquidity Threshold record must not overlap with any existing record for that MIDP;

(b) Where the Action is ‘Update’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP;

(c) Where the Action is ‘Delete’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP.

In cases where a change in MIDP Liquidity Threshold would be retrospective, the SAA will confirm correctness with BSCCo before applying the update.

If a retrospective change to MIDP Liquidity Thresholds requires Market Index Data to be resubmitted (in order to be revalidated), then a check will be made by SAA to confirm that this does occur. BSCCo will communicate the details of what files will be resubmitted, from which Market Index Data Providers, along with details of the timeframe in which this should occur. Where files are not re-submitted within the expected timeframe, then this will be escalated to BSCCo.

Changes to Liquidity Thresholds, retrospective or otherwise, will not be applied to existing Market Index Data.

Where a Liquidity Threshold record fails validation then it is rejected, and the details of the rejection are reported back to BSCCo.

After applying an update, or set of updates, for a given MIDP, the Liquidity Threshold data for current and future dates is reported back to BSCCo, using the SAA-I032 flow.

Non-Functional Requirement:

Interfaces:

SAA-I031, SAA-I032

Issues:

5.24 SAA-F024: Daily Check for Missing Settlement Calculation Data Flows

Requirement ID:

SAA-F024

Status:

N/a

Title:

Daily Check for Missing Settlement Calculation Data Flows

BSC reference:

SAA SD 2.1.1, CP639, P71, P344

Man/auto:

Manual & Automatic

Frequency:

Daily (not related to specific run types)

Volumes:

Functional Requirement:

The SAA shall validate certain incoming data flows to check for potential out of sequence files, which would indicate missing Settlement Calculation data. This check will be carried out for the following types of data:

Bid Offer Acceptance data;
BM Unit Applicable Balancing Services Volume data
Replacement Reserve Auction Result Data.

The SAA will report a failure of the above check to BSCCo through manual flow SAA-I027 and await further instruction. BSCCo shall immediately respond to the SAA through SAA-I028 with an indication as to whether to proceed with the settlement run, or whether to suspend the run pending further instruction. Instruction on how to proceed shall be received by SAA from BSCCo through SAA-I029.Missing data should be provided within 2 days, otherwise the matter will be escalated.

Non Functional Requirement:

Interfaces:

See SAA-I027, SAA-I028, SAA-I029

Issues:

5.25 SAA-F025: Process Withdrawing Party Settlement Details

Requirement ID:

SAA-F025

Status:

Mandatory

Title:

Process Withdrawing Party Settlement Details

BSC reference:

CP974

Man/auto:

Manual

Frequency:

On request

Volumes:

Low

Functional Requirement:

The SAA shall provide the information specified by Interface Requirement SAA-I037 to CRA, on request.

Settlement details shall be matched to the request by means of the participant name and / or participant id registered in SAA.

Non Functional Requirement:

Interfaces:

SAA-I037: Issue Withdrawing Party Settlement Details.

5.26 SAA-F026: Process Emergency Acceptance Data

Requirement ID:

SAA-F026

Status:

Mandatory

Title:

Process Emergency Acceptance Data

BSC reference:

P172, P448

Man/auto:

Manual

Frequency:

On request

Volumes:

Low

Functional Requirement:

The SAA shall receive from the NETSO requests for data changes from time to time via the manual interface SAA-I033, which is then agreed between the SAA and BSCCo via the manual interfaces SAA-I034 and SAA-I035, and then reported to the NETSO via the manual interface SAA-I036.

BSCCo may also send to the SAA requests for data change on behalf of the Network Gas Supply Emergency Settlement Validation Committee, where that Committee agrees changes to FPNs, Bid-Offer Data or Acceptance Data relating to a Network Gas Supply Emergency Acceptance.

These requests may relate to Emergency Instructions, and if so, will be clearly marked ‘EMERGENCY INSTRUCTION’. In addition, where the Emergency Instruction is to be treated as an ‘Excluded Emergency Acceptance’, the request will also include the words ‘EXCLUDED EMERGENCY ACCEPTANCE’. Where it is not to be treated as an ‘Excluded Emergency Acceptance’ the words ‘EMERGENCY ACCEPTANCE’ will be included in the request.

The SAA shall enter this data manually and perform the next Settlement Run (usually the II Run).

If the Instruction has been determined by the NETSO to be treated as an Excluded Emergency Acceptance, the following steps should also be performed:

The SAA shall receive recalculated Energy Imbalance Prices to be achieved in the next run from BSCCo via manual interface SAA-I038.

SAA shall calculate and apply any adjustments required:

Adjusted BPA_j = existing BPA_j + BPA adjustment_j

Adjusted SPA_j = existing SPA_j + SPA adjustment_j

SAA shall carry out an additional settlement ‘dry run’ and send confirmation to BSCCo, via manual interface SAA-I039, that the adjustments to BSAD have given the required Energy Imbalance Prices. The SAA will liaise with BSCCo until such time as it is able to confirm that the adjustments to BSAD have generated the required Energy Imbalance Prices. The 'dry run' will only be carried out once the associated CDCA Aggregation Run has been completed. In order to allow sufficient lead time between the 'dry run' and the 'live run' the SAA will not wait for receipt of the relevant data from SVAA (via SAA-I007) but instead use SVAA data from the most recent Settlement Run for the purposes of carrying out the 'dry run'.

Where such a request relates to a Network Gas Supply Emergency Acceptance, the first line of the instruction should contain the words ‘NETWORK GAS SUPPLY EMERGENCY ACCEPTANCE’.

The SAA will not conduct the actual live Settlement Run without prior authorisation to do so from BSCCo via manual interface SAA-I040.

The SAA will check and confirm that the amended BSAD has not been overwritten by any other subsequently submitted BSAD data, and that, consequently, the amended BSAD data is used in the live Settlement Run.

Note: Subsequent adjustments for later runs will be processed by iterations of the above manual processing.

Non Functional Requirement:

Interfaces:

SAA-I033: Receive Request for Data Change.

SAA-I034: Report Recommended Data Change

SAA-I035: Receive Instruction for Data Change

SAA-I036: Report Confirmation of Data Change

SAA-I038: Receive Excluded Emergency Acceptance Pricing Information

SAA-I039: Send Excluded Emergency Acceptance Dry Run Results.

SAA-I040: Receive Confirmation of Additional Run Results.

5.27 SAA-F027: Calculate BM Unit Chargeable Demand for EMR

Requirement ID:

SAA- F027

Status:

Mandatory

Title:

Calculate BM Unit Chargeable Demand

BSC reference:

EMR

Man/auto:

Automatic

Frequency:

Once, on each Settlement Run

Volumes:

Functional Requirement:

The SAA shall determine the TLM-Adjusted BM Unit Gross Demand for registered BM Units, for use by a CFD Settlement Services Provider.

For Supplier BM Units the TLM-Adjusted BM Unit Gross Demand is defined as:

TLM-Adjusted BM Unit Gross Demand = – TLM_ij * BM Unit SVA Gross Demand

where BM Unit SVA Gross Demand is the value received from the SVAA for that BM Unit and Settlement Period, and will be deemed to be zero if no such value has been received.

For BM Units other than Supplier BM Units and Interconnector BM Units) the TLM-Adjusted BM Unit Gross Demand is defined as:

TLM-Adjusted BM Unit Gross Demand = TLM_ij * min (QM_ij, 0)

For all other BM Units, TLM-Adjusted BM Unit Gross Demand is not defined (and the SAA will not provide a value for that BM Unit and Settlement Period to a the EMR Settlement Services Provider).
For Settlement Dates before 02 November 2023, the SAA shall report TLM-Adjusted BM Unit Gross Demand values to the EMR Settlement Services Provider for each relevant BM Unit and Settlement Period in the Settlement Day via SAA-I042.

Determination of TLM-Adjusted BM Unit Chargeable Demand for inclusion in the SAA-I042
1. For Settlement Dates from 02 November 2023 the SAA shall determine TLM-Adjusted BM Unit Chargeable Demand for use by the EMR Settlement Services Provider. TLM-Adjusted BM Unit Chargeable Demand will replace TLM-Adjusted BM Unit Gross Demand in the SAA-I042 report.
2. For each Base and Additional Supplier BM Unit for which SVAA has provided Supplier BM Unit Period Non-Chargeable Demand Volume, the TLM-Adjusted BM Unit Chargeable Demand will be calculated as follows:

TLM-Adjusted BM Unit Non-Chargeable Demand

= min(0, (-1*BM Unit Period Non-Chargeable Demand * TLM_ij))

where BM Unit Period Non-Chargeable Demand² is the value received from the SVAA in the SAA-I057 for that BM Unit and Settlement Period, and will be deemed to be zero if no such value has been received for a SVA BM Unit.

TLM-Adjusted BM Unit Chargeable demand =TLM-Adjusted BM Unit Gross Demand –TLM-Adjusted BM Unit Non-Chargeable Demand.

For P395 qualifying Directly-connected and Embedded BM Units, TLM-Adjusted BM Unit Chargeable demand will be equal to 0. Elexon Kinnect (as the CRA) will notify the SAA of all CVA BM Units included in EMR CVA BM Unit Declarations (i.e. of P395 qualifying CVA BM Units).
For P395 non-qualifying Directly-connected and Embedded BM Units, TLM-Adjusted BM Unit Chargeable demand will be equal to TLM-Adjusted BM Unit Gross Demand.
The SAA shall report TLM-Adjusted Chargeable Demand values to the EMR Settlement Services Provider for each relevant BM Unit and Settlement Period in the Settlement Date via the SAA-I042.

Determination of Aggregated TLM-Adjusted Non-Chargeable Demand for the SAA-I058 Report
1. For Settlement Dates from 02 November 2023, the SAA shall determine Aggregated TLM-Adjusted Non-Chargeable Demand, for BM Units, for publication on the Elexon Portal where it will be available for interested parties to download.
2. SAA will calculate the BM Unit TLM-adjusted Unit Non-Chargeable Demand for each Settlement Run Period for P395 qualifying Directly-connected and Embedded BM Units only:

BM Unit TLM-adjusted Unit Non-Chargeable Demand = -1 * BM Unit TLM-adjusted Unit Gross Demand

SAA will aggregate TLM-Adjusted BM Unit Non-Chargeable Demand for P395 qualifying Embedded CVA BM Units and Base and Additional Supplier BM Unit, by Settlement Date, Settlement Run Type, GSP group and for each individual Settlement Period to calculate GSP Group Aggregated SVA and Embedded CVA TLM-Adjusted Non-Chargeable Demand.
SAA will aggregate values of TLM-Adjusted Non-Chargeable Demandfor Directly Connected CVA BM Units by Settlement Date, Settlement Run Type and for each individual Settlement Period to calculate Aggregated Directly Connected CVA TLM-Adjusted Non-Chargeable Demand.
The SAA will produce the ‘Aggregated TLM-Adjusted Non-Chargeable Demand’ report for each Run Type on the 6th working day of each month. The report will include TLM-Adjusted Non-Chargeable Demand calculated on each calendar day during the preceding month.

For example, the ‘Aggregated TLM-Adjusted Non-Chargeable Demand’ report for the II Settlement Run produced in January 2024 would contain the following data:

Calendar date of SAA Settlement run	Settlement Date(s)
20231201	20231124	20231125	20231126
20231204	20231127
20231205	20231128
20231206	20231129
20231207	20231130
20231208	20231201	20231202	20231203
20231211	20231204
20231212	20231205
20231213	20231206
20231214	20231207
20231215	20231208	20231209	20231210
20231218	20231211
20231219	20231212
20231220	20231213
20231221	20231214
20231222	20231215	20231216	20231217
20231227	20231218
20231228	20231219
20231229	20231220

Non Functional Requirement:

Interfaces:

SAA-I041: BM Unit SVA Gross Demand Data File

SAA-I042: BM Unit Chargeable Demand Report

SAA-I057: Supplier BM Unit Period Non-Chargeable Demand Data File

SAA-I058: Aggregated TLM-Adjusted Non-Chargeable Demand

5.28 SAA-F029: Calculate Trading Unit Data

Requirement ID:

SAA-F029

Status:

Mandatory

Title:

Calculate Trading Unit Data

BSC reference:

P321

Man/auto:

Automatic

Frequency:

Once, on each Settlement Run

Volumes:

Functional Requirement:

The SAA shall determine Trading Unit Data for each Trading Unit for each Settlement Period at each Settlement Run. This data shall comprise of the Trading Unit Export Volume, the Trading Unit Import Volume and the Trading Unit Delivery Mode.

The Trading Unit Export Volume shall be determined as:

QTUE_rj = Σ_(non-S) max(QM_ij, 0) + Σ_N(AE) | CORC_iNj |

where:

Σ_(non-S) represents the sum over all BM Units other than Supplier BM Units belonging to the Trading Unit; and

Σ_N(AE) represents the sum over all Consumption Component Classes that are associated with active export over all Supplier BM Units belonging to the Trading Unit.

The Trading Unit Import Volume shall be determined as:

QTUI_rj = Σ_(non-S)min(QM_ij, 0) – Σ_N(AI) | CORC_iNj |

where:

Σ_(non-S) represents the sum over all BM Units other than Supplier BM Units belonging to the Trading Unit; and

Σ_N(AI) represents the sum over all Consumption Component Classes that are associated with active import over all Supplier BM Units belonging to the Trading Unit.

The Trading Unit Delivery Mode shall be determined as

"Delivering" if QTUE_rj + QTUI_rj > 0; or

"Offtaking" if QTUE_rj + QTUI_rj ≤ 0.

The SAA shall report Trading Unit Data for each Trading Unit for each Settlement Period for each Settlement Run to the BMRA via SAA-I049.

Non Functional Requirement:

Interfaces:

SAA-I049: Trading Unit Data

5.29 SAA-F030: Build RR Schedule

Requirement ID:

SAA-F030

Status:

Title:

Build RR Schedule

BSC reference:

P344

Man/auto:

Automatic

Frequency:

Once on each settlement run.

Volumes:

Functional Requirements:

The RR Schedule defines the volume of energy that a BM Unit must deliver in each Settlement Period, in order to be treated in Settlement as having fully delivered its RR Activations. When a BM Unit does not deliver this volume of energy, its Lead Party may be liable to Energy Imbalance Charges and Non-Delivery Charges.

The RR Schedule is a piecewise linear MW profile, made up of a number of straight line segments each defined by- From Time and To Time (UTC times on a minute boundary)

- From Level and To Level (MW values, to one decimal place)

The RR Schedule for a given hour will start no earlier than H-25, but may continue for hours or days after the end of the Auction Period.

1. Identify the quarter hours with non-zero activations, quarter hour boundaries and quarter hours where the activation for the previous period is different to that of the current period.

2. Derive the RR Baseline that defines the level from which an RR activation needs to be delivered. The RR Baseline is defined as:

Duration	Value	Notes
H-30 to H + 60	FPN + BOAs + RRIs	For BOAs and RR Instructions issued before Gate closure for that Auction period.
After H+60	Final MW level in the last RR Instruction relating to the hour.	If no such instruction exists, it is the value of FPN in the settlement period ending at H+60.

H-30 means 30 minutes before the start of the hour for that Auction Period and H+60 means 60 minutes after the start of the hour for that Auction Period

3. Determine the profile P(t) to which the ramp must be added

$P (t) = \{\begin{matrix} R R B a s e l i n e (f o r t i m e s t b e f o r e o r a f t e r t h e a u c t i o n h o u r) \\ F P N + R R A (f o r t i m e s w i t h i n t h e a u c t i o n h o u r) \end{matrix}$ (1)

Special Cases

Discontinuity of the RR Baseline

When there is a discontinuity on the RR Baseline at the border of a Quarter Hour with a non-zero RR Activation, there are two potential start points for the ramp as shown in Figure 5 below.

complex image of process

In this case, the ramp can start from two different coordinates (14:15, 240MW) and (14:15, 500 MW). The process to test feasible ramps is as follows:

For a time t within the Auction Period, the value of the profile at time t is taken as being the limit as one approaches t from the direction of the centre of the Quarter Hour block to which the candidate ramp relates; and
For a time t outside the Auction Period, the Methodology will try both options, starting with the limit as one approaches time t from the direction of the Auction Period.

4. Identify the Run Up Rates (RURs) and the Run Down Rates (RDRs) needed to build the Ramps (R) in the RR Schedule. The rates used are those that were in effect at Gate closure for the auction period and fully deliver the RR Activation for the 5 Central minutes of each quarter hour for an Auction Period (H to H+60).

The Dynamics of RURs and RDRs vary depending on whether a BM Unit is Exporting or Importing. Additionally, the RURs and RDRs for a BM Unit will comprise of up to three Run-Up Rates expressed in MW/minute and associated Elbows (BP) expressed in MW. This means that the starting point of a ramp will affect the RUR and RDR that SAA will use.

complex image of process

RURE = Run-Up Rate Export	RDRE = Run-Down Rate Export		BP are the elbow points	R1, R2 and R3 are the ramp rates
RURI = Run-Up Rate Import	RDRI = Run-Down Rate Import		BP are the elbow points	R1, R2 and R3 are the ramp rates

5. Build RR Schedule Ramp ≤ 10 minutes

For each Quarter Hour with boundary times t (where t = H, H+15, H+30, H+45 and H+60), SAA shall test whether it is possible to find a ramp of ten minutes or less. The ramps respect the declared Run-Up and Run-Down Rates and associated elbow points; and deliver the RR Activation in full for the Central 5 minutes of each quarter hour.

Assuming a notation of t-x and t-y, where x, and y are number of minutes before and after t, the following process shall be followed to find a ramp that meets the RR Activation for the central 5 minutes of the quarter hour. Test:

Ramp from t–1 to t; or failing that t–1 to t+1
Ramp from t–2 to t+1; or failing that t–2 to t+2
Ramp from t–3 to t+2; or failing that t–3 to t+3
Ramp from t–4 to t+3; or failing that t–4 to t+4
Ramp from t–5 to t+4; or failing that t–5 to t+5

In order to identify the start times (t₀) and end times (t₁) of a ramp that fully deliver an RR Activation, the SAA shall use linear interpolation where (x,y) coordinates in a graph represent (time, MW);

Given the equation for a line is defined by:

$y_{1} = y_{0} + m (x_{1} - x_{0})$ (2)

Where

m = slope	m < 0 for run down rates	y₀ > y₁
m = slope	m > 0 for run up rates	y₀ < y₁

The (time, MW) coordinates will define the RR Schedule Product Point Variables (qRRS^k_ijt) and shall be recorded after the successful construction of each ramp.

6. Build ramps of 30 minutes or less

When a ramp of less than 10 minutes is not feasible and the candidate ramp is for the first non- zero RRA for the auction period; then SAA shall attempt to build a ramp of a maximum duration of 30 minutes which ends 5 minutes after the start of the hour. Following a similar logic to the previous step, the candidates to be tested are:

Ramp from t–6 to t+5
Ramp from t–7 to t+5
…
Ramp from t–25 to t+5

7. Draw a straight line

If no ramp is found following the previous steps, provided the ramp is not a final ramp, then draw a straight line from the starting coordinates to the coordinates that reach the RR Activation level on the 5^th minute of the quarter hour.

8. Create a final ramp

SAA shall schedule ramps that comply with the following:

Start five minutes before the end of the Quarter Hour boundary;
Comply with the BM Unit’s declared Run-Up or Run-Down Rates; and
Have no specific limit on their duration.

Initially SAA should check ramps that are symmetric to the ramp that was built to reach the RR Activation. When this is not possible because the ramp is a slow ramp, then the final ramp should converge to the RR Baseline defined for times after the end of RR Auction Period (i.e. H+60), whose level is defined by:

The final MW level in the last RR Instruction issued by the NETSO relating to the hour; or
If no such RR Instruction was received, the final value of the FPN in the Settlement Period ending at H+60.

9. Collate the RR Schedule

This is done by combining there ramps created for each time (H, H+15, H+30, H+45, and H+60); and the values of FPN + RRA for all times t that are within the hour, but not included in any of the ramps.

The process flow below is a high-level visual demonstration of the steps outlined above. Assuming it is used for a one hour period, then the loop can run a maximum of 4 times (in the case of all 4 quarter hours having non-zero RR Activations).

complex image of process

* RRS = RRA is true when that iteration of the RR Schedule ramp has reached the RR Activation.

Non-Functional Requirement:

Interfaces:

Issues:

5.30 SAA-F031: Deemed Standard Product Variables

Requirement ID:

SAA-F031

Status:

Title:

Deemed Standard Product Variables

BSC reference:

P344

Man/auto:

Automatic

Frequency:

Once on each settlement run.

Volumes:

Functional Requirements:

1. Upon receipt of Replacement Reserve Auction Result Data from National Grid, SAA shall assign the quarter hour variable J to each Quarter Hour RR Activation (RRA^J) in the RR Auction Period.

2. SAA will create Deemed Product Point Variables(qDSP^J_ijt) for each Quarter Hour RR Activation, to be processed in ascending order by reference to the Quarter Hour RR Activation 'J', where;

i) a point variable (t, MW) is created such that t is set 5 minutes before the start time of the Quarter Hour for which the RR Activation relates. The MW level is set equal to the level of the immediately preceding Quarter Hour RR Activation. If not immediate preceding quarter hour exists, then it is set to zero.

ii) a point variable (t, MW) is created such that t is set 5 minutes after the start time for the Quarter hour RR Activation. The MW level equals RR Activated Quantity for that Quarter Hour.

iii) a point variable (t, MW) is created such that t is set 5 minutes before the end time for the Quarter hour RR Activation. The MW level equals RR Activated Quantity for that Quarter Hour.

iv) a point variable (t, MW) is created such that t is set 5 minutes after the end time for the Quarter hour RR Activation. The MW level equals RR Activated Quantity for that Quarter Hour.

v) qDSP^J_ijt will have the same format and structure as other BSC point variables as per BSC X-2 4.4

Non-Functional Requirement:

Interfaces:

Issues:

5.31 SAA-F032: Period Supplier BM Unit Delivered Volume for Secondary BM Units

Requirement ID:

SAA-F032

Status:

Title:

Period Supplier BM Unit Delivered Volume for Secondary BM Units

BSC reference:

P344

Man/auto:

Automatic

Frequency:

Once on each settlement run.

Volumes:

Functional Requirements:

For each Settlement Period and each Primary BM Unit "i", or Secondary BM Units “i2”

1: The Period Secondary BM Unit Non-Delivered Volume (QSND_ij) for each Secondary BM Unit is the amount determined as follows:

QSND_ij = Max{ Min( QBS_ij, QNDO_ij ) , QNDB_ij }

And

2: The Period Secondary BM Unit Delivered Volume (QSD_ij) for each Secondary BM Unit is the amount determined as follows:

QSD_ij = QBS_ij -QSND_ij

3: The Secondary BM Unit Supplier Delivered Volume (QSD_iji2) for each Secondary BM Unit "i2", for each Primary BM Unit "i" for the period is determined as follows:

QSD_iji2 = QSD_i2j * SP_iji2

Where the Period Secondary BM Unit Delivered Proportion (SP_iji2) is determined as a weighted average of Secondary BM Unit Supplier Delivered Volume, VBMUSDV_iji2:

SP_iji2 = VBMUSDV_iji2 / Σ_iVBMUSDV_iji2

where Σ_i represents the summation over all Primary BM Units "i" and VBMUSDV_iji2is the Secondary BM Unit Supplier Delivered Volume which is defined in more detail in Section 9.6.1C of Annex S-2.

2: The Period Supplier BM Unit Delivered Volume (QBSD_ij) is the amount determined as follows:

QBSD_ij = Σ_i2QSD_iji2

where Σ_i2 represents the sum over all Secondary BM Units i2 for which Primary BM Unit "i" is to be allocated a value of QSD_iji2.

Non-Functional Requirement:

Interfaces:

Issues:

5.32 SAA-F033: Deemed Standard Product Volumes and RR Instructed Deviation Volumes

Requirement ID:

SAA-F033

Status:

Title:

Deemed Standard Product Volumes and RR Instructed Deviation Volumes

BSC reference:

P344

Man/auto:

Automatic

Frequency:

Once on each settlement run

Volumes:

Functional Requirements:

1. The Deemed Standard Product Volume (qDSPV^J_ij(t)) is calculated as follows:

qDSPV^J_ij(t) = qDSP^J_ij(t) - qDSP^J-1_ij(t)

where, the Settlement Period, J-1 represents that Deemed Standard Product Shape from the previous Quarter Hour and is measured in MWh for each BM Unit I and Settlement period J.

If there is no qDSP^J_ij(t) has been determined in the Settlement Period which has a qDSP^J_ij(t) then qDSP^J-1_ij(t) shall be set equal to zero.

2. The Deemed Standard Product Offer Volume (qDSPO^J_ij(t)) and Deemed Standard Product Bid Volume (qDSPB^J_ij(t)) for Accepted Offers and Bids are calculated as follows:

qDSPO^J_ij(t)) = max (qDSPV^J_ij (t) , 0 )

qDSPB^J_ij (t)) = min (qDSPV^J_ij(t) , 0 )

3. The Period Deemed Standard Product Offer Volume (DSPO^J_ij) and Period Deemed Standard Product Bid Volume (DSPB^J_ij) in each settlement period for each BM Unit are calculated by integrating (DSPO^J_ij) and (DSPB^J_ij), respectively, over all spot times in the Settlement Period, for each Quarter Hour RR Activation J.

The formula to calculate the area for a trapezoid shown below can be applied as follows:

$V o l u m e = \frac{({M W}_{t 1} - {M W}_{t 0})}{2} \frac{(t_{1} - t_{0})}{60}$

4: The Total Period Deemed Standard Product Offer Volume (TDSPO_ij) and Total Period Deemed Standard Product Bid Volume (TDSPB_ij) are calculated as follows:

TDSPO_ij = Σ^JDSPO^J_ij

TDSPB_ij = Σ^J DSPB^J_ij

For each Settlement Period J and each BM Unit i and are measured in MWh.

5: The Replacement Reserve Instructed Offer and Bid Deviation (IOD_ij,IBD_ij) shall be calculated respectively as:

IOD_ij = Σⁿ RRAOⁿ_ij - TDSPO_ij

IBD_ij = Σⁿ RRABⁿ_ij - TDSPB_ij

IOD_ijand IBD_ijare measured in MWh and represent the deviation of RR Accepted Offers and Bids, respectively from the Deemed Standard Product Shape for a BM Unit i in settlement period j.

Non-Functional Requirement:

Interfaces:

Issues:

6 Interface Requirements

The SAA Service shall provide an interface to the following external parties.

Other Service Providers:

Central Registration Agent (CRA)
Central Data Collection Agent (CDCA)
Funds Administration Agent (FAA)
Balancing Mechanism Reporting Agent (BMRA)
Energy Contract Volume Aggregation Agent (ECVAA)
Supplier Volume Allocation Agent (SVAA)

Other external parties:

BSC Party
BSCCo Ltd
NETSO (SO)
Interconnector Administrator (IA)
Interconnector Error Administrator (IEA)

The SAA Service shall provide inbound and outbound interfaces as summarised in the following table. Each interface requirement is described in detail below.

It is the intention that the SAA URS and the IDD should be fully consistent. However, in the event that some inconsistency is found, the definition in the IDD should be assumed to take precedence until such time as the inconsistency can be corrected at the next release of the document.

It is anticipated that the SAA Service will acquire correct and complete operational data from market participants on an ongoing basis. The SAA Service will not be migrating bulk data from any source.

Reqt No.	Interface Requirement	Inbound/ Outbound	Interface User (IU)	Mechanism
SAA-I001	Receive Registration Data	Inbound	CRA	Automatic
SAA-I002	Receive Credit Assessment Load Factor	Inbound	CRA	Automatic
SAA-I003	Receive Balancing Mechanism Data	Inbound	BMRA	Automatic
SAA-I004	Receive Period Meter Data	Inbound	CDCA	Automatic
SAA-I005	Requirement not currently used
SAA-I006	Receive BM Unit Metered Volumes for Interconnector Users	Inbound	IA	Automatic
SAA-I007	Receive BM Unit Allocated Demand Volume	Inbound	SVAA	Automatic
SAA-I008	Receive Energy Contract Data	Inbound	ECVAA	Automatic
SAA-I009	Receive Transmission Loss Data	Inbound	BSCCo Ltd	Manual
SAA-I010	Receive BSCCo Ltd Costs (Redundant)	Inbound	BSCCo Ltd	Automatic
SAA-I011	Receive Payment Calendar Data	Inbound	FAA	Manual
SAA-I012	Receive Dispute Notification	Inbound	BSC Party, BSCCo Ltd, NETSO	Manual
SAA-I013	Issue Credit/Debit Reports	Outbound	FAA, ECVAA	Automatic
SAA-I014	Issue Settlement Reports	Outbound	BSC Party, BSCCo Ltd, NETSO, VLP	Automatic
SAA-I015	Issue BM Unit Credit Assessment Import Capability Data	Outbound	CRA	Automatic
SAA-I016	Publish Settlement Calendar	Outbound	BSC Party, BSC Party Agent, SVAA, BSCCo Ltd	Manual
SAA-I017	Issue SAA Data Exception Reports	Outbound	ECVAA, NETSO, SVAA, IA, MIDP	Automatic
SAA-I018	Issue Dispute Reports	Outbound	BSC Party, BSCCo Ltd, NETSO	Manual
SAA-I019	Issue BSC Party Performance Reports (Redundant)	Outbound	BSCCo Ltd	Automatic
SAA-I020	Issue SAA Performance Reports	Outbound	BSCCo Ltd	Manual
SAA-I021	Receive Acknowledgement of SAA Messages	Inbound	All automatic outbound IU	Automatic
SAA-I022	Issue SAA Acknowledgement of Messages	Outbound	All automatic inbound IU	Automatic
SAA-I023	Receive System Parameters	Inbound	BSCCo Ltd	Manual
SAA-I025	SAA BSC Section D Charging Data	Outbound	BSCCo Ltd	Manual
SAA-I026	Receive Balancing Services Adjustment Date	Inbound	NETSO	Automatic
SAA-I027	Report pre-settlement run validation failure	Outbound	BSCCo Ltd	Manual
SAA-I028	Receive settlement run decision	Inbound	BSCCo Ltd	Manual
SAA-I029	Receive settlement run instructions	Inbound	BSCCo Ltd	Manual
SAA-I030	Receive Market Index Data	Inbound	MIDP	Automatic
SAA-I031	Receive Market Index Data Provider Thresholds	Inbound	BSCCo Ltd	Manual
SAA-I032	Report Market Index Data Provider Thresholds	Outbound	BSCCo Ltd	Manual
SAA-I033	Receive Request for Data Change	Inbound	NETSO	Manual
SAA-I034	Report Recommended Data Change	Outbound	BSCCo Ltd	Manual
SAA-I035	Receive Instruction for Data Change	Inbound	BSCCo Ltd	Manual
SAA-I036	Report Confirmation of Data Change	Outbound	BSCCo Ltd, NETSO	Manual
SAA-I037	Issue Withdrawals Checklist - Settlement Data	Outbound	CRA	Automatic
SAA-I038	Receive Excluded Emergency Accepted Pricing Information	Inbound	BSCCo Ltd	Manual
SAA-I039	Send Excluded Emergency Acceptance Dry Run Results	Outbound	BSCCo Ltd	Manual
SAA-I040	Receive Authorisation To Proceed With Full Settlement Run	Inbound	BSCCo Ltd	Manual
SAA-I042	BM Unit Gross Chargeable Demand Report	Outbound	EMR	Electronic data file transfer
SAA-I043	Demand Control Instructions to CDCA	Outbound	CDCA	Automatic
SAA-I044	Aggregated BM Unit Disconnection Volumes	Inbound	CDCA	Automatic
SAA-I045	BM Unit Allocated Disconnection Demand Volume	Inbound	SAA	Electronic data file transfer, Pool Transfer File Format
SAA-I049	Trading Unit Data	Outbound	BMRA	Manual
SAA-I050	Secondary BM Unit Demand Volumes	Inbound	SVAA	Electronic data file transfer
SAA-I051	Secondary BM Unit Supplier Delivered Volumes	Inbound	SVAA	Electronic data file transfer
SAA-I052	Daily Activations Report	Outbound	SVAA	Electronic data file transfer
SAA-I053	Daily Exchange Rate Report	Inbound	BMRA	Electronic data file transfer
SAA-I054	Supplier BM Unit Non BM ABSVD	Inbound	SVAA	Electronic data file transfer
SAA-I055	BM Unit Settlement Expected Volume	Inbound	SVAA	Electronic data file transfer
SAA-I057	Supplier BM Unit Period Non-chargeable Demand	Inbound	SVAA	Electronic data file transfer
SAA-I058	Aggregated TLM-Adjusted Non-Chargeable Demand	Outbound	Elexon Portal	Electronic data file transfer

The following diagrams illustrate these interface requirements.

SAA Service: Inbound Interface Requirements

SAA Service: Outbound Interface Requirements³

7 Non-functional Requirements

This section specifies the specific non-functional requirements of the SAA Services. Common non-functional requirements are described in CRA URS - Appendix D.

7.1 SAA-N001: Audit Requirements

Requirement ID:

SAA-N001

Status:

Title:

Audit Requirements

BSC reference:

SAA SD: 5.3.2

Man/auto:

Automatic

Frequency:

All business transactions

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. Sufficient information shall be stored such that the service provider shall be able to demonstrate how the results of any individual settlement calculations were derived.

2. It shall be possible to re-run any individual settlement process to recreate the results exactly as originally generated, as a historic report. This shall include the facility to exclude later versions of business data, for instance meter readings, which were received after the settlement process was originally run. Standard reconciliation runs shall include the current version of all current business data relevant to the trading day of the run, including any data received after the settlement process was originally run.

3. It shall be possible to maintain separate settlement calculation rules applicable to individual trading days, since these rules may change over time. In performing subsequent reconciliations of individual trading days, it shall be possible to apply either the calculation rule which was in force at the date on which the trading day was first settled, or alternatively to apply retrospectively an amended calculation rule if deemed necessary. This application of alternative calculation rules shall also be possible for a historic report which uses the same business data as the original settlement run.

4. Should any settlement run or other report process generate informational, warning or error logs as part of its processing, these logs should be available for inspection by an operator.

5. 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:

a) Data quality is of the required standards for settlement.

b) Settlement issues/disputes can be investigated.

7.2 SAA-N002: Requirement not currently used

Requirement ID: SAA-N002	Status:	Title: Requirement not currently used	BSC reference:
Man/auto:	Frequency:	Volumes:
Non Functional Requirement:

7.3 SAA-N003: Operational Control

Requirement ID:

SAA-N003

Status:

Title:

Operational Control

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

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

Procedures are likely to include, but not be limited to, the following.

1. It shall be possible to perform settlement runs to satisfy “what if” scenarios, especially in order to gauge materiality in the event of disputes. The results of such “what if” calculations should not be available to subsequent reconciliation runs for the relevant trading day unless so confirmed by a suitably authorised operator.

2. The system shall be sized to support the provision of at least ten settlement runs over the course of each working day in order to comply with the requirements of the Settlement Calendar.

3. It shall be possible to run settlement calculations associated with balancing mechanism requirements prior to, and separately from, calculations associated with imbalancing mechanism settlement.

4. Settlement reports associated with a particular settlement run shall be made available for release to all relevant recipients at approximately the same time. Note that the time of receipt of a given report by a particular BSC Party after release by the central system will be dependent on the type and grade of communications service which that BSC Party has chosen to purchase.

7.4 SAA-N004: Requirement not currently used

Requirement ID: SAA-N004	Status:	Title: Requirement not currently used	BSC reference:
Man/auto:	Frequency:	Volumes:
Non Functional Requirement:

8 Service Requirements

There are no specific service requirements for the SAA Services. All common service requirements including indicative volumetrics and performance criteria are described in CRA URS - Appendix.

9 User Roles and Activities

The following table describes the user roles which will support the day to day operation of the SAA 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 Co-ordination of creation of the Settlement Calendar Management of planned operational activities to meet Settlement Calendar timescales 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. Performance of procedures to initiate and monitor settlement runs and reports. 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. Note that the Help Desk facility shall be shared by more than one service provision.
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.

These roles and activities will be refined and developed in more detail during detailed business process definition.

The following parties are associated with the SAA business processes in the wider context, and may thus be considered as “users” of the service. The detailed functional requirements and data interfaces necessary to support these parties are described earlier in this chapter.

Role	Summary of Activities related to SAA
BSCCo Ltd	Receives summary settlement reports from SAA at periodic intervals (daily, weekly, monthly).
Balancing Mechanism Operator	Transmits balancing mechanism data (via the BMRA service) to be settled by the SAA service according to Settlement Calendar timescales.
BSC Party	Receives detailed settlement reports daily from SAA.
CRA	Provides registration data to the SAA which defines the set of items such as the BM Units relevant to each trading period.
ECVAA	Provides total energy contract volume associated with each energy account and settlement period.
CDCA	Provides metered volumes for BM Units, Interconnectors and GSP Groups as input to the settlement process performed by SAA.
SVAA	Provides Supplier Take Energy volumes as input to the settlement process performed by SAA.
Interconnector Administrator	Provides BM Unit Metered Volumes for Interconnector Users as input to the settlement process performed by SAA.
Funds Administration Agent (FAA)	Receives debit/credit instructions from SAA in order to perform funds clearance. Provides payment calendar annually.

Appendix A Glossary

A standard NETA glossary is included in the Appendix of the CRA URS.

Appendix B Requirements Compliance Matrix

The following tables show the mapping of requirements defined in this URS document to the requirements set out in the Service Description for Settlement Administration, Change Notices and Clarification Notes.

Service Description Requirement Number	URS Requirement Reference Number	Notes
1		Overview section therefore no mapping of requirements
2.1.1	SAA-I003 SAA-F002	Balancing Mechanism data received from BMRA not NETSO
2.1.2	SAA-I026
2.1.4	SAA-F002 SAA-I003
2.1.6	SAA-F002 SAA-I003
2.2.1	SAA-I004 SAA-I044 SAA-F002
2.3.1	SAA-I008 SAA-F002
2.3.2	SAA-I008 SAA-F002
2.4.1	SAA-I006 SAA-F002
2.5.1	SAA-I007 SAA-I045 SAA-F002 SAA-F003
2.5.2	SAA-F029 SAA-I049
2.6.1	SAA-I001 SAA-F002
2.6.2	SAA-I010 SAA-F002
2.6.3	SAA-I023
2.6.4	SAA-I023
2.6.9	SAA-F005 SAA-F009b
2.7.1	SAA-I001 SAA-I002 SAA-F002
2.8.1	SAA-I011 SAA-F002
2.9.1	SAA-I012 SAA-F002
3.1.1	SAA-F006
3.1.2	SAA-F006
3.1.3	SAA-F006
3.2.1	SAA-F007
3.2.2	SAA-F005
3.2.3	SAA-F005
3.2.4	SAA-F005
3.2.5	SAA-F005
3.2.6	SAA-F005
3.2.7	SAA-F005
3.2.8	SAA-F007
3.3.1	SAA-F005
3.3.2	SAA-F005
3.4.1	SAA-F005
3.4.2	SAA-F005
3.5.1	SAA-F005
3.5.2	SAA-F005
3.5.3	SAA-F005
3.5.4	SAA-F005
3.59	SAA-F029 SAA-I049
3.6.1	SAA-F005
3.7.1	SAA-F005
3.8.1	SAA-F005
3.9.1	SAA-F005
3.9.2	SAA-F005
3.9.3	SAA-F005
3.10.1	SAA-F005
3.11.1	SAA-F005 SAA-F010
3.11.2	SAA-F010
3.12.1	SAA-F005
3.12.2	SAA-F005
3.13.1	SAA-F005
3.13.2	SAA-F005
3.14.1	SAA-F005
3.15.1	SAA-F007
3.15.2	SAA-F007
3.16.1	SAA-F007
3.16.2	SAA-F007
3.17.1	SAA-F007
3.17A	SAA-F005
3.17B	SAA-F005
3.17C	SAA-F005
3.18.1	SAA-F007
3.19.1	SAA-F005
3.19.2	SAA-F013
3.19.3	SAA-F013
3.20.1	SAA-F005
3.21.1	SAA-F005
3.22.1	SAA-F013
3.22.2	SAA-F013
3.23.1	SAA-F013
3.24.1	SAA-F013
3.25.1	SAA-F013
3.26.1	SAA-F009
3.26C	SAA-F009b
3.27	SAA-F009
3.28	SAA-F009
3.29	SAA-F005
3.30	SAA-F005
3.31.1	SAA-F009
3.31.2	SAA-F009
3.32.1	SAA-F009
3.32.2	SAA-F009
3.32C	SAA-F009b
3.33.1	SAA-F011
3.34.1	SAA-F008
3.34.2	SAA-F008
3.34.3	SAA-F008
3.35.1	SAA-F008
3.36.1	SAA-F011
3.37.1	SAA-F011
3.38.1	SAA-F011
3.39.1	SAA-F011
3.40.1	SAA-F011
3.41.1	SAA-F014
3.41.2	SAA-F014
3.41.3	SAA-F014
3.42.1	SAA-F014
3.43.1	SAA-F014
3.44.1	SAA-F014
3.44.2	SAA-F014
3.44.3	SAA-F014
3.45.1	SAA-F014
3.45.2	SAA-F014
3.45.3	SAA-F014
3.46.1	SAA-F015
3.47.1	SAA-F015
3.48.1	SAA-F015
3.49.1	SAA-F015
3.50.1	SAA-F018
3.50.2	SAA-F018
3.51.1	SAA-F016
3.52.1	SAA-F017
3.53.1	SAA-F017
3.54.1	SAA-F017
3.55.1	SAA-F017
3.56.1	SAA-F019
3.56.2	SAA-F019 SAA-I013
3.56.3	SAA-F019
3.57.1	SAA-I013 SAA-I014
4.1	SAA-F022
4.1.1	SAA-I013 SAA-I014
4.1.2	SAA-I013 SAA-I014
4.1.3	SAA-I013 SAA-I014
4.1.4	SAA-I013 SAA-I014
4.2.1	SAA-I013 SAA-I014
4.2.2	SAA-I013 SAA-I014
4.2.3	SAA-I013 SAA-I014
5.1.1	SAA-F021
5.1.2	SAA-F021
5.1.3	SAA-F021
5.1.4	SAA-F021 SAA-I018
5.1.5	SAA-F021
5.1.6	SAA-F021
5.2.1	SAA-F001 SAA-I016
5.2.2	SAA-F001
5.3.1	SAA-I001
5.3.2	SAA-N001
5.3.3	SAA-I001

Change Notice or Clarification Note	URS Requirement Reference Number	Notes
CR002	SAA-F010
CR003	SAA-F006 SAA-F009
CR004		not applicable to SAA
CR005	SAA-F008 SAA-I008
CR006	SAA-F005
CR007	SAA-F018
CR008		not applicable to SAA
CR009	SAA-F005

CR_18_990909		not applicable to SAA
CR_990813_06a		not applicable to SAA
CR_990813_06b	SAA-F022 SAA-I014 SAA-N003
CR_990813_07		not applicable to SAA
CR_991027_06a	SAA-I014
CR_991027_06b		not applicable to SAA
CR065	SAA-I025
CP555	SAA-F001
	SAA-F010
	SAA-I006
	SAA-I011
	SAA-I016
	SAA-I024
CP598	SAA-F002
CP595	SAA-I017
CP596	SAA-F013
P8	SAA-I014
P18A	SAA-I014
P2	SAA-F004
	SAA-I013
P71	SAA-F005
	SAA-F024
	SAA-I003
	SAA-I014	SAA-I014 changes for P71 are documented in the IDD, however they are included in this cross reference for completeness
P78	SAA-F002
	SAA-F009
	SAA-F009a
	SAA-F009b
	SAA-F012
	SAA-F020
	SAA-F023
	SAA-I014	The SAA-I014 changes for P78 are documented in the IDD, however they are included in this cross reference for completeness
	SAA-I017
	SAA-I020
	SAA-I026
	SAA-I030
	SAA-I031
	SAA-I032
CP754	SAA-I014	The SAA-I014 changes for CP754 are documented in the IDD, however they are included in this cross reference for completeness
CP797	SAA-I014	The SAA-I014 changes for CP797 are documented in the IDD, however they are included in this cross reference for completeness
CP915	SAA-I006
CP975	SAA-I001
CP995	SAA-I003 SAA-I033 SAA-I034 SAA-I035 SAA-I036
CP974	SAA-F025 SAA-I037
P215	SAA-F001
CP1283	SAA-I034 SAA-I035 SAA-I036
CP1286	SAA-I003
P217	SAA-F009 SAA-I003 SAA-I014 SAA-I023 SAA-I026
P285	SAA-F017
ORD005	SAA-I042
P305	SAA-F002 SAA-F003 SAA-F005 SAA-F009a SAA-F009b SAA-I044
P323	SAA-F028
P321	SAA-F028 SAA-I049
P344	SAA-F002 SAA-F003 SAA-F004 SAA-F005 SAA-F006 SAA-F007 SAA-F009b SAA-F011 SAA-F014 SAA-F015 SAA-F016 SAA-F017 SAA-F019 SAA-F024 SAA-F030 SAA-F031 SAA-F032 SAA-F033 SAA-F033 SAA-I050 SAA-I051 SAA-I052
P396	SAA-I025	The SAA-I014 changes for P396 are documented in the IDD, however they are included in this cross reference for completeness
P395	SAA-I057 SAA-I058	The SAA-I057 and SAA-I058 changes for P395 are documented in the IDD, however they are included in this cross reference for completeness

Appendix C Logical Data Model

The diagram above illustrates the logical data model as it affects the SAA User Requirements Specification. It does not describe the entire system data model and it is included for indicative purposes only.

Appendix D Business Process Model

The Business Process Model diagram(s) for the SAA Service will be found in the NETA PROGRAMME shared folder (Reference 07-5505). The diagram below is included for indicative purposes only.

Appendix E Price Derivation Code Definitions

The possible values of the Price Derivation Code are defined in the table below. The description gives a brief summary of what the code represents, and the condition detail defines the relevant conditions that cause this related code to be true. Refer to the description of how the System Buy Price and System Sell Price are calculated for further understanding of what these conditions mean.

For Settlement Dates prior to the P217 effective date:

Code	Description	Condition Detail
A	SBP = Main price; SSP = Reverse Price	NIV is positive ΣQXP is non zero SBP = NIV; SSP = PXP; QAPO + UEBVA is not zero; SSP is not greater than SBP
B	SSP Capped to SBP	NIV is positive ΣQXP is non zero SBP = NIV; SSP = NIV; QAPO + UEBVA is not zero; SSP is greater than SBP
C	SSP Defaulted to SBP	NIV is positive ΣQXP is zero SBP = NIV; SSP = NIV; QAPO + UEBVA is not zero
D	SBP & SSP Defaulted to Market Price	NIV is positive ΣQXP is non zero SBP = PXP; SSP = PXP; QAPO + UEBVA is zero
E	SSP & SBP Defaulted to Zero	NIV is positive ΣQXP is zero SBP = 0; SSP = 0; QAPO + UEBVA is zero
F	SSP = Main Price; SBP = Reverse Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = NIV; QAPB + UESVA is not zero; SSP is not greater than SBP
G	SBP Capped to SSP	NIV is negative ΣQXP is non zero SBP = NIV; SSP = NIV; QAPB + UESVA is not zero; SSP is greater than SBP
H	SBP Defaulted to SSP	NIV is negative ΣQXP is zero SBP = NIV; SSP = NIV; QAPB + UESVA is not zero
I	SBP & SSP Defaulted to Market Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = PXP; QAPB + UESVA is zero
J	SSP & SBP Defaulted to Zero	NIV is negative ΣQXP is zero SBP = 0; SSP = 0; QAPB + UESVA is zero
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;

For Settlement Dates on or after the P217 effective date (note: Price Derivation Codes D, E, I, and J are not applicable for P217 effective dates):

Code	Description	Condition Detail
A	SBP = Main price; SSP = Reverse Price	NIV is positive ΣQXP is non zero SBP = NIV; SSP = PXP; SSP is not greater than SBP
B	SSP Capped to SBP	NIV is positive ΣQXP is non zero SBP = NIV; SSP = NIV; SSP is greater than SBP
C	SSP Defaulted to SBP	NIV is positive ΣQXP is zero SBP = NIV; SSP = NIV;
F	SSP = Main Price; SBP = Reverse Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = NIV; SSP is not greater than SBP
G	SBP Capped to SSP	NIV is negative ΣQXP is non zero SBP = NIV; SSP = NIV; SSP is greater than SBP
H	SBP Defaulted to SSP	NIV is negative ΣQXP is zero SBP = NIV; SSP = NIV;
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;

For Settlement Dates on and after the P305 effective date:

Code	Description	Condition Detail
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;
N	SSP Defaulted to Main Price; SBP = SSP	NIV is Negative
P	SBP Defaulted to Main Price, SSP = SBP	NIV is Positive

1 As detailed in the CRA URS.

2 BM Unit Non-Chargeable Demand is sent by SVAA as number which is ≥ 0, so must be converted by SAA into a number which is ≤ 0

3 Note that details of the SAA-I017 (Data Exception Report) flow have not been included in this diagram, in order to avoid excessive clutter.

User Requirements Specifications

CONTENTS

SAA: Settlement Administration Agent

1 Management Summary

2 Introduction

3 Scope of Specification

4 Business and System Overview

4.1 Summary of Business Requirements

4.2 The Settlement Calendar

4.3 Service Context

4.4 Requirements Summary

4.5 Numbering Scheme for Requirement Definitions

4.6 Attributes of Individual Requirements

5 Functional Requirements

5.1 SAA-F001: Produce Settlement Calendar

5.2 SAA-F002: Validate settlement data

5.3 SAA-F003: Validate SVAA meter data

5.4 SAA-F004: Calculate Supplier BM Unit Metered Volumes

5.5 SAA-F005: Calculate balancing mechanism and Replacement Reserve volumes

5.6 SAA-F006: Calculate BM unit transmission loss multipliers

5.7 SAA-F007: Calculate balancing mechanism Replacement Reserve cashflows

5.8 SAA-F008: Calculate Credited Energy Volumes

5.9 SAA-F009: Calculate energy imbalance prices

5.10 SAA-F010: Calculate interconnector error

5.11 SAA-F011: Calculate energy imbalance cashflows

5.12 SAA-F012: Validate Adjustment Data

5.13 SAA-F013: Calculate information imbalance charges

5.14 SAA-F014: Calculate non-delivery volumes

5.15 SAA-F015: Calculate non-delivery charges

5.16 SAA-F016: Calculate system operator BM cashflow

5.17 SAA-F017: Calculate residual cashflows

5.18 SAA-F018: Allocate BSCCo Ltd Costs (Redundant)

5.19 SAA-F019: Aggregate charges and payments

5.20 SAA-F020: Validate Market Index Data

5.21 SAA-F021: Manage settlement disputes

5.22 SAA-F022: Provide settlement reports

5.23 SAA-F023: Process Market Index Data Provider Liquidity Thresholds

5.24 SAA-F024: Daily Check for Missing Settlement Calculation Data Flows

5.25 SAA-F025: Process Withdrawing Party Settlement Details

5.26 SAA-F026: Process Emergency Acceptance Data

5.27 SAA-F027: Calculate BM Unit Chargeable Demand for EMR

For Supplier BM Units the TLM-Adjusted BM Unit Gross Demand is defined as:

For BM Units other than Supplier BM Units and Interconnector BM Units) the TLM-Adjusted BM Unit Gross Demand is defined as:

For all other BM Units, TLM-Adjusted BM Unit Gross Demand is not defined (and the SAA will not provide a value for that BM Unit and Settlement Period to a the EMR Settlement Services Provider).

For Settlement Dates before 02 November 2023, the SAA shall report TLM-Adjusted BM Unit Gross Demand values to the EMR Settlement Services Provider for each relevant BM Unit and Settlement Period in the Settlement Day via SAA-I042.

5.28 SAA-F029: Calculate Trading Unit Data

5.29 SAA-F030: Build RR Schedule

5.30 SAA-F031: Deemed Standard Product Variables

5.31 SAA-F032: Period Supplier BM Unit Delivered Volume for Secondary BM Units

5.32 SAA-F033: Deemed Standard Product Volumes and RR Instructed Deviation Volumes

6 Interface Requirements

7 Non-functional Requirements

7.1 SAA-N001: Audit Requirements

7.2 SAA-N002: Requirement not currently used

7.3 SAA-N003: Operational Control

7.4 SAA-N004: Requirement not currently used

8 Service Requirements

9 User Roles and Activities

Appendix A Glossary

Appendix B Requirements Compliance Matrix

Appendix C Logical Data Model

Appendix D Business Process Model

Appendix E Price Derivation Code Definitions