My BSC Dashboard Subscriptions Kinnect Customer Solution

Next version

1. Introduction

2. Not Used

3. Interface and Timetable Information

4. Appendices

AMENDMENT RECORD – BSCP503

BSCP503: Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS

v 30.0

Effective From Date:23/02/2023

Status:LIVE

Other versions

Download

BSC Procedure 503 relating to Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS

1. Reference is made to the Balancing and Settlement Code (the Code) for the Electricity Industry in Great Britain and, in particular, to the definition of "BSC Procedure".

2. This is BSCP503, Version 30.0 relating to Half Hourly Data Aggregation for SVA Metering Systems registered in SMRS.

3. This BSC Procedure is effective from 23 February 2023.

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

1. Introduction

1.1 Scope and Purpose of the Procedure

This BSC Procedure defines the processes that the Half Hourly Data Aggregator (HHDA) shall use for data aggregation for SVA Metering Systems with Half Hourly (HH) SVA Metering Equipment.

This BSC Procedure focuses on the interfaces between the HHDA and other Agencies seen from the perspective of the HHDA.

The purpose of this procedure is:

to ensure that the work of the HHDA is carried out in an orderly manner and in accordance with the registration in the Supplier Meter Registration Service (SMRS);
to achieve the proper aggregation of half hour consumption data received from the HH Data Collector (HHDC) together with calculated line loss consumption data;
to provide this and other information timely to the Supplier Volume Allocation Agent (SVAA) and to each Supplier for whom the HHDA is registered in SMRS; and
where requested by the SVAA, to provide non-aggregated Half Hourly Metered Volumes for individual SVA Metering Systems (‘Metering System Half Hourly Metered Volumes’) to the SVAA.

1.2 Main Users of Procedure and their Responsibilities

This BSC Procedure should be used by Suppliers and their agent(s), the SVAA, and by each SMRA and each Licensed Distribution System Operator (LDSO).

The HHDA shall be responsible to the Supplier for processing data for all Settlement Days (i.e. until final reconciliation of each day’s data takes place in SVAA) within the period of the HHDA’s registration in the SMRS in accordance with BSCP501 (Supplier Meter Registration Service).

From time to time the HHDA may also be instructed by the SVAA to report an individual Metering System’s metered data to the SVAA (i.e. Allocated Metering System Metered Consumption). Where instructed, in accordance with section 3.7 below, the HHDA must send such metered data to the SVAA in respect of all Settlement Days from the Effective From Date of the instruction and for each Volume Allocation Run (i.e. until final reconciliation of each day’s data takes place in SVAA), but only within the period of the HHDA’s appointment in the SMRS in accordance with BSCP501 (Supplier Meter Registration Service) or until the SVAA instructs the HHDA to stop reporting in accordance with section 3.8 below. Similarly, if a HHDA is instructed to commence reporting metered data from a given Settlement Day that does not coincide with a current or future period of appointment in the SMRS then the HHDA must reject the SVAA’s instruction.

The SVAA may instruct HHDAs to report Allocated Metering System Metered Consumption for a number of reasons, e.g. to support the provision of Metered Data for Secondary BMUs and/or for SVA Non-Final Demand Facilities. As a consequence there are a number of scenarios in which the SVAA may instruct HHDAs to commence reporting, to update an existing instruction or to cease reporting. These scenarios are described in Appendix 4.6.1.

The HHDA shall record sufficient details received from the Supplier to enable the HHDA to perform its functions as HHDA. The details shall include the HHDA’s registration in the applicable SMRS to a SVA Metering System, the relevant SVA Metering System Number, the Identifiers for the HHDC and the relevant LDSO. These details shall also include the Settlement Days for which the HHDA is appointed.

The HHDA shall ensure that, for each SVA Metering System for which it is responsible, energy consumption data is aggregated and passed to the SVAA using systems and processes approved in accordance with BSCP537 and in accordance with the SVAA Calendar.

Where the SVAA has specified to the HHDA that metered volumes are required for a MSID in the SVA Metering System Register, the HHDA shall ensure that Metering System Half Hourly Metered Volumes are passed to the SVAA. For the avoidance of doubt, any such Metering System Half Hourly Metered Volumes should not be excluded from the aggregated energy consumption data passed to the SVAA.

The systems and processes used by the HHDA must comply with all other applicable requirements set out in the Code, PSL100 and BSCP537.

The HHDA will receive active energy data from the HHDC in kWh and in clocktime, will convert it to MWh, and send it to SVAA. The HHDA will aggregate the half hourly energy to GSP Group, Supplier, Consumption Component Class, BM Unit¹ and Settlement Period, and for Metering Systems registered to Measurement Classes F or G, Line Loss Factor Class. The line losses must be determined separately from the consumption or generation, and must also be given in MWh. The number of SVA Metering Systems contributing to each Consumption Component Class must be recorded with the aggregated data.

Where a Demand Disconnection occurs as part of a Demand Control Event, the HHDA will receive estimates of the disconnection volume, in kWh and in clocktime, for each impacted MSID. The HHDA will aggregate the estimated disconnection volumes to GSP Group, Consumption Component Class, BM Unit and Settlement Period level, and will determine for each Consumption Component Class, a corresponding volume of disconnection line losses.

Line Loss Factors are obtained by the HHDA from BSCCo via the BSC Website, in accordance with BSCP128 (Production, Submission, Audit and Approval of Line Loss Factors).

SVAA is responsible for providing Market Domain Data (MDD) in accordance with BSCP508 (Supplier Volume Allocation Agent).

In the event of any dispute as to whether an item of MDD is appropriate or, as the case may be, affects the accuracy of Settlement, the decision of the Panel shall be conclusive.

Where the HHDA has not received data in sufficient time to enable it to fulfil its obligations as HHDA the HHDA shall request from the Supplier or its agent that the data that has not been received be supplied forthwith.

Once the HHDA is the registered agent for a Settlement Day the HHDA will remain responsible for the Interim Information Volume Allocation Run, the Initial Volume Allocation Run and subsequent Reconciliation Volume Allocation Runs until the Final Reconciliation Volume Allocation Run of that Settlement Day has been completed. Furthermore the HHDA shall support any Post Final Reconciliation Volume Allocation Runs and Extra-Settlement Determinations. On termination of the HHDA’s appointment by the Supplier, the HHDA shall ensure that its obligations, including EMR responsibilities (see section 1.2A), will be discharged until the Final Reconciliation Volume Allocation Run and will retain data in accordance with PSL100.

The HHDA shall ensure that in the event that it ceases to operate, plans are in place for data and other information to be transferred to the Supplier so that the obligations of the Supplier under the Code can continue to be discharged.

The HHDA shall ensure that it is able to transfer data and other information to the Panel immediately in the event that the HHDA ceases to operate at the same time as the Supplier.

The HHDA shall, in accordance with this BSCP, request and load a Full Refresh from a SMRS comprising the complete registration and standing data for all SVA Metering Systems for which the HHDA is responsible in that SMRS whenever it is required to ensure the integrity of the HHDA’s database.

The HHDA shall acknowledge receipt of all files received from a SMRS by an automatic acknowledgement by the HHDA’s gateway in the Managed Data Network.

In any case where a data transfer defined in this BSCP503 is carried out by the HHDA by a method other than the Managed Data Network, the HHDA shall ensure that receipt thereof is acknowledged by the recipient by an appropriate means.

The SVAA will be managing the Market Domain Data in addition to performing the Supplier Volume Allocation role, and therefore SVAA is the Market Domain Data Manager (MDDM).

1.2A EMR Responsibilities

The HHDA shall send to the CfD Service Provider and the CM Service Provider Half Hourly metered data for specific Metering Systems for which it is responsible. The HHDA’s Supplier shall instruct the HHDA of the specific Metering Systems. The data shall be submitted for each VAR and in accordance with the SVAA calendar. Please note that this requirement is for the purposes of submitting certain Capacity Market Capacity Providers, and certain Energy Intensive Industry (EII) SVA Customers energy volumes to EMR settlement.

Once the HHDA has accepted to send the metered data for specific Metering Systems it must continue to send the metered data for all Settlement Days from the effective from settlement date to the effective to settlement to date in the instructions.

1.3 Use of the Procedure

The remaining sections in this document are:

Section 2 – This Section is no longer used.

Section 3 - Interface and Timetable Information: this section defines in detail each business process. In addition, there may be references to ‘D’ (Energy Market Data Specification) and ‘P’ (BSC SVA Data Catalogue dataflows in the ‘Information Required’ column.

Section 4 - Appendices: this section contains supporting information, including validation details. For any information received, validation of the sender’s Id is carried out against the appropriate MDD held by the HHDA.

1.4 Balancing and Settlement Code Provision

This BSC Procedure has been produced in accordance with the provisions of the Balancing and Settlement Code (the Code). In the event of an inconsistency between the provisions of this BSC Procedure and the Code, the provisions of the Code shall prevail.

The requirements of HHDAs under the Code can be found in BSC Section J ‘Party Agents’ and S ‘Supplier Volume Allocation’. The principal functions of a HHDA are:

(a) Receive half-hourly data from the relevant HHDC;

(b) Validate data and provide reports;

(d) Maintain relevant standing data;

(e) Receive and maintain Line Loss Factors provided by BSCCo and approved by the Panel;

(f) Aggregate the metered data in MWh in the relevant data aggregation system;

(g) Receive and maintain Additional BM Unit data for each Supplier (in respect of which the HHDA is appointed) and to receive, validate and maintain details of the SVA Metering Systems for which such Supplier is the Registrant allocated by that Supplier to its Additional BM Units in the same GSP Group; and

(h) Provide to the SVAA data aggregated by Supplier BM Unit or by Supplier and by GSP Group in accordance with the further provisions of Section S.

(i) Provide, where applicable, Half Hourly metered data for the Capacity Market to the CM Settlement Services Provider in accordance with Section S 2.9.

(j) Provide, where applicable, Half Hourly metered data for the CFD Arrangements to the CfD Settlement Services Provider in accordance with Section S 2.10; and

(k) Provide, where requested by the SVAA, Half Hourly MSID Metered Volumes to the SVAA.

1.5 Associated BSC Procedures

BSCP01	Overview of Trading Arrangements.
BSCP11	Trading Disputes.
BSCP128	Production, Submission, Audit and Approval of Line Loss Factors
BSCP501	Supplier Meter Registration Service.
BSCP502	Half Hourly Data Collection for Metering Systems Registered in SMRS.
BSCP507	Supplier Volume Allocation Standing Data Changes
BSCP508	Supplier Volume Allocation Agent.
BSCP515	Licensed Distribution
BSCP537	Qualification Process for SVA Parties, SVA Party Agents, VLPS, AMVLPs, AMVLP Agents and CVA MOAs.
BSCP602	SVA Metering System & Asset Metering System Register

1.6 Acronyms and Definitions

1.6.1 Acronyms

The terms used in this BSC Procedure are defined as follows.

BM	Balancing Mechanism
BSC	Balancing and Settlement Code
BSCP	Balancing and Settlement Code Procedure
CfD	Contracts for Difference
CM	Capacity Market
DCC	Data Communications Company
DCE	Demand Control Event
DTN	Data Transfer Network
EMDS	Energy Market Data Specification
FAA	Funds Administration Agent
GSP	Grid Supply Point
HH	Half Hourly
HHDA	Half Hourly Data Aggregator
HHDC	Half Hourly Data Collector
Id	Identifier
kWh	kilowatt hour
LDSO	Licensed Distribution System Operator
LLF	Line Loss Factor
MDD	Market Domain Data
MDDM	Market Domain Data Manager
MSID	Metering System Identifier
MWh	Megawatt hour
NETSO	National Electricity Transmission System Operator
Ref	Reference
SMETS	Smart Metering Equipment Technical Specifications
SMRA	Supplier Meter Registration Agent
SMRS	Supplier Meter Registration Service
SVA	Supplier Volume Allocation
SVAA	Supplier Volume Allocation Agent
TUoS	Transmission Use of System
UTC	Co-ordinated Universal Time
WD	Working Day

1.6.2 Definitions

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

2. Not Used

3. Interface and Timetable Information

3.1 Market Data Activities.

3.1.1 SVAA sends Market Domain Data².

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.1.1.1	If required.	Request MDD from SVAA.	HHDA.	MDDM.	HHDA Id.	Electronic or other method, as agreed.
3.1.1.2	When published by SVAA or within 1 WD of request from HHDA.	Send MDD.	SVAA.	HHDA.	D0269 Market Domain Data Complete Set. D0270 Market Domain Data Incremental Set. D0299 Stage 2 BM Unit Registration Data File³. P0186 Half Hourly Default EAC.	Electronic or other method, as agreed.
3.1.1.3	Within 4 working hours of receipt of MDD.	Send acknowledgement that data has been received.	HHDA.	MDDM.	P0024 Acknowledgement.	Electronic or other method, as agreed.
3.1.1.4	If file not readable & / or not complete.	Send notification and await receipt of MDD.	HHDA.	MDDM.	P0035 Invalid Data.	Electronic or other method, as agreed.
3.1.1.5	After receiving notification.	Send corrected MDD.	SVAA.	HHDA.	Refer to 3.1.1.2 for dataflows.	Electronic or other method, as agreed.
3.1.1.6	As soon as possible after data in correct format.	Update records² ⁴.	HHDA.			Internal Process.

3.2 Interface To SMRS.

3.2.1 Receive Changes of SMRS Data.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.2.1.1	At any time.	Send instruction file.	SMRA.	HHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Electronic or other method, as agreed.
3.2.1.2.	Within 2 WD of receiving instruction file.	Validate instruction file in line with Appendix 4.1.	HHDA.			Internal Process.
3.2.1.3	Within 2 WD of 3.2.1.2 if File validation fails.	Report instruction file problems⁵ ⁶.	HHDA.	SMRA.	P0035 Invalid Data.	Electronic or other method, as agreed.
3.2.1.4	As soon as possible.	Re-send an exact copy of instruction file.	SMRA	HHDA.	As appropriate.	Electronic or other method, as agreed.
3.2.1.5	Within 2 WD of receipt of instruction file if file is valid.	Validate instructions in line with Appendix 4.1⁷.	HHDA.			Internal Process.
3.2.1.6	Within 2 WD of 3.2.1.5 if instruction validation fails.	Report instruction problems⁵^.	HHDA.	SMRA.	D0023 Failed Instructions.	Electronic or other method, as agreed.
3.2.1.7	As soon as possible.	Generate and send a refreshed instruction file.	SMRA.	HHDA.	As appropriate.	Electronic or other method, as agreed.
3.2.1.8	Within 2 WD of 3.2.1.5 if instruction is valid.	Process instruction & update records.	HHDA.			Internal Process.

3.2.2 Request SMRS Refresh Data.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.2.2.1	At any time for Selective Refresh. When requested by BSCCo or the Performance Assurance Board (PAB), or at any other agreed time for Full Refresh.	Request Full or Selective Refresh of database⁸.	HHDA.	SMRA.	MSID, if for Selective Refresh. For Full Refresh, all relevant data covering those Settlement dates for which a Final Reconciliation Run has not yet taken place at the time the Full Refresh is generated.	Manual.
3.2.2.2	If request refused⁹ then: within 1 WD of receipt of request.	Advise refusal.	SMRA.	HHDA.	Identification of request & reason for refusal.	Manual.
3.2.2.3	If request accepted, then within 1 WD of receipt of request for Full Refresh.	Notify HHDA of scheduled date for delivery of Full Refresh.	SMRA.	HHDA.	Scheduled date for delivery of Full Refresh.	Manual, Fax.
3.2.2.4	Within 15 WD of receipt of Full/Selective Refresh request.	Send information to refresh of HHDA’s database.	SMRA.	HHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Electronic or CD ROM, or other method, as agreed.
3.2.2.5	After receiving instruction file.	Validate instruction file information received in line with Appendix 4.1.	HHDA.			Internal Process.
3.2.2.6	If File validation fails.	Report instruction file problems⁵ ⁶.	HHDA.	SMRA.	P0035 Invalid Data.	Electronic or other method, as agreed.
3.2.2.7	As soon as possible.	Re-send an exact copy of instruction file.	SMRA.	HHDA.	As appropriate.	Electronic or other method, as agreed.
3.2.2.8	If File is valid.	Validate instructions in line with Appendix 4.1⁷.	HHDA.			Internal Process.
3.2.2.9	If instruction validation fails.	Report instruction problems⁵.	HHDA.	SMRA.	D0023 Failed Instructions.	Electronic or other method, as agreed.
3.2.2.10	As soon as possible.	Generate and send a refresh instruction file.	SMRA.	HHDA.	As appropriate.	Electronic or other method, as agreed.
3.2.2.11	If instruction is valid.	Process instructions & update records.	HHDA.			Internal Process.
3.2.2.12	If a re-send required, then anytime within 28 days of original message.	Request a re-send of original message.	HHDA.	SMRA.	Message number and / or date.	Manual.
3.2.2.13	If request refused then: within 1 WD of receipt of request.	Advise refusal.	SMRA.	HHDA.	Identification of original request & reason for refusal.	Manual.
3.2.2.14	If request accepted then: if HHDA error within reasonable endeavours if not within 36 hrs of receipt of request	Resend message.	SMRA.	HHDA.	Duplicate of original message.	Electronic or other method, as agreed.

3.3 Interface To BSCCo

3.3.1 Changes to Line Loss Factors.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.3.1.1	At any time.	Following Panel approval, send ELEXON Circular indicating new Line Loss Factors available.	BSCCo.	HHDA.	ELEXON Circular – Panel decision including information on LDSO, Effective Dates, Version and location of files on BSC Website.	E-mail.
3.3.1.2	After 3.3.1.1.	Obtain Line Loss Factors for Line Loss Factor Classes from BSC Website.	HHDA.		D0265 Line Loss Factor Data File.	File Transfer Protocol (FTP).
3.3.1.3	Validate within 6 WD of 3.3.1.1.	Validate data in accordance with Appendix 4.2¹⁰.	HHDA.			Internal Process.
		If invalid, report exceptions to sender.	HHDA.	BSCCo.		E-mail.
		If valid update records with data loaded in timestamp order.	HHDA.			Internal Process.

3.4 Aggregation Activities.

3.4.1 Receive Consumption Data from HHDC.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.4.1.1	At any time.	Send consumption data in kWh.	HHDC.	HHDA.	D0036 Validated Half Hourly Advances for Inclusion in Aggregated Supplier Matrix. or (for Half Hourly Advances retrieved by the Supplier¹¹, and where elective Half Hourly arrangements are supported by the HHDC and HHDA) D0380 Half Hourly Advances for Inclusion in Aggregated Supplier Matrix	Electronic or other method, as agreed.

REF.

WHEN

ACTION

FROM

INFORMATION REQUIRED

METHOD

3.4.1.1

At any time.

Send consumption data in kWh.

HHDC.

HHDA.

D0036 Validated Half Hourly Advances for Inclusion in Aggregated Supplier Matrix.

or (for Half Hourly Advances retrieved by the Supplier¹¹, and where elective Half Hourly arrangements are supported by the HHDC and HHDA)

D0380 Half Hourly Advances for Inclusion in Aggregated Supplier Matrix

Electronic or other method, as agreed.

3.4.2 Perform Data Aggregation Run¹².

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.4.2.1	As late as possible (to ensure most recent data from SMRS) to meet SVAA’s Calendar.	Perform checks in accordance with Appendix 4.3 and send Exception Reports, if any.	HHDA.	HHDC, Supplier.	D0235 Half Hourly Aggregation Exception Report.	Electronic or other method, as agreed.
3.4.2.2	After 3.4.2.1.	Aggregate data in line with Appendix 4.4. If invalid BM Unit data exclude the consumption of the MS(s) associated with the BM Unit from the aggregation process.	HHDA.			Internal Process.
3.4.2.3	Aggregated data to reach SVAA by the date specified in SVAA’s Calendar.	Send aggregated data in MWh & in clocktime. (Failure of the HHDC to provide consumption data must not result in failure of aggregated data being sent to the SVAA)	HHDA.	SVAA and Supplier.	D0040 Aggregated Half Hour Data File (BM Unit(s) not supported) or D0298 BM Unit Aggregated Half Hour Data File (BM Unit(s) supported).	Electronic or other method, as agreed.
3.4.2.3A	At the same time as 3.4.2.3	Where instructed by the Supplier, send EMR data in kWh and clocktime.	HHDA	CfD Service Provider and CM Service Provider	D0357 Half Hourly Metered Data for EMR	Electronic or other method, as agreed
3.4.2.3B	Upon receipt of a D0354 – Metering System Reporting Notification¹³ At the same time as 3.4.2.3	Where the HHDA is the subject of a valid/current instruction by the SVAA (in accordance with 3.7 and 3.8) and is the registered HHDA for the Metering System according to SMRS, send Metering System Half Hourly Metered Volumes in kWh and clocktime.	HHDA	SVAA	D0385 Metering System Half Hourly Metered Volumes	Electronic or other method, as agreed
3.4.2.3C	If D0385 expected in 3.2.4.3 has not been received	Notify HHDA that D0385 has not been received.	SVAA	HHDA	P0310 Missing Metering System Data	Electronic or other method, as agreed.
3.4.2.4	Within 1 WD of aggregation run.	If invalid BM Unit data send notification.	HHDA.	BSC Service Desk and Supplier.	P0035 Invalid Data.	Electronic or other method, as agreed.
3.4.2.5	Before invoking run	Load and validate incoming HHDA files. If file fails any validation check for reasons other than standing data mismatch, ask HHDA to assess if file is valid.	SVAA.	HHDA.	P0035 Invalid Data. P0311 Invalid Metering System Data (for an invalid D0385).	Electronic or other method, as agreed.
3.4.2.6	Within 2 working hours of notification received from SVAA.	If file is valid, notify the SVAA or if the file is not valid send corrected file to SVAA.	HHDA.	SVAA.	D0040 Aggregated Half Hour Data File (BM Unit(s) not supported) or D0298 BM Unit Aggregated Half Hour Data File (BM Unit(s) supported).	Electronic or other method, as agreed.

3.4.3 Perform Data Aggregation for Demand Control Events

REF	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.4.3.1	Within the period of 1WD commencing on the Business Day after the BMRA receives the data from the NETSO specified in Section Q6.9.5	Notice of the DCE sent to all Category A Authorised Persons, to establish the appropriate operational contact. The Category A Authorised Persons will be used as the contact unless another contact is provided	BSCCo	Category A Authorised Persons from BSC Parties and Party Agents	Notice of the DCE	Email or other method, as agreed.
3.4.3.2	Within the period of 1WD commencing on the Business Day after the BMRA receives the data from the NETSO specified in Section Q6.9.5	BSCCo will assess the costs and value of the DCE in accordance with the Demand Disconnection Event Threshold Rules and notify BSC Parties, Party Agents and BSC Panel Members of the outcome of its assessment	BSCCo	BSC Parties, Party Agents and BSC Panel	Notice of the outcome of BSCCo assessment	Email, Circular, BSC Website
3.4.3.3	Within 4WD of 3.4.3.2	Notify HHDC and HHDA of Demand Control Event and all affected MSIDs¹⁴	LDSO	BSCCo	P0238 MSIDs affected by Demand Control Event¹⁵ - the P0238 contains details of all MSIDs disconnected by the LDSO, i.e. for a single Demand Control Event, a single P0238 is sent by the LDSO, ultimately, to all DCs and DAs.	Email
3.4.3.4	Within 1WD of 3.4.3.3	Acting on behalf of LDSOs, BSCCo will forward notifications received from LDSOs to HHDCs, HHDAs, SVAA	BSCCo	HHDC, HHDA, SVAA	P0238 MSIDs affected by Demand Control Event	Email
3.4.3.5	Within 1WD of receiving P0241 from the National Electricity Transmission System Operator (NETSO)	Notify HHDC and HHDA of any MSIDs subject to demand side Non-BM STOR instruction along with estimated volumes of reduction¹⁶	SVAA	HHDC, HHDA	D0375 Disconnected MSIDs and Estimated Half Hourly Demand Disconnection Volumes	Electronic or other method, as agreed
3.4.3.6	Within 19WD of receipt of P0238 or after 3.4.3.5in time for next Settlement Run	Send estimated HH Demand Disconnection volume to HHDA. Where no MSIDs are impacted, report volume as zero.	HHDC	HHDA	D0375 Disconnected MSIDs and Estimated Half Hourly Demand Disconnection Volumes¹⁷	Electronic or other method, as agreed
3.4.3.7	As late as possible (to ensure most recent data from SMRS) to meet SVAA’s Calendar.	Perform checks in accordance with Appendix 4.3 and send Exception Reports, if any	HHDA	HHDC, Supplier.	Details of exception identified.	Manual
3.4.3.8	After 3.4.3.7	Aggregate disconnection data in line with Appendix 4.4. Where disconnection volume is zero, report aggregated volume as zero. If invalid BM Unit data, exclude the consumption of the MS(s) associated with the BM Unit from the aggregation process.	HHDA			Internal Process.
3.4.3.9	Aggregated data to reach SVAA by the date specified in SVAA’s Calendar.	Send aggregated disconnection data in MWh & in clocktime.	HHDA	SVAA, Supplier.	D0376 Supplier’s Demand Disconnection Volume Data File or D0378 BM Unit Aggregated Half Hour Demand Disconnection Data File (BM Unit(s) supported).	Electronic or other method, as agreed.
3.4.3.10	Within 1 WD of aggregation run.	If invalid BM Unit data send notification.	HHDA	BSC Service Desk and Supplier.	P0035 Invalid Data.	Electronic or other method, as agreed.

3.5 Balancing Mechanism Unit Standing Data Changes.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.5.1.	Must be received before Gate Closure for the period to which the BM Unit Allocation¹⁸ applies.	Send the BM Unit Allocation / revised BM Unit Allocation change proposal (following rejection of change proposal by HHDA).	Supplier.	HHDA¹⁹ ²⁰.	D0297 Notification of BM Unit Allocation.	Electronic or other method, as agreed.
3.5.2.	Within 1 WD of 3.5.1.	Log change proposal then validate Supplier BM Unit Allocation.	HHDA.		Appendix 4.5 - BM Unit File Validation.	Internal Process.
3.5.3	Within 1 WD of 3.5.1.	If file cannot be processed send notification²¹. Return to 3.5.1 if Supplier wishes to provide revised change proposal.	HHDA.	Supplier	P0035 Invalid Data.	Electronic or other method, as agreed.
3.5.4.	Within 1 WD of 3.5.1.	If BM Unit Allocation invalid send rejection of BM Unit Allocation²¹. Return to 3.5.1 if Supplier wishes to provide revised change proposal.	HHDA.	Supplier.	D0295 Rejection of BM Unit Allocation.	Electronic or other method, as agreed.
3.5.5.	Within 1 WD of 3.5.1.	If BM Unit Allocation valid send confirmation of acceptance of BM Unit Allocation.	HHDA.	Supplier.	D0294 Confirmation of BM Unit Allocation.	Electronic or other method, as agreed

3.6 Processing Supplier Instructions for EMR

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.6.1	Where request received from Capacity Provider: Within 1 WD of valid request from Capacity Provider. Where EII Certificate issued or commencing supply²² to an EII holding a valid EII Certificate: On being notified by an EII customer that it holds a valid EII Certificate, by the later of the 30^th day after the date the notification was received, or the effective from date stated on the EII Certificate. Where a supplier ceases to supply an EII: By the 30^th day after the supplier ceased supplying the EII that held the EII Certificate²³. Where EII Certificate expires or is revoked: On being notified that an EII Certificate is being or has been revoked, by the later of the 30th day after the date the notification was received, or the date the revocation notice takes effect²⁴. Where no notification of revocation is received relating to an EII Certificate, by the 30th day after the date that the EII certificate ceased to be valid²⁵.	Send Metering System Reporting Notification	Supplier	HHDA	D0354 Metering System Reporting Notification	Electronic or other method, as agreed.
3.6.2	Within 1 WD of 3.6.1	Process notification and validate	HHDA		Appendix 4.6	Internal Process
3.6.3	Within 1 WD of 3.6.1	If Metering System Reporting Notification cannot be processed or is invalid send reporting rejection notice. Return to 3.6.1 if Supplier wishes to provide revised notification.	HHDA	Supplier	D0356 Metering System Reporting Rejection	Electronic or other method, as agreed.
3.6.4	Within 1 WD of 3.6.1	If Metering System Reporting Notification valid send confirmation of acceptance.	HHDA	Supplier, CfD Service Provider and CM Service Provider	D0355 Metering System Reporting Confirmation	Electronic or other method, as agreed.

3.7 Processing of SVAA instructions to report metered data for Metering Systems

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.7.1	As soon as the SVAA identifies a need to instruct a HHDA to begin reporting or to update an instruction to report Allocated Metering System Metered Consumption for a specific Metering System²⁶, e.g. on receipt of notification of Metering System(s) in the SVA Metering System Register in accordance with BSCP507 or confirming the validity of a Non-Final Demand Declaration for an SVA Non-Final DemandFacility	Notify Metering System(s) to relevant HHDA(s)	SVAA	HHDA	D0354 – Metering System Reporting Notification²⁷	Electronic or other method, as agreed.
3.7.2	Within 1 WD of 3.7.1	Process notification and validate²⁸	HHDA		Appendix 4.6	Internal Process
3.7.3	Within 1 WD of 3.7.1	If Metering System Reporting Notification cannot be processed or is invalid send reporting rejection notice.	HHDA	SVAA	D0356 - Metering System Reporting Rejection	Electronic or other method, as agreed.
3.7.4	Within 1 WD of 3.7.1	If Metering System Reporting Notification can be processed and is valid, send confirmation of acceptance.	HHDA	SVAA	D0355 Metering System Reporting Confirmation	Electronic or other method, as agreed.

3.7A Processing of SVAA instructions to report historic metered data for Baselined Metering Systems

REF	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.7A.1	As soon as the SVAA identifies a need to request historic metered data (because a Supplier, Asset Metering Virtual Lead Party or Virtual Lead Party has opted to use Baselining for a Metering System participating in the Balancing Mechanism).	Notify Metering System(s) to relevant HHDA(s)	SVAA	HHDA	D0hhh – Metered Volume History Request D0354 - Metering System Reporting Notification The data flow will specify the Metered Volume History From Date to identify the period for which data is requested.	Electronic or other method, as agreed.
3.7A.2	Within 1 WD of 3.7A.1	Process notification and validate			Appendix 4.6.2	Internal process
3.7A.3	Within 1 WD of 3.7A.1	If the Metered Volume History Request cannot be processed or is invalid send reporting rejection notice.	HHDA	SVAA	D0iii – Invalid Metered Volume History Request	Electronic or other method, as agreed.
3.7A.4	Within 1 WD of 3.7A.1	If Metering System Baselining Data Request can be processed and is valid, send confirmation and any consumption data the HHDA has within the requested period.	HHDA	SVAA	D0jjj – Metered Volume History Acceptance	Electronic or other method, as agreed.

3.8 Instruction to HHDA to cease reporting metered data for individual Metering Systems

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.8.1	As soon as the SVAA becomes aware that it no longer requires Allocated Metering System Metered Consumption for an individual Metering System(s) for any process specified under the BSC²⁹.	Notify the HHDA of the Effective to Settlement Date to cease reporting.	SVAA	HHDA	D0354 – Metering System Reporting Notification³⁰	Electronic or other method, as agreed.
3.8.2	Within 1 WD of 3.8.1	Process notification and validate³¹	HHDA		Appendix 4.6	Internal Process
3.8.3	Within 1 WD of 3.8.1	If Metering System Reporting Notification cannot be processed or is invalid send reporting rejection notice.	HHDA	SVAA	D0356 - Metering System Reporting Rejection	Electronic or other method, as agreed.
3.8.4	Within 1 WD of 3.8.1	If Metering System Reporting Notification can be processed and is valid, send confirmation of acceptance.	HHDA	SVAA	D0355 Metering System Reporting Confirmation	Electronic or other method, as agreed.

4. Appendices

4.1 SMRS Instruction File Validation.

The HHDA records, validates against MDD, maintains a history of change and uses the latest registration data and appointment data from a SMRS.

The HHDA records, validates against MDD, maintains a history of change and uses the latest standing data from SMRS to ensure that the GSP Group, Line Loss Factor Class, Energisation status, Measurement Class and Measurement Quantity assigned to a SVA Metering System belong to a valid set.

The file received from the SMRA is verified to ensure:

physical integrity;
that it is for the HHDA;
that it is from a valid SMRA;
that the file sequence number is the next instruction file sequence number from the source. If this sequence number is higher than the next sequence number, the file is not processed, but is stored for processing in correct sequence.
that the instructions in the file are in instruction sequence number order and the first sequence number in the file follows on from the last instruction received from the source of the file;
that, if the file contains a SMRS Refresh instruction, it is the only instruction in the file;

Each instruction is validated according to the type of instruction as detailed below, using the systems and processes approved in accordance with BSCP537. Validation failures are resolved by the HHDA where possible or referred to SMRS; in each case the HHDA records explanations of its actions and reasons.

4.1.1 HHDA Appointment Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
that there is not an existing HHDA Appointment in the system with a start date before the significant date and either no end date or an end date on or after the significant date (unless it is also in the instruction);
that, if the instruction contains only a HHDA Appointment record with a start and end date (with no related details), a HHDA Appointment exists on the system with the same start date and no end date;
for the ‘SVA Metering System’s Registrations’ in the instruction:

that they all contain valid Supplier Ids;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that all the start dates are unique;
that each registration has at least one HHDA Appointment;

for the ‘SVA Metering System’s HHDA Appointments’ in the instruction:

that they are all for this HHDA;
that the start date is less than or equal to the end date;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start or end date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that none of the Appointments overlap each other or any other appointment for the SVA Metering System;
that all the start dates are unique;

for the ‘SVA Metering System’s HHDC Appointments’ in the instruction:

that they are all for valid HHDCs;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that no Registrations will be left without a HHDC Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s relationships with Measurement Classes’ in the instruction:

that they are all for valid Measurement Classes;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without a Measurement Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s Energisation Statuses’ in the instruction:

that the Energisation Status are ‘D’ or ‘E’;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without an Energisation Status for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s relationships with Line Loss Factor Classes’ in the instruction:

that they are all for a valid LDSO and Line Loss Factor Classes;
that they are all for SVA Metering Systems that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which will exist if the instruction is applied;
that the SVA Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;

all the ‘SVA Metering System’s relationships with GSP Groups’ in the instruction:

that they are all for valid GSP Groups;
that they are all for SVA Metering Systems that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which will exist if the instruction is applied;
that the SVA Metering System will not be left without a GSP Group for any Settlement Day within a HHDA Appointment if the instruction is applied.
that all the start dates are unique;

4.1.2 HHDC Appointment Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
For the HHDC Appointment relationships in the instruction:

that they are all for valid HHDCs;
that they are all for Registrations that already exist in the system;
that they all overlap or start on or after the significant date (Data Collector Appointments for different Registrations should be considered separately for the purpose of overlap);
that if one has a start date before the significant date, all other Data Collector Appointments for the same Registration must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that no Registrations will be left without a HHDC Appointment if the instruction is applied.
that all the start dates must be unique for Data Collector Appointments that are for the same Registration;

4.1.3 Measurement Class Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
For the Measurement Class relationships in the instruction:

that they are all for valid Measurement Classes;
that they are all for registrations that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which already exist for this Registration;
that no Registrations will be left without a Measurement Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique.

4.1.4 Energisation Status Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
For the Energisation Status relationships in the instruction:

that they are all either ‘D’ or ‘E’;
that they are all for registrations that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which already exist for this Registration;
that no Registrations will be left without an Energisation Status for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique.

4.1.5 GSP Group Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
For the GSP Group relationships in the instruction:

that they are all for valid GSP Groups;
that they are all for SVA Metering Systems that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which already exist for this SVA Metering System;
that no HHDA Appointments will be left without a GSP Group for any Settlement Day if the instruction is applied;
that all the start dates are unique.

4.1.6 Line Loss Factor Class Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;
For the Line Loss Factor Class relationships in the instruction:

that they are all for a valid LDSO and Line Loss Factor Classes;
that they are all for SVA Metering Systems that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which will exist if the instruction is applied;
that the SVA Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique.

4.1.7 Refresh SMRS Metering System Details

The instruction is validated to ensure:

that the SMRA which sent the instruction is currently appointed to the LDSO that is the subject of the instruction;
for each SVA Metering System in the instruction:

for the ‘SVA Metering System’s Registrations’ in the instruction:

that they all contain valid Supplier Ids;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that all the start dates are unique;
that each registration has at least one HHDA Appointment;

for the ‘SVA Metering System’s HHDA Appointments’ in the instruction:

that they are all for this HHDA;
that the start date is less than or equal to the end date;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start or end date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that none of the Appointments overlap each other;
that all the start dates are unique;

for the ‘SVA Metering System’s HHDC Appointments’ in the instruction:

that they are all for valid HHDCs;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that no Registrations will be left without a HHDC Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s relationships with Measurement Classes’ in the instruction:

that they are all for valid Measurement Classes;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without a Measurement Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s Energisation Statuses’ in the instruction:

that the Energisation Status are ‘D’ or ‘E’;
that they are all for registrations that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier than the start date for the registration;
that none have a start date on or later than the start date of the subsequent registration (if one exists) for the SVA Metering System if the instruction is applied;
that they all overlap with one or more HHDA Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without a Measurement Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘SVA Metering System’s relationships with Line Loss Factor Classes’ in the instruction:

that they are all for a valid LDSO and Line Loss Factor Classes;
that they are all for SVA Metering Systems that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which will exist if the instruction is applied;
that the SVA Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique;
all the ‘SVA Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and overlap with a HHDA Appointment for the HHDA.
that they are all for valid GSP Groups;
that they are all for SVA Metering Systems that will exist if the instruction is applied;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more HHDA Appointments which will exist if the instruction is applied;
that the SVA Metering System’s will not be left without a GSP Group for any Settlement Day within a HHDA Appointment if the instruction is applied;
that all the start dates are unique.

4.2 Line Loss Factor Data Validation.

Line Loss Factor Class Data is validated against MDD using systems and processes so approved in accordance with BSCP537.

Line Loss Factor Data is validated for completeness:

If the file does not contain data for a valid Line Loss Factor Class
If the file contains data for an invalid Line Loss Factor Class

The HHDA rectifies validation failures where possible or refers the failures to BSCCo for rectification. The HHDA keeps a record of all validation failures for audit and control purposes, and records explanations and reasons for its actions in rectifying any failures.

4.3 Checks for data anomalies during Data Aggregation Run.

As far as is practicable, the HHDA’s system must validate the data it receives from the HHDC against MDD and against data received from SMRAs.

1. For all the Settlement Periods in the Settlement Day, apply the following checks (in the following order) for data anomalies, and process and report each type of anomaly as indicated:

(a) Consumption Data Received but Not Expected

Check for SVA Metering Systems which have consumption values stored against them but for which the HHDA is not appointed to aggregate on this Settlement Day.

Record such data anomalies for reporting purposes and ignore these consumption values from this point on for this aggregation process.

Report full details of any such anomalies to the HHDC supplying the data.

(b) Expected Consumption Data Received but from Incorrect Source

Check for any SVA Metering Systems that have stored consumption values that have been supplied by the incorrect HHDC. The validity of a consumption value is determined by checking that it has been provided by the HHDC whose period of appointment spans the settlement period to which the consumption value relates.

Record such data anomalies for reporting purposes and ignore these consumption values from this point on for this aggregation process.

Report full details of any such anomalies to the correct HHDC, invalid HHDC and Supplier.

Check for any SVA Metering Systems, for which a consumption value is expected, that have not had a complete set of consumption values supplied by the correct HHDC - whether a partial set of values has been received, or no values at all. If SVA Metering Systems have missing consumption they may simply be de-energised. Therefore, check their Energisation Status before confirming this anomaly.

Record this data anomaly for reporting purposes. Derive and use in the aggregation process, default consumption values as follows;

For import SVA Metering Systems the HHDA should equally divide the Measurement Class specific HH Default EAC provided in Market Domain Data, over the year, irrespective of leap years. This should be rounded to the nearest kWh, i.e.

Default Value = \frac{HH Default EAC}{Settlement Periods in non leap year} = \frac{HH Default EAC}{17520}

Default"`"Value"= { {"HH"`"Default"`"EAC"} over {"Settlement"`"Periods"`"in"`"non"`"leap"`"year "} } = { {"HH"`"Default"`"EAC"} over {"17520"} } } {}

For Export SVA Metering Systems the Half Hourly Data Aggregator should use a value of zero.

Line Loss Factors (LLFs) should be applied to any default values for SVA Metering Systems submitted to Settlements.

Report full details of any such anomalies to the HHDC and Supplier.

(d) Consumption Data Received for De-Energised Meter

If a SVA Metering System is de-energised, treat the consumption as zero, unless there is a non-zero consumption value, in which case this will be used in the aggregation process.

Record this data for reporting purposes.

Report the anomaly to the HHDC and Supplier.

Non-zero values recorded on the Effective From Date of an energisation status change, from energised to de-energised, should not be reported as an anomaly to the HHDC and the Supplier.

(e) Consumption Data Received for Incorrect Supplier

Check for any SVA Metering Systems for which valid consumption data has been received, but for which a different Supplier is specified to that defined in SMRS.

Record this data anomaly for reporting purposes and aggregate the data against the Supplier defined by SMRS.

Report the anomaly to the HHDC and both Suppliers.

(f) Mismatch in the Direction of Energy Flow information provided by SMRS and HHDC.

Check that the Direction of Energy Flow derived from the LLFC ID provided by SMRS matches the Direction of Energy Flow derived from the Measurement Quantity ID provided by the HHDC. For the purpose of this check, values of ‘A’ and ‘B’ for the LLFC ID’s MS Specific LLF Class Indicator can be regarded as Import, and values of ‘C’ and ‘D’ can be regarded as Export.

If there is a mismatch, treat the consumption value as zero and report the anomaly manually to the HHDC and Supplier.

(g) Demand Disconnection Volume data Received for De-Energised Meter

If a SVA Metering System is de-energised, treat the Demand Disconnection Volume as zero, unless there is a non-zero Demand Disconnection value, in which case this will be used in the aggregation process.

Record this data for reporting purposes.

Report the anomaly manually to the HHDC and Supplier.

Non-zero values recorded on the Effective From Date of an energisation status change, from energised to de-energised, should not be reported as an anomaly to the HHDC and the Supplier.

(h) Demand Disconnection Volume data Received for Incorrect Supplier

Check for any SVA Metering Systems for which valid Demand Disconnection Volume data has been received, but for which a different Supplier is specified to that defined in SMRS.

Record this data anomaly for reporting purposes and aggregate the data against the Supplier defined by SMRS.

Report the anomaly manually to the HHDC and both Suppliers.

2. There may still be more than one valid consumption value for a Settlement Period stored against a SVA Metering System e.g. an estimated value and an actual reading. In this case, only the most recently received valid consumption value should be used and any older values should be ignored.

3. Any discrepancies between data sent by the SMRA and data sent by the HHDC must be recorded as exceptions for the Interim Information Volume Allocation run or Initial Volume Allocation Run or Reconciliation Volume Allocation Run. In the event of such a discrepancy, data from the SMRA shall prevail.

4.4 Aggregate Consumption Data.

The HHDA’s system must perform aggregation of the Half Hourly consumption and (when appropriate) or Demand Disconnection Volume data by Supplier in accordance with the data supplied by the SMRS.

The HHDA’s system must precisely aggregate those SVA Metering Systems for which the SMRS deems it is responsible under the SMRS, and must ensure that each such metering system is accounted for exactly once.

The method by which the HHDA will aggregate data will depend on whether the HHDA decides to implement Additional BM Units for a Supplier within a GSP Group. The introduction of Additional BM Units is optional for the HHDA, but for any HHDA that implements them, the notification of BM Unit Allocation must be received prior to Gate Closure for the period to which it applies.

In relation to HH consumption the HHDA must provide the SVAA with a D0040 Aggregated Half Hour Data File or a D0298 BM Unit Aggregated Half Hour Data File only for each GSP Group. And in relation to Demand Disconnection Volume data the HHDA must provide the SVAA with a D0376 Supplier’s Demand Disconnection Volume Data File or a D0378 BM Unit Aggregated Half Hour Demand Disconnection Data File only for each GSP Group.

Each set of aggregation data the HHDA provides to the SVAA must relate to a single GSP Group and a particular Interim Information Volume Allocation run or Initial Volume Allocation Run or Reconciliation Volume Allocation Run for a Settlement Day.

The HHDA’s system must allow more than one aggregation run to be performed for any Settlement Day. The results of each run must be identified with a unique run number.

An aggregation run must, for each Supplier, sum to the level of Consumption Component Class and, for Metering Systems registered to Measurement Classes F or G, Line Loss Factor Class, where Consumption Component Class is the combination of:

Estimated/Actual;
Pseudo Unmetered/Metered;
Site specific/Non-site specific Line Loss Factors; and
Third Party Generator Generation/Consumption.

The line losses must be determined separately for consumption and generation. The number of SVA Metering Systems contributing to each consumption component class must be recorded with the aggregated data.

4.4.1 Base Balancing Mechanism Unit Aggregation

A HHDA who decides not to implement Additional BM Units will aggregate data as follows:

1. For each SVA Metering System calculate the line losses by Settlement Period by applying the appropriate Line Loss Factor to the consumption values.

2. For each GSP Group add up the consumptions of all the SVA Metering Systems for each Settlement Period, by Supplier and by Consumption Component Class in MWh and for Metering Systems registered to Measurement Classes F or G, by Line Loss Factor Class.

3. For each GSP Group add up the line losses of all SVA Metering Systems for each Settlement Period, by Supplier and by Consumption Component Class in MWh and for Metering Systems registered to Measurement Classes F or G by Line Loss Factor Class.

Full details of the aggregation rules are given in the Supplier Volume Allocation Rules which must prevail, in the event of any conflict with this BSCP.

The D0040 Aggregated Half Hour Data File gives the full data list produced by the aggregation, all items within are self-explanatory except for the following:

MSID Count

The MSID count is the count of SVA Metering Systems by Consumption Component Class, Settlement Period and Supplier in a GSP Group.

Run number

This is a number which identifies uniquely an aggregation run for that HHDA. Each aggregation run that the HHDA does has a unique run number including any aggregation runs for which data is not sent to the SVAA.

The aggregated data will be provided to the SVAA who then allocates the aggregated data to the Base BM Unit.

4.4.2 Additional Balancing Mechanism Unit Aggregation

A HHDA who decides to implement Additional BM Units will assign all the energy to an appropriate BM Unit(s) when carrying out the aggregation run. In the case of a SVA Metering System for which the Supplier has not provided a BM Unit allocation, the HHDA will assign the energy to the Base BM Unit. The HHDA will aggregate data as follows:

1. For each SVA Metering System calculate the line losses by Settlement Period by applying the appropriate Line Loss Factor to the consumption values.

2. For each GSP Group add up the consumption of all the SVA Metering Systems for each Settlement Period, by Supplier and by Consumption Component Class in MWh and maintain separate totals for each Supplier’s BM Unit(s) and for Metering Systems registered to Measurement Classes F or G by Line Loss Factor Class.

3. For each GSP Group add up the line losses of all SVA Metering Systems for each Settlement Period, by Supplier and by Consumption Component Class and by BM Unit in MWh and for Import Metering Systems registered to Measurement Classes F or G by Line Loss Factor Class.

Full details of the aggregation rules are given in the Supplier Volume Allocation Rules which must prevail, in the event of any conflict with this BSCP.

The D0298 BM Unit Aggregated Half Hour Data File gives the full data list produced by the aggregation run all items within are self-explanatory except for the following:

MSID Count

The MSID count is the count of SVA Metering Systems by Consumption Component Class, Settlement Period and Supplier in a GSP Group.

Run number

The aggregated data, by BM Unit(s), will be provided to the SVAA.

4.4.2A Base Balancing Mechanism Unit Demand Disconnection Aggregation

Where a Demand Disconnection occurs as part of a Demand Control Event, the HHDA’s system must aggregate the estimated disconnection volumes provided by the HHDC and report these separately to the SVAA.

1. For each SVA Metering System calculate the disconnection line losses by Demand Control Impacted Settlement Period by applying the appropriate Line Loss Factor to the estimated disconnection volumes.

2. For each GSP Group add up the estimated disconnection volumes of all the SVA Metering Systems for each Demand Control Impacted Settlement Period, by Supplier and by Consumption Component Class in MWh.

3. For each GSP Group add up the disconnection line losses of all SVA Metering Systems for each Demand Control Impacted Settlement Period, by Supplier and by Consumption Component Class in MWh.

Full details of the aggregation rules are given in the Supplier Volume Allocation Rules which must prevail, in the event of any conflict with this BSCP.

The D0376 Supplier’s Deemed Disconnection Volume Data File gives the full data list produced by the aggregation, all items within are self- explanatory except for the following:

MSID Count

The MSID count is the count of SVA Metering Systems by Consumption Component Class, Demand Control Impacted Settlement Period and Supplier in a GSP Group.

Run number

This is a number which identifies uniquely an aggregation run for that HHDA. Each aggregation run that the HHDA completes has a unique run number including any aggregation runs for which data is not sent to the SVAA.

The aggregated data will be provided to the SVAA who then allocates the aggregated data to Base BM Units.

Demand Control Event ID

The Demand Control Event ID is originally determined by the National Electricity Transmission System Operator (NETSO), who uses it in its correspondence with the LDSO and SVAA. The HHDA should therefore use the DCE ID reported to it by the LDSO or HHDC when sending a corresponding D0376 to the SVAA.

4.4.2B Additional Balancing Mechanism Unit Demand Disconnection Aggregation

3. For each GSP Group add up the disconnection line losses of all SVA Metering Systems for each Demand Control Impacted Settlement Period, by Supplier and by Consumption Component Class in MWh.

Full details of the aggregation rules are given in the Supplier Volume Allocation Rules which must prevail, in the event of any conflict with this BSCP.

The D0378 BM Unit Aggregated Half Hour Demand Disconnection Data File gives the full data list produced by the aggregation, all items within are self-explanatory except for the following:

MSID Count

The MSID count is the count of SVA Metering Systems by Consumption Component Class, Demand Control Impacted Settlement Period and Supplier in a GSP Group.

Run number

The aggregated data, by BM Unit(s), will be provided to the SVAA.

Demand Control Event ID

The Demand Control Event ID is originally determined by the NETSO, who uses it in its correspondence with the LDSO and SVAA. The HHDA should therefore use the DCE ID reported to it in the P0238 or D0375 by the LDSO or HHDC when sending a corresponding D0378 to the SVAA.

4.4.3 EMR Data

In addition to performing aggregation for the SVAA, the HHDA will collate and process data relating to Metering Systems that have been notified by the Supplier as supporting EMR. The HHDA must provide the results of this processing to the CfD Service Provider and CM Service Provider.

Where the Supplier has notified the HHDA of Metering Systems supporting EMR, the HHDA will, for each relevant SVA Metering System, for each Settlement Period, calculate the line losses by applying the appropriate Line Loss Factor to the energy volumes that it has received from the Half Hourly Data Collector. Where data is not received from the HHDC the HHDA shall use the existing provisions in section 4.3.

The D0357 Half Hourly Metered Data for EMR gives the full data list produced by the aggregation run.

The HHDA will provide the CfD Service Provider and the CM Service Provider with the collated data, grouped by Supplier.

4.5 Balancing Mechanism Unit File Validation.

The HHDA will validate the BM Unit files in accordance with the Data Interfaces document.

A record of all validation failures must be kept for audit and control purposes.

4.6 Metering System Reporting Notification Validation

The HHDA will validate the Metering System Reporting Notification files received in accordance with the Energy Market Data Specification.

The HHDA must be able to differentiate between instructions sent to it by its Supplier and instructions sent to it by SVAA. That is because the File Sequence Number and Instruction Number included in two D0354 data flows may be the same except that one is sent by a Supplier and the other by the SVAA. In such a scenario each D0354 instruction is independent of the other and should be actioned separately by the HHDA.

A record of all validation failures must be kept for audit and control purposes.

Where a Supplier, Asset Metering Virtual Lead Party or Virtual Lead Party has opted to use Baselining (for a Metering System participating in the Balancing Mechanism) SVAA may also request up to 60 days of historic data, using the process described in section 3.7A.

4.6.1 SVAA:HHDA appointment scenarios

HHDAs may receive a Metering System Reporting Notification in a number of different scenarios.

In general, where a HHDA already has a D0354 appointment for a Metering System and receives a new D0354 for that Metering System, the most recent appointment will replace any earlier appointment for that Metering System, even if the two appointments do not overlap.

The following summaries explain how a HHDA should treat a notification in nine different scenarios. These include scenarios where an earlier appointment is being replaced or updated. Please note that this is a non-exhaustive list of scenarios but it should illustrate what might happen in a wide range of scenarios.

Scenario 1 – Retaining an existing appointment(s) and adding a future non-contiguous appointment(s)

Situation – HHDA1 has an existing D0354 appointment (‘Appt1’) for an MSID (MSIDx) with a defined effective to date (ETD). The existing appointment is necessary to provide data for an SVA Non-Final Demand Facility but has a defined end date. During the first appointment the SVAA identifies a need for metered data from MSIDx to support reporting for a Secondary BMU but that this requirement takes effect after the first appointment ends.

Desirable outcome – Retain the terms of ‘Appt1’ and introduce a second appointment (‘Appt2’) with a period where no appointment exists (and therefore no reporting by the HHDA occurs) in between both appointments.

Action taken - In this scenario the SVAA will send a D0354 to HHDA1 with two new appointments for MSIDx: new ‘Appt2’ to reconfirm the effective from date (EFD) and ETD of the original appointment (‘Appt1’) and new ‘Appt3’ to add a second appointment with an EFD and where necessary an ETD for the second reporting requirement.

Nb an ETD is not always necessary, for example if the appointment is intended to be open-ended (sometimes referred to as ‘evergreen’).

Scenario 2 – Extending an existing appointment

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) for an MSID (MSIDx) with a defined ETD. The existing appointment is necessary to provide data for an SVA Non-Final Demand Facility but has a defined end date. During the first appointment the SVAA identifies a need for metered data from MSIDx to support reporting for a Secondary BMU and that this requirement takes effect during the first appointment and outlasts the first appointment, i.e. the second reporting requirement ETD is after the first requirement’s ETD, and the second reporting requirement EFD is between the first requirement’s EFD and ETD.

Desirable outcome – ensure the HHDA is appointed to report metered data for MSIDx that satisfies both reporting requirements, thereby retaining the original terms of ‘Appt1’ and also the newer terms of the second reporting requirement.

Action taken - In this scenario the SVAA will send a new D0354 to HHDA1 with a brand new appointment (‘Appt2’) that covers both the first and second reporting requirement. That is the new appointment (‘Appt2’) will have an EFD that is the same as the original appointment for the first requirement and an ETD that matches the ETD for the second reporting requirement. ‘Appt2’ replaces ‘Appt1’.

Scenario 3 - Retaining an existing appointment and adding another longer-lasting appointment

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) for an MSID (MSIDx) with a defined ETD. The existing appointment is necessary to provide data for an SVA Non-Final Demand Facility but has a defined end date. Before or during the first appointment the SVAA identifies a need for metered data from MSIDx to support reporting for a Secondary BMU and that this requirement takes effect from the same EFD as ‘Appt1’ but outlasts the first appointment, i.e. the second reporting requirement ETD is after the first requirement’s ETD.

Action taken - In this scenario the SVAA will send a new D0354 to HHDA1 with a brand new appointment (‘Appt2’) that covers both the first and second reporting requirement. That is the new appointment (‘Appt2’) will have an EFD that is the same as the original appointment for the first requirement and the second requirement, and an ETD that matches the ETD for the second reporting requirement. ‘Appt2’ replaces ‘Appt1’.

Scenario 4 – Retaining an existing future appointment and adding another appointment to take effect sooner

Situation - HHDA1 has an existing future dated D0354 appointment (‘Appt1’) to report metered data for an MSID (MSIDx) with a defined effective to date (ETD). Before the first appointment takes effect SVAA identifies a need for metered data from MSIDx to support reporting for a Secondary BMU and that this requirement takes effect before ‘Appt1’ and ends at the same time as ‘Appt1’.

Desirable outcome – ensure the HHDA is appointed to report metered data from MSIDx that satisfies both reporting requirements, thereby retaining the original terms of ‘Appt1’ and also the newer terms of the second reporting requirement.

Action taken - In this scenario the SVAA will send a new D0354 to HHDA1 with a brand new appointment (‘Appt2’) that covers both the first and second reporting requirement. That is the new appointment (‘Appt2’) will have an EFD that is equal to the EFD for the second, newer requirement and an ETD that matches the ETD for both the first and second reporting requirement. ‘Appt2’ replaces ‘Appt1’.

Scenario 5 – Replacing an existing appointment for one purpose with another appointment for a different purpose

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) to report metered data for an MSID (MSIDx) with a defined effective to date (ETD). ‘Appt1’ was created to provide metered data for an SVA Non-Final Demand Facility. Before or during the first appointment the SVAA identifies a need for metered data from MSIDx to support reporting for another purpose, e.g. for a Secondary BMU, and that the original requirement is no longer required. The second, newer requirement has the same EFD and ETD as the original requirement.

Desirable outcome – ensure the HHDA is appointed to report metered data that satisfies the second, newer requirement.

Action taken - In this scenario the SVAA does not need to take any further action. That is, the original, existing appointment satisfies the requirements for the second reporting requirement.

Scenario 6 - Replacing an existing appointment for one purpose with new appointments for several other different purposes

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) to report metered data for an MSID (MSIDx) with a defined effective to date (ETD). ‘Appt1’ was created to provide metered data for an SVA Non-Final Demand Facility. Before or during the first appointment the SVAA identifies a need for metered data from MSIDx to support other reporting requirements. The modified and new reporting requirements all have EFD and ETDs that are equal to or within the EFD and ETD of the original appointment.

Desirable outcome – ensure the HHDA is appointed to report metered data that satisfies revised original requirement and all other new requirements for metered data.

Action taken - In this scenario the SVAA does not need to take any further action. That is, the EFD and ETD of the original, existing appointment satisfies the requirements of the revised and newer reporting requirements.

Scenario 7 – Replacing an earlier appointment with an updated/correct appointment

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) to report metered data for an MSID (MSIDx) with a defined effective to date (ETD). ‘Appt1’ was created to provide metered data for an SVA Non-Final Demand Facility. Before or during the first appointment the SVAA identifies a need to change/correct the original Appt1 so that metered data is reported between new EFD and ETD.

Desirable outcome – ensure the HHDA is appointed to report metered data in accordance with the newer/corrected requirements.

Action taken - In this scenario the SVAA sends a D0354 with new appointment details (‘Appt2’) that reflect the EFD and ETD of the changed/corrected requirements. ‘Appt2’ replaces ‘Appt1’.

Scenario 8 – Removing an erroneous appointment with an incorrect agent

Situation - HHDA1 has an existing D0354 appointment (‘Appt1’) to report metered data for an MSID (MSIDx) with a defined effective to date (ETD). HHDA2 has an existing appointment (‘Appt2’) to continue reporting metered data for MSIDx, where the EFD for Appt2 is the day after the ETD of App1. Both ‘Appt1’ and ‘Appt2’ were created to provide metered data for an SVA Non-Final Demand Facility. Appt2 may have been created because the SVAA expected a future change of agent event. Before or during the first appointment the SVAA identifies that Appt2 is no longer required.

Desirable outcome – ensure that HHDA1 continues to report in accordance with its appointment but close HHDA2’s appointment.

Action taken - In this scenario the SVAA sends a D0354 to HHDA2 where the appointment’s EFD=ETD, thereby reducing the Appt2 to a single settlement day. SVAA should populate the D0354 Contract Reference with ‘Delete’.

Scenario 9 – End date an existing appointment and add another future appointment

Situation – HHDA1 has an existing D0354 appointment (‘Appt1’) for an MSID (MSIDx) with no defined ETD, i.e. it is an ever-green appointment. During the first appointment the SVAA identifies a need for metered data from MSIDx to support reporting for a Secondary BMU but that this requirement will be supported by a different HHDA (HHDA2). Furthermore SVAA identifies that the first Appointment should be end-dated before the second appointment takes effect.

Desirable outcome – Update the terms of ‘Appt1’ so that it is correctly end-dated and introduce a second future appointment with a period where no appointment exists (and therefore no reporting by the HHDA occurs) in between both appointments.

Action taken - In this scenario the SVAA will send a D0354 to HHDA1 with a new appointment (Appt2) which replaces Appt1 with a specific EFD and ETD for MSIDx. The SVAA also sends a D0354 to HHDA2 with an appointment (Appt3) for MSIDx.

4.6.2 Requests for Baselining Data

A HHDA may receive a Metered Volume History Request in a number of different scenarios, some of which are described below for explanatory purposes. However, in all scenarios the action required is the same:

Validate the request (e.g. that the format of the request is correct, and that the HHDA is appointed to the Metering System).
If the request is valid, return an Invalid Metered Volume History Request Data flow containing any consumption data held for Settlement Days within the requested date range. Only data that has been processed in a Volume Allocation Run should be included.

Scenario 1 – Data Requested for Metering System with no previous D0354

This scenario would arise, for example, if a Supplier decided to use Baselining for a Metering System that has not previously participated in the Balancing Mechanism. The HHDA would receive the following data flows (not necessarily in the order specified):

A D0297 (Notification of BM Unit Allocation) from the Supplier, moving the Metering System from the Base BM Unit to an Additional BM Unit (in order to allow participation in the Balancing Mechanism);
A D0hhh (Metered Volume History Request), requesting consumption data for Settlement Dates D-60 to D-1 (where D is the date on which the Metering System was moved into the Additional BM Unit)
A D0354 (Metering System Reporting Notification) with an Effective From Settlement Date (EFSD) of D-60, and a null (open-ended) Effective To Settlement Date (ETSD). Note that the EFSD is back‑dated to D-60 in order to request subsequent updates to the one-off request for historic data.

Scenario 2 – Data Requested for Metering System with previous D0354

A Metering System Baselining Data Request may also be received for a Metering System which has already had a D0354. This would occur if a Metering System is already participating in the BM (through a VLP) without using Baselining, but is changed to use Baselining going forward.

If the Effective From Settlement Date (EFSD) on the previous D0354 was more than 60 days in the past SVAA would not need to send a Metering System Baselining Data Request, as it would already have received consumption data for the 60 day period. But if (for example) the EFSD of the previous D0354 was thirty days previously (D‑30), SVAA would send the HHDA:

A D0hhh (Metered Volume History Request), requesting consumption data for Settlement Dates D-60 to D-1; and
A D0354 (Metering System Reporting Notification) updating the EFSD to be D-60 rather than D-30.

4.7 Reporting and Data Entry.

1. It must be possible to obtain a report from the HHDA’s system, on request, of all exceptions encountered during an aggregation run for an Interim Information Volume Allocation Run or Initial Volume Allocation Run or a Reconciliation Volume Allocation Run. It must be possible to obtain these exceptions at the levels defined by combinations of all or a subset of:

Supplier;
GSP Group;
HHDC.

2. It must be possible to obtain from the HHDA’s system a report, on request, of statistics of exceptions encountered in an Interim Information Volume Allocation Run or Initial Volume Allocation Run or Reconciliation Volume Allocation Run. It must be possible to obtain these statistics at the levels defined by combinations of all or a subset of:

Exception type;
Supplier;
GSP Group;

HHDC.

3. It must be possible to obtain from the HHDA’s system a report, on request, of statistics of exceptions encountered across a range of Interim Information Volume Allocation Runs and/or Initial Volume Allocation Runs and/or Reconciliation Volume Allocation Runs. It must be possible to select these Interim Information Volume Allocation Runs and/or Initial Volume Allocation Runs and/or Reconciliation Volume Allocation Runs by a range of Settlement Days and a set of Settlement codes. It must be possible to obtain these statistics at the levels defined by combinations of all or a subset of:

Exception type;
Supplier;
GSP Group;

HHDC.

4. It must be possible to obtain from the HHDA’s system a report, on request, of all file and instruction validation failures. It must be possible to obtain this report at the levels defined by combinations of all or a subset of:

Validation failure type;
Supplier;
GSP Group;

HHDC.

5. The HHDA must allow manual entry of the following MDD:

Suppliers;
BM Unit details;
HHDCs;
LDSOs;
Measurement Classes;
SVAA;
SMRAs;
GSP Groups (and their timed relationships with the SVAA, SMRAs and LDSOs);
Line Loss Factor Classes;
GMT/BST clock change details.

4.8 HHDA System Requirements.

4.8.1 Audit Requirements.

The HHDA’s system must be an auditable system and it must be possible to inspect both the aggregated results and the audited data used.

1. The following data about ‘SVA Metering System Half Hourly Consumption Data’ files received must be stored:

Which HHDC the file was received from;
When the file was delivered to the system.

2. The following data about ‘Half Hourly SVA Metering System Registration Data’ files received must be stored:

Which SMRA the file was received from;
When the file was delivered to the system;
When the file underwent receipt processing.

3. The following data about half hour ‘SVA Metering System standing data’ files received must be stored:

Which SMRA the file was received from;
When the file was delivered to the system;
When the file underwent receipt processing.

4. The following data about ‘Line Loss Factors data’ files received must be stored:

Which LDSO the file was received from;
When the file was delivered to the system;
When the file underwent receipt processing.

5. The following data about ‘BM Unit Allocation’ files received must be stored:

Which Supplier the file was received from;
When the file was delivered to the HHDA’s gateway;
When the file underwent receipt processing.

6. The following data about a Full Refresh from a SMRS sent must be stored:

Which SMRA the file was received from;
When the file was delivered to the system;
When the file underwent receipt processing.

7. The following data about aggregated data files sent must be stored:

Which SVAA the file was sent to;
When the file was extracted;
When the file was sent.

8. Codes and identifiers must, wherever possible, be the same as those recognised by the BSCCo and FAA.

9. Version control must be applied to all data received. Resubmitted data from Data Collectors, Suppliers or SMRAs must not cause the deletion of previously sent data.

10. Version control must be applied to all data sent out. For data that relates to an aggregation run, the aggregation run number must be included in the control.

11. All reports produced must clearly identify what information is being reported, the date and time it was produced, who requested it.

12. All reports should be available in both human and machine readable format.

13. All reports in machine readable format must be available electronically.

14. All reports in human readable format should be available both electronically and in hardcopy.

15. Where changes are made by HHDA users, the system must maintain audit trails so that the change can be tracked. Tracking details must include:

The identity of the user who made the change;
The nature of the change; and
The date and time of the change.

16. The HHDA’s system must be able to perform aggregations for Interim Information Volume Allocation Run, Initial Volume Allocation Run, Reconciliation Volume Allocation Run and Post Final Volume Allocation Run of a Settlement Day up to 28 months after the Settlement Day.

17. It must be possible to archive onto a removable media all data relating to a Settlement Day.

18. It must not be possible to archive data relating to a Settlement Day until a user defined (configurable but not before the Final Reconciliation Volume Allocation Run of the Settlement Day) period after the Settlement Day.

4.8.2 Security and Control Requirements.

The HHDA’s system must comply with the 1998 Programme’s Security and Control Framework and the Pool’s 1998 Programme’s standard codes and naming conventions. The following requirements support this.

1. The system must keep track of all file numbers and instruction numbers of data files from every SMRA.

2. The system must ensure that files or instructions received from SMRAs are not processed out of sequence.

3. The HHDA must check the hash totals of all files received from any SMRAs to ensure that the file has been received correctly.

4. The system must alert the HHDA of any SMRA file or instruction anomalies identified and report these errors to the relevant SMRA.

5. The HHDA must identify and report any Additional BM Unit errors to the Supplier.

6. The HHDA must be able to monitor receipt of all data files from SMRAs.

7. The system must ensure that files received from the HHDC are not processed out of sequence.

8. The HHDA must be able to monitor receipt of ‘SVA Metering System Half Hour Consumption Data’ files.

9. The system must alert the HHDA of any HHDC file anomalies identified and report these errors to the relevant HHDC.

10. The HHDA must provide hash totals of all files transmitted to the SVAA.

11. The HHDA must identify files sent to the SVAA using the Settlement Day, Settlement code and an aggregation run number.

12. Aggregation runs must be based on the most up to date data at the time of aggregation, subject to not prejudicing Settlement timescales.

13. The system must not prevent the implementation of a disaster recovery plan. The system must provide appropriate back-up and recovery facilities.

14. Controls shall be put in place to minimise the risk of unwanted cessation of data processing. This objective will in part be met by adequate access restriction. Robust software and controls over computer operations will also be needed.

4.8.3 Operational Requirements.

The design and implementation of the HHDA system must not prevent it, given an appropriate hardware and software environment, being operated to meet the prescribed Settlement and reconciliation schedule. The following requirements support this.

1. The HHDA must be able to meet the published Settlement timetable.

2. The HHDA must be able to complete sufficient aggregation runs to comply with the Settlement timetable.

3. The HHDA must be able to process all consumption data from the number of SVA Metering Systems for which it is Qualified, when run in the proposed hardware and software environment.

4. For each Settlement, the HHDA must be able to send aggregated data to all relevant SVAAs when run in the proposed hardware and software environment.

5. The HHDA’s system and its proposed hardware and software environment must not have any constraints on the variability of the volumes of data and events that it must handle for different aggregation runs because the number of SVA Metering Systems could vary greatly between HHDA aggregation runs performed on the same day for different Volume Allocation Runs.

4.8.4 Design Constraint Requirements.

The design and implementation of the HHDA’s system must not adversely constrain the operation and performance of the systems to which it interfaces - SVA systems, HHDC systems, and SMRS systems. The following requirement supports this.

1. The HHDA’s software, its proposed hardware, and its interfaces, must not compromise the integrity of existing trading mechanisms and TUoS charging or their business processes, software, data, and their operating environment.

4.8.5 Monitoring.

Processes must be capable of providing statistical information to enable monitoring of performance by the Panel.

AMENDMENT RECORD – BSCP503

Version	Date	Description of Changes	Changes Included	Mods/ Panel/ Committee Refs
D0.1	Code Effective Date	Full document before Re-Badging.
D.02	Code Effective Date	Re-Badging.
D.03	Code Effective Date	Incorporated Version D.02 review comments.
2.0	Code Effective Date	Approved for use by the Panel.
3.0	Code Effective Date	Version alignment changes from AP503 embodied.	NCR329
4.0	03/02/03	SVA Documentation Batch Release.	CPs 696, 698, 715, 791, 800	SVG22/275
5.0	01/08/03	Updated for Modification P62	P62	SVG29/390
6.0	27/11/03	Updated for Modification P116	P116	SVG33/447
7.0	04/11/04	SVA November 04 Release	CPs 892, 951 and 1032	SVG43/003 TDC58/003
8.0	BETTA Effective Date	BETTA 6.3 and SVA February 05 Release	BETTA 6.3, CP1091	SVG48/004
9.0	29/06/06	June 06 Release	CP1146	SVG57/006
10.0	01/11/07	November 07 Release	CP1176 (part) CP1188	SVG67/16 ISG68/01 SVG77/04
11.0	06/11/08	November 08 Release	CP1235	SVG87/02 ISG87/01 PAB87/09
12.0	20/04/09	P216 Release	P216	SVG97/08
13.0	01/11/10	November 10 Release	CP1325	SVG111/01
14.0	03/11/11	November 11 Release	P253	SVG127/13
15.0	26/02/15	February 15 Release	ORD005	Directed by the Secretary of State
			CP1427	SVG168/06
16.0	25/06/15	Electricity Market Reform	ORD006	Directed by the Secretary of State
		June 2015 Release	CP1424	SVG168/05
17.0	05/11/15	November 2015 Release	P300	P228/06
			CP1432	SVG171/03
			P305	SVG176/03
18.0	29/06/17	June 2017 Release	CP1469	SVG188/03
19.0	02/11/17	November 2017 Release	CP1484	Panel 266/06
20.0	01/11/18	November 2018 Release	CP1509	SVG213/04
21.0	28/02/19	February 2019 Release	P344	Panel 284C/01
22.0	29/03/19	March 2019 Standalone Release	P369	Panel 285/12
23.0	27/06/19	June 2019 Release	P367 Self-Governance	SVG219/02
24.0	01/04/20	April 2020 Standalone Release	P354, P388	SVG229/07
25.0	12/10/20	P397 Standalone Release	P397	P298/05
26.0	01/04/21	April 2021 Standalone Release	P383	SVG241/04
27.0	01/09/21	1 September 2021 Non-Standard Release	P420	P316/05
28.0	30/06/22	30 June 2022 Standard Release	P375, P433	P309/06, P322/05
29.0	03/11/22	03 November 2022	CP1560	ISG253/05 and SVG255/04
30.0	23/02/23	February 2023 Standard Release	P376,P419	P312/04 and P323/06

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

1 Allocation of aggregated data to Additional BM Units is optional and is dependent on both the Supplier and HHDA agreeing to implement Additional BM Units.

2 The HHDA shall record and use such MDD as is considered appropriate by the Panel (having regard to the HHDA’s functions) and shall, in particular, use only MDD for those items in relation to which there is a MDD entry.

3 This dataflow is optional and is only sent by the SVAA if the HHDA requests the dataflow via the BSC Service Desk.

4 On receipt of any new MDD, the HHDA shall ensure that all MDD affecting the accuracy of Settlement which is manually entered by the HHDA shall be validated against the source data supplied by the SVAA to the HHDA by means of double entry keying before the data is recorded by the HHDA and used in performing its functions.

5 The HHDA shall keep a record of all files and instructions that fail validation, for audit and control purposes.

6 If an instruction file validation failure is due to a transmission problem, the HHDA shall notify the SMRS of the reason of the failure and shall request that the file be resent with the same file sequence number.

7 Rejection of one instruction in a file does not preclude processing of other unrelated instructions in that file.

8 Where required to resolve a failed instruction or query, the HHDA shall request a Selective Refresh for the relevant SVA Metering Systems from SMRS.

9 If request for refresh is for data more than 2 years old.

10 The HHDA shall record, validate and use Line Loss Factor data for the LDSO(s), and maintain a history of change.

11 Where the Supplier uses the DCC or other service provider to retrieve HH data from a Meter that complies with the Smart Metering Equipment Technical Specifications (SMETS).

12 The HHDA is not obliged to issue reports to Suppliers or Supplier Agents for the Interim Information Volume Allocation Run i.e. only reporting to SVAA, and where applicable the CMSSP is required

13 The SVAA shall specify the Effective from Settlement Date (J1869) the Effective to Settlement Date (J1870) in the D0354 Metering System Reporting Notification

14An affected MSID is any MSID that an LDSO disconnects due to a Demand Control Event. The period of disconnection should match the length of the DCE as reported by NETSO in its Demand Control Imminent Notification(s), regardless of the actual period of disconnection.

15 Whilst the P0238 is sent by the LDSO to the BSCCo, it should be generated by the LDSO as though it is to be sent direct to Party Agents, i.e. the ‘MPID To’ in the header should reflect the various agents that are intended to receive the file.

16 Demand side Non-BM STOR MSIDs will only ever be Active Import MSIDs. Therefore any estimated volumes of reduction reported by the SVAA to the HHDC will be an AI value.

17 The HHDC should only send a D0375 where it is appointed to at least one MSID listed in the P0238. Where it is not appointed to any affected MSIDs, the HHDC does not need to send a D0375.

18 Each BM Unit Allocation will be for one or more Settlement Days i.e. an allocation can only change at a Settlement Day boundary, which is Gate Closure for the first Settlement Period of the Settlement Day on which the BM Unit Allocation becomes effective.

19 The HHDA must be able to receive, date and timestamp BM Unit Allocations 24 hours a day, 7 days a week, for all days of the year, excluding those instances where time is spent on backup or disaster recovery. In the event that the HHDA’s systems are out of service for backup or disaster recovery, the HHDA should inform the Supplier as early as possible.

20 The HHDC must acknowledge receipt of the BM Unit Allocation files received from the Supplier by an automatic acknowledgement by the HHDA’s gateway in the Managed Data Network;

21 In the case of BM Unit Allocation validation failures, the HHDA shall use the previous BM Unit Allocation, or if no previous BM Unit Allocation is available shall use the Base BM Unit Allocation, unless the Supplier provides an alternative BM Unit Allocation prior to Gate Closure.

22 Suppliers do not need to wait until its supply has commenced for its EII customer before sending the D0354 Metering System Reporting Notification. Suppliers should endeavour to get its HHDA to submit metered data to the CfD Service Provider and CM Service Provider from its Supply Start Date.

23 Suppliers should send the D0354 Metering System Reporting Notification setting the Effective to Settlement Date (J1870) to the last day of supply.

24 Suppliers should send the D0354 Metering System Reporting Notification setting the Effective to Settlement Date (J1870) to the date the revocation notice takes effect.

25 Suppliers should send the D0354 Metering System Reporting Notification setting the Effective to Settlement Date (J1870) to the expiry date of the certificate.

26 There are different scenarios in which the SVAA may send an instruction to a HHDA. These scenarios are described in more detail below in Appendix 4.6.1. For Baselined Metering Systems, SVAA may additionally request 60 days of historic data, using the process in section 3.7A.

27 The SVAA shall specify the Effective from Settlement Date (J1869) and where necessary the Effective to Settlement Date (J1870) in the D0354 Metering System Reporting Notification

28 Please refer to the scenarios described in Appendix 4.6.1

29 There are different scenarios in which the SVAA may send an instruction to a HHDA. These scenarios are described in more detail below in Appendix 4.6.1.

30 The SVAA shall specify the Effective to Settlement Date (J1870) in the D0354 Metering System Reporting Notification.

31 Please refer to the scenarios described in Appendix 4.6.1

CONTENTS

BSCP503: Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS

1. Introduction

1.1 Scope and Purpose of the Procedure

1.2 Main Users of Procedure and their Responsibilities

1.2A EMR Responsibilities

1.3 Use of the Procedure

1.4 Balancing and Settlement Code Provision

1.5 Associated BSC Procedures

1.6 Acronyms and Definitions

1.6.1 Acronyms

1.6.2 Definitions

2. Not Used

3. Interface and Timetable Information

3.1 Market Data Activities.

3.1.1 SVAA sends Market Domain Data2.

3.2 Interface To SMRS.

3.2.1 Receive Changes of SMRS Data.

3.2.2 Request SMRS Refresh Data.

3.3 Interface To BSCCo

3.3.1 Changes to Line Loss Factors.

3.4 Aggregation Activities.

3.4.1 Receive Consumption Data from HHDC.

3.4.2 Perform Data Aggregation Run12.

3.4.3 Perform Data Aggregation for Demand Control Events

3.5 Balancing Mechanism Unit Standing Data Changes.

3.6 Processing Supplier Instructions for EMR

3.7 Processing of SVAA instructions to report metered data for Metering Systems

3.7A Processing of SVAA instructions to report historic metered data for Baselined Metering Systems

3.8 Instruction to HHDA to cease reporting metered data for individual Metering Systems

4. Appendices

4.1 SMRS Instruction File Validation.

4.1.1 HHDA Appointment Details

4.1.2 HHDC Appointment Details

4.1.3 Measurement Class Details

4.1.4 Energisation Status Details

4.1.5 GSP Group Details

4.1.6 Line Loss Factor Class Details

4.1.7 Refresh SMRS Metering System Details

4.2 Line Loss Factor Data Validation.

4.3 Checks for data anomalies during Data Aggregation Run.

4.4 Aggregate Consumption Data.

4.4.1 Base Balancing Mechanism Unit Aggregation

4.4.2 Additional Balancing Mechanism Unit Aggregation

4.4.2A Base Balancing Mechanism Unit Demand Disconnection Aggregation

4.4.2B Additional Balancing Mechanism Unit Demand Disconnection Aggregation

4.4.3 EMR Data

4.5 Balancing Mechanism Unit File Validation.

4.6 Metering System Reporting Notification Validation

4.6.1 SVAA:HHDA appointment scenarios

4.7 Reporting and Data Entry.

4.8 HHDA System Requirements.

4.8.1 Audit Requirements.

4.8.2 Security and Control Requirements.

4.8.3 Operational Requirements.

4.8.4 Design Constraint Requirements.

4.8.5 Monitoring.

AMENDMENT RECORD – BSCP503

3.1.1 SVAA sends Market Domain Data².

3.4.2 Perform Data Aggregation Run¹².