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 | |
Effective date | |
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. |
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 |
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.
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.
BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS;
Interface Specification.
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.
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.
Interim Initial Settlement;
Initial Settlement;
Reconciliation Settlement (3 runs)
Final Reconciliation;
Settlement Dispute (runs as necessary).
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. |
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 |
Non-Functional |
|
SAA-N001 | Audit Requirements |
SAA-N002 | Security Requirements |
SAA-N003 | Operational Control |
SAA-N004 | Euro Compliance |
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).
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.
CRA-F001
BMRA-S022
GEN-N112
SAA-I033
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 1st April. FAA will issue a draft Payment Calendar to SAA by January 15th, 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 31st 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:
For Interim Initial settlement runs for Settlement Dates prior to the P253 effective date, the following additional check is performed:
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:
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:
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 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.
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:
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.
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 QMij 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: QMij = GSPGTij * QMij΄ / GSPGTij
Where: GSPGTij is the GSP Group Take for the GSP Group associated with BM Unit i in Settlement Period j on Settlement Day d QMij΄ is the BM Unit Metered Volume for BM Unit i in Settlement Period j΄ on Settlement Day d΄ GSPGTij΄ 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 QMij 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 qAOknij(t) and qABknij(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 (FPNij(t)) Bid-Offer Volume (qBOnij(t)) Bid-Offer Upper Range (BOURnij(t)) Bid-Offer Lower Range (BOLRnij(t)) Acceptance Volume (qAkij(t)) Accepted Bid-Offer Volume (qABOknij(t)) Accepted Offer Volume (qAOknij(t)) Accepted Bid Volume (qABknij(t)) | |||
1: The value of Final Physical Notification, FPNij(t) shall be defined for times, t, falling within Settlement Period j by linear interpolation from the values of Point FPN (fFPNit), submitted for that Settlement Period j, for BM Unit i. | |||
2: For any value of Bid-Offer Number, n, the Bid-Offer Volume (qBOnij(t)) at any time t shall be defined by linear interpolation from the values of Point Bid-Offer Volume (fqBOnit) 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:
BOURnij(t) = FPNij(t) + Σn+qBOnij(t); and
BOUR ij0(t) = FPNij(t) Where Σn+ 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 BOLRnij(t) is defined for all times in Settlement Period j as:
BOLRnij(t) = FPNij(t) + Σn-qBOnij(t); and BOLR ij0(t) = FPNij(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) qAkij(t) is the acceptance level for acceptance k If, for any k, qAkij(t) > FPNij(t) + Σ+qBOnij(t) then: if FPNij(t) >= 0 and there is at least one positive bid-offer pair, the highest numbered Bid-Offer pair is extended up to Maxk(qAkij(t)) otherwise, a new bid-offer pair is created with pair number one greater than the highest (or 1 if none exist) with: BOURnij(t) = Max{ FPNij(t) + Σ+qBOnij(t), Maxk(qAkij(t)) } If, for any k, qAkij(t) < FPNij(t) + Σ-qBOnij(t) then: if FPNij(t) <= 0 and there is at least one negative bid-offer pair, the lowest numbered Bid-Offer pair is extended down to Mink(qAkij(t)) otherwise, a new bid-offer pair is created with pair number one lower than the lowest (or -1 if none exist) with: BOLRnij(t) = Min{ FPNij(t) + Σ-qBOnij(t), Mink(qAkij(t)) }
| |||
4: The Acceptance Volume (qAkij(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 (FPNij(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 (qABOknij (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,
qABOknij(t) = Max{Min(qAkij(t), BOURn ij(t)), BOURn-1ij(t)} - Max{Min(qAk-ij(t), BOURnij(t)), BOURn-1ij(t)}
For n<0,
qABOknij (t) = Min{Max(qAkij(t), BOLRnij(t)), BOLRn+1ij(t)} - Min{Max(qAk-ij(t), BOLRnij(t)), BOLRn+1ij(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 qAk-ij(t) = FPNij(t) for each Acceptance k that is not flagged as relating to an RR Instruction. | |||
6: The Accepted Offer Volume (qAOknij(t)) and Accepted Bid Volume qABknij (t) shall be defined in MW by splitting the positive and negative parts of the Bid-Offer Acceptance Volume.
The Accepted Offer Volume (qAOknij(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 knij(t) = Max {qABOknij(t), 0}
Similarly, the Accepted Bid Volume (qABknij(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:
qABknij (t) = Min {qABO knij(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 (QAOknij) and Period Accepted Bid Volume (QABknij) 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 (QAOknij) 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 (QABknij) 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 (RRAOknij) 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 (RRABknij) 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:
QAOnij = ΣkQAOknij
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:
QABnij = ΣkQABknij
This is the total MWh volume of Offer or Bid n accepted from all Bid-Offer Acceptances.
Where either of QAOnij or QABnij is non-zero, a flag (NZni) 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:
RRAOnij = Σk RRAOknij
The Period RR Total Accepted Bid Volume, for all Acceptances that are flagged as relating to an RR Schedule shall be established as follows:
RRABnij = Σk RRABknij
Where Σk represents the sum over all Acceptances within the Settlement Period for RRABnij and RRAOnij.
| |||
9: The Period BM Unit Balancing Services Volume shall be calculated as follows:
QBSij = Σn (QAOnij + QABnij) + Σn (RRAOnij + RRABnij) + QASij + BMUADDVij – QDDij + QBSDij + SNBABSVDij
where Σn represents the sum over all Bid-Offer Pair numbers for the BM Unit QASij is the BM Unit Applicable Balancing Services Volume BMUADDVij is the BM Unit Allocated Demand Disconnection Volume QDDij is the Period BM Unit Demand Disconnection Volume RRAOnij is the Period BM Unit RR Total Accepted Offer Volume RRABnij is the Period BM Unit RR Total Accepted Bid Volume QBSDij represents the Period Supplier Primary BM Unit Delivered Volume SNBABSVDij 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 (QBSDij).
| |||
10: The Period FPN (FPNij) shall be calculated for each BM Unit i, by integrating the value of Final Physical Notification FPNij(t) across all times t, falling within Settlement Period j. The Period FPN is quoted in MWh.
| |||
11: The Reserve Scarcity Price (RSVPj) 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 RSVPj is calculated as: RSVPj = LoLPj * 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: RSVPj = 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 (QSIVtj) 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 (QSIVtj) shall be equal to the Period Accepted Offer Volume derived from an accepted Offer that is STOR Flagged.
| |||
13: The STOR Action Price (STAPtj) 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: STAPtj = max(POnij, RSVPj). In respect of each Settlement Period, for each Balancing Services Adjustment Action that is a STOR action: STAPtj = max(BSAPmj, RSVPj).
| |||
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 (QSDCj) 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 (QBDCj) 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 (qAkij(t)) shall be calculated for any spot times, t. where the following criteria are met:
- qAkij(t) is not flagged as relating to a RR Schedule or a RR Instruction; and - there exists a qAk*ij(t) flagged as relating to a RR Schedule; and - BEGCT < qAkij(t) Bid-Offer Acceptance Time < qAk*ij(t) associated Replacement Reserve Activation Time; and - either: qAk-ij(t) (MW) < qAkij(t) (MW) < qAk*ij(t) (MW) or qAk*ij(t) (MW) < qAkij(t) (MW) < qAk-ij(t) (MW)
where qAk-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 qAk-ij(t) exists, then the Acceptance Volume shall be set to the value of FPNij(t) for those spot times; and
where qAkij(t) (MW), qAk-ij(t) (MW) and qAk*ij(t) (MW) represent the associated spot time MW values. In the example below, a BOA, qAk-ij, is requested after BEGCT by the TSO. The BOA falls between an existing BOA, qAkij’ 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 = – {α(Σ+QMij + Σ-QMij) + Σ+(non-I) (QMij * TLFij)} / Σ+(non-I) QMij; TLMO-j = {(α–1)(Σ+QMij + Σ-QMij) – Σ- (non-I) (QMij * TLFij)} / Σ-(non-I) QMij;
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:
TLMij = 1 + TLFij + TLMO+j for all non-Interconnector BM Units that are in Trading Units that are net deliverers of energy in Settlement Period j, TLMij = 1 + TLFij + TLMO-j for all non-Interconnector BM Units that are in Trading Units that are net offtakers of energy in Settlement Period j, TLMij = 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 TLFij 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 TLFij will, in general be determined by the BSC. The value of αis 0.45 and TLFij 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:
TLMij = TLMij(Base)
where TLMij(Base) means the value of TLMij 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 CAOknij shall be calculated as: CAOknij = QAOknij * POnij * TLMij. The Period Acceptance Bid Cashflow CABknij shall be calculated as: CABknij = QABknij * PBnij * TLMij Where QABknij is the Period Accepted Bid Volume; QAOknij is the Period Accepted Offer Volume; PBnij is the Bid Price for the corresponding Bid; POnij is the Offer Price for the corresponding Offer; and TLMij is the Transmission Loss Multiplier for BM Unit i and Settlement Period j. The Period Acceptance Bid Cashflow (CABknij) and Period Acceptance Offer Cashflow (CAOknij) 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 QABknij is negative and PBnij 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 (COnij ) shall be calculated as: COnij = QAOnij * POnij * TLMij (=ΣkCAOknij) The Period BM Unit Bid Cashflow (CBnij) shall be calculated as: CBnij = QABnij * PBnij * TLMij (=ΣkCABknij) 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 (CBMij).shall be calculated as: CBMij = ΣnCOnij + Σn CBnij 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 (TCBMj) shall be calculated as: TCBMj = Σi CBMij 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 (CCRiJ) is defined as:
CCRiJ = RRAViJ * RRAPJ
where RRAPJ represents the Quarter Hour RR Activation Price and RRAViJ is the RR Activation Volume established as follows:
RRAViJ = Quarter Hour RR Activated Quantity * 0.25
| |||
6: The Period RR BM Unit Cashflow (CRRij) for a BM unit is calculated as:
CRRij = ΣJ CCRiJ where ΣJ is the sum over all Quarter Hours J within Settlement Period j.
| |||
7:The Daily Party RR Cashflow (CRRp) is calculated as:
CRRp = Σj Σiϵp CRRij
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 BEDPj is the Balancing Energy Deviation Price and is equal to zero.
| |||
9: The Replacement Reserve Period Instruction Deviation Cashflow (CDRij) 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:
CDRij = CDOij + CDBij
| |||
10: The Daily Party RR Instruction Deviation Cashflow is determined as:
CDRp = Σj Σiϵp CDRij
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 (TCRRj) for all BM units is calculated as:
TCRRj = Σ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 (QMij) and the Period BM Unit Balancing Services Volume (QBSij) 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 CRA1 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 QCEiaj 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:
QCEiaj = {(QMij - QBSij)*(QMPRiaj/100) + QMFRiaj}*TLMij ,
Where a≠A, and A is the Lead Energy Account for BM Unit i; QMFRiaj is the Metered Volume Fixed Reallocation, a fixed volume in MWh, assigned to Energy Account a from BM Unit i in Settlement Period j; QMPRiaj 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 QMij is the Primary BM Unit Metered Volume.” QCEiaj 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:
QCEiAj = (QMij * TLMij) - Σa≠A QCEiaj
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 (QACEaj).shall be calculated for each Energy Account a, as follows: QACEaj = Σi QCEiaj 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, CADLd then the Short Duration Acceptance flag for each acceptance in the group is set to show that it is a Short-Duration Acceptance. If CADLd = 0 then no acceptances are “Short-Duration Acceptances”. CADLd 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
TQAOj = ΣiΣnQAOnij
where: Σi represents the sum over all BM Units; Σn represents the sum over all accepted Offers
b. Total Volume of Bids
TQABj = ΣiΣnQABnij
where: Σi represents the sum over all BM Units; Σn represents the sum over all accepted Bids
c. Total Period Applicable Balancing Services Volume
TQASj = ΣiQASij
where: Σi represents the sum over all BM Units;
d. Total Balancing Services Adjustment Buy Volume
TBVAj = ΣmQBSABmj
where: Σm represents the sum over all Balancing Services Adjustment Buy Actions.
e. Total Balancing Services Adjustment Sell Volume
TSVAj = ΣmQBSASmj
where: Σm represents the sum over all Balancing Services Adjustment Sell Actions
f. TQSIVj = ΣtQSIVtj
where: Σt represents the sum over all STOR Actions.
g. TQSDCj = ΣQSDCj
where: Σ represents the sum over all System Demand Control Volumes.
h. TQBDCj = ΣQBDCj
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 |QAOnij| < DMATd or |QABnij| < DMATd) 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 |QBSABmj| < DMATd or |QBSASmj| < DMATd) 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 |QSDCj| < DMATd or |QBDCj| < DMATd) 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 DMATd is set to 0, then no volumes will be tagged in this way. DMATd will always be a positive number or 0. | |||||||||||||||||||||||||||||||
4: Build Buy and Sell Stacks.
Buy System Actions (QSBwj) are considered to be: i. All those Accepted Offers (QAOknij) which are not “De Minimis Acceptance Volumes” and not STOR Actions; ii. All Balancing Services Adjustment Buy Actions (QBSABmj) which are not “De Minimis Acceptance Volumes” and not STOR Actions;
iii. in relation to each STOR Action, the STOR Instructed Volume (QSIVtj) which are not “De Minimis Acceptance Volumes”: iv. in relation to each Demand Control Impacted Settlement Period, the System Demand Control Volume (QSDCj) which are not “De Minimis Acceptance Volumes” v. in relation to each Demand Control Impacted Settlement Period, the Balancing Demand Control Volume (QBDCj) 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 (VGBJj) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below: VGBJ = GBJ * 0.25
where GBJ 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 (RRAUSBj) determined by the SAA for each Settlement Period as below: RRAUSBj = max {(∑ni RRAO nij + ∑ni RRAB nij ), 0} + max (∑J VI nj , 0) – max (∑J VGB Jj, 0)
where VIJ represents the Quarter Hour Volume Interconnector Schedule to be determined from the Quarter Hour Interconnector Schedule (IJ) as below;
VIJ = IJ * 0.25
where IJ represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour Interconnector Schedule for Quarter Hour ‘J’
Sell System Actions (QSSwj) are considered to be:
i. All those Accepted Bids (QABknij) which are not “De Minimis Acceptance Volumes”; and ii. All Balancing Services Adjustment Sell Actions (QBSASmj) 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 (VGBJj) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below: VGBJ = GBJ * 0.25
where GBJ 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 (RRAUSSj) determined by the SAA for each Settlement Period as below: RRAUSSj = min {(∑ni RRAO nij + ∑ni RRAB nij ), 0} + min (∑J VI nj , 0) – min (∑J VGB Jj, 0)
The price of a System Action is considered to be (SAPwj):
i. In the case of an accepted Offer that is not a STOR Action, the Offer Price POnij; ii. In the case of an accepted Bid, the Bid Price PBnij; iii. In the case of Balancing Services Adjustment Actions that are not STOR Actions, Balancing Services Adjustment Price BSAPmj (derived from Cost/Volume, i.e. a £/MWh price); iv. In the case of a STOR Action, the STOR Action Price (STAPtj); 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 (QHRRAPJ); 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' (QSBw'j * SAPw'j) / ∑w' QSBw'j
and if NIV is negative then:
RP j = ∑w' (QSSw'j * SAPw'j) / ∑w' QSSw'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 (PARd).
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 PARd 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 PARd 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 (QTAOnij) and Bids (QTABnij) are the amounts of QAOnij and QABnij 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 (QRAOnij) and Bids (QRABnij) are the amounts of QAOnij and QABnij 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 (QOAOnij) and Bids (QOABnij) are the amounts of QAOnij and QABnij 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 (TQPAOj) and Bids (TQPABj) are the sum of QAOnij and QABnij respectively which were not Classified as Second-Stage Flagged. b. System Total Tagged Accepted Volume of Offers (TQTAOj) and Bids (TQTABj) are the sum of QAOnij and QABnij 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 (TQRAOj) and Bids (TQRABj) are the sum of QAOnij and QABnij 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 (TQOAOj) and Bids (TQOABj) are the sum of QAOnij and QABnij 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 (TSVAj) and Sell Items (TBVAj) are the sum of QBSABmj and QBSASmi respectively. b. Total System Tagged Adjustment Volume of Buy Items (TSTVAj) and Sell Items (TBSVAj) are the sum of QBSABmj and QBSASmi 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 (TSRVAj) and Sell Items (TBRVAj) are the sum of QBSABmj and QBSASmi 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 (TSOVAj) and Sell Items (TBOVAj) are the sum of QBSABmj and QBSASmi 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:
TCQj = {Σw QSBwj – Σw QSSwj} / 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:
NIVj = Σw QSBwj – Σw (-QSSwj)
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 (SBPj) 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ΣnΣk {QAOknij * TLMij} + Σm {QBSABmj + ΣtQSIVt + QSDCj + QBDCj}+ ΣJ {VGBjJ} + {RRAUSBj} is not equal to zero, then the System Buy Price will be determined as follows: SBPj = {ΣiΣnΣk {QAOknij * POnij * TLMij} + Σm {QBSABmj * BSAPmj} + Σt {QSIVtj * STAPtj} + {QSDCj + QBDCj} * VoLL} } + ΣJ {VGBJ * QHRRAPJ} + {RRAUSBj * 0} _______________________________________________________________________________________________ + {BPAj} {ΣiΣnΣk {QAOknij * TLMij} + Σm QBSABmj + Σt QSIVtj + QSDCj + QBDCj } + ΣJ {VGBjJ} + {RRAUSBj}
where Σi represents the sum over all BM Units; Σk represents the sum over all Acceptances; Σn 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 POnij 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 BSAPmj is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); BPAj is the Buy-Price Price Adjustment; and The System Sell Price SSPj = SBPj.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In respect of each Settlement Period, if the Net Imbalance Volume is not equal to zero and is a negative number, and {ΣiΣnΣk {QABknij * TLMij} + Σm {QBSASmj} + ΣJ {VGBjJ} + {RRAUSBj} is not equal to zero, then the System Sell Price will be determined as follows: SSPj = {SPAj} +
{ΣiΣnΣk {QABknij * PBnij * TLMij} + Σm {QBSASmj * BSAPmj}} + ΣJ {VGBJ * QHRRAPJ} + {RRAUSBj * 0} ___________ ___________________________________________________________________________________ {ΣiΣnΣk {QABknij * TLMij} + Σm QBSASmj} + ΣJ {VGBjJ} + {RRAUSBj}
where Σi represents the sum over all BM Units; Σk represents the sum over all Acceptances; Σn 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; PBnij 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; BSAPmj is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); SPAj is the Sell-Price Price Adjustment; and The System Buy Price SBPj = SSPj. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
if {ΣiΣnΣk {QAOknij * TLMij} + ΣmQBSABmj + ΣtQSIVt + QSDCj + QBDCj} + ΣJ {VGBjJ} + {RRAUSBj} is equal to zero,
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
if {ΣiΣnΣk {QABknij * TLMij} + ΣmQBSABmj}+ ΣJ {VGBjJ} + {RRAUSSj} is equal to zero,
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 RPARd, PARd, Arbitrage Flag, DMATd, CADLd 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 (PDCj) 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 (QMij) 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 (ΣQMij) (obtained above) shall be compared with the aggregated meter reading (IMVj) (obtained from the Interconnector Metered Flow from the CDCA). The difference is the Interconnector Error Administrator Volume (ErrorVolj) 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:
ErrorVolj = IMVj - ΣiQMij
where ErrorVolj 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 QMij = Max (ErrorVolj, 0) For the consumption IEA BM Unit for the Interconnector QMij = Min (ErrorVolj, 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, QABSaj, for each Energy Account and Virtual Balancing Account, shall be calculated as follows:
QABSaj = Σ i∈a QBSij * TLMij + (Σi2QSNDi2j * TLMi2j)
Where Σi∈a in relation to QBSij represents a sum over all Primary BM Units i for which Energy Account a is the Lead Energy Account; Σi2 in relation to QSNDi2j 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; TLMij is the Transmission Loss Multiplier for Primary BM Unit i in Settlement Period j. TLMi2j 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, QAEIaj, 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 (QABCaj) and Account Period Balancing Services Volume (QABSij) from the Account Credited Energy Volume (QACEaj), as follows:
QAEIaj = QACEaj – QABSaj – QABCaj
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 TQEIj (summed across all Energy Accounts a) shall be calculated as follows:
TQEIj = Σa QAEIaj
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 (CAEIaj).shall be calculated for each Energy Account a, in Settlement Period j as follows:
If QAEIaj > 0, then
CAEIaj = -QAEIaj * SSPj ,
Otherwise, CAEIaj = -QAEIaj * SBPj ,
Where SSPj is the System Sell Price and SBPj 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, TCEIj shall be calculated as: TCEIj = Σa CAEIaj
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:
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 as follows:
QMEij = FPNij + QBSij
Where FPNij is the Period FPN and QBSij 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 (QIIij) shall be calculated for each BM Unit in each Settlement Period as follows:
QIIij = | QMij - QMEij |
This is the modulus of the difference between the Period Metered Volume (QMij) and the Period Expected Metered Volume QMEij | |||
3: The Information Imbalance Charge (CIIij) shall be calculated for each BM Unit in each Settlement Period. CIIij is calculated by multiplying the Information Imbalance Volume, QIIij, by the appropriate Information Imbalance Price, (IIP1ij or IIP2ij).
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 CIIij = QIIij * IIP1ij Else CIIij = QIIij * IIP2ij Endif
where IIP1ij is the Information Imbalance Price 1 and IIP2ij 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, TCIIj. shall be calculated for each settlement period as:
TCIIj = Σi CIIij
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.
BM / RR
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 (QNDOij) shall be calculated for each BM Unit i in each Settlement Period j by processing the Period Expected Metered Volume (QMEij), Period Meter Volume (QMij), Period Accepted Offer Volume (ΣnQAOnij) , and RR Accepted Offer Volumes (RRAOnij), as follows:
QNDOij = Min{Max{QMEij – QMij, 0}, ΣnQAOnij} + Σn RRAOnij)}
where Σn, in relation to QAOnij, represents the sum over all Bid-Offer Pair Numbers for the Accepted Offer Volumes and Σn, in relation to RRAOnij, 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 (QNDBij) shall be calculated for each BM Unit I in each Settlement Period j by processing the Expected Period Meter Volume (QMEij), Period Meter Volume (QMij), and Period Accepted Bid Volume (ΣnQABnij) , and RR Accepted Bid Volumes (RRABnij), as follows:
QNDBij = Max {Min{QMEij - QMij,0}, ΣnQABnij }+ Σn RRABnij)
where Σn, in relation to QABnij, represents the sum over all Bid-Offer Pair Numbers for the Accepted Bid Volumes and Σn, in relation to RRABnij, 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 (QNDOnij) shall be calculated as follows. If QNDOij > 0, then the Period BM Unit Non-Delivered Offer Volume is apportioned across all accepted Offers (AOnij), (being Accepted Offer Volumes (QAOnij) and for upward RR Activations within the Settlement Period the associated Deemed Standard Product Offer Volume (DSPOJij) and the Replacement Reserve Instructed Offer Deviation Volume (IODij)), to determine values of Offer Non-Delivery Volume.
In each Settlement Period, the set of all accepted Offers (i.e. Offers for which AOnij >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 {AOn1ij, AOn2ij, …….. AOnuij} 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: QNDOnij = Min(AOnuij, RQNDOu-1ij)
Where RQNDOu-1ij is the Remaining Period BM Unit Non-Delivered Offer Volume determined as: RQNDOuij = RQNDOu-1ij - QNDOnu-1ij and RQNDO0ij = QNDOij, and QNDOn0ij = 0
| |||
4: The Bid Non-Delivery Volume (QNDBnij) shall be calculated as follows If QNDBij < 0, then the Period BM Unit Non-Delivered Bid Volume is apportioned across accepted Bids (ABnij), (being Accepted Bids Volumes (QABnij) and for downward RR Activations within the Settlement Period the associated Deemed Standard Product Bid Volume (DSPBJij) and the Replacement Reserve Instructed Bid Deviation Volume (IBDij)), to determine values of Bid Non-Delivery Volume.
In each Settlement Period, the set of all accepted Bids (i.e. Bids for which ABnij <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 {ABn1ij, ABn2ij, …….. ABnuij, } 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:
QNDBnij = Max(ABnuij, RQNDBu-1ij)
Where RQNDBu-1ij is the Remaining Period BM Unit Non-Delivered Bid Volume determined as: RQNDBuij = RQNDBu-1ij - QNDBnu-1ij and RQNDB0ij = QNDBij and QNDBnojj= 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 (CNDOnij) shall be calculated for the non-delivery of Offer n in Settlement Period j from BM Unit i, as follows:
CNDOnij = QNDOnij * Max {(NDPOnij – SBPj ), 0}* TLMij
Where SBPj is the System Buy Price, NDPOnij is the Offer Price and TLMij is the Transmission Loss Multiplier for that BM Unit and Settlement Period.
NDPOnij is the Non-Delivered Offer Price for each Accepted Offer allocated a Non-Delivery Volume and will vary depending on the following:
Where RRAPJ is the Replacement Reserve Activation Price associated to the Quarter Hour RR Activation.
| |||
2:The Non-Delivered Bid Charge (CNDBnij) shall be calculated for the non-delivery of Bid n in Settlement Period j from BM Unit i, as follows:
CNDBnij = QNDBnij * Min {(NDPBnij – SSPj), 0} * TLMij
Where SSPj is the System Sell Price, NDPBnij is the Bid Price and TLMij is the Transmission Loss Multiplier for that BM Unit and Settlement Period. NDPBnij is the Non-Delivered Bid Price for each Accepted Bid allocated a Non-Delivery Volume and will vary depending on the following:
Where RRAPJ is the Replacement Reserve Activation Price associated to the Quarter Hour RR Activation and BEDPij is the Balancing Energy Deviation Price (BEDPj) 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 (CNDij).shall be calculated for the non-delivery of Bids and Offers in Settlement Period j from BM Unit i, as follows:
CNDij = Σn (CNDOnij + CNDBnij) | |||
4: The Total System Non-Delivery Charge (TCNDj) shall be calculated for the non-delivery of Bids and Offers in Settlement Period j, summed across all BM Units, as follows:
TCNDj = Σi CNDij | |||
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 (CSOj) shall be calculated by subtracting the Total System Non-Delivery Charge (TCNDj) from the Total System BM Cashflow (TCBMj) for each Settlement Period. Specifically: CSOj = (TCBMj + TCRRj) – TCNDj | |||
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 (TRCj) shall be calculated as follows: TRCj = TCIIj + CSOj + TCNDj – TCBMj- TCRRj + TCEIj 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 (TCIIj), Total System Non-Delivery Charge (TCNDj), System Operator Cashflow (CSOj), Total System BM Cashflow (TCBMj) and Total System Energy Imbalance Cashflow (TCEIj). | |||
2: The Residual Cashflow Reallocation Proportion (RCRPaj) to be allocated to each Energy Account (excluding the SO’s (NETSO’s) account) in each Settlement Period shall be calculated as follows:
RCRPaj = {Σ+(non-I) (QCEaij) + Σ-(non-I) (-QCEaij )} / Σa {Σ+(non-I) (QCEaij) + Σ-(non-I) (–QCEaij)} 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 QMij >= 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 QMij < 0) is a Consumption Account. Note that Σa RCRPaj 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 (RCRDj) in each Settlement Period shall be defined as the denominator in the expression for RCRPaj above. | |||
4: The Residual Cashflow Reallocation Cashflow (RCRCaj.) shall be calculated by multiplying the Residual Cashflow Reallocation Proportion with the Total System Residual Cashflow, as follows: RCRCaj = RCRPaj * TRCj This represents the proportion of the Total System Residual Cashflow allocated to the Energy Account a.
| |||
Non-Functional Requirement: | |||
| |||
Interfaces: | |||
| |||
Issues: | |||
|
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 (ECQzbaj). The NETSO’s (SO) Energy Contract Volumes and Credited Energy Volumes will be excluded from these calculations. (i) Σ+(QCEaij,) 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 QMij >= 0); and (ii) Σ-(-QCEaij), 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 QMij < 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: | |||
|
Requirement ID: SAA-F019 | Status: M | 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: | |||
|
Requirement ID: SAA-F020 | Status: M | 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):
For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):
| |||
Non-Functional Requirement: | |||
| |||
Interfaces: | |||
SAA-I030 | |||
Issues: | |||
|
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: | |||
|
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: | |||
|
Requirement ID: SAA-F023 | Status: M | 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: | |||
|
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:
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: | |||
|
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. |
Requirement ID: SAA-F026 | Status: Mandatory | Title: Process Emergency Acceptance Data | BSC reference: P172 |
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. 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 BPAj = existing BPAj + BPA adjustmentj Adjusted SPAj = existing SPAj + SPA adjustmentj 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'. 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. |
Requirement ID: SAA-F026 | Status: Mandatory | Title: Calculate BM Unit Gross 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.
TLM-Adjusted BM Unit Gross Demand = – TLMij * 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.
TLM-Adjusted BM Unit Gross Demand = TLMij * min (QMij, 0)
| |||
Non Functional Requirement: | |||
| |||
Interfaces: | |||
SAA-I041: BM Unit SVA Gross Demand Data File SAA-I042: BM Unit Gross Demand Report |
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: QTUErj = Σ(non-S) max(QMij, 0) + ΣN(AE) | CORCiNj | 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: QTUIrj = Σ(non-S) min(QMij, 0) – ΣN(AI) | CORCiNj | 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 QTUErj + QTUIrj > 0; or "Offtaking" if QTUErj + QTUIrj ≤ 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 |
Requirement ID: SAA-F030 | Status: M | 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:
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 (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.
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:
| ||||||||||||
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.
| ||||||||||||
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:
In order to identify the start times (t0) and end times (t1) 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: (2) Where
The (time, MW) coordinates will define the RR Schedule Product Point Variables (qRRSkijt) 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:
| ||||||||||||
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 5th minute of the quarter hour. | ||||||||||||
8. Create a final ramp SAA shall schedule ramps that comply with the following:
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:
| ||||||||||||
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).
* RRS = RRA is true when that iteration of the RR Schedule ramp has reached the RR Activation.
| ||||||||||||
Non-Functional Requirement: | ||||||||||||
| ||||||||||||
Interfaces: | ||||||||||||
| ||||||||||||
Issues: |
Requirement ID: SAA-F031 | Status: M | 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 (RRAJ) in the RR Auction Period.
| |||
2. SAA will create Deemed Product Point Variables(qDSPJijt) 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) qDSPJijt will have the same format and structure as other BSC point variables as per BSC X-2 4.4 | |||
Non-Functional Requirement: | |||
| |||
Interfaces: | |||
| |||
Issues: | |||
| |||
Issues: |
Requirement ID: SAA-F032 | Status: M | 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 (QSNDij) for each Secondary BM Unit is the amount determined as follows:
QSNDij = Max{ Min( QBSij, QNDOij ) , QNDBij }
And
2: The Period Secondary BM Unit Delivered Volume (QSDij) for each Secondary BM Unit is the amount determined as follows:
QSDij = QBSij -QSNDij
| |||
3: The Secondary BM Unit Supplier Delivered Volume (QSDiji2) for each Secondary BM Unit "i2", for each Primary BM Unit "i" for the period is determined as follows:
QSDiji2 = QSDi2j * SPiji2
Where the Period Secondary BM Unit Delivered Proportion (SPiji2) is determined as a weighted average of Secondary BM Unit Supplier Delivered Volume, VBMUSDViji2:
SPiji2 = VBMUSDViji2 / ΣiVBMUSDViji2
where Σi represents the summation over all Primary BM Units "i" and VBMUSDViji2 is 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 (QBSDij) is the amount determined as follows:
QBSDij = Σi2QSDiji2
where Σi2 represents the sum over all Secondary BM Units i2 for which Primary BM Unit "i" is to be allocated a value of QSDiji2.
| |||
Non-Functional Requirement: | |||
| |||
Interfaces: | |||
| |||
Issues: | |||
| |||
Issues: |
Requirement ID: SAA-F033 | Status: M | 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 (qDSPVJij(t)) is calculated as follows:
qDSPVJij(t) = qDSPJij(t) - qDSPJ-1ij(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 qDSPJij(t) has been determined in the Settlement Period which has a qDSPJij(t) then qDSPJ-1ij(t) shall be set equal to zero.
| |||
2. The Deemed Standard Product Offer Volume (qDSPOJij(t)) and Deemed Standard Product Bid Volume (qDSPBJij(t)) for Accepted Offers and Bids are calculated as follows:
qDSPOJij(t)) = max (qDSPVJij (t) , 0 )
qDSPBJij (t)) = min (qDSPVJij(t) , 0 )
| |||
3. The Period Deemed Standard Product Offer Volume (DSPOJij) and Period Deemed Standard Product Bid Volume (DSPBJij) in each settlement period for each BM Unit are calculated by integrating (DSPOJij) and (DSPBJij), 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:
| |||
4: The Total Period Deemed Standard Product Offer Volume (TDSPOij) and Total Period Deemed Standard Product Bid Volume (TDSPBij) are calculated as follows:
TDSPOij = Σ J DSPOJij
TDSPBij = ΣJ DSPBJij
For each Settlement Period J and each BM Unit i and are measured in MWh.
| |||
5: The Replacement Reserve Instructed Offer and Bid Deviation (IODij, IBDij) shall be calculated respectively as:
IODij = Σn RRAOnij - TDSPOij
IBDij = Σn RRABnij - TDSPB ij
IODij and IBDij are 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: |
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)
BSC Party
BSCCo Ltd
NETSO (SO)
Interconnector Administrator (IA)
Interconnector Error Administrator (IEA)
Reqt No. | Interface Requirement | Inbound/ Outbound | Interface User (IU) | Mechanism |
SAA-I001 | Receive Registration Data | Inbound | CRA | Via shared database |
SAA-I002 | Receive Credit Assessment Load Factor | Inbound | CRA | Via shared database |
SAA-I003 | Receive Balancing Mechanism Data | Inbound | BMRA | Automatic |
SAA-I004 | Receive Period Meter Data | Inbound | CDCA | Via shared database |
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 | Via shared database |
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 | Via shared database |
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-I043 | Demand Control Instructions to CDCA | Outbound | CDCA | Via shared database |
SAA-I044 | Aggregated BM Unit Disconnection Volumes | Inbound | CDCA | Via shared database |
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 |
Requirement ID: SAA-N001 | Status: M | 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. |
Requirement ID: SAA-N002 | Status:
| Title: Requirement not currently used | BSC reference: |
Man/auto:
| Frequency: | Volumes: | |
Non Functional Requirement: | |||
|
Requirement ID: SAA-N003 | Status: M | 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. |
Requirement ID: SAA-N004 | Status:
| Title: Requirement not currently used | BSC reference: |
Man/auto: | Frequency: | Volumes:
| |
Non Functional Requirement: | |||
|
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. |
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. |
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 |
|
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 |
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; |
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; |
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 Note that details of the SAA-I017 (Data Exception Report) flow have not been included in this diagram, in order to avoid excessive clutter.