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 26.0 relating to Non Half Hourly Data Aggregation.
3. This BSC Procedure is effective from 01 October 2024 .
4. This BSC Procedure has been approved by the Panel.
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 their 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 them by the Supplier via SMRS. In accordance with timescales set by the Settlement Timetable, they are 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 their database of the SVA Metering Systems relevant to their 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
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.
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.
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.
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;
(c) to enter data into the relevant data aggregation system;
(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.
The NHHDA shall perform the services to be performed by it as NHHDA pursuant to this BSCP.
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. |
PSL100 | Generic Non Functional Requirements For Licensed Distribution System Operators And Party Agents |
1.13 Acronyms and Definitions
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 |
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 |
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.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. |
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 |
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: 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. |
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 NHHDCs, NHHDAs, 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: 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.1 This page has intentionally been left blank.
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;
(c) that if one has a start date before the significant date, the rest must have start dates 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;
(c) that they are all for registrations that will exist if the instruction is applied;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they are all for a valid combination of Profile Class and Standard Settlement Configuration;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they are all for valid combinations of Valid Settlement Configuration Profile Class;
(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 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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(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.
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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) for the ‘SVA Metering System’s NHHDC Appointments’ in the instruction:
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;
(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;
(c) that the meter advance periods for the sets of AA details do not overlap;
(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;
(c) that they all overlap or start on or after the significant date;
(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;
(c) that if one has a start date before the significant date, the rest must have start dates 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;
(c) that they are all for a valid combination of Profile Class, Standard Settlement Configuration and GSP Group;
(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;
(c) that if one has a start date before the significant date, the rest must have start dates 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;
(c) that if one has a start date before the significant date, the rest must have start dates 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;
(c) that if one has a start date before the significant date, the rest must have start dates 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.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:
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:
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.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:
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.6.15 The NHHDA’s system should be capable of supporting at least:
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.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:
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:
(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.
AMENDMENT RECORD – BSCP505
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/22 | November 2023 Standard Release | CP1560 | ISG253/05 and SVG255/04 |
25.0 | 29/06/23 | June 2023 Standard Release | CP1580 | P338/04 |
26.0 | 01/10/24 | 01 October 2024 Non-Standard Release | ORD009 | Directed by Secretary of State |
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. |
