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.

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

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.

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

Requirement ID:

SAA-F001

Status:

M

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:

Requirement ID:

SAA-F002

Status:

M

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:

Requirement ID:

SAA-F003

Status:

M

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:

Requirement ID:

SAA-F004

Status:

M

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:

Requirement ID:

SAA-F005

Status:

M

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.

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.

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ⁿ_ij is the Period BM Unit RR Total Accepted Offer Volume

RRABⁿ_ij is 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)

or

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.

Non-Functional Requirement:

Interfaces:

Issues:

Requirement ID:

SAA-F006

Status:

M

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:

Requirement ID:

SAA-F007

Status:

M

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_ij is the Period Accepted Bid Volume; QAO^kn_ij is the Period Accepted Offer Volume; PBⁿ_ij is the Bid Price for the corresponding Bid; POⁿ_ij is the Offer Price for the corresponding Offer; and TLM_ij is 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_iJ is 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 = Σ_J CCR_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:

Requirement ID:

SAA-F008

Status:

M

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_iaj are 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:

Requirement ID:

SAA-F009

Status:

M

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:

Requirement ID:

SAA-F009b

Status:

M

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_d then 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 (∑^J VGB ^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 (∑^J VGB ^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:

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:

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

Sell Stack

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:

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:

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:

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ⁿ_ij is 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_d and 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:

Requirement ID:

SAA-F010

Status:

M

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:

Requirement ID:

SAA-F011

Status:

M

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 Σ_a is 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_j is the System Sell Price and SBP_j is 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_j shall 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:

Requirement ID:

SAA-F012

Status:

M

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:

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

2. 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

Requirement ID:

SAA-F013

Status:

M

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_ij or 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:

Requirement ID:

SAA-F014

Status:

M

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.

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:

Requirement ID:

SAA-F015

Status:

M

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ⁿ_ij is the Non-Delivered Offer Price for each Accepted Offer allocated a Non-Delivery Volume and will vary depending on the following:

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ⁿ_ij is the Non-Delivered Bid Price for each Accepted Bid allocated a Non-Delivery Volume and will vary depending on the following:

NDPB ijn =PB ijn, for Accepted Bid volumesRRAPJ, for upward RR ActivationsBEDPJ, for RR Instructed Bid Deviation Volumes (IBDij)

Where RRAP_J is the Replacement Reserve Activation Price associated to the Quarter Hour RR Activation and BEDP_ij is 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:

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:

Requirement ID:

SAA-F017

Status:

M

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.