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 BSCP505, Version 24.0 relating to Non Half Hourly Data Aggregation.

3. This BSC Procedure is effective from 03 November 2022.

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

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

AMENDMENT RECORD

Version	Date	Description of Changes	Changes Included	Mods/ Panel/ Committee Refs
D0.1	Code Effective Date	Re-Badged
D.02	Code Effective Date	Incorporated version D.01 review comments
D.03	Code Effective Date	Comments embodied following CMC1273
2.0	Code Effective Date	Approved for use by the Panel
3.0	Code Effective Date	Version alignment changes from AP505 embodied.	NCR329
4.0	27/03/01	Further changes embodied for NCR329.	NCR329
5.0	03/02/03	SVA Documentation Batch Release.	CPs 698, 790, 791, 800	SVG22/275
6.0	17/02/03	Incorporates changes for P63.	P63	SVG20/251 SVG21/256
7.0	01/08/03	Updated for Modification P62	P62	SVG29/390
8.0	03/11/04	Change Proposal for the CVA Programme Nov 04 Release	CP1032	TDC58/03
9.0	BETTA Effective Date	BETTA 6.3 and SVA February 05 Release CPs agreed by SVG	BETTA 6.3, CP1091	SVG48/004
10.0	29/06/06	June 06 Release	CP1146 CP1149	SVG64/02
11.0	06/11/08	November 08 Release	CP1176 part	ISG68/02 SVG67/02
			CP1233	ISG87/01 SVG87/02 PAB87/09
12.0	25/06/09	June 09 Release	P222
13.0	25/02/10	February 10 Release	CP1295	SVG102/01
14.0	01/11/10	November 10 Release	CP1325	SVG111/01
15.0	03/11/11	November 11 Release	P253	SVG127/13
16.0	27/06/13	June 13 Release	CP1376	SVG139/08
17.0	27/02/14	February 2014 Release	CP1401	SVG154/04
18.0	06/11/14	November 2014 Release	CP1405	SVG157/06
			CP1408	SVG159/02
19.0	25/06/15	June 2015 Release	CP1424	SVG168/05
20.0	05/11/15	November 2015 Release	P305	SVG176/03
21.0	29/03/19	29 March 2019 Standalone Release	P369	P285/12
22.0	27/06/19	June 2019 Release	P367 Self-Governance	SVG219/02
23.0	12/10/20	P397 Standalone Release	P397	P298/05
24.0	03/11/2022	CP1560	CP1560	ISG253/05 and SVG255/04

1. Introduction

1.1 Scope and Purpose of the Procedure

This BSC Procedure defines the processes that the Non Half Hourly Data Aggregator (NHHDA) shall use to carry out the processing of meter data for Non Half Hourly SVA Metering Systems.

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

Where there is to be a change in any Non Half Hourly Supplier Agent (bulk change of agent) such that the number of SVA Metering Systems affected exceeds a threshold set by the BSC Panel, a bulk change of agent application will be submitted for approval in accordance with BSCP513. Following such approval and where the NHHDA is impacted, this BSC Procedure will be used to process the bulk change of agent.

1.2 Main Users of Procedure and their Responsibilities

The main user of this Procedure is the NHHDA. The NHHDA is required, on a trickle feed basis, from appropriate Non Half Hourly Data Collectors (NHHDCs), to receive, validate and update his database with Non Half Hourly data (viz. settlement register Estimated Annual Consumption and/ or Annual Advance (EAC/AA)), for all Non Half Hourly SVA Metering Systems assigned to him by the Supplier via SMRS. In accordance with timescales set by the Settlement Timetable, he is required to aggregate this data in the form of Supplier Purchase Matrices which are sent to SVAA for Volume Allocation Runs (VAR). These details shall also include the Settlement Days for which the NHHDA is appointed. The level of aggregation is to Settlement Class, i.e. to combination of Supplier, GSP Group, Profile Class and Timeslot (also referred to as ‘Measurement Requirement’) and Line Loss Factor Class. Additionally, where a Demand Disconnection occurs as part of a Demand Control Event, the NHHDA is required to generate and provide to the SVAA a separate Disconnection Purchase Matrix detailing the effect of such disconnection.

The NHHDA is also responsible for maintenance of his database of the SVA Metering Systems relevant to his aggregation responsibilities (viz nominated Supplier, NHHDC, NHHDA, Standard Settlement Configuration, Energisation Status, Profile Class, Measurement Class, Line Loss Factor Class and GSP Group) and relevant Market Domain data.

The NHHDA shall ensure that for each SVA Metering System for which it is responsible, energy consumption data is aggregated and passed to the Supplier Volume Allocation Agent (SVAA) using systems, software and processes so approved in accordance with BSCP537.

These systems, software and processes must also comply with all other applicable requirements set out in the Code and the BSC Procedures.

1.3 Market Domain Data Obligations

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

On receipt of any new MDD, the NHHDA shall find and resolve as soon as reasonably possible any conflicts with existing data in its system caused by the new MDD.

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 NHHDA has loaded the Data Aggregation and Settlements Timetable File, the NHHDA shall validate this file in accordance with Section 4.3.

1.4 Interface to Supplier Meter Registration Services

1.4.1 SMRS Data

The NHHDA shall accept instructions from any SMRS and shall promptly input into its processes so approved in accordance with BSCP537 the data and other information so received.

In performing its functions as NHHDA, the NHHDA shall treat data or other information received from a SMRS as definitive where it conflicts with data or other information provided to the NHHDA by its Supplier or its NHHDC.

1.4.2 Refresh Supplier Meter Registration Service MSID Data

When instructed to do so by BSCCo or the Performance Assurance Board (PAB), the NHHDA shall request and load a Full Refresh from a SMRS comprising the complete registration and standing data for all SVA Metering Systems for which the NHHDA is responsible in that SMRS whenever required to ensure the integrity of the NHHDA’s database.

Where required to resolve a failed instruction, query or exception reported during an aggregation run the NHHDA shall request a Selective Refresh for the relevant SVA Metering Systems from the relevant SMRS.

1.5 Communications

The NHHDA shall send and receive data and other information relating to its activities as NHHDA in accordance with the BSC SVA Data Catalogue. Except to the extent otherwise specified by the Panel, the NHHDA shall use the Managed Data Network for data transfers defined in this BSCP to and from any third party unless an alternative method for data transfer is agreed with that third party for data transfer to that third party.

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

1.6 Exception Management

1.6.1 Problem Log

The NHHDA shall establish and use a problem log for the management of failed and discarded instructions and shall maintain the log for audit and control purposes. The log shall hold information about failed or discarded instructions.

The NHHDA shall promptly record in the problem log the reasons for failure of failed instructions and the date and time of the latest processing attempt and shall record the instructions to be resolved by the NHHDA and those that have been resolved by it. The NHHDA shall, record in the problem log the corrective action taken in respect of each resolved instruction failure. For the purposes of audit requirements the NHHDA shall use the standardised script provided by BSCCo to report the number of exceptions in a consistent manner.

1.6.2 Identifying Negative Estimates of Annual Consumption

Upon request by the BSCCo, the NHHDA shall, within 10 Working Days, identify any negative EAC values in its database that are being used in Settlement and shall notify the Supplier of these negative EAC values and associated details. This shall be carried out by the execution of a script supplied by the BSCCo when making the request. Other than for the purposes of checking the initial data cleanse, it is not anticipated that the BSCCo will make such a request more than once per year, unless exceptional circumstances arise.

The Supplier shall, within 5 Working Days of receiving such notification from the NHHDA, pass details of the negative EAC values and associated details to the NHHDC by email or other agreed means.

1.7 Use of the Procedure

The Sections in this document should be used as follows:

Section 2 – No longer used.

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

Section 4 - Appendices: this section contains supporting information.

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

The NHHDA will be informed via BSCP513 of any Supplier’s intention to initiate a bulk change of agent where the number of Metering Systems affected exceeds the threshold set by the Panel. The NHHDA will be required to confirm whether it can implement the proposed changes without adversely impacting other NHHDA activities. Any bulk change of agent must therefore be initiated via BSCP513 before triggering the processes in this BSC Procedure.

1.8 Balancing and Settlement Code Provision

This BSC Procedure has been produced in accordance with the provisions of 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 NHHDAs under the Code can be found in BSC Sections J ‘Party Agents’ and S ‘Supplier Volume Allocation’ Section 2.4. An overview of these requirements is as follows:

The principle functions of a NHHDA are:

(a) to receive EAC/AAs from NHHDCs;

(b) to check EAC/AAs and provide reports;

(d) to maintain relevant standing data;

(e) to aggregate the annualised consumption data in MWh; and

(f) to provide aggregate annualised consumption data to the SVAA.

1.9 Service Levels

The NHHDA shall perform the services to be performed by it as NHHDA pursuant to this BSCP.

1.10 NHHDA Principles

The requirements of NHHDAs as set out under the Code are supported by the following functional, non-functional and operational principles. Further detail regarding these principles can be found in Section 4.4 to 4.6.

1.10.1 Functional Requirements Principles:

1. The NHHDA system must aggregate EACs and AAs to produce aggregated results for each Supplier by Settlement Class;

2. The NHHDA’s system must treat data provided by SMRAs as definitive where it conflicts with data or other information provided to the NHHDA by its Supplier or its NHHDC;

3. The NHHDA’s system must validate the data it receives from NHHDCs and SMRAs against MDD;

4. The NHHDA’s system must check inconsistencies between data received from NHHDCs and data received from SMRAs and must report such inconsistencies to Suppliers so that they may be operationally resolved;

5. The NHHDA’s system must support interfaces with all relevant parties and systems, to facilitate the timely and accurate provision and receipt of data.

1.10.2 Non-Functional Requirements:

1. The NHHDA’s system must be an auditable system and it must be possible to inspect both the aggregated results and the audited data used in their aggregation up to 28 months following the Settlement Day to which the results relate;

2. The NHHDA’s system must comply with the 1998 Programme’s Security and Control Framework.

1.10.3 Operational Requirements

1. The design and implementation of the NHHDA’s system must, given an appropriate hardware and software environment, enable operation to meet the prescribed SVAA Calendar.

1.11 Associated BSC Procedures

BSCP01	Overview of Trading Arrangements.
BSCP11	Trading Disputes.
BSCP501	Supplier Meter Registration Service.
BSCP504	Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS.
BSCP508	Supplier Volume Allocation Agent.
BSCP513	Bulk Change of Non Half Hourly Supplier Agent.
BSCP515	Licensed Distribution
BSCP537	Qualification Process for SVA Parties, SVA Party Agents and CVA MOAs.

1.12 Party Service Line

PSL100

Generic Non Functional Requirements For Licensed Distribution System Operators And Party Agents

1.13 Acronyms and Definitions

1.13.1 Acronyms

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

AA	Annualised Advance
BSCCo	Balancing and Settlement Code Company
DCE	Demand Control Event
EAC	Estimated Annual Consumption
GSP	Grid Supply Point
Id	Identifier
LDSO	Licensed Distribution System Operator
LLF	Line Loss Factor
MDD	Market Domain Data
MDDM	Market Domain Data Manager
MSID	Metering System Identifier
NETSO	National Electricity Transmission System Operator as the holder of the Transmission Licence and any reference to "NETSO", "NGESO", "National Grid Company" or "NGC" in the Code or any Subsidiary Document shall have the same meaning
NHHDA	Non Half Hourly Data Aggregator
NHHDC	Non Half Hourly Data Collector
PAB	Performance Assurance Board
Ref	Reference
SD	Settlement Day
SMRA	Supplier Meter Registration Agent
SMRS	Supplier Meter Registration Service
SPM	Supplier Purchase Matrix
SVA	Supplier Volume Allocation
SVAA	Supplier Volume Allocation Agent
SVAA	Supplier Volume Allocation Agent
VAR	Volume Allocation Run
WD	Working Day

1.13.2 Definitions

Full definitions of the above acronyms are included in the Code.

2. This section is no longer in use

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.	NHHDA.	MDDM.	NHHDA Id.	Electronic or other method, as agreed.
3.1.1.2	When published by SVAA or within 1 WD of request from NHHDA.	Send MDD.	SVAA.	NHHDA.	D0227 BSCCo Market Domain Data File. D0269 Market Domain Data Complete Set. D0270 Market Domain Data Incremental Set. D0286 Data Aggregation and Settlements Timetable File.	Electronic or other method, as agreed.
					P0223 GSP Group Profile Class Default EAC	Email
3.1.1.3	Within 4 working hours of receipt of MDD.	Send acknowledgement that data has been received.	NHHDA.	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.	NHHDA.	MDDM.	Appendix 4.3 - Validation of Data Aggregation and Settlements Timetable File.	Internal Process.
					P0035 Invalid Data.	Electronic or other method, as agreed.
3.1.1.5	After receiving notification.	Send corrected MDD.	SVAA.	NHHDA.	Refer to 3.1.1.2 for dataflows.	Electronic or other method, as agreed.
3.1.1.6	If data in correct format.	Update database.	NHHDA.			Internal Process

3.1.2 NHHDA Run and Send EAC Data to Distributors Report

The EAC Data to Distributor Report is a snapshot containing Estimated Annual Consumption (EAC) data and Metering System details in respect of Metering Systems located at Boundary Points on the relevant LDSO’s Distribution System(s) and Associated Distribution System(s), in accordance with Section S 2.4.2 (g).

This process is to be followed on a quarterly basis, with the report generated on (or the first Working Day after) the following Annual Dates: 1 February, 1 May, 1 August and 1 November.

Steps 3.1.2.1 and 3.1.2.2 are only to be followed when the LDSO first ‘opts in’ to receive the report, not for every time the report is to be run.

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.1.2.1	At least 20 WD before quarterly report date	LDSO’s ‘opt in’ by informing Suppliers they wish to receive EAC data, providing their Distributor ID, address and contact details¹	LDSO	Supplier	Notification of the LDSO	Fax/ Post/ E-mail
3.1.2.2	Within 5 WD following 3.1.2.1	Suppliers provide NHHDA with relevant LDSO details	Supplier	NHHDA.	Details of the ‘opted-in’ LDSOs	Fax/ Post/ E-mail, Electronic or other method, as agreed.
3.1.2.3	On Annual Date (or the first Working Day following this date)	NHHDAs generate EAC Data to Distributor Report	NHHDA.		P0222 EAC Data to Distributor Report	Internal Process
3.1.2.4	If data available, within 1 WD of 3.1.2.3	NHHDA send the report	NHHDA.	LDSO	P0222 EAC Data to Distributor Report	CD, or another medium if agreed by both parties²
3.1.2.5	If no data available, within 1 WD of 3.1.2.3	NHHDA notifies the relevant LDSOs they have no EAC data	NHHDA.	LDSO	Notification no data is available	Fax/ Post/ E-mail

3.2 Interface to SMRS

3.2.1 Appointment Changes³

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.2.1.1	As required.	Send appointment. In the event of a conflict between the D0209 from the SMRA and the D0153 from the Supplier (including the absence of either flow), the D0209 shall take precedence.	Supplier	NHHDA	D0153 Notification of Data Aggregator Appointment and Terms	Electronic or other method, as agreed.
3.2.1.2	If appointment rejected and within 2 WD of 3.2.1.3.	Send notification of rejection of appointment including the reason why the request has been rejected.	NHHDA	Supplier	D0261 Rejection of Agent Appointment. (Go to 3.2.1.3 if required).	Electronic or other method, as agreed.
3.2.1.3	If appointment accepted and within 2 WD of 3.2.1.3.	Send notification of acceptance of appointment.	NHHDA	Supplier	D0011 Agreement of Contractual Terms.	Electronic or other method, as agreed.
3.2.1.4	SMRA informed: that Supplier has obtained a new connection. of change of Supplier &/or NHHDA for an existing SVA Metering System (including measurement class change resulting in NHHDA to HHDA change or vice versa). of NHHDC change.	Send NHHDA / Supplier appointment start information. Send NHHDA / Supplier appointment finish information Send NHHDA / Supplier appointment start information. Send NHHDC / Supplier appointment change information.	SMRA. SMRA. SMRA. SMRA.	New NHHDA. Old NHHDA. New NHHDA. NHHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator. D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator. D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator. D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Electronic or other method, as agreed.
3.2.1.5	After receiving information.	Validate information in accordance with Section 3.4 and Appendices: 4.2.1 Instruction Files; and 4.2.2 NHHDA appointment changes; or 4.2.3 NHHDC appointment changes.	NHHDA.			Internal Process.

3.2.2 Changes to SVA Metering System standing Data

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.2.2.1		Send information with change of SVA Metering System’s standing data.	SMRA.	NHHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Electronic or other method, as agreed.
3.2.2.2	After receiving information.	Validate information received in accordance with Section 3.4 and Appendices: 4.2.1 Instruction Files; and 4.2.4 SVA Metering System standing data changes.	NHHDA.			Internal Process.

REF.

WHEN

ACTION

FROM

INFORMATION REQUIRED

METHOD

3.2.2.1

Send information with change of SVA Metering System’s standing data.

SMRA.

NHHDA.

D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.

Electronic or other method, as agreed.

3.2.2.2

After receiving information.

Validate information received in accordance with Section 3.4 and Appendices:

4.2.1 Instruction Files;

and

4.2.4 SVA Metering System standing data changes.

NHHDA.

Internal Process.

3.2.3 Requests for SMRS Information

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.2.3.1	At any time for Selective Refresh. When instructed by BSCCo or the Performance Assurance Board (PAB), or at any other agreed time for Full Refresh.	Request Full or Selective Refresh of database.	NHHDA.	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, Fax.
3.2.3.2	If request refused⁴ then: within 1 WD of receipt of request.	Advise refusal.	SMRA.	NHHDA.	Identification of request and reason for refusal.	Manual.
3.2.3.3	If request accepted, then within 1 WD of receipt of request for Full Refresh.	Notify NHHDA of scheduled date for delivery of Full Refresh.	SMRA.	NHHDA.	Scheduled date for delivery of Full Refresh.	Manual, Fax.
3.2.3.4	Within 15 WD of receipt of Full/Selective refresh request.	Send information to refresh NHHDA’s database.	SMRA.	NHHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Electronic or CD ROM, or other method, as agreed.
3.2.3.5	After receipt of information.	Validate information received in accordance with Appendix 4.2 and if Selective Refresh proceed in accordance with Section 3.4.	NHHDA.			Internal Process.
3.2.3.6	If Full Refresh and if refresh failed for any SVA MS	Either: Request re-send of Full Refresh Or Refresh database for SVA MS’s that passed validation And For SVA MS’s that failed validation and if problem with file not caused by NHHDA, continue in accordance with Section 3.4.	NHHDA. NHHDA.	SMRA.	All relevant NHHDA data.	Manual, Fax. Internal Process.
	If Full Refresh and if refresh passed.	Refresh database.	NHHDA.			Internal Process.
3.2.3.7	If a re-send required, then anytime within 28 days of original message.	Request a re-send of original message.	NHHDA.	SMRA.	Message number and / or date.	Manual.
3.2.3.8	If request refused then: within 1 WD of receipt of request.	Advise refusal and reason.	SMRA.	NHHDA.	Identification of original request and reason for refusal.	Manual.
3.2.3.9	If request accepted then: if NHHDA error within reasonable endeavours; if not, within 36 hrs of receipt of request.	Re-send message.	SMRA.	NHHDA.	Duplicate of original message.	Electronic or other method, as agreed.

3.3 Aggregation Activities

3.3.1 Receive AA/EAC Data from NHHDC

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.3.1.1		Send SVA Metering System’s AA/EACs & relationships.	NHHDC.	NHHDA.	D0019 Metering System EAC/AA Data.	Electronic or other method, as agreed.
3.3.1.1	After receipt of information.	Validate information received in accordance with Section 3.4⁵ and Appendices: 4.2.1 Instruction Files; and 4.2.6 NHHDC consumption data.	NHHDA.			Internal Process

REF.

WHEN

ACTION

FROM

INFORMATION REQUIRED

METHOD

3.3.1.1

Send SVA Metering System’s AA/EACs & relationships.

NHHDC.

NHHDA.

D0019 Metering System EAC/AA Data.

Electronic or other method, as agreed.

3.3.1.1

After receipt of information.

Validate information received in accordance with Section 3.4⁵ and Appendices:

4.2.1 Instruction Files;

and

4.2.6 NHHDC consumption data.

NHHDA.

Internal Process

3.3.2 Data Aggregation Run⁶

REF.	WHEN		ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.3.2.1		In accordance with SVA Agent’s calendar deadline for 3.3.2.3 below for the relevant Settlement Day.	For each MSID, validate relevant data from NHHDC: If invalid: If consumption data missing, inconsistent or in error, use defaults (in accordance with the Code). If other (non-consumption) data different from SMRS data then use SMRS data. Create an exception record containing invalid data details.	NHHDA.		EAC/AA used for MSID and when applicable, the EAC/AA default method used. Any of the following Exception Conditions: SMRA / NHHDC mismatch of: Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status Missing EAC/AA for the SVA Metering System resulting in a default EAC being used⁷. Unmetered SVA Metering System with an AA. De-energised SVA Metering System with non-zero AA. Missing standing data: Data Collector Appointments, Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status.	Internal Process.
3.3.2.2		After 3.3.2.1.	Carry out aggregation run⁸ for specified Settlement Day to produce Supplier Purchase Matrix (SPM), in accordance with the SVA Rules.	NHHDA.			Internal Process.
3.3.2.3		In accordance with SVAA Calendar.	Send SPM Data File⁹.	NHHDA	SVAA¹⁰, Supplier¹¹.	D0041 Supplier Purchase Matrix Data File.	Electronic or other method, as agreed.
3.3.2.4		If file missing or invalid in accordance with BSCP508.	Send notification of missing or invalid SPM Data File and request to provide SPM Data File. Return to 3.3.2.3.	SVAA.	NHHDA.	P0034 Missing Data. P0035 Invalid Data.	Electronic or other method, as agreed.
3.3.2.5		Within 5 WD of aggregation for Final Reconciliation Volume Allocation Run.	Send notification of those MSIDs which were excluded from SPM because there was missing SVA Metering System specific details (derived from the NHHDA Aggregation Exception Log).	NHHDA.	Supplier / Panel	MSID and Supplier for those MSIDs which were excluded from the SPM because of missing SVA Metering System specific details.	Manual Process.

3.3.3 NHHDA investigates inconsistencies

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.3.3.1	In accordance with Supplier's timetables and prior next to VAR.	Check NHHDA Database for data exceptions.	NHHDA.			Internal Process.
3.3.3.2	Following 3.3.3.1 and in accordance with Supplier's timetable and prior to next VAR.	Send Exception Report.	NHHDA.	Supplier / Panel / PAB.	D0095 Non Half Hourly Data Aggregation Exception Report.	Electronic or other method, as agreed.

REF.

WHEN

ACTION

FROM

INFORMATION REQUIRED

METHOD

3.3.3.1

In accordance with Supplier's timetables and prior next to VAR.

Check NHHDA Database for data exceptions.

NHHDA.

Internal Process.

3.3.3.2

Following 3.3.3.1 and in accordance with Supplier's timetable and prior to next VAR.

Send Exception Report.

NHHDA.

Supplier /

Panel /

PAB.

D0095 Non Half Hourly Data Aggregation Exception Report.

Electronic or other method, as agreed.

3.3.4 Data Aggregation for Demand Control Events

The aggregation of data for MSIDs affected by Demand Disconnection only takes place for Settlement Days that include Demand Control Impacted Settlement Periods. The aggregation of impacted MSIDs will run in parallel to the ordinary aggregation of data for all MSIDs (irrespective of any Demand Disconnection) as set out in section 3.3.2.

REF	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.3.4.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.3.4.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.3.4.3	Within 5WD of 3.3.4.2	Send notification of Demand Control Event and all affected MSIDs¹²	LDSO	BSCCo	P0238 MSIDs affected by Demand Control Event¹³	Email to bscservicedesk@cgi.com
3.3.4.4	Within 1WD of 3.3.4.3	Acting on behalf of LDSOs, BSCCo will forward notifications received from LDSOs to HHDCs, HHDAs, SVAA	BSCCo	NHHDC, NHHDA, SVAA	P0238 MSIDs affected by Demand Control Event	Email Nb BSCCo will maintain details of Party Agent contact details to ensure it is able to send P0238
3.3.4.5	Within 26WD of 3.3.4.2	Notify NHHDC and NHHDA of any MSIDs subject to demand side Non-BM STOR instruction along with estimated volumes of reduction	SVAA	NHHDC, NHHDA	D0375 Disconnected MSIDs and Estimated Half Hourly Demand Disconnection Volumes	Electronic or other method, as agreed
3.3.4.6	At any time after 3.3.4.4 or 3.3.4.5	Send EAC/AA data taking account of Demand Disconnection	NHHDC	NHHDA	D0019 Metering System EAC/AA Data	Electronic or other method, as agreed
3.3.4.6	In accordance with SVA Agent’s calendar deadline for 3.3.4.8 below for the relevant Settlement Day.	For each Demand Disconnection impacted MSID, validate relevant data from NHHDC: If invalid: If consumption data missing, inconsistent or in error, use defaults (in accordance with the Code). If other (non-consumption) data different from SMRS data then use SMRS data. Create an exception record containing invalid data details.	NHHDA.		EAC/AA used for MSID and when applicable, the EAC/AA default method used. Any of the following Exception Conditions: SMRA / NHHDC mismatch of: Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status Missing EAC/AA for the SVA Metering System resulting in a default EAC being used¹⁴. Unmetered SVA Metering System with an AA. De-energised SVA Metering System with non-zero AA. Missing standing data: Data Collector Appointments, Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status.	Internal Process.
3.3.4.7	After 3.3.4.6	Carry out aggregation run¹⁵ for Settlement Day(s) including Demand Control Impacted Settlement Periods and for MSIDs affected by Demand Disconnection only to produce Disconnection Purchase Matrix (DPM), in accordance with the SVA Rules.	NHHDA		EAC/AA for MSIDs affected by Demand Disconnection	Internal
3.3.4.8	In accordance with SVAA Calendar.	Send Disconnection Supplier Purchase Matrix File	NHHDA	SVAA	D0377 Disconnection Purchase Matrix Data File¹⁶	Electronic or other method, as agreed

3.4 Instruction Processing

REF.	WHEN	ACTION	FROM	TO	INFORMATION REQUIRED	METHOD
3.4.1	On receipt of file.	Perform validation checks.	NHHDA.		D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Internal Process.
3.4.2	If validation successful.	Update database with instruction data.	NHHDA.		D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator.	Internal Process.
3.4.3	If validation unsuccessful.	Notify SMRA of problem.	NHHDA.	SMRA.	P0035 Invalid Data (for transmission problems). D0023 Failed Instructions (for instruction level validation problems).	Electronic or other method, as agreed.
3.4.4	Upon receipt of failure notification.¹⁷	If transmission problem, resend exact copy of instruction file.¹⁸ If file validation problem, generate and send refresh file. If problem believed to be caused by NHHDA, notify NHHDA.¹⁹	SMRA.	NHHDA, Supplier. NHHDA, Supplier. NHHDA.	D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator. D0209 Instruction(s) to Non Half Hourly or Half Hourly Data Aggregator. As appropriate.	Electronic or other method, as agreed.

4. Appendices

4.1 This page has intentionally been left blank.

4.2 Data Validation

4.2.1 Instruction Files

The file will be validated to ensure:

physical integrity;
that it is for the NHHDA;
that it is from a valid SMRA or a valid NHHDC;
that the file only contains instructions which are valid for the source (e.g. a NHHDC can only send a “EAC/AA and MS Details” Instruction; a SMRA can only send instructions relating to SVA Metering System Registration);
that the file sequence number is contiguous with and higher than the last instruction file sequence number from the source. If this is not the case, the file is not processed and is left in the ‘Receipt’ area;
that the instructions in the file are in instruction sequence number order and the first instruction sequence number in the file is contiguous with the sequence number of the last instruction received from the source of the file;
that, if the file contains a SMRS Full Refresh instruction, it is the only instruction in the file.

4.2.2 NHHDA Appointment changes

The data are validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) that there is not an existing NHHDA 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);

(iii) that, if the instruction contains only a NHHDA Appointment record with a start and end date (with no related details), a NHHDA Appointment exists on the system with the same start date and no end date;

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

(a) that they all contain valid Supplier Ids;

(b) that they all overlap or start on or after the significant date;

(d) that all the start dates are unique;

(e) that each registration has at least one NHHDA Appointment;

(v) for the ‘SVA Metering System’s NHHDA Appointments’ in the instruction:

(a) that they are all for this NHHDA;

(b) that the start date is less than or equal to the end date;

(d) that they all overlap or start on or after the significant date;

(e) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(f) that none have a start or end date earlier that the start date for the registration;

(g) 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;

(h) that none of the appointments overlap each other or any other appointment for the SVA Metering System;

(i) that all the start dates are unique;

(vi) for the ‘SVA Metering System’s NHHDC Appointments’ in the instruction:

(a) that they are all for valid NHHDCs;

(b) that they are all for registrations that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier that the start date for the registration;

(f) that no Registrations will be left without a NHHDC Appointment if the instruction is applied;

(g) that all the start dates are unique;

(vii) for the ‘SVA Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ in the instruction:

(a) that they are all for valid Profile Classes;

(b) that they are all for valid Standard Settlement Configurations;

(d) that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Annual Fraction of Yearly Consumption for all Settlement Days within all Non Half Hourly Data Aggregator Appointments;

(e) that they are all for registrations that will exist if the instruction is applied;

(f) that they all overlap or start on or after the significant date;

(g) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(h) that none have a start date earlier than the start date for the registration;

(i) 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;

(j) that they all overlap with one or more NHHDA Appointments which will exist for this Registration if the instruction is applied;

(k) that no Registrations will be left without a Profile Class or Standard Settlement Configuration for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(l) that all the start dates are unique;

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

(a) that they are all for valid Measurement Classes;

(b) that they are all for registrations that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier that the start date for the registration;

(f) 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;

(g) that they all overlap with one or more NHHDA Appointments which will exist for this Registration if the instruction is applied;

(h) that no Registrations will be left without a Measurement Class for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(i) that all the start dates are unique;

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

(a) that the Energisation Status are ‘D’ or ‘E’;

(b) that they are all for registrations that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier that the start date for the registration;

(f) 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;

(g) that they all overlap with one or more NHHDA Appointments which will exist for this Registration if the instruction is applied;

(h) that no Registrations will be left without an Energisation Status for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(i) that all the start dates are unique;

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

(a) that they are all for valid LDSOs and Line Loss Factor Classes;

(b) that they are all for SVA Metering Systems that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that they all overlap with one or more NHHDA Appointments which will exist if the instruction is applied;

(f) that the SVA Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(g) that all the start dates are unique;

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

(a) that they are all for valid GSP Groups;

(b) that they are all for SVA Metering Systems that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that they all overlap with one or more NHHDA Appointments which will exist if the instruction is applied;

(f) that the SVA Metering System will not be left without a GSP Group for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(g) that all the start dates are unique;

(h) that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Annual Fraction of Yearly Consumption for all Settlement Days within all Non Half Hourly Data Aggregator Appointments.

4.2.3 NHHDC Appointment changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) For the NHHDC Appointment relationships in the instruction:

(a) that they are all for valid NHHDCs;

(b) that they are all for registrations that already exist in the system;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier that the start date for the registration;

(f) that no Registrations will be left without a NHHDC Appointment if the instruction is applied;

(g) that all the start dates are unique.

4.2.4 SVA Metering System standing data changes

4.2.4.1 Profile Class/ SSC changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) for the Profile Class / Standard Settlement Configuration relationships in the instruction:

(a) that they are all for valid Profile Classes;

(b) that they are all for valid Standard Settlement Configurations;

(e) that they are all for registrations that already exist in the system;

(f) that they all overlap or start on or after the significant date;

(g) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(h) that none have a start date earlier that the start date for the registration;

(i) 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;

(j) that they all overlap with one or more NHHDA Appointments which already exist for this Registration;

(k) that no Registrations will be left without a Profile Class or Standard Settlement Configuration for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(l) that all the start dates are unique.

4.2.4.2 Measurement Class changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) for the Measurement Class relationships in the instruction:

(a) that they are all for valid Measurement Classes;

(b) that they are all for registrations that already exist in the system;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier than the start date for the registration;

(f) 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;

(g) that they all overlap with one or more NHHDA Appointments which already exist for this Registration;

(h) that no Registrations will be left without a Measurement Class for any Settlement Day within a NHHDA Appointment if the instruction is applied; and

(i) that all the start dates are unique.

4.2.4.3 Energisation Status changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) for the Energisation Status relationships in the instruction:

(a) that they are all either ‘D’ or ‘E’;

(b) that they are all for registrations that already exist in the system;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none have a start date earlier that the start date for the registration;

(f) 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;

(g) that they all overlap with one or more NHHDA Appointments which already exist for this Registration;

(h) that no Registrations will be left without an Energisation Status for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(i) that all the start dates are unique.

4.2.4.4 GSP Group changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) for the GSP Group relationships in the instruction:

(a) that they are all for valid ‘GSP Groups’;

(b) that they are all for SVA Metering Systems that already exist in the system;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that they all overlap with one or more NHHDA Appointments which already exist for this SVA Metering System;

(f) that no NHHDA Appointments will be left without a GSP Group for any Settlement Day if the instruction is applied;

(g) that all the start dates are unique;

4.2.4.5 LLFC changes

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO associated with the SVA Metering System;

(ii) for the Line Loss Factor Class relationships in the instruction:

(a) that they are all for valid LDSOs and Line Loss Factor Classes;

(b) that they are all for SVA Metering Systems that will exist if the instruction is applied;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that they all overlap with one or more NHHDA Appointments which will exist if the instruction is applied;

(f) that the SVA Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a NHHDA Appointment if the instruction is applied;

(g) that all the start dates are unique.

4.2.5 SMRS Full Refresh Data

The instruction is validated to ensure:

(i) that the SMRA which sent the instruction is currently appointed to the LDSO that is the subject of the instruction;

(ii) that no SVA Metering System(s) exist on the database with a NHHDA Appointment which begins prior to the significant date and either does not end or ends on or after the significant date and this NHHDA Appointment is not included in the instruction;

(iii) for each SVA Metering System in the instruction:

(a) 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 NHHDA Appointment;

(b) for the ‘SVA Metering System’s NHHDA Appointments’ in the instruction:

that they are all for this NHHDA;
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;

that they are all for valid NHHDCs;
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 that the start date for the registration;
that no Registrations will be left without a NHHDC Appointment if the instruction is applied;
that all the start dates are unique;

(d) for the ‘SVA Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ in the instruction:

that they are all for valid Profile Classes;
that they are all for valid Standard Settlement Configurations;
that they are all for a valid combination of Profile Class and Standard Settlement Configuration;
that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Annual Fraction of Yearly Consumption for all Settlement Days within all Non Half Hourly Data Aggregator Appointments;
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 that 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 NHHDA Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without a Profile Class or Standard Settlement Configuration for any Settlement Day within a NHHDA Appointment if the instruction is applied;
that all the start dates are unique;

(e) 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 that 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 NHHDA 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 NHHDA Appointment if the instruction is applied;
that all the start dates are unique;

(f) 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 NHHDA 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 NHHDA Appointment if the instruction is applied;
that all the start dates are unique;

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

that they are all for valid LDSOs 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 NHHDA 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 NHHDA Appointment if the instruction is applied;
that all the start dates are unique;

(h) for all the ‘SVA Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and overlap with a NHHDA Appointment for the NHHDA.

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 NHHDA 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 NHHDA Appointment if the instruction is applied;
that all the start dates are unique;
that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Average Fraction of Yearly Consumption for all Settlement Days within all Non Half Hourly Data Aggregator Appointments.

4.2.6 NHHDC consumption data

The instruction is validated to ensure that:

(i) applying the instruction will not result in the SVA Metering System being without (in the NHHDC’s view) a Registration, Profile Class, Standard Settlement Configuration, Measurement Class, Energisation Status or GSP Group at any time during any of the NHHDC’s view of its Meter Advance Consumptions or Estimated Annual Advances;

(ii) there is not an existing Meter Advance Consumption which begins prior to the significant date and ends on or after the significant date which is not also contained in the instruction;

(iii) that none of the following change during a Meter Advance Period:

(a) Standard Settlement Configuration;

(b) Energisation Status;

(d) Measurement Class.

(iv) for the sets of AA details for the SVA Metering System:

(a) that the Effective From Settlement Date is less than or equal to the Effective To Settlement Date;

(b) that the set of AAs are for the set of Time Pattern Regimes associated with this NHHDC’s view of the SVA Metering System’s Standard Settlement Configuration;

(d) that they all overlap or start on or after the significant date;

(e) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(f) that none of the set of AAs exceed a consumption threshold value, configurable through NHHDA software;

(v) for the sets of EAC details for the SVA Metering System:

(a) that the set of EACs are for the set of Time Pattern Regimes associated with this NHHDC’s view of the SVA Metering System’s Standard Settlement Configuration;

(b) that the start dates for the sets of EAC details are unique;

(d) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(e) that none of the set of EACs exceed a consumption threshold value, configurable through NHHDA software;

(vi) for the NHHDC’s view of ‘SVA Metering System’s Registrations’ in the instruction:

(a) that they all contain valid Supplier Ids;

(b) that they all overlap or start on or after the significant date;

(d) that all the start dates are unique;

(e) that the SVA Metering System will not be left without a Registration for any Settlement Day within the NHHDC’s view of the SVA Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

(vii) for the NHHDC’s view of ‘SVA Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ in the instruction:

(a) that they are all for valid Profile Classes;

(b) that they are all for valid Standard Settlement Configurations;

(d) that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Annual Fraction of Yearly Consumption for all Settlement Days within all Meter Advance Periods;

(e) that they all overlap or start on or after the significant date;

(f) that if one has a start date before the significant date, the rest must have start dates after the significant date;

(g) that all the start dates are unique;

(h) that the SVA Metering System will not be left without a Profile Class or Standard Settlement Configuration for any Settlement Day within the NHHDC’s view of the SVA Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

viii) for the NHHDC’s view of ‘SVA Metering System’s relationships with Measurement Classes’ in the instruction:

(a) that they are all for valid Measurement Classes;

(b) that they all overlap or start on or after the significant date;

(d) that all the start dates are unique;

(e) that the SVA Metering System will not be left without a Measurement Class for any Settlement Day within the NHHDC’s view of the SVA Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

(ix) for the NHHDC’s view of ‘SVA Metering System’s Energisation Statuses’ in the instruction:

(a) that the Energisation Status are ‘D’ or ‘E’;

(b) that they all overlap or start on or after the significant date;

(d) that all the start dates are unique;

(e) that the SVA Metering System will not be left without an Energisation Status for any Settlement Day within the NHHDC’s view of the SVA Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

(x) for the NHHDC’s view of ‘SVA Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and overlap with a NHHDA Appointment for the NHHDA:

(a) that they are all for valid GSP Groups;

(b) that they all overlap or start on or after the significant date;

(d) that all the start dates are unique;

(e) that the SVA Metering System will not be left without a GSP Group for any Settlement Day within the NHHDC’s view of the SVA Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

(f) that the Profile Class, Standard Settlement Configuration and GSP Group have an associated Annual Fraction of Yearly Consumption for all Settlement Days within all Meter Advance Periods.

4.3 Validation of Data Aggregation and Settlements Timetable File

The NHHDA shall validate this file and will reject the file if any of the following conditions are not satisfied:

4.3.1 that the First Payment Date is less than or equal to the Last Payment Date;

4.3.2 that all Payment Dates are on or between the First and Last Payment Dates;

4.3.3 that every Settlement Date is less than its Planned Data Aggregation Run Date;

4.3.4 that every Planned Data Aggregation Run Date is less than its SVA Notification Date;

4.3.5 that every SVA Notification Date is less than its Payment Date; and

4.3.6 that every Settlement Code is valid.

The NHHDA shall report any of the above exceptions to the SVA Agent.

4.4 Functional Requirements

4.4.1 Market Domain Data

4.4.1.1 The NHHDA must be able to enter manually into the NHHDA’s system the following information from the BSCCo’s MDD:

Suppliers;
NHHDC;
SVA Agent;
SMRAs;
LDSO (and their timed relationships with SMRAs);
GSP Groups (and their timed relationships with SVA Agents, SMRAs and LDSO);
Profile Classes;
Standard Settlement Configurations, their Measurement Requirements, valid combinations with Profile Classes and Average Fraction of Yearly Consumptions;
Threshold Parameter.

The NHHDA’s system will store this data, including all the data defined in the following entities in the Enduring Design Authority (EDA) : Supplier, Non Half Hourly Data Collector, SVA Agent, SMRA, GSP Group, SVA Agent Appointment, SMRA Appointment, Licensed Distribution System Operator, Profile Class, Measurement Class, Standard Settlement Configuration, Measurement Requirement, Valid Settlement Configuration Profile Class, Valid Measurement Requirement Profile Class, Average Fraction of Yearly Consumption and Threshold Parameter. (Mandatory).

4.4.1.2 The NHHDA must be able to enter manually into the NHHDA’s system the following information from the BSCCo’s MDD:

Line Loss Factor Classes.

originating from the LDSO, maintained and distributed by the MDD Agent.

The NHHDA’s system will store this data, including all the data defined in the following entity in the EDA: Line Loss Factor Class. (Mandatory).

4.4.1.3 The NHHDA must be able to enter manually into the NHHDA’s system the following information from the BSCCo’s MDD:

GSP Group Profile Class Default EACs for the relevant GSP Group and the date from which they are effective.

originating from the LDSO, maintained and distributed by the MDD Agent.

The NHHDA’s system will store this data, including all the data defined in the following entity in the EDA: GSP Group Profile Class Default EAC. (Mandatory).

4.4.1.4 The NHHDA must be able to load electronically into the NHHDA’s system the following information from the BSCCo’s MDD:

Threshold Parameters, Line Loss Factor Classes, Measurement Requirements, Valid Settlement Configuration Profile Class details, Standard Settlement Configuration details, Profile Class details, Average Fraction of Yearly Consumption details, Time Pattern Regimes, Supplier, Non Half Hourly Data Collector, SVA Agent, SMRA, Licensed Distribution System Operator, SMRA Appointment, SVA Agent Appointment and GSP Group Licensed Distribution System Operator. (Mandatory).

When loading the MDD the NHHDA’s system must report any conflicts with existing data.

4.4.2 Instruction Processing

4.4.2.1 The NHHDA’s system must have an interface to receive files containing numbered data maintenance Instructions from SMRAs and NHHDCs. The NHHDA’s system must support the processing of these files and instructions. (Mandatory).

4.4.2.2 NHHDA must be able to browse and report Instructions, and their reason for being in the state they are in. (Mandatory).

4.4.2.3 The NHHDA must be able to manage and rectify Instruction and File processing problems. The NHHDA’s system must support the processing of these files and instructions. (Mandatory).

4.4.2.4 The NHHDA must be able to advise the source of Instructions that have failed and the reasons for failure. The NHHDA’s system must support the processing of these files and instruction. (Mandatory).

4.4.2.5 The NHHDA must be notified by the NHHDA system if an unrecognised SMRS instruction type is received from a SMRA. (Mandatory).

4.4.2.6 Each Instruction received from a SMRA must be validated against the BSCCo’s and the LDSO’s MDD (Mandatory). Each Instruction received from a SMRA must undergo the business validation as detailed in Section 4.2.1. (Mandatory).

4.4.2.7 Inconsistencies found between existing data and data contained in each “SMRS Full Refresh” Instruction must be reported by the NHHDA system to the NHHDA. (Mandatory).

4.4.2.8 The NHHDA must be notified by the NHHDA system if an unrecognised Data Collector instruction type is received from a Data Collector. (Mandatory).

4.4.2.9 Each Instruction received from a Data Collector must be validated against the BSCCo’s MDD. (Mandatory).

Each Instruction received from a Data Collector must undergo the business validation as detailed in Section 4.2.1. (Mandatory).

4.4.2.10 The subject of a Full Refresh of data from a SMRA must be a LDSO. (Mandatory).

4.4.2.11 Instruction file sequence numbers and Instruction sequence numbers within the Instruction file must be unique and sequential between source and target.

4.4.2.12 The NHHDA’s system must be able to store all of the data defined in the following entities in the EDA: SVA Metering System, Settlement Configuration in Registration, SVA Metering System Profile Class in Registration, SVA Metering System Line Loss Factor Class, SVA Metering System GSP Group, SVA Metering System Energisation Status, SVA Metering System Measurement Class in Registration, Registration, Data Collector Appointment, Data Aggregator Appointment, SVA Metering System Measurement Class (DC), Registration (DC), SVA Metering System GSP Group (DC), SVA Metering System Energisation Status (DC), SVA Metering System Profile Class (DC), Settlement Configuration (DC), Settlement Register (DC), Estimated Annual Consumption (DC), Meter Advance Period (DC) and Meter Advance Consumption (DC). (Mandatory).

4.4.2.13 The NHHDA’s system must be capable of reporting upon the consistency of data received from a Data Collector with data received from SMRAs and other Data Collectors.

The exception report will be produced on request by the NHHDA’s system, and must be sent to the NHHDA and the Supplier.

The report must also contain details of the total number of SVA Metering Systems, the total number of SVA Metering Systems in each of the above categories and the total number of metering systems in one or more of the above categories.

It must be possible to restrict the report to a selected range of dates, and / or selected SMRA(s). (Mandatory).

4.4.2.14 In the event of an inconsistency in the data provided by the SMRA and that provided by the NHHDC, the data provided by the SMRA must be treated as definitive. (Mandatory).

4.4.3 Aggregation Runs

4.4.3.1 The NHHDA must be able to request aggregation runs. For each aggregation run, the NHHDA must be able to specify:

the Interim Information Volume Allocation Run, the Initial Volume Allocation Run or the Reconciliation Volume Allocation Run that the appropriate run is for (Mandatory);
the date and time the run should take place (Mandatory);
the applicable GSP Group to be included in the run (Mandatory).

4.4.3.2 The NHHDA’s system will store details of the aggregation runs requested, including all the data defined in the following entities in the EDA: Data Aggregation Run and GSP Group in Aggregation Run. (Mandatory).

4.4.3.3 The NHHDA may electronically load the Data Aggregation and Settlements Timetable File. Each Data Aggregation and Settlements Timetable File will contain the following data items:

First / Last Payment Date, i.e. those dates for which Settlement activities are included within the Settlement timetable (Mandatory);
Settlement Date and Settlement Code for which an aggregation run is required (Mandatory);
Payment Date i.e. the date on which Moneys are to be transferred (Mandatory);
the SVA Notification Deadline Date, i.e. the latest Calendar Day on which the SVAA is to receive Supplier Purchase Matrix data from the NHHDA for that aggregation run (Mandatory);
the Planned Data Aggregation Run Date, i.e. the advisory date upon which an aggregation run is scheduled to start (Mandatory);
the Planned SVA Run Date, i.e. the date upon which an SVA Run is scheduled to start (Desirable).

4.4.3.4 Loading the Data Aggregation and Settlements Timetable File will schedule the aggregation runs required to support it. (Mandatory).

4.4.3.5 Each aggregation run will be scheduled either on the Planned Aggregation Run Date in the Data Aggregation and Settlements Timetable File or a configurable number of working days before the aggregated results are required to be sent to the SVAA. (Mandatory).

4.4.3.6 The NHHDA will be able to browse and update the scheduled aggregation runs. (Mandatory).

4.4.3.7 Aggregated results should be automatically sent to the SVAA. (Desirable).

4.4.3.8 An aggregation run must sum to Settlement Class level all totals and counts described and in accordance with the aggregation rules specified in Section 3.3.2.

If a NHHDC has been appointed but not supplied any data, then previously supplied data must be used, if available.

EACs and AAs, which are received in kWh, must be summed and output in MWh by dividing by 1000.

Only Metering Systems to which the NHHDA is appointed for the Settlement Day must be included in the aggregation run.

AAs will not be used for SVA Metering Systems which SMRS deems to be unmetered, even if an AA is submitted by the appointed Data Collector. (Mandatory).

4.4.3.9 If, during an aggregation run, there is no valid EAC/AA for a SVA Metering System’s Settlement Register that is required to be included in the aggregation, a default EAC must be used. The default EAC must be the average for SVA Metering System Settlement Registers of the same Measurement Class (metered or unmetered), supplied by the same Supplier and assuming the same Settlement Class.

If the number of SVA Metering System Settlement Registers to base an average on is less than the Threshold Parameter, then the average EAC for the SVA Metering System’s GSP Group and Profile class (determined through load research by the Profile Administrator) multiplied by the average yearly consumption for the Settlement Register’s Measurement Requirement must be used.

4.4.3.10 The NHHDA’s system must transmit aggregated results for each GSP Group prepared during the aggregation run of an Interim Information Volume Allocation Run or an Initial Volume Allocation Run or Reconciliation Volume Allocation Run to the SVAA. Aggregated consumption must be provided to SVAA in MWh. (Mandatory).

4.4.3.11 The NHHDA shall provide data for any adjustments to Volume Allocation Runs arising as a result of Trading Disputes in accordance with BSCP11.

4.4.4 General Requirements

4.4.4.1 SVA Metering System numbers must be associated with a LDSO such that it appears to the NHHDA’s system that SVA Metering Systems can never change LDSO. (Mandatory).

4.4.4.2 The appointment of SMRAs must be to a LDSO and not to a GSP Group.

All SVA Metering Systems for the GSP Groups within a LDSO must be appointed to one and only one SMRA at any one time. (There must be one and only one SMRA administering any given SVA Metering System at any given time.) (Mandatory).

4.4.4.3 Extract files from the NHHDA’s system shall be formulated into a predictable output as described in the BSC SVA Data Catalogue. (Mandatory).

4.5 Non Functional Requirements

4.5.1 The following data must be recorded about all files received by the NHHDA’s system:

the Id of the organisation from which the file was received;
the date and time at which the file was delivered to the system;
the date and time at which the file underwent receipt processing.

4.5.2 The following data must be recorded about all files sent by the Non NHHDA’s system:

the Id of the organisation to which the file was sent;
the date and time at which the file was created;
the date and time at which the file was sent.

4.5.3 Controls (including checksum values) must be included in files such that the recipient of the file can verify that the file has been successfully delivered with its contents unaltered.

This extends to files sent and files received and is described in the BSC SVA Data Catalogue.

4.5.4 Controls must be in place to prevent unauthorised sources providing data and to prevent authorised sources masquerading as a different authorised source.

4.5.5 Compliance with BS7799 (Code of Practice for Information Security Management) should be achieved. (This is highly desirable not mandatory).

4.5.6 NHHDA infrastructure must enable secure, complete, uncorrupted and timely transfer of external data.

4.5.7 Where changes are made by Instructions, the NHHDA’s system must maintain an audit trail so that the change can be tracked.

4.5.8 Instructions received from SMRAs and Data Collectors must be kept for audit purposes 28 months following the Settlement Day.

4.5.9 Controls must be included in the files containing aggregated results which are passed to SVAA so that the SVAA is able to determine the number of SVA Metering System Settlement Registers contributing to each aggregated element.

4.5.10 Controls must be included in the files containing aggregated results which are passed to SVAA so that the SVAA is able to determine the number of SVA Metering System Settlement Registers contributing to each aggregated element for which a default EAC had to be used (a default EAC being one automatically derived in accordance with aggregation rules in the event of a missing or invalid EAC).

4.5.11 Aggregation runs must be based on the most up to date data at the time of aggregation.

4.5.12 When performing an aggregation run, the NHHDA’s system must detect (and subsequently be able to report upon for audit purposes) the following exceptions in Data Collector data:

no EAC or AA data has been received from the appointed Data Collector for the Settlement Day;
EAC or AA data received from more than one Data Collector for the Settlement Day;
GSP Group, Profile Class, Standard Settlement Configuration, Supplier Registration, Measurement Class or Energisation Status data received from the appointed Data Collector is inconsistent with that recorded on a SMRS.

4.5.13 It must be possible to electronically browse, query and report data calculated in or used in, or data exceptions encountered in an aggregation run. (The implementation of this may include restoration of archived data).

4.5.14 It must be possible to electronically browse exceptions or report and log files generated in other processing.

4.5.15 The MDD will be finalised prior to the Interim Information Volume Allocation Run (prior to the Initial Volume Allocation Run or any Reconciliation Volume Allocation Runs). Under normal circumstances this data must not be updated after the Initial Volume Allocation.

4.5.16 Changes to MDD after the final Interim Information Volume Allocation Run (prior to the Initial Volume Allocation Run or any Reconciliation Volume Allocation Runs) must only be made by Data Aggregator users with suitable authorisation and must be reported to the Data Aggregator for audit purposes.

4.5.17 Ad hoc reporting facilities should be available for all data for audit purposes. (This is highly desirable not mandatory).

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

4.5.19 All reports should be available in both human readable and machine readable format. (This is highly desirable not mandatory).

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

4.5.21 All reports in human readable format should be available both electronically and paper based. (This is highly desirable not mandatory).

4.5.22 Operation access rights of Data Aggregator users and groups of Data Aggregator users must be controlled.

4.5.23 Controls must exist to ensure the risk of intentional corruption/errors/fraud is minimised.

This extends to both data and software.

Where changes are made by users, the NHHDA’s system must maintain audit trails so that the change can be tracked and must provide reporting for all on-line input.

Tracking details must include:

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

Logging of the authorisation process will be a manual process outside of the NHHDA’s system.

4.5.24 Attempts to breach access rights must be monitored and reported.

4.5.25 Aggregation runs for Interim Information Volume Allocation Run, Initial Volume Allocation Run and Reconciliation Volume Allocation Run of a Settlement Day must be supported for at least 28 months after the Settlement Day.

4.5.26 Settlement Data retained after the period specified in 4.5.25 will be provided to support an Extra-Settlement Determination as specified in 10.2.1 and 10.2.1 of PSL100.

4.5.27 It must be possible to archive onto a removable magnetic or optical medium all data that is no longer required for Settlement Days after a user-configurable number of days in the past.

4.5.28 It must not be possible to archive data relating to a Settlement Day until a user defined (configurable) period after the Settlement Day.

4.5.29 The NHHDA’s system must not prevent the implementation of a disaster recovery plan.

4.5.30 The software which forms the NHHDA’s system must be robust.

4.5.31 Following a processing interruption, the NHHDA’s system must be capable of correctly resuming processing.

4.5.32 Following a processing interruption, the NHHDA’s system must be capable of performing the processing back log.

4.5.33 There must be controls to ensure that the risk of unintentional errors arising and not being corrected in a timely fashion is minimised.

4.5.34 This includes those controls specifically described in this document and controls needed to address risks specific to the design proposed.

4.5.35 For any aggregation run, the system must be able to provide an audit report of:

the data in place when the run took place;
the exceptions in place when the run took place;
what consumption was used for each metering system;
whether the consumption was:

(i) provided by a Data Collector, and if so which one;

(ii) determined via a static default EAC;

(iii) determined via a dynamic default EAC.

NB. An acceptable way of achieving this is as follows.

Perform the set of aggregation runs scheduled for the day but do not log the audit data.

Perform a full backup of the system and record which aggregation runs have taken place since the last backup.

If the BSC Auditor should then require the audit data for an aggregation run, determine which backup was taken immediately after the aggregation run. Restore this backup and re run to provide the necessary audit data.

4.5.36 Controls must exist to link the EACs and AAs received to the aggregation runs in which they are used.

4.6 Operational Requirements

4.6.1 The NHHDA’s system must be able to process aggregations for up to 21 Interim Information Volume Allocation Runs or Initial Volume Allocation Runs or Reconciliation Volume Allocation Runs per day. (Mandatory).

4.6.2 The NHHDA’s system should be able to process aggregations for up to 28 Interim Information Volume Allocation Runs or Initial Volume Allocation Runs or Reconciliation Volume Allocation Runs per day. (Highly desirable).

4.6.3 The NHHDA’s system should be able to process aggregations for up to 35 Interim Information Volume Allocation Runs or Initial Volume Allocation Runs or Reconciliation Volume Allocation Runs per day. (Desirable).

4.6.4 The NHHDA’s system must be able to interface with up to 100 Data Collectors. (Mandatory).

4.6.5 The NHHDA’s system should be able to interface with up to 2000 Data Collectors. (Highly desirable).

4.6.6 The NHHDA’s system must be able to interface with up to 58 Suppliers. (Mandatory).

4.6.7 The NHHDA’s system should be able to interface with up to 200 Suppliers. (Highly desirable).

4.6.8 The NHHDA’s system must be able to interface with all SMRAs. (Mandatory).

4.6.9 The NHHDA’s system must be able to interface with all SVA Agents. (Mandatory).

4.6.10 The NHHDA’s system must be able to process 10,000 SVA Metering Systems per aggregation run with an average of 1.5 Settlement Registers per SVA Metering System. This scenario caters for small Data Aggregators. (Mandatory).

4.6.11 The NHHDA’s system should be able to process 5,000,000 SVA Metering Systems per aggregation run with an average of 1.5 Settlement Registers per SVA Metering System, for a large Supplier with significant room for Market growth. (Highly desirable).

4.6.12 The NHHDA’s system should be able to process 10,000,000 SVA Metering Systems per aggregation run with an average of 1.5 Settlement Registers per SVA Metering System, for a large Supplier merging with another large Supplier with significant room for Market growth. (Desirable).

4.6.13 The NHHDA’s system must be able to send Supplier Purchase Matrix data to up to 15 SVA Agents. (Mandatory).

4.6.14 The NHHDA’s system must be capable of supporting at least:

16 Profile Classes;

48 Line Loss Factor Classes;

964 Standard Settlement Configurations;

2104 Measurement Requirements;

1640 Valid Settlement Configuration Profile Classes;

4284 Valid Measurement Requirement Profile Classes;

4 Measurement Classes;

15 GSP Groups;

15 SMRAs;

1 SVA Agents;

100 Data Collectors;

58 Suppliers;

15 LDSO.

(Mandatory).

4.6.15 The NHHDA’s system should be capable of supporting at least:

20 Profile Classes;

50 Line Loss Factor Classes;

2500 Standard Settlement Configurations;

4000 Measurement Requirements;

4000 Valid Settlement Configuration Profile Classes;

16000 Valid Measurement Requirement Profile Classes;

4 Measurement Classes;

15 GSP Groups;

15 SMRAs;

1 SVA Agents;

2000 Data Collectors;

200 Suppliers;

15 LDSOs.

(Highly desirable).

4.6.16 The NHHDA’s system must be capable of supporting an average of 1 exception per SVA Metering System on any Settlement Day. It must be designed in such a way that, should this limit be exceeded, all Suppliers receive an equitable level of exception reporting.

An exception must be considered as one of:

no EAC or AA data has been received from the NHHDC for the Settlement Day;

EAC or AA data received from more than one NHHDC for the Settlement Day;

GSP Group, Profile Class, Standard Settlement Configuration, Supplier Registration, Measurement Class or Energisation Status data received from the appointed Data Collector is inconsistent with that recorded on SMRS. (Mandatory).

4.6.17 The NHHDA’s system and its 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 given that the number of SVA Metering Systems could vary greatly between NHHDA aggregation runs performed on the same day for different Supplier Volume Allocation Runs. (Mandatory).

4.6.18 The Non NHHDA’s system must prevent the failure of one aggregation run impacting on the success of any subsequent aggregation runs.

4.6.19 The NHHDA’s system must always be able to accept, process, and deliver the required data to the SVA Agent within timescales specified by the SVAA Calendar. (Mandatory).

4.6.20 The NHHDA’s system must comply with the operational SVAA Calendar. (Mandatory).

4.6.21 The language to be used for all user interfaces in the NHHDA’s system must be English. (Mandatory).

4.7 Instruction Processing – Problem Management Log Information Requirement

Unsuccessful processing of instructions may be because of a problem on the part of the NHHDA or a problem on the part of the provider.

The NHHDA shall use an instruction problem management log in order to manage failed and discarded instructions and individual MSID failures from a Full Refresh. The log must hold the latest information about all instructions that are either:

(i) currently in a failed or discarded state;

(ii) SMRS Full Refresh instructions that are awaiting NHHDA intervention to move them to an applied or discarded state because they contained one or more Metering Systems that were not successfully processed;

(iii) the Metering System level details that could not be successfully processed from a SMRS Full Refresh instruction.

This information shall include:

(i) the SVA Metering System identifier;

(ii) the instruction number;

(iii) the instruction type except for a Full Refresh;

(iv) the instruction source;

(v) the latest processing attempt date / time (except for a Full Refresh From SMRS);

(vi) the reasons for failure / discard encountered in the latest processing attempt;

(vii) for SMRS Full Refresh instruction types the:

number of Metering Systems that were in the instruction;

number of Metering Systems that were in the instruction and were not successfully processed;

number of Metering Systems that were not in the instruction but are associated with the same LDSO as the instruction and were already on the database;

(viii) whether the NHHDA is able to resolve each reason for failure / discard (except for a Full Refresh);

(ix) whether each reason for failure / discard that the NHHDA is able to resolve has been resolved (except for a Full Refresh);

(x) whether the NHHDA wants the instruction to be reprocessed (only required when valid);

(xi) whether the NHHDA wants data in the instruction to be re-sent by the appropriate SMRA / NHHDC (only required for Full Refresh failures and failed instructions);

(xii) whether the SMRA / NHHDC has been asked to resend data in the instruction since the latest processing attempt and if so when the request was issued to them.

1 Once a Supplier is informed the LDSO should receive all relevant EAC reports quarterly on dates set out in the timetable above unless otherwise notified to the Supplier. If the request is received after the cut-off date it shall be processed at the discretion of the Supplier/NHHDA.

2 Both Parties must agree on the medium of communication if it is not to be a CD.

3 Where a bulk change of agent is being initiated, BSCP513 must have been completed prior to triggering this process.

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

5 Validation failures shall be rejected by the NHHDA and reported by it to its NHHDC. All files and instructions that fail validation shall be recorded by the NHHDA in accordance with the requirements of Section 4.4.

6 The NHHDA shall ensure that each aggregation run is based on the most up to date data available to it at the time of aggregation run; and the NHHDA is not obliged to issue reports to Suppliers for the Interim Information Volume Allocation Run.

7 In each aggregation run, where there is no valid EAC/AA, the NHHDA shall use a default EAC

8 Where the NHHDA experiences a problem with an MSID during the data aggregation run, as a result of missing Metering System specific data, this MSID need not be included in the SPM and the SPM must continue to be produced but a Selective Refresh of data must be requested from SMRS for that MSID (process 3.2.3) within 5 working days.

9 The NHHDA shall, where requested by the SVAA in accordance with BSCP508, provide aggregated data (Supplier Purchase Matrix) in such a manner that those files are received by the SVAA in accordance with the timescales specified in BSCP508.

10 This dataflow will contain data for all the Suppliers that the NHHDA is appointed to in the GSP Group.

11 This dataflow will only contain data for the relevant Supplier in the GSP Group. Where the NHHDA is appointed to more than one Supplier in the GSP Group, then each Supplier will receive a dataflow which is unique to itself. Where the NHHDA is appointed to the Supplier in many GSP Groups, the Supplier will receive one dataflow for each GSP Group. If there is no aggregated consumption for the Supplier, then no dataflow will be sent to the Supplier.

12An 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.

13 Whilst the P0238 is sent by the LDSO to 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.

14 In each aggregation run, where there is no valid EAC/AA, the NHHDA shall use a default EAC

15 Where the NHHDA experiences a problem with an MSID during the data aggregation run, as a result of missing Metering System specific data, this MSID need not be included in the DPM and the DPM must continue to be produced but a Selective Refresh of data must be requested from SMRS for that MSID (process 3.2.3) within 5 working days.

16 When sending a D0377, 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 NHHDA should therefore use the DCE ID reported to it in the P0238 by the LDSO when sending a corresponding D0377 to the SVAA.

17 The NHHDA shall investigate the cause of file failures and shall rectify any failures caused by it as soon as reasonably practicable.

18 The NHHDA shall notify the provider of the reason for the failure and shall request that the file be resent with the same file sequence number.

19 If an instruction file validation error is caused by the provider of the file, the NHHDA shall notify the provider of the reason for the failure and shall request the provider to send a revised instruction file containing the all instructions required to rectify the situation.

CONTENTS

BSCP505: Non Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS V24.0

Re-Badged

1. Introduction

1.1 Scope and Purpose of the Procedure

1.2 Main Users of Procedure and their Responsibilities

1.3 Market Domain Data Obligations

1.4 Interface to Supplier Meter Registration Services

1.4.1 SMRS Data

1.4.2 Refresh Supplier Meter Registration Service MSID Data

1.5 Communications

1.6 Exception Management

1.6.1 Problem Log

1.6.2 Identifying Negative Estimates of Annual Consumption

1.7 Use of the Procedure

1.8 Balancing and Settlement Code Provision

1.9 Service Levels

1.10 NHHDA Principles

1.10.1 Functional Requirements Principles:

1.10.2 Non-Functional Requirements:

1.10.3 Operational Requirements

1.11 Associated BSC Procedures

1.12 Party Service Line

1.13 Acronyms and Definitions

1.13.1 Acronyms

1.13.2 Definitions

2. This section is no longer in use

3. Interface and Timetable Information

3.1 Market Data Activities

3.1.1 SVAA sends Market Domain Data

3.1.1.1

3.1.1.2

3.1.1.3

3.1.1.4

3.1.1.5

3.1.1.6

3.1.2 NHHDA Run and Send EAC Data to Distributors Report

3.1.2.1

3.1.2.2

3.1.2.3

3.1.2.4

3.1.2.5

3.2 Interface to SMRS

3.2.1 Appointment Changes3

3.2.2 Changes to SVA Metering System standing Data

3.2.3 Requests for SMRS Information

3.3 Aggregation Activities

3.3.1 Receive AA/EAC Data from NHHDC

3.3.2 Data Aggregation Run6

3.3.3 NHHDA investigates inconsistencies

3.3.4 Data Aggregation for Demand Control Events

3.4 Instruction Processing

4. Appendices

4.1 This page has intentionally been left blank.

4.2 Data Validation

4.2.1 Instruction Files

4.2.2 NHHDA Appointment changes

4.2.3 NHHDC Appointment changes

4.2.4 SVA Metering System standing data changes

4.2.5 SMRS Full Refresh Data

4.2.6 NHHDC consumption data

4.3 Validation of Data Aggregation and Settlements Timetable File

4.4 Functional Requirements

4.4.1 Market Domain Data

4.4.2 Instruction Processing

Each Instruction received from a Data Collector must undergo the business validation as detailed in Section 4.2.1. (Mandatory).

The exception report will be produced on request by the NHHDA’s system, and must be sent to the NHHDA and the Supplier.

The report must also contain details of the total number of SVA Metering Systems, the total number of SVA Metering Systems in each of the above categories and the total number of metering systems in one or more of the above categories.

It must be possible to restrict the report to a selected range of dates, and / or selected SMRA(s). (Mandatory).

4.4.3 Aggregation Runs

the Interim Information Volume Allocation Run, the Initial Volume Allocation Run or the Reconciliation Volume Allocation Run that the appropriate run is for (Mandatory);

the date and time the run should take place (Mandatory);

the applicable GSP Group to be included in the run (Mandatory).

First / Last Payment Date, i.e. those dates for which Settlement activities are included within the Settlement timetable (Mandatory);

Settlement Date and Settlement Code for which an aggregation run is required (Mandatory);

Payment Date i.e. the date on which Moneys are to be transferred (Mandatory);

the SVA Notification Deadline Date, i.e. the latest Calendar Day on which the SVAA is to receive Supplier Purchase Matrix data from the NHHDA for that aggregation run (Mandatory);

the Planned Data Aggregation Run Date, i.e. the advisory date upon which an aggregation run is scheduled to start (Mandatory);

the Planned SVA Run Date, i.e. the date upon which an SVA Run is scheduled to start (Desirable).

If a NHHDC has been appointed but not supplied any data, then previously supplied data must be used, if available.

3.2.1 Appointment Changes³

3.3.2 Data Aggregation Run⁶