BSCP 18: Corrections to Bid-Offer Acceptance Related Data

v 14.0
Effective From Date:
Status:SUPERSEDED
Other versions
Download

Balancing and Settlement Code

BSC PROCEDURE

Corrections to Bid-Offer Acceptance Related Data

BSCP18

Version 14.0

Date: 24 October 2022

BSCP18

relating to

Corrections to Bid-Offer Acceptance Related Data

1. Reference is made to the Balancing and Settlement Code dated Code Effective Date and, in particular, to the definition of “BSC Procedure” in Section X, Annex X-1 thereof.

2. This is BSC Procedure 18, Version 14.0 relating to Corrections to Bid-Offer Acceptance Related Data.

3. This BSC Procedure is effective from 24 October 2022.

4. This BSC Procedure has been approved by the BSC Panel.

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

AMENDMENT RECORD

Version

Date

Description of Changes

Changes Included

Mods/ Panel/

Committee Refs

1.0

30/06/04

Designated version

CP995

2.0

BETTA Effective Date

BETTA 6.3 rebadging changes for the CVA Feb 05 Release

BETTA 6.3

3.0

02/11/05

CVA Programme November 05 Release

P172

Panel

4.0

05/11/09

November 09 Release

CP1176 (Part)

ISG68/02

SVG67/02

CP1283

ISG100/01

P217

Panel 142/06

P231

Panel 155/04

5.0

04/11/10

November 10 Release

P257

Panel

6.0

31/03/14

Modification P276

P276

ISG154/03

7.0

26/06/14

June 2014 Release

CP1400

ISG151/04

8.0

26/02/15

February 2015 Release

CP1392

ISG149/06

9.0

05/11/15

November 2015 Release

P323

P245/06

10.0

29/03/19

29 March 2019 Standalone Release

P369

P285/12

11.0

27/06/19

June 2019 Release

P367 Self-Governance

SVG219/02

ISG216/01

12.0

11/12/19

December 2019 Standalone Release

CP1517

ISG220/01

13.0

27/02/20

February 2020 Release

P394 Self Governance

P297/07

14.0

30/09/2022

September Special Releae

P447

P330c/01

1 Introduction

1.1 Scope and Purpose of the Procedure

This BSC Procedure (BSCP) defines the processes that BSCCo, the Settlement Administration Agent (SAA), the National Electricity Transmission System Operator (NETSO) and BSC Parties will use. This is specifically to input corrections to erroneous Final Physical Notification (FPN), Bid-Offer Data (BOD), Bid-Offer Acceptance Level (BOAL)1 and Bid-Offer Acceptance Level Flagged (BOALF)2 data (collectively referred to as the ‘Bid-Offer Acceptance Related Data’) and Replacement Reserve data within the Settlement Administration Agent (SAA) systems or Balancing Mechanism Reporting Agent (BMRA) systems. For the avoidance of doubt, the correction of erroneous Bid-Offer Acceptance Data or Replacement Reserve Data means correcting incorrect data, or removing non-applicable data (e.g. Winter Contingency Offers) or inserting missing data. All changes relating to volume (MW, Time and Duration) are submitted by the NETSO with agreement of the affected BSC Parties (except for Winter Contingency Notifications), and are authorised by BSCCo.

This procedure also defines the process that BSCCo, the Settlement Administration Agent and the NETSO will use to input manual corrections to erroneous SO-Flagged data fields within the BOALF data changes are submitted by the NETSO and are authorised by BSCCo, agreement is not required from BSC Parties because they are not directly impacted by a flag change.

This BSCP describes the key interfaces and timetables for inputting changes to the affected BMRA and SAA systems. All corrections to the Bid-Offer Acceptance related data and to Replacement Reserve data must have the consent of the associated BSC Parties (aside from SO-Flag changes and Winter Contingency Notifications) and corrections must be applied before the Initial Settlement Run (SF). If consent, or in the case of Winter Contingency Notification or SO-Flag correction notification from the NETSO, is not received prior to SF then the data corrections must be raised as a Trading Dispute and progressed through the Trading Disputes process in accordance with BSCP11.

1.2 Main Users of the Procedure and their Responsibilities

The main users of this BSCP are:

    • BSCCo – witness and authorise the correction process for each change made (including SO-Flag changes and Winter Contingency Notifications) and confirm that any corrections made are in accordance with the changes agreed (excluding SO-Flag changes and Winter Contingency Notifications) between the affected BSC Parties and the NETSO.

    • BSC Parties – confirm that settlement error has occurred and agree to the proposed corrections (excluding SO-Flag changes and Winter Contingency Notifications).

    • NETSO – submit corrections directly to the SAA for manual update prior to the Initial Settlement Run. After this point, all corrections must be submitted using the Trading Disputes process detailed in BSCP11.

    • BMRA – receives corrections via electronic transfer (FTP) directly from the NETSO.

    • SAA – receives corrections from NETSO or BMRA and determines the most appropriate changes to be made to the database in order to ensure that the data concerning the Bid-Offer Acceptance or Replacement Reserve data accurately reflects the steps taken by the affected BSC Parties and / or the SO-Flag field is correctly reflected in the database.

1.3 Use of the Procedure

The remaining sections in this document are:

Section 2 – Not Used.

Section 3 - Interface and Timetable Information: this section defines in more detail the requirements of each business process.

1.4 Balancing and Settlement Code Provision

This BSCP should be read in conjunction with the BSC and in particular Sections Q, T, U and W. This BSCP has been produced in accordance with the provisions of the BSC. In the event of an inconsistency between the provisions of this BSCP and the BSC, the provisions of the BSC shall prevail.

1.5 Associated BSC Procedures

BSCP01 Overview of Trading Arrangements

BSCP11 Trading Disputes

1.6 Acronyms and Definitions

1.6.1 List of Acronyms

The terms used in this BSCP are defined as follows;

BOA

Bid-Offer Acceptance

BOAL

Bid-Offer Acceptance Level

BOALF

Bid-Offer Acceptance Level Flagged

BOD

Bid-Offer Data

BSAD

Balancing Services Adjustment Data

BSC

Balancing and Settlement Code

BSCCo

Balancing and Settlement Code Company

BSCP

Balancing and Settlement Code Procedure

FPN

Final Physical Notification

II

Interim Information Settlement Run completed 5 Working Days after the Settlement Day

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.

RR

Replacement Reserve

SAA

Settlement Administration Agent

SD

Settlement Day

SF

Initial Settlement Run completed 16 Working Days after the Settlement Day

Winter Contingency Offer

A Bid Offer Acceptance which relates to a Winter Contingency BM Unit and which must be removed from Settlement so that the Offer volume can instead be Settled as Balancing Services Adjustment Data (BSAD) and Applicable Balancing Services Volume Data (ABSVD), in accordance with Approved Modification P447.

Winter Contingency Notification

Details of the data correction required to remove a Winter Contingency Offer from Settlement.

WD

Working Day

Full definitions of the above acronyms are, where appropriate, included in the BSC.

1.6.2 Definitions

Full definitions of the above acronyms are, where appropriate, included in the Balancing and Settlement Code.

2. Not Used

3. Interface and Timetable Information

3.1 Identification and Agreement of Changes to Data (excluding changes arising from Emergency Instructions)

REF

WHEN3

ACTION

FROM

TO

INFORMATION REQUIRED

METHOD

3.1.1

No less than 8 WD before SF Run.

Identify that a data correction is required to data submitted to SAA.

BSC Party or NETSO4

NETSO

Details of data correction.

E-mail or fax, NETSO Internal reporting.

3.1.2

Within 1 WD of 3.1.1.

Review proposed data correction and determine if data correction request is valid.

NETSO

Proposed data correction.

Internal Process.

3.1.3

Within 2 WD of 3.1.2.

Provide details of proposed data correction and agree action to be taken.

NETSO

BSC Party

Proposed data correction.

Telephone contact with authorised personnel at BSC Party followed by e-mail.

3.1.3a

Within 5 WD of 3.1.2

Provide details of Winter Contingency Notification or SO-Flag correction data

NETSO

SAA

BSCCo

Proposed data correction

E-mail.

3.1.4

By 15:00 hrs within 2 WD of 3.1.3.

Agreed Data Correction received by the NETSO. Proceed to Section 3.2.1.

BSC Party

NETSO

Refer to Section 3.2.1.

E-mail.

3.1.5

15:00 hrs within 2 WD of 3.1.3.

No agreement reached on proposed corrections

Proceed to BSCP11.

NETSO or BSC Party

BSCCo, NETSO or BSC Party as appropriate.

Refer to BSCP11.

E-mail.

3.2 (a) Corrections of SAA databases for FPN, BOD and RR data)

REF.

WHEN

ACTION

FROM

TO

INFORMATION REQUIRED

METHOD

3.2.1

Following 3.1.4 and 2 WD before SF Run.

Provide SAA with FPN, BOD and/or RR data correction.

NETSO

SAA

BSCCo

Receive Request for Data Change

(SAA-I033).

E-mail.

3.2.2

Up to 1 WD before SF Run.

Update SAA database and confirm database updates have been implemented.

SAA

BSCCo

NETSO

Report Confirmation of Data Change

(SAA-I036).

E-mail.

3.2.3

Following 3.1.3a and up to 1WD before SF Run

Update SAA database and confirm database updates have been implemented

SAA

BSCCo

NETSO

Report Confirmation of Data Change

E-Mail.

3.2 (b) Corrections of BMRA and SAA databases (for BOA Changes excluding Emergency Instructions)

Changes to BOALF data (excluding those arising from Emergency Instructions) are applied to the BMRA and SAA databases using an automated process as follows:

REF.

WHEN

ACTION

FROM

TO

INFORMATION REQUIRED

METHOD

3.2.3

Following 3.1.4 and 2 WD before SF Run.

Provide BMRA BOA data correction

NETSO

BMRA

Balancing Mechanism Data (BMRA‑I002)

Electronic.

3.2.4

Following 3.2.3.

Provide SAA with BOA data correction

BMRA

SAA

SAA Balancing Mechanism Data (SAA‑I003)

Electronic.

3.3. No longer used

3.4. Corrections to SAA Databases arising from Emergency Instructions

The process is triggered by the issue of an Emergency Instruction by the NETSO.

In accordance with the Grid Code and Section Q5.1.3(b) of the BSC, Emergency Instructions issued in respect of a BM Unit shall be treated as Bid-Offer Acceptances, except certain Black Start processes, Maximum Generation Service and Emergency De-energisation Instructions5.

The NETSO identifies Emergency Instructions as being either:

    • Emergency Acceptances’; or

    • ‘Emergency Flagged’ Acceptances.

BSC Annex T-1 details how Emergency Instructions are treated in the Energy Imbalance Price calculations.

REF.

WHEN

ACTION

FROM

TO

INFORMATION REQUIRED

METHOD

3.4.1

As soon as possible after issuing Emergency Instruction

Send details of Emergency Acceptance to BMRA and BSCCo.

NETSO

BMRA

BSCCo

Receive System Related Data (BMRA-I003)

Time of Emergency Instruction

Affected BM Unit (s)q

Electronic.

Phone/Fax/E-mail.

3.4.2

Upon receipt of information following 3.4.1

Publish notice on BMRS6

BMRA

BMRS Users

Publish System Related Data (BMRA-I005)

Time of Emergency Instruction

Affected BM Unit (s)

Electronic.

3.4.3

Upon receipt of information following 3.4.1

Log details of Emergency Acceptance and allocate reference number.

BSCCo

Details of Emergency Acceptance. BSC Service Desk reference number.

Internal Process.

3.4.4

As soon as possible after 3.4.3

Provide reference number for Emergency Acceptance.

BSCCo

NETSO

BSC Service Desk reference number.

Phone/Fax/E-mail.

3.4.5

After 3.4.1 and where possible, at least 1 WD prior to II Run7

Identify and agree Emergency Instruction related Acceptance with BSCCo and Party.

NETSO

BSCCo

Party

Acceptance Data arising from Emergency Instruction

Phone/Fax/E-mail.

Decide whether it is to be treated as ‘Emergency Flagged’.

NETSO

Decision on whether the Emergency Acceptance is to be treated as ‘Emergency Flagged’.

Internal Process.

3.4.6

After 3.4.5 and where possible at least 1 WD prior to II Run

Send Acceptance Data and details of approach for settling Emergency Instruction to the BMRA, SAA and BSCCo.

NETSO

BMRA

SAA

BSCCo

Receive System Related Data (BMRA-I003)

Receive Request for Data Change (SAA-I033)

Acceptance Data arising from Emergency Instruction

Specify whether the Emergency Acceptance is to be treated as ‘Emergency Flagged’.

Electronic.

Phone/Fax/E-mail.

3.4.7

Upon receipt of information after 3.4.6

Publish details of Acceptance Data to be entered into Settlement and whether it is to be treated as ‘ Emergency Flagged’6

BMRA

BMRS Users

Publish System Related Data (BMRA-I005)

Acceptance Data arising from Emergency Instruction

Electronic.

3.4.8

Upon receipt of information after 3.4.6

Acknowledge receipt of Acceptance Data and approach for settling Emergency Instruction.

BSCCo

NETSO

Acknowledgement of receipt

Phone/Fax/E-mail.

3.4.9

Upon receipt of information after 3.4.6

Request authorisation to input post event Acceptance Data in SAA Database.

SAA

BSCCo

Report Recommended Data Change (SAA-I034)

Phone/Fax/E-mail.

3.4.10

As soon as possible after 3.4.9

Authorise input of post event Acceptance Data in SAA Database.

BSCCo

SAA

Receive Instruction for Data Change

(SAA-I035)

Acceptance Data arising from Emergency Instruction.

Phone/Fax/E-mail.

3.4.11

As soon as possible after 3.4.10 and where possible, prior to II run

Enter post event Acceptance Data into SAA Database and provide confirmation Database has been updated.

SAA

BSCCo

NETSO

Acceptance Data arising from Emergency Instruction

Report Confirmation of Data Change

(SAA-I036).

Internal Process.

Phone/Fax/E-mail.

1 For Settlement Days before the implementation of Approved Modification P217.

2 For Settlement Days on or after the implementation of Approved Modification P217.

3 The relevant BSC Party and NETSO are required to adhere to the timeframes set out above. However, in exceptional circumstances, which shall be determined by the NETSO e.g. where a number of data corrections are issued in close succession, these timeframes may not be practical. Where the NETSO has deemed that exceptional circumstances exist, the NETSO and the SAA shall determine and notify the BSC Party of the alternative process to be used. For the avoidance of doubt, BSC Parties are expected to contact the NETSO as soon as they become aware of any potential issues.

4 The SAA may also notify NETSO of any such errors.

5 For Settlement Periods falling within both a Black Start Period and a Market Suspension Period, no Emergency Instructions shall be treated as Bid-Offer Acceptances. For Settlement Periods falling within a Black Start Period but not within a Market Suspension Period, any Emergency Instructions issued under BC2.9.1.2(e) of the Grid Code shall not be treated as a Bid-Offer Acceptances. See BSC Section G3, BSCP201 and Grid Code BC2 for further details.

6 Notice to be published using the BMRSSystem Warning’ function.

7 In exceptional circumstances, e.g. where a number of Emergency Instructions have been issued in close succession, the II run target may not be met. In such cases, the data shall be entered into Settlement in time for the Initial Settlement Run (SF Run). A Trading Dispute will need to be raised to enter such data into Settlement after the SF Run.