Abstract	This document describes the requirements for a system to aggregate consumption for non half hourly Metering Systems and to pass the results to the ISRA system.
Version	16.0
Effective Date	5 November 2015

AMENDMENT RECORD

Date	Version	Details of Change	Mods/ Panel/ Committee Refs
28 August 2007	14.0	Modification P197
6 November 2014	15.0	Document rebadged and amended for November 2014 Release (CP1408)
5 November 2015	16.0	Amended for November 15 Release (P305)	SVG177/03

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

1 INTRODUCTION

1.1 Introduction

1. The franchises for electricity supply held by Public Electricity Suppliers are due to expire on 31 March 1998. As a consequence, all electricity customers will be free to seek competitive supplies from 1 April 1998. The current arrangements for administering settlement payments between Suppliers and Generators - which require metered consumption data for each half-hour - are unsuited to this expanded market.

2. Accordingly, the Electricity Pool of England and Wales (the Pool) has developed proposals for new arrangements for electricity trading and settlement to support the "1998 market". The 1998 Operational Framework (reference 1) has been prepared to document the Pool's proposals and to provide a Programme Brief for the programme of work for introducing the new arrangements. This programme of work is referred to as the Pool's 1998 Programme.

3. The Operational Framework, release 3.1, documented the Pool’s proposals for the arrangements for trading and settlement to be adopted for the 1998 market. The OFFER statement “The Competitive Electricity Market from 1998: Supply Code, Trading Arrangements and Costs January 1996” challenged many of the trading and commercial proposals and went on to propose revisions to the scope of the Pool’s responsibility in the 1998 market.

4. In the light of the January statement the Pool initiated a review of the OFFER proposals and in addition undertook an assessment of other possible areas where simplification might provide benefits. This review was undertaken by a Business Requirements Group of Pool Members reporting to the 1998 Steering Group. The conclusions arising from the work of the Business Requirements Group were incorporated in release 4.2 of the Operational Framework (reference 1).

1.2 Purpose and Scope

1. This document describes the requirements for a system that will aggregate the estimates of annual consumption (EACs and AAs) for non-half hourly meters and pass the aggregated figures through to the ISR Agency Systems to enable Initial Settlement between Suppliers and Generators (within the pre-1998 settlement timescales) and subsequent Reconciliations between Suppliers to be performed. This process comprises the Non Half Hourly Data Aggregation (NHHDA) system, which could be run by individual Non Half Hourly (NHH) Data Aggregators for a number of Suppliers in each GSP Group.

2. The NHHDA system must work within the defined context of the Trading Arrangements (TA) for the 1998 market, and therefore this specification includes details of the interfaces between it and the other systems in the TA. The principles and structure of the TA for the 1998 market are described in detail in the 1998 Operational Framework (reference 1).

3. This specification excludes descriptions of other developments to be carried out as part of the 1998 Programme.

4. The specification is developed in accordance with the 1998 User Requirements Standard (reference 2). SSADM Version 4 has been used, although not all products for Stage 3 have been produced; Stages 1 and 2 have been completed. In addition, Steps 310 and 320 have been completed and parts of 330, 360 and 380 have been carried out. These have been provided to enhance the document and clarify the requirements analysis. A full Stage 3 design should not be inferred from the inclusion of these products.

5. This specification will form the basis of an Enhanced URS, produced by the 1998 Programme.

1.3 Summary of the Document

1. The User Requirements Specification (URS) comprises:

a statement of the high level principles and the objectives of the NHHDA system;
a summary of the constraints and assumptions on which the URS is based;
a description of the scope and functions covered by the URS;
the detailed requirements for the NHHDA system;
supporting information, including the Required Data Flow Model, Logical Data Model, Data Catalogue, Function Descriptions, System Event Descriptions and User Roles.

2. Programme wide terms that have been used have upper case leading letters. These terms are defined in the 1998 Programme Glossary of Terms (reference 9).

1.4 Responsibilities

This URS will:

1. form the basis of a competitive tender by the 1998 Programme for the logical design, physical design and build of the system described, which will be the responsibility of the appointed Contractors. Acceptance testing of these systems and their integration with other 1998 systems will be the responsibility of the 1998 Programme;

2. be issued to NHH Data Aggregators who elect to build their own system and take responsibility for their delivery;

3. be used as the basis for the Qualification of all NHH Data Aggregators, and the Qualification of their systems.

Qualification will include the identification and approval of any differences (e.g. in volumetrics) between the requirements set out in this document, and those of systems developed independently by NHH Data Aggregators.

1.5 Terminology

The terms Metering System and Settlement Register, as used in this document, refer to logical entities which may not correspond directly to physical meters and registers. For example, Metering Systems and Settlement Registers must satisfy the following constraints:

1. a Metering System must be assigned to a single Profile Class. If there is a requirement to assign the registers of a physical meter to two different Profile Classes, then that meter consists of two Metering Systems;

2. Settlement Registers must not ‘double count’ electricity. If two physical registers record the same consumption, then the Data Collector must perform a process of differencing.

These points can be illustrated by a consideration of two different types of metering configuration currently in use to support domestic two-rate tariffs:

1. a standard Economy 7 meter has a low register and a normal register, with a timeswitch to control which one records consumption. The requirement is to assign both registers to the Domestic Economy 7 Profile Class, and therefore the meter is a single Metering System for Settlement purposes;

2. a ‘restricted hours’ meter is attached to a circuit, typically used for heating, which contains a timeswitch or teleswitch to restrict its use to certain hours. An unrestricted circuit, with its own meter, may be used at any time. The requirement is to assign the unrestricted register to the Domestic Unrestricted Profile Class, and the restricted register to the Domestic Economy 7 Profile Class. Therefore each meter is a distinct Metering System for Settlement purposes. A variation on this is where there is a single meter with two registers, one unrestricted and one switched. This will be treated the same way within the system.

2 PRINCIPLES AND OBJECTIVES

2.1 Principles

The requirements of the NHHDA system all arise from a set of basic high level principles. The detailed requirements listed in the Requirements Catalogue (section 5) of this document all relate to and support one or more of these principles. Listed below are the high level principles for the system.

1. The NHHDA system must aggregate Estimated Annual Consumptions (EACs) and Annualised Advances (AAs) to produce aggregated results for each Supplier by Settlement Class;

2. The NHHDA system must treat data provided by PRS Agents as definitive;

3. The NHHDA system must validate the data it receives from NHH Data Collectors and PRS Agents against Market Domain Data;

4. The NHHDA system must check inconsistencies between data received from NHH Data Collectors and data received from PRS Agents and must report such inconsistencies to Suppliers so that they may be operationally resolved;

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

6. The NHHDA system must be a fully 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 after the Settlement Day to which the results relate;

7. The NHHDA system must comply with the 1998 Programme’s Security and Control Framework (reference 7);

8. The design and implementation of the NHHDA system must, given an appropriate hardware and software environment, enable operation to meet the prescribed Settlement Timetable (reference 4);

9. The design and implementation of the NHHDA system must not adversely constrain the operation and performance of the systems to which it interfaces - ISR Agency systems, NHH Data Collection systems, and PRS systems.

2.2 Business Objectives

The major business objectives of the NHHDA system are:

1. to aggregate Estimated Annual Consumptions (EACs) and Annualised Advances (AAs) producing aggregated results for each Supplier and Settlement Class for each Initial Settlement and Reconciliation;

2. to pass the aggregated results for each Initial Settlement and Reconciliation to the relevant ISR Agents in timescales specified in the Settlement Timetable (reference 4);

3. to check that data being used by NHH Data Collectors is consistent with PRS Agent data and report inconsistencies in order that they may be operationally resolved;

4. to provide aggregated data for each Reconciliation for each Settlement Day up to two years after the Settlement Day;

5. to be a fully auditable system with both aggregated results and the data used in their aggregation being available for inspection up to 28 months after the Settlement Day to which the results relate.

2.3 System Objectives

The major system objectives of the NHHDA system are:

1. to support electronic interfaces with NHH Data Collection systems, ISR Agency systems, PRS systems and Suppliers to facilitate the timely and accurate provision or receipt of data;

2. to enable a NHH Data Aggregator, as agent of the Supplier, to run the system:

for some or all of the Metering Systems supplied by one or more Suppliers; and
for one or more GSP Groups;

3. to ensure that the NHH Data Aggregator is able to operate the system to meet the Settlement Timetable (reference 4);

4. to comply with 1998 Programme’s Security and Control Framework (reference 7);

5. to comply with 1998 Technical Architecture Policy (reference 5);

6. not to constrain adversely the operation and performance of ISR Agency systems, PRS systems or NHH Data Collection systems;

7. to maintain any appropriate settlement related standing data required to achieve the system objectives;

8. to provide a robust system which can run independently of the other 1998 systems, subject to the necessary data being made available;

9. to provide audit, security and control measures and maintain and retain sufficient audit information to satisfy all Pool members, the Pool Auditor and all legal requirements.

3 CONSTRAINTS AND ASSUMPTIONS

The baseline for this specification is the 1998 Operational Framework, Release 4.2 (reference 1) which has been approved by Pool Members. Where relevant, specific paragraphs in that document are referenced in the format “(OF nnn)”.

3.1 Business Constraints and Assumptions

1. The Pool will undertake Reconciliations between Suppliers for a Settlement Day, outside existing settlement timescales (OF 484 - 489).

2. The Final Reconciliation will occur no later than 24 months after the Settlement Day (OF 488).

3. The updates of Estimated Annual Consumption (EAC), Annualised Advance (AA) and Metering System reference data will be deemed to take effect at 00:00 hrs (clock time) preceding the collection of a meter reading (OF 445).

4. Suppliers may opt to use multi-register meters. Where this is the case the NHH Data Collectors will provide EACs/AAs for each Settlement Register to the appropriate NHH Data Aggregator in accordance with the Qualification requirements set by the BSC Panel or its Delegated Authority.

5. Non half hourly Metering Systems are not allowed to have Metering System specific line loss factors.

6. For Market inception, the Market Domain Data Agent will publish a GSP Group Profile Class Default EAC for each Profile Class and GSP Group. Changes to these initial values will be provided infrequently (once or twice a year) via the Market Domain Data Agent.

7. A GSP Group consist of one or more distribution systems (each owned and operated by a LDSO) (OF 411).

8. Initial Settlement and Reconciliation requires a number of contributing processes to be co-ordinated in terms of when they are performed and what data they are based upon. In order to achieve this, it is assumed that a Settlement Timetable (reference 4) is published by the Pool detailing each Initial Settlement and Reconciliation for each Settlement Day, the GSP Groups to be settled and the date by which each Initial Settlement and Reconciliation must be successfully completed.

9. Certain interfaces between Pool processes, including that between the NHHDA and ISRA systems, are required to transmit data for each Initial Settlement or Reconciliation. In such cases, an Initial Settlement or Reconciliation identifier is required for communication between processes such that each process knows the purpose of the data it receives. It is assumed that this identifier is the Settlement Date and a Settlement Code.

10. Pool appointment of ISR Agents and the Distributor’s appointments of PRS Agents to GSP Groups is on a calendar date basis rather than a Settlement Day basis. That is to say that appointment is to fulfil the role for calendar dates in the operational schedule irrespective of the Settlement Days being settled or reconciled on these calendar dates.

11. Supplier appointment of NHH Data Collectors to Metering Systems is effective from a specified calendar date. From this calendar date onwards the NHH Data Collector is responsible for all Settlement Days within that Supplier’s Registration to the Metering System (until the Supplier appoints another NHH Data Collector for the same Registration of the Metering System).

12. Supplier appointment of NHH Data Aggregators to Metering Systems is on a Settlement Day basis rather than a calendar date basis. That is to say that appointment is to fulfil the role for all Initial Settlements and Reconciliations of Settlement Days irrespective of the calendar dates when they are settled or reconciled.

13. NHH Data Aggregators must aggregate the Metering Systems that PRS Agents deem them responsible for. This is the case even if the Data Aggregator does not have a contract in place with the Supplier.

14. If a Metering System changes Distribution Business it is assumed it will be allocated a new Metering System Id.

3.2 System Constraints and Assumptions

3.2.1 Scope

1. EACs and AAs for Settlement Registers for individual Metering Systems will be calculated by NHH Data Collectors and will be submitted to NHH Data Aggregators. (OF 472)

2. NHH Data Aggregators sum Settlement Register EAC/AA data for defined groups of Metering Systems, but do not apply Line Loss Factors (this is done by the ISR Agent). The groups of Metering Systems are defined for each Supplier to allow summation of data from Metering Systems for each Settlement Class, i.e. by:

Supplier;
GSP Group;
Profile Class and Timeslot (also referred to as ‘Measurement Requirement’); and
Line Loss Factor Class¹.

(OF 473)

3.2.2 Operational

1. The NHHDA system will be operated by NHH Data Aggregators. NHH Data Aggregators can operate the system for non half hourly Metering Systems in one or more GSP Groups.

2. The NHHDA system will be run in order to prepare Supplier Purchase Matrices that will be used in the ISR Agency systems.

3. NHH Data Aggregators are required to be capable of supporting Initial Settlement and Reconciliation up to 2 years after the Settlement Day.

4. NHH Data Aggregators are required to provide historical trading data for a period of 28 months to satisfy audit requirements (OF 513(e)).

5. Capacity requirement analysis in the ISRA URS (reference 8) is correct.

3.2.3 System Interfaces

1. The interfaces between the NHHDA system and its ‘feeder systems’ (i.e. NHH Data Collection systems and PRS systems) will work on a ‘drip feed’ basis:

the NHHDA system will maintain a copy in its database of relevant information held by the feeder systems;
the feeder systems will inform the NHHDA system of changes to this data by sending files of update Instructions to the NHHDA system on a regular basis. These Instructions will be numbered to ensure that they are processed in the correct sequence;
the NHHDA system will include a mechanism for processing ‘Refresh’ Instructions sent by the PRS feeder systems, in order to detect and correct any inconsistencies which have arisen.

2. The NHHDA system will validate data received from the Data Collector against that received from PRS when the data is used in an aggregation run (for audit purposes only), or upon request, but not when the data is received. The reason for this is that changes to Metering System Registration data may be reflected in data received from the NHH Data Collector prior to the NHHDA system being informed of the change by the PRS system.

3. The interface between the NHHDA system and the ISRA system will not work on a ‘drip feed’ basis. Instead the NHHDA system will provide a complete ‘batch’ of EACs and AAs aggregated to the level of Settlement Class to the ISR Agents for each Initial Settlement or Reconciliation.

4. Only EAC/AA data received from a NHH Data Collector who was, according to the PRS Agent, registered for the Metering System concerned will be aggregated into Supplier Purchase Matrices.

5. The NHHDA system will be able to interface with multiple ISR Agents appointed to different GSP Groups.

6. The NHHDA system will not restrict retrospective changes of Metering System data.

7. The NHHDA system is not required to validate the Licensing and Qualification status of trading parties.

8. EAC/AAs for the full set of Metering System Settlement Registers must be included for each Metering System passed across the interface between NHHDC systems and NHHDA systems.

3.2.4 End-User Interfaces

1. Market Domain standing data (except for Standard Settlement Configurations) and operational standing data may be entered and maintained manually.

2. Market Domain Standard Settlement Configurations and other relatively high volume standing data which is published electronically by the Market Domain Data Agent will be loaded electronically. A manual interface will also be available, for minor changes and as a backup interface.

3.3 Project Constraints and Assumptions

1. The 1998 Programme is assuming that the host PES will have a 2 year exclusive agreement for Meter Operation, Data Collection and Data Aggregation for non half hourly metered customers with Pool Members within its authorised area, starting on 1 April 1998 (OF 444). However, the requirement expressed in this URS is for a system that can be configured to work with one or many Data Collectors and Data Aggregators within each GSP Group. The system will therefore support the requirements both before and after 1 April 2000.

4 BUSINESS DESCRIPTION

4.1 Introduction

This section describes the business process, scope and context of the NHHDA system and contains:

an overview of the NHHDA business process;
an overview of the system required to support the NHHDA business process;
the scope of the required system in terms of the Business Process Model in the 1998 Operational Framework (reference 1);
diagrammatic representation of the context of the required system in terms of its interfaces with trading parties, Pool organisations, 1998 systems and other systems;
the business events which affect the NHHDA system.

4.2 Business Process Overview

The primary role of non half hourly Data Aggregators is to aggregate estimates of annual consumption (EACs and AAs) to the level of Settlement Class for each Supplier and to pass the aggregated results to the relevant ISR Agents. An additional role is to check that Metering System data being used by Data Collectors is consistent with Metering System data registered with the relevant PRS Agents.

PRS Agents send registered Metering System data to the appointed Data Aggregators. Data Collectors send EAC/AAs and the Metering System data they have been using to the Data Aggregators they consider appointed.

Using the registered Metering System data provided by PRS Agents and the EAC/AAs provided by the registered Data Collectors, Data Aggregators perform aggregation for each Initial Settlement and Reconciliation. Once results have been aggregated, Data Aggregators send them to the relevant ISR Agents. The timescales and frequencies with which they do this is driven by the Settlement Timetable (reference 4).

In addition, on a more infrequent basis, Data Aggregators compare the registered data provided by the PRS Agents with the Metering System data provided by Data Collectors. Exceptions found are reported to the Suppliers in order that they can be operationally resolved.

4.3 System Overview

4.3.1 Receipt of Data from PRS Agents and Data Collectors

Changes to registered Metering System data are received from PRS Agents in the form of Instructions. These are the Instructions that must be applied to keep the applicable subset of the Data Aggregator’s database in line with the applicable subset of the PRS Agent’s database. In order to prevent these databases becoming too far out of step, from time to time Refresh Instructions are received from the PRS Agents.

Changes to EAC/AAs are received from Data Collectors in the form of Instructions. These are the Instructions that must be applied to keep the applicable subset of the Data Aggregator’s database in line with the applicable subset of the Data Collector’s database.

Instructions assume that all previous Instructions from the same source and for the same Metering System have been successfully applied. For this reason it is essential that Instructions for each Metering System coming from the same source are applied in strict order.

All Instructions received are validated and, if valid, are applied.

4.3.2 Data Aggregation and Sending Aggregated Results

The Data Aggregator configures an aggregation run for each Initial Settlement and Reconciliation of each Settlement Day. At the specified time an aggregation run is performed and EAC/AAs are aggregated. Exceptions encountered are recorded for audit purposes.

Once the aggregated results have been calculated the Data Aggregator extracts them and sends them to the relevant ISR Agents. The aggregated results for each Supplier are also sent to the relevant Suppliers.

4.3.3 Reporting Exceptions for Data Collectors and Suppliers

The Data Aggregator requests an exception report for combinations of Suppliers and Data Collectors. The reports are produced and are sent to the relevant Suppliers and Data Aggregator.

4.3.4 Maintenance of Market Domain Data

The Data Aggregator enters (or loads) into the system:

the set of Market Domain Data provided by the Pool and published by the Market Domain Data Agent;
the Market Domain Line Loss Factor Classes determined by the Distribution Businesses and published by the Market Domain Data Agent;
the Market Domain GSP Group Profile Class Default EACs determined by the Distribution Businesses and published by the Market Domain Data Agent

The Market Domain Data is used primarily for validating data received from PRS Agents and Data Collectors.

4.4 Scope

The high level processes in the Business Process Model in the Operational Framework (reference 1) maps onto the NHHDA as follows:

BPM Ref	BPM Process Name	Representation in NHHDA URS
7a	Data Processing (Non HH)	External entity - NHH Data Collector
8Aa	Supplier Data Aggregation (Non HH)	External entity - NHH Data Aggregator Process - Non Half Hourly Data Aggregation
8B	GSP Group Aggregation	External entity - ISR Agent
10	PES Registration Service	External entity - PRS Agent

BPM Process 8A Supplier Data Aggregation covers both Half hourly and Non Half hourly Supplier data aggregation. NHHDA covers only the second of these functions.

4.5 NHHDA Context

Below is the context diagram for NHHDA.

4.6 Business Events

NHHDA is affected by the following business events:

1. Change of a Metering System’s Data Aggregator;

2. New Metering System;

3. Change of a Metering System’s Supplier;

4. Change of a Metering System’s Data Collector;

5. Change of a Metering System’s Standard Settlement Configuration;

6. Change of a Metering System’s Profile Class;

7. Change of a Metering System’s Measurement Class;

8. Change of a Metering System’s GSP Group;

9. Change of a Metering System’s Line Loss Factor Class;

10. Change of a Metering System’s Energisation Status;

11. Change of a Metering System’s Settlement Register EAC/AA;

12. Market Domain Data Agent distributes a change to Market Domain data;

13. Initial Settlement or Reconciliation run to take place.

14. Demand Control Event occurs

A brief summary of these business events is given below. The summaries only give business context to the data aggregation process. They do not attempt to detail all activities and exchanges of information associated with the event. The business events are cross referenced to the system events described in section 8.

4.6.1 Change of a Metering System’s Data Aggregator

A Supplier appoints a Data Aggregator to a Metering System. The Supplier informs the Data Collector and the PRS Agent of the change.

The PRS Agent informs the new Data Aggregator of the appointment and of information about the Metering System that the Data Aggregator requires to perform data aggregation. The PRS Agent informs the old Data Aggregator that they are no longer appointed.

This business event may trigger one or more of the following system events:

Data Aggregation appointment end received;
Data Aggregation appointment start received.

4.6.2 New Metering System

A Supplier requires a new Metering System to be set up. The Supplier requests the Distribution Business to allocate a Metering System Id. The Distribution Business allocates a Metering System Id and informs the PRS Agent and the Supplier. The Supplier appoints a Data Collector and Data Aggregator and informs the PRS Agent and the Data Collector of information about the Metering System that they require to perform Registration and data collection respectively.

The PRS Agent informs the Data Aggregator of their appointment and of information about the Metering System that the Data Aggregator requires to perform data aggregation.

This business event may trigger one or more of the following system events:

Data Aggregation appointment start received.

4.6.3 Change of a Metering System’s Supplier

A Customer chooses to change their Supplier. The new Supplier appoints a Data Collector and a Data Aggregator for the Metering System. The new Supplier informs the Data Collector and the PRS Agent of the change.

The PRS Agent informs the Data Aggregator of the appointment and of information about the Metering System that the Data Aggregator requires to perform data aggregation. The PRS Agent informs the old Data Aggregator that they are no longer appointed.

This business event may trigger one or more of the following system events:

Data Aggregation appointment end received;
Data Aggregation appointment start received.

4.6.4 Change of a Metering System’s Data Collector

A Supplier chooses to change the Data Collector for a Metering System. The Supplier informs the old and new Data Collectors and the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the Data Collector appointment change.

This business event may trigger one or more of the following system events:

Change of Data Collector received.

4.6.5 Change of a Metering System’s Standard Settlement Configuration

The Supplier (in consultation with the Customer) decides to change the Standard Settlement Configuration. The Supplier informs the Data Collector and the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the change.

This business event may trigger one or more of the following system events:

Change of Profile Class and/or SSC received.

4.6.6 Change of a Metering System’s Profile Class

A Customer’s electricity usage changes such that the Metering System’s Profile Class is no longer correct in terms of Pool defined Profile Class allocation rules. The Supplier informs the Data Collector and the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the change.

This business event may trigger one or more of the following system events:

Change of Profile Class and/or SSC received.

4.6.7 Change of a Metering System’s Measurement Class

A Metering System’s measuring apparatus is changed such that its unmetered/metered status or its non half hourly/half hourly status changes. The Supplier informs the Data Collector and the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the change.

This business event may trigger one or more of the following system events:

Data Aggregation appointment end received;
Data Aggregation appointment start received;
Changes to Measurement Class received.

4.6.8 Change of a Metering System’s GSP Group

Following Pool Member approval, a Distribution Business’s network configuration changes such that a Metering System is located in a different GSP Group². The Distribution Business informs the Supplier and the PRS Agent of the change. The Supplier informs the Data Collector of the change. The PRS Agent informs the Data Aggregator of the change.

This business event may trigger one or more of the following system events:

Changes to GSP Group assignment received.

4.6.9 Change of a Metering System’s Line Loss Factor Class

The Distribution Business changes the Line Loss Factor Class of a Metering System. The Distribution Business informs the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the change.

This business event may trigger one or more of the following system events:

Change of LLF Class received.

4.6.10 Change of a Metering System’s Energisation Status

For safety reasons or at the Supplier’s request, the Distribution Business change the Energisation status of a Metering System. The Distribution Business informs the PRS Agent of the change. The PRS Agent informs the Data Aggregator of the change.

Energisation status will be initially set by the Distribution Business. Ongoing status will be set by the Supplier.

This business event may trigger one or more of the following system events:

Change of Energisation Status received.

4.6.11 Change of a Metering System’s Settlement Register EAC/AA

A Data Collector:

calculates an AA and revised EAC following collection of an actual or Deemed Meter Reading;
records an initial EAC following creation of a new Metering System or change of an existing Metering System’s Standard Settlement Configuration;
records a revised EAC for a profiled unmetered supply following issue of a certificate by the Distribution Business.

The Data Collector informs the Data Aggregator of the change and of the Metering System’s Standard Settlement Configuration(s), Supplier(s), Profile Class(es), GSP Group(s) and Measurement Class(es).

This business event may trigger one or more of the following system events:

Metering System EAC & AA data received.

4.6.12 Market Domain Data Agent distributes a Change to Market Domain Data

Market Domain Data Agent distributes a change to Market Domain Data:

Suppliers;
Distributors
Data Collectors;
ISR Agents;
Line Loss Factor Classes;
PRS Agents;
GSP Groups (and their timed relationships with ISR Agents, PRS Agents and Distributors);
GSP Group Profile Class Default EACs;
Profile Classes;
Standard Settlement Configurations;
Threshold Parameter;
Standard Settlement Configuration Measurement Requirements (and their valid combinations with Profile Classes);
Settlement Timetable.

This business event may trigger one or more of the following system events:

Average Fractions of Yearly Consumption deleted;
Average Fractions of Yearly Consumption entered;
Average Fractions of Yearly Consumption updated;
Data Aggregation run cancelled;
Data Aggregation run amended;
Data Aggregation run scheduled;
Data Collector details deleted;
Data Collector details entered;
Data Collector details updated;
Distributor assignment to a GSP Group;
Distributor assignment deleted;
Distributor details deleted;
Distributor details entered;
Distributor details updated;
GSP Group Amended;
GSP Group Deleted;
GSP Group Entered;
ISR Agent appointed to GSP Group;
ISR Agent appointment deleted;
ISR Agent details deleted;
ISR Agent details entered;
ISR Agent details updated;
Line Loss Factor Class details deleted;
Line Loss Factor Class details entered;
Line Loss Factor Class details updated;
Market domain data received;
Profile Class details deleted;
Profile Class details entered;
Profile Class details updated;
PRS Agent appointed;
PRS Agent appointment deleted;
PRS Agent details deleted;
PRS Agent details entered;
PRS Agent details updated;
Standard Sett Config assigned to Profile Class;
Standard Settlement Configuration deleted;
Standard Settlement Configuration entered;
Standard Settlement Configuration updated;
Standard Sett Config deassigned From Profile Class;
Supplier details deleted;
Supplier details entered;
Supplier details updated;
Threshold Parameter deleted;
Threshold Parameter entered;
Threshold Parameter updated;
Time Pattern assigned to Standard Sett Config;
Time Pattern deassigned From Standard Sett Config.

4.6.13 Initial Settlement or Reconciliation run to take Place

The window within which Data Aggregators must perform an aggregation run in order to adhere to the Settlement Timetable (reference 4) is reached.

This business event may trigger one or more of the following system events:

Data Aggregation run cancelled;
Data Aggregation run amended;
Data Aggregation run scheduled;
Scheduled Data Aggregation run initiated.

4.6.14 Demand Control Event occurs

A Distributor may identify that a Demand Control Event has occurred, affecting the consumption of a number of Metering Systems for a given range of Settlement Periods. In this case, Data Aggregators must load details of the affected MSIDs received from the Distributor, and as part of a timetabled aggregation run, generate a Disconnection Purchase Matrix file, alongside the usual Supplier Purchase Matrix file, for submission to the ISR Agent.

5 REQUIREMENTS CATALOGUE

5.1 Introduction

The Requirements Catalogue is divided into four sections:

Functional Requirements;
Non-Functional Requirements;
Operational Requirements;
Design Constraint Requirements.

The principles that requirements in each of these sections support are stated at the start of the sections.

The scope of the Requirements Catalogue does not include Service Requirements, such as user support, training, documentation, and maintenance.

5.2 Key to the Requirements Catalogue

The status of each requirement is coded as M (mandatory), H (highly desirable), or D (desirable).

The penultimate column indicates the source of the requirement. This has been left blank when the requirement has been derived by the ISR Team.

The last column indicates where the requirement has been addressed. This has been left blank when the requirement has not yet been addressed.

5.3 Functional Requirements

The Functional Requirements are in support of principles 1-5:

1. The NHHDA system must aggregate Estimated Annual Consumptions (EACs) and Annualised Advances (AAs) to produce aggregated results for each Supplier by Settlement Class;

2. The NHHDA system must treat data provided by PRS Agents as definitive;

3. The NHHDA system must validate the data it receives from NHH Data Collectors and PRS Agents against Market Domain Data;

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

Requirement number	Status	Description	Source of requirement	Resolution and cross reference
	M	The Data Aggregator must be able to enter manually into the system the following Market Domain Data: Suppliers; non half hourly Data Collectors; ISR Agents; PRS Agents; Distributors (and their relationships with their PRS Agent); GSP Groups (and their timed relationships with ISR Agents and Distributors); Profile Classes; Standard Settlement Configurations, their Measurement Requirements, valid combinations with Profile Classes and Average Fraction of Yearly Consumptions; Threshold Parameter. The system will store this data, including all the data defined in the following entities in the LDM (section 7): Supplier, Data Collector, ISR Agent, PRS Agent, GSP Group, ISR Agent Appointment, PRS Agent Appointment, Distributor, GSP Group Distributor, Profile Class, Standard Settlement Configuration, Measurement Requirement, Valid Settlement Configuration Profile Class, Valid Measurement Requirement Profile Class, Average Fraction of Yearly Consumption and Threshold Parameter.	Security and Control Team Change Request 065, 113, 156, R1298	EPDs 4.1 4.2 4.3 4.4 4.5.2 4.5.3 4.5.4 4.6 4.7 4.9 4.10 LDM
	M	The Data Aggregator must be able to load electronically into the system the following Market Domain Data: Standard Settlement Configurations, their Measurement Requirements, valid combinations with Profile Classes and Average Fraction of Yearly Consumptions. Threshold Parameters Line Loss Factor Classes (excluding site specific import and site specific export) Measurement Requirements Profile Class details Time Pattern Regimes Market Participants Market Participant Roles PRS Agent Appointments ISR Agent Appointments GSP Group Distributors	Security and Control Team Change Request156, R1285, R1298	EPD 4.11.1
	M	The Data Aggregator must be able to enter manually into the system the following Market Domain Data: Line Loss Factor Classes originating from Distribution Businesses, maintained and distributed by the Market Domain Data Agent. The system will store this data, including all the data defined in the following entity in the LDM (section 7): Line Loss Factor Class.	Security and Control Team Change Request 156	EPD 4.8 LDM
	M	The Data Aggregator must be able to enter manually into the system the following Market Domain Data: GSP Group Profile Class Default EACs and the date from which they’re effective originating from Distribution Businesses, maintained and distributed by the Market Domain Data Agent. The system will store this data, including all the data defined in the following entity in the LDM (section 7): GSP Group Profile Class Default EAC.	Supply Development Group Change Request 156 Change Request 487	EPD 4.1 LDM
	M	The system must have an interface to receive files containing numbered data maintenance Instructions from PRS Agents and Data Collectors (EAC/AA from the Data Collector must be provided in kWhs). The system must support the processing of these files and Instructions as specified in Data Interfaces (reference 6).	OF Appendix A OF 474 Supply Development Group Change Request 113 Change Request 494	EPD 1 EPD 2.1
	M	The system must store the data contained in valid Instructions in the following entities in the LDM (section 7): Metering System, Settlement Configuration in Registration, Profile Class in Registration, Metering System Line Loss Factor Class, Metering System GSP Group, Energisation Status in Registration, Measurement Class in Registration, Registration, Data Collector Appointment, Data Aggregator Appointment, Metering System Measurement Class (DC), Registration (DC), Metering System GSP Group (DC), Metering System Energisation Status (DC), Metering System Profile Class (DC), Settlement Configuration (DC), Settlement Register (DC), Estimated Annual Consumption (DC) and Meter Advance Consumption (DC).	Systems Architecture Team Security and Control Team Change Request 013, 047, 060, 113	EPD 1 EPD 2.1-2.9 LDM
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
	M	The Data Aggregator must be able to browse and report Instructions, and their reason for being in the state they are in.	Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
	M	The Data Aggregator must be able to manage and rectify Instruction and File processing problems. The system must support this as specified in Data Interfaces (reference 6).	Systems Architecture Team Security and Control Team Change Request 113 Change Request 494
	M	The Data Aggregator must be able to advise the NHHDC source of Instructions that have failed and the reasons for failure. The Data Aggregator must be able to advise the Instruction’s Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) that have failed and the reason for failure. Normally this will be the same as the Instruction’s source PRS Agent. The system must support this as specified in Data Interfaces (reference 6).	Systems Architecture Team Security and Control Team Change Request 113 Change Request 494, R1218, R1298
		Requirement removed	Security and Control Team Change Request 113
		Requirement removed	Security and Control Team Change Request 113
	M	The Data Aggregator must be notified if an unrecognised PRS Instruction type is received from a PRS Agent.	Systems Architecture Team PRS Team Security and Control Team Change Request 113	EPD 2.1
	M	Each Instruction received from a PRS Agent must be validated against Market Domain Data as described in EPD 2.2 - 2.9 and Data Interfaces (reference 6).	Security and Control Team Change Requests 113, 156 Change Request 494 Change Request R1298	EPD 2.2-2.9
	M	Each Instruction received from a PRS Agent must undergo the business validation described in EPD 2.2 - 2.9 and Data Interfaces (reference 6).	Security and Control Team Change Request 113, 494, R1231	EPD 2.2-2.9 Section 9
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
		Requirement removed	Systems Architecture Team Security and Control Team Change Request 113
	M	Inconsistencies found between existing data and data contained in each “PRS Refresh” Instruction must be reported to the Data Aggregator.	Security and Control Team Change Request 113, R1218	EPD 2.9
	M	The Data Aggregator must be notified if an unrecognised Data Collector Instruction type is received from a Data Collector.	Systems Architecture Team NHH Data Collection Team Security and Control Team Change Request 113	EPD 1
	M	Each Instruction received from a Data Collector must be validated against Market Domain Data as described in EPD 1 and Data Interfaces (reference 6).	Security and Control Team Change Requests 113, 156 Change Request 494, R1298	EPD 1
	M	Each Instruction received from a Data Collector must undergo the business validation described in EPD 1 and Data Interfaces (reference 6).	Security and Control Team Change Request 113 Change Request 494	EPD 1
	M	The system must be capable of reporting upon the consistency of data received from a Data Collector with that received from PRS Agents and other Data Collectors. The report will be requested by the Data Aggregator, and must be sent to the Data Aggregator and the Supplier. The exceptions that must be reported are those identified in EPD 6. The report must also contain the total number of Metering Systems in each of the categories defined in EPD 6 and the total number of Metering Systems in one or more of those categories. It must be possible to restrict the report to a selected range of dates, and/or selected PRS Agent(s).	Supply Development Group Security and Control Team Change Request 380, R1279 CP1001, CP1016	EPD 6
	M	In the event of an inconsistency in the data provided by the PRS Agent and that provided by the registered Data Collector, the data provided by the PRS Agent must be treated as definitive.	Supply Development Group Security and Control Team	EPD 3.2
	M	The Data Aggregator must be able to request aggregation runs. For each run they must be able to specify the Initial Settlement or Reconciliation the run is for, the GSP Groups to be included (based on the Settlement Timetable - reference 4) and the date and time the run should take place. The system will store the runs requested, including all the data defined in the following entities in the LDM (section 7): Data Aggregation Run and GSP Group in Aggregation Run.	OF 473	EPD 3.1 LDM
	D	It should be possible to electronically load the Settlement Timetable (reference 4). Each Settlement Timetable Detail record in the file will contain the following data items: Payment Date, i.e. the date on which monies are to be transferred; Settlement Date and Settlement Code for which an Aggregation Run is required; the ISR Notification Deadline, i.e. the latest Calendar Day on which ISRA is to receive SPM data from NHHDA for that Aggregation Run; The Planned Data Aggregation Run Date, i.e. the proposed date upon which all Data Aggregators are advised to aggregate for the specified Settlement Date and Settlement Code. The Data Aggregators may chose to ignore the proposed date.	Expert User Change Request 156, 239 Change Request R1245	EPD 4.11.2
	D	Loading the settlement timetable should automatically schedule the aggregation runs required to support it. Each aggregation run should be scheduled to take place a configurable number of working days before the aggregated results are required to be sent to the ISR Agent. The NHH Data Aggregator should be able to browse and update these scheduled runs. They should also be able to provisionally approve them and then subsequently confirm their approval. The runs should not take place unless they are approved (which is assumed to have happened for data loaded and validated automatically). Provisionally approved runs should not take place without confirmed approval.	Expert User Change Request 238 Change Request R1245	EPD 4.11.2
	D	Aggregated results should be automatically sent to the ISR Agents.	Expert User
	M	An aggregation run must sum to Settlement Class level all totals and counts described in EPD 3.2 in accordance with the aggregation rules specified within the same EPD. If a Data Collector has been appointed but not supplied any data yet, 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 Data Aggregator is appointed for the settlement day must be included in the aggregation run. Note that AAs will not be used for Metering Systems which PRS deems to be unmetered, even if an AA is submitted by the appointed Data Collector.	OF 473 Supply Development Group Change Request 065, 130, 236, R1274	EPD 3.2
	M	If, during an aggregation, there is no valid EAC/AA for a Metering System’s Settlement Register that is required to be included in the aggregation, a default EAC must be used. This default EAC must be the average for 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 Metering System Settlement Registers to base an average on is less than the Threshold Parameter, then the default EAC for the Metering System’s GSP Group and Profile Class multiplied by the average yearly consumption for the Settlement Register’s Measurement Requirement must be used.	Supply Development Group CR487	EPD 3.2
	M	The system must transmit aggregated results for each GSP Group prepared during the aggregation run of an Initial Settlement or Reconciliation to the ISR Agents appointed to the GSP Groups. Aggregated consumption must be provided to ISR Agents in MWh.	OF 475	EPD 5
	M	Metering System identifiers must be associated with a Distribution Business such that it appears to the system that Metering Systems can never change Distribution Businesses.	Change Request 113	LDM
	M	The appointment of PRS Agents must be to a Distribution Business and not to a GSP Group. All Metering Systems for the GSP Groups within a Distribution Business must be appointed to one and only one PRS Agent.	Change Request 113	LDM
	M	The subject of a refresh of data from a PRS Agent must be a Distribution Business.	Change Request 113	EPD 2.9
	M	Instruction file sequence numbers must be unique and sequential between source and target. Instruction sequence numbers must be unique and sequential between source and target. An organisation acting in one market role (e.g. as a Data Collector) is considered a different source to the same organisation acting in a different role (e.g. as a Data Aggregator)	Change Request 113
	M	The system must transmit the results for a Supplier for each GSP Group prepared during the aggregation run to each Supplier. The information sent to each Supplier will be restricted to the data for that Supplier only. Aggregated consumption must be provided to Suppliers in MWh.	Change Request R1208	EPD 5
	M	The system must be capable of validating MDD files prior to loading. This must operate in either of two modes: validate only, or validate and commit.	Change Request R1285	EPD 4.11.1
	M	During automatic load of MDD files it will be possible to restrict GSP Group related data in the file to those GSP Groups that are known to the NHHDA database. Note that the Data Aggregator must have procedures to resolve the situation where not loading MDD for a GSP Group would cause the rejection of an instruction from PRS.	Change Request R1285	EPD 4.11.1
	M	No deletions will be performed as part of the automatic load of MDD files.	Change Request R1285
	M	The system must be able to send Supplier Purchase Matrix data for a particular GSP Group to the ISR Agent or IAR Agent (the IAR Agent is the equivalent of ISR Agent, but for Scotland). The appropriate agent will be determined using a system date parameter corresponding to the first BETTA Settlement Date. Supplier Purchase Matrix Data for Settlement Dates prior to the first BETTA Settlement Date will be sent to the IAR Agent for Scotland or the ISR Agent for England and Wales. Supplier Purchase Matrix Data for Settlement Dates on or after the first BETTA Settlement Date will be sent to the ISR Agent operating for Great Britain. BETTA stands for the British Electricity Trading and Transmission Arrangements. It is the extension of the England and Wales Trading Arrangements into Scotland.	BETTA
	M	The system must be able to send Disconnection Purchase Matrix data for a particular GSP Group to the ISR Agent where a Demand Control Event has occurred.	P305

5.4 Non- Functional Requirements

The Non-Functional Requirements for NHHDA are those concerned with Audit, Security and Control. Operational requirements and Design Constraints are covered in separate sections. They support principles 6-7:

7. The NHHDA system must comply with the 1998 Programme’s Security and Control Framework (reference 7).

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
	M	The following data must be recorded about all files received by the 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.	Security and Control Team
	M	The following data must be recorded about all files sent by the 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.	Security and Control Team
	M	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 Data Interfaces (reference 6).	Security and Control Team Systems Architecture Team
	M	Controls must be in place to prevent unauthorised sources providing data and to prevent authorised sources masquerading as a different authorised source.	Security and Control Team Pool Auditor
	H	Compliance with BS7799 (Code of Practice for Information Security Management) should be achieved.	Security and Control Team
	M	NHHDA infrastructure must enable secure, complete, uncorrupted and timely transfer of external data.	Security and Control Team
	M	Where changes are made by Instructions, the system must maintain an audit trail so that the change can be tracked.	Security and Control Team
	M	Instructions received from PRS Agents and Data Collectors must be kept for audit purposes for at least 28 months after their receipt.	Security and Control Team
	M	Controls must be included in the files containing aggregated results which are passed to ISR Agents so that the ISR Agent is able to determine the number of Metering System Settlement Registers contributing to each aggregated element.	Security and Control Team	EPD 3.2
	M	Controls must be included in the files containing aggregated results which are passed to ISR Agents so that the ISR Agent is able to determine the number of 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).	Security and Control Team	EPD 3.2
	M	Aggregation runs must be based on the most up to date data at the time of aggregation.	Security and Control Team	EPD 1 EPD 2.1-2.9 EPD 3.2
	M	When performing an aggregation run, the 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 PRS.	Security and Control Team Supply Development Group	EPD 3.2
	M	It must be possible to electronically browse, query and report data calculated in or used in an aggregation run for a Settlement Day at least 28 months after the Settlement Day. (The implementation of this may include restoration of archived data).	Security and Control Team
	M	It must be possible to electronically browse, query and report data exceptions encountered in an aggregation run for a Settlement Day at least 28 months after the Settlement Day. (The implementation of this may include restoration of archived data).	Security and Control Team
	M	The Market Domain Data will be finalised prior to the final Initial Settlement (prior to any Reconciliations). Under normal circumstances this data must not be updated after the final Initial Settlement.	Supply Development Group Change Request 156
	M	Changes to Market Domain Data after the final Initial Settlement (prior to any Reconciliations) must only be made by Data Aggregator users with suitable authorisation and must be reported to the Data Aggregator for audit purposes.	Supply Development Group Pool Auditor Change Request 156
	H	Ad hoc reporting facilities should be available for all data for audit purposes.	Security and Control Team
	M	All reports produced must clearly identify what information is being reported, the date and time it was produced and who requested it.	Security and Control Team
	H	All reports should be available in both human readable and machine readable format.	Security and Control Team
	M	All reports in machine readable format must be available electronically.	Security and Control Team
	H	All reports in human readable format should be available both electronically and paper based.	Security and Control Team
	M	Operation access rights of Data Aggregator users and groups of Data Aggregator users must be controlled.	Security and Control Team Pool Auditor	EPD 3.1 EPD 4.1-4.11 EPD 5 EPD 6 EPD 7
	M	Controls must exist to ensure the risk of intentional corruption/errors/fraud is minimised. This extends to both data and software.	Security and Control Team
	M	Where changes are made by users, the 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 system.	Security and Control Team Change Request 237
	M	Attempts to breach access rights must be monitored and reported.	Security and Control Team Pool Auditor
	M	Aggregations for Initial Settlement and Reconciliation of a Settlement Day must be supported for at least 28 months after the Settlement Day.	Security and Control Team
	D	Aggregations for a Settlement Day should be supported after final Reconciliation and at least 28 months after the Settlement Day. (The implementation of this may include restoration of archived data).	Security and Control Team
	M	It must be possible to archive onto a removable magnetic or optical medium all data that is no longer required for Settlement Dates after a user-configurable number of days in the past.	Security and Control Team Change Request 314
	M	It must be possible to restore archived data for electronic browsing, querying and reporting. Note that data does not have to be restored into the same system that it was archived from.	Security and Control Team
	M	It must not be possible to archive data relating to a Settlement Day until a user defined (configurable) period after the Settlement Day.	Security and Control Team
	M	The system must not prevent the implementation of a disaster recovery plan.	Security and Control Team
	M	The software which forms the system must be robust.	Security and Control Team
	M	Following a processing interruption, the system must be capable of correctly resuming processing.	Security and Control Team
	M	Following a processing interruption, the system must be capable of performing the processing back log.	Security and Control Team
	M	There must be controls to ensure that the risk of unintentional errors arising and not being corrected in a timely fashion is minimised. This includes those controls specifically described in this document and controls needed to address risks specific to the design proposed.	Security and Control Team
	M	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 provided by a Data Collector, and if so which one; determined via a static default EAC; 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. Should the Pool Auditor 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.	Pool Auditor Change Request 115
	M	The content of reports will be arranged in a predictable and practical order. That is, for given data the output will always appear the same and will be arranged in a logical manner that makes it easy for a human to read.	Change Request R1179	Physical Design
N38	M	The system must track the identity of any user manually creating, modifying or deleting any other user via the user interface.	CP933	Logical and Physical Design

5.5 Operational Requirements

The Operational Requirements support the principle 8:

8. The design and implementation of the NHHDA system must, given an appropriate hardware and software environment, enable operation to meet the prescribed Settlement Timetable (reference 4).

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
	M	The system must be able to process aggregations for up to 18 Initial Settlements/Reconciliations per day.
	H	The system should be able to process aggregations for up to 24 Initial Settlements/Reconciliations per day.
	D	The system should be able to process aggregations for up to 30 Initial Settlements/Reconciliations per day.
	M	The system must be able to interface with up to 100 Data Collectors, when run in the proposed hardware and software environment.
	H	The system should be able to interface with up to 2000 Data Collectors, when run in the proposed hardware and software environment.
	M	The system must be able to interface with up to 58 Suppliers, when run in the proposed hardware and software environment.
	H	The system should be able to interface with up to 200 Suppliers, when run in the proposed hardware and software environment.
	M	The system must be able to interface with all PRS Agents, when run in the proposed hardware and software environment.
	M	The system must be able to interface with all ISR Agents, when run in the proposed hardware and software environment.
	M	The system must be able to process 10,000 Metering Systems per Aggregation Run with an average of 1.5 Settlement Registers per Metering System, when run in the proposed hardware and software environment. This scenario caters for small Data Aggregators.
	H	The system should be able to process 5,000,000 Metering Systems per Aggregation Run with an average of 1.5 Settlement Registers per Metering System, when run in the proposed hardware and software environment. This scenario caters for a large GSP Group with significant room for Market growth.
	D	The system should be able to process 10,000,000 Metering Systems per Aggregation Run with an average of 1.5 Settlement Registers per Metering System, when run in the proposed hardware and software environment. This scenario caters for a large GSP Group merging with another large GSP Group with significant room for Market growth.
	M	The system must be able to send Supplier Purchase Matrix data to up to 15 ISR Agents, when run in the proposed hardware and software environment.
	M	The 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; 30 PRS Agents; 15 ISR Agents; 100 Data Collectors; 58 Suppliers; 30 Distributors.
	H	The 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; 40 PRS Agents; 15 ISR Agents; 2000 Data Collectors; 200 Suppliers; 40 Distributors.
	M	The system must be capable of supporting an average of 1 exception per 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 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 PRS, and EACs or AAs have been received from the Data Collector within the exception period.	CP965
	M	The system and its proposed hardware and software environment must not have any constraints on the variability of the volumes of data and events that it must handle for different aggregation runs. This is because the number of Metering Systems could vary greatly between NHHDA aggregation runs performed on the same day for different Initial Settlement and Reconciliations.
	M	The system must always be able to accept, process, and deliver the required data to ISR Agents to allow the Pool to clear within timescales specified by the Settlement Timetable (reference 4).	OF 432 OF 482
	M	The system must comply with the operational Settlement Timetable (reference 4).	OF 432 OF 482
	M	The language to be used for all user interfaces in the system must be English.
	M	There must be a facility to inform users of the status of any (relevant) running or scheduled tasks within a definable period.	CR1189	Physical Design
	M	There must be a facility to enable a user to browse the any log files produced.	CR1189	Physical Design
	M	If the system encounters an error during aggregation due to missing Metering System data such that the aggregation for any metering system fails then the error should be reported and aggregation for the remaining metering systems should continue.	CR1324	Physical Design
	M	The failure of one data aggregation run should not adversely impact subsequent data aggregation runs.	CR1324	Physical Design

5.6 Design Constraints

5.6.1 Design Constraint Requirements

The Design Constraint Requirements support principle 9:

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
	H	The system, its software, its proposed hardware, and its interfaces, should be compatible with the 1998 Technical Architecture Policy (reference 5).	Systems Architecture Team
	M	The system’s interfaces must adhere to the 1998 Data Interfaces (reference 6).	Systems Architecture Team

Requirement number

Status

Description

Source of requirement

Resolution / Cross reference

The system, its software, its proposed hardware, and its interfaces, should be compatible with the 1998 Technical Architecture Policy (reference 5).

Systems Architecture Team

The system’s interfaces must adhere to the 1998 Data Interfaces (reference 6).

Systems Architecture Team

6 DATA FLOW MODEL

6.1 Purpose and Scope

1. Data Flow Modelling is an SSADM technique used to build a logical model of information flows and to describe processing. This analysis serves to identify and clearly define:

the system environment, in terms of the scope and system boundary;
External Entities that input data to the system and accept output from it;
data flows carrying those inputs and outputs across the system boundary;
data flows within the boundary;
data stores;
the processes that transform data and cause it to flow and be stored.

2. The Data Flow Model comprises a hierarchical set of Data Flow Diagrams (DFDs) and supporting descriptive products:

Elementary Processes Descriptions - that is a description of the processes which appear on the lowest level diagrams;
Input/Output Descriptions - that is a description of the data flows which cross the system boundary going to or from external entities;
External Entity Descriptions - that is a description of the entities which are external to the system and interface with it;
Logical Data Store/Entity Cross Reference - that is a cross reference between the datastores on the DFDs and the entities they represent in the Logical Data Model.

3. Also included in this Data Flow Model is a cross reference between the top level DFD and the Trading and Settlement Processes in Appendix A of the Operational Framework (reference 1).

4. Not included in the model is any indication of how the flows and processing should be implemented - the model is logical and shows, for example, what data is required from an External Entity not how it is obtained. In particular, the following requirements apply to all data received from Data Collectors and PRS Agents, but are not included in the Elementary Process Descriptions:

The data will consist of Instructions. Each Instruction will be of one of a number of pre-defined types, will be identified by a sequential Instruction Number, and will include a checksum value. The system will check the Instruction Number and checksum, and will not process Instructions if they are out of sequence or if the checksum is incorrect.
Instructions which cannot be processed will be stored for subsequent attempts at reprocessing. No further Instructions from that source for that Metering System will be processed until the Instruction has been successfully reprocessed, or explicitly marked as not requiring processing, or (in the case of PRS) the data has been refreshed.

The requirements relating to Instructions are fully described in requirements F5 - F27 & F39 - F40 of the Requirement Catalogue (section 5).

1. Also not included in the Data Flow Diagrams are flows of data for control and audit purposes, such as exception reports (except in the case of process 6, where the primary purpose of the process is to produce an exception report). However, these flows are included in the Elementary Process Descriptions, and in the Requirements Catalogue (section 5).

2. A brief explanation of Data Flow Diagram notation is included in Appendix C. Further information about the SSADM Data Flow Modelling technique may be obtained in the SSADM V4 manuals (reference 3).

6.2 Data Flow Diagrams

6.2.1 Level 1 - Non Half Hourly Data Aggregation

6.2.2 Process 2 - Receive Registration Updates

6.2.3 Process 3 - Aggregate Annualised Consumption Data

6.2.4 Process 4 - Maintain Market Domain Data

6.2.5 Process 4.5 - Maintain Standard Settlement Configuration

6.2.6 Process 4.11 – Process Market Domain Data Files

6.3 Elementary Process Descriptions

6.3.1 Process 1 - Receive EAC/AA Data

Brief Description

This process receives, validates and stores Estimated Annual Consumptions (EACs) in kWhs and Annualised Advances (AAs) for each Metering System sent from a Non-Half Hourly Data Collector.

Detail Processing Description

Receipt of a file from the Data Collector

The process receives a file containing a set of instructions from a Non-Half Hourly Data Collector. The full file handling process is described in detail in Data Interfaces (reference 6).

The file will be validated to ensure:

physical integrity;
that it is for the Data Aggregator;
that it is from a valid Non-Half Hourly Data Collector;
that the file only contains instructions which are valid for the source (e.g. a Data Collector can only send a “EAC/AA and MS Details” Instruction);
that the file sequence number is the next instruction file sequence number from the source. If this sequence number is higher than the next sequence number, the file is not processed and is left in the ‘Receipt’ area;
that the instructions in the file are in instruction sequence number order and the first sequence number in the file follows on from the last instruction received from the source of the file;

If the file is valid, the instructions are written to the instruction data store D2/1 with a status of ‘Unprocessed’, otherwise the file is marked as ‘Erroneous’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Data Content

Each instruction should include the details for a Metering System and its associated details as described below:

the significant date for the instruction;
the Data Collector’s view of ‘sets of AA details for the Metering System’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of ‘sets of EAC details for the Metering System’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of ‘Metering System’s Registrations’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of the ‘Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of the ‘Metering System’s relationships with Measurement Classes’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of the ‘Metering System’s Energisation Statuses’ which overlap or start on or after the significant date and are relevant to the Data Aggregator;
the Data Collector’s view of the ‘Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and are relevant to the Data Aggregator.

Validation

The instruction is validated to ensure that:

applying the instruction will not result in the Metering System being without (in the NHH Data Collector’s view) a Registration, Profile Classes, Standard Settlement Configuration, Measurement Class, Energisation Status or GSP Group at any time during any of the NHH Data Collector’s view of its Meter Advance Consumptions or Estimated Annual Advances;
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;
that none of the following change during a Meter Advance Period:

Standard Settlement Configuration;
Energisation Status;
Registration;
Measurement Class.

for the sets of AA details for the Metering System:

that the Effective From Settlement Date is less than or equal to the Effective To Settlement Date;
that the set of AAs are for the set of Time Pattern Regimes associated with this Data Collector’s view of the Metering System’s Standard Settlement Configuration;
that the meter advance periods for the sets of AA details do not overlap;
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 of the set of AAs have more integer digits than a consumption threshold value, configurable through NHHDA software;

for the sets of EAC details for the Metering System:

that the set of EACs are for the set of Time Pattern Regimes associated with this Data Collector’s view of the Metering System’s Standard Settlement Configuration;
that the start dates for the sets of EAC details are unique;
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 of the set of EACs have more integer digits than a consumption threshold value, configurable through NHHDA software;

for the Data Collector’s view of ‘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 the Metering System will not be left without a Registration for any Settlement Day within the Data Collector’s view of the Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

for the Data Collector’s view of ‘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 & Standard Settlement Configuration;
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for:
the duration of all meter advance periods in the instruction, and,
the first day of any EAC in the instruction;
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 the Metering System will not be left without a Profile Class or Standard Settlement Configuration for any Settlement Day within the Data Collector’s view of the Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

for the Data Collector’s view of ‘Metering System’s relationships with Measurement Classes’ in the instruction:

that they are all for valid Measurement Classes;
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 the Metering System will not be left without a Measurement Class for any Settlement Day within the Data Collector’s view of the Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

for the Data Collector’s view of ‘Metering System’s Energisation Statuses’ in the instruction:

that the Energisation Status are ‘D’ or ‘E’;
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 the Metering System will not be left without an Energisation Status for any Settlement Day within the Data Collector’s view of the Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;

for the Data Collector’s view of ‘Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and overlap with a Data Aggregator Appointment for the Data Aggregator.

that they are all for valid GSP Groups;
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 the Metering System will not be left without a GSP Group for any Settlement Day within the Data Collector’s view of the Metering System’s Meter Advance Consumptions and Estimated Annual Consumptions if the instruction is applied;
that the Metering System has a valid combination of Valid Settlement Configuration Profile Class and GSP Group for:
the duration of all meter advance periods in the instruction, and,
the first day of any EAC in the instruction;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

If there is one or more relationships in the instruction and the Metering System doesn’t exist, create it.

Delete all this NHH Data Collector’s view of the Metering System’s relationships of the following types which begin on or after the earlier of the significant date and the start date of the earliest relationship of the same type in the instruction:

Meter Advance Consumption;
Estimated Annual Consumption;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Registration;
GSP Group.

Insert all the relationships of the following types in the instruction:

Registration;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
GSP Group;
Meter Advance Consumption;
Estimated Annual Consumption.

Delete all the Metering System’s relationships of the following types which do not overlap with either a Meter Advance Consumption for this Metering System and from this NHH Data Collector or an Estimated Annualised Advance for this Metering System and from this NHH Data Collector:

Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Registration;
GSP Group.

If, once all the relationship types associated with the instruction have been processed in this way, the Metering System is left without any details, delete it.

Set the instruction’s status to ‘Applied’.

6.3.2 Process 2 - Receive Registration Updates

Brief Description

This process receives, validates and stores non-half hourly Metering System Registration details for each Metering System. This data is sent from a PRS Agent.

Detail Processing Description

The process receives a file containing a set of instructions from PRS Agent. The file handling verification and error handling processing is described in Process 2.1.

The non-half hourly Metering System Registration details can be received in the following sets:

Data Aggregator appointment details
Profile Class and / or Standard Settlement Configuration details
Data Collector appointment details
Measurement Class details
Energisation Status details
GSP Group details
Line Loss Factor Class details
all Registration details for all Metering Systems in a distributor’s SMRS.

The data content, validation, and processing of each of these is described in Processes 2.2 to 2.9.

6.3.3 Process 2.1 - Receive Registration Details

Brief Description

This process receives a file containing a set of instructions from a PRS Agent. It verifies the validity of the file and handles any required error processing. The full file handling process is described in detail in Data Interfaces (reference 6).

Detail Processing Description

Receipt of a file from the PRS Agent

The file received from the PRS Agent is verified to ensure:

physical integrity;
that it is for the Data Aggregator;
that it is from a valid PRS Agent;
that the file only contains instructions which are valid for the source (a PRS Agent can only send instructions relating to Metering System Registration);
that the file only contains instructions for Metering Systems that belong to the matching distributor, as determined by the first two digits of their MSID;
that the file sequence number is the next instruction file sequence number from the source. If this sequence number is higher than the next sequence number, the file is not processed and is left in the ‘Receipt’ area;
that the instructions in the file are in instruction sequence number order and the first sequence number in the file follows on from the last instruction received from the source of the file;
that, if the file contains a PRS Refresh instruction, it is the only instruction in the file;

6.3.4 Process 2.2 - Process Data Aggregator Appointment Details

Brief Description

This process receives, validates and stores a set of Data Aggregator Appointment details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include the details of the Data Aggregator Appointments and all the associated details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s Registrations’ which overlap or start on or after the significant date and for which the Data Aggregator has an appointment, where such appointments also occur in the instruction;
all the ‘Metering System’s Data Aggregator Appointments’ for the Data Aggregator which overlap or start on or after the significant date;
all the ‘Metering System’s Data Collector Appointments’ which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator and either:

start on or after the significant date; or
start prior to the significant date and is the latest Data Collector Appointment on or prior to the significant date for the Registration in effect on the significant date;

all the ‘Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with Measurement Classes’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s Energisation Statuses’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with Line Loss Factor Classes’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator.

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
that there is not an existing Data Aggregator Appointment in the system with a start date before the significant date and either no end date or an end date on or after the significant date (unless it is also in the instruction);
that, if the instruction contains only a Data Aggregator Appointment record with a start and end date (with no related details), a Data Aggregator Appointment exists on the system with the same start date and no end date;
for the ‘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 Data Aggregator Appointment;

for the ‘Metering System’s Data Aggregator Appointments’ in the instruction:

that they are all for this Data Aggregator;
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 date earlier than the start date for their Registration;
that none have a start or end date on or later than the start date of the subsequent Registration (if one exists) for the Metering System if the instruction is applied;
that none of the Appointments overlap each other or any other appointment for the Metering System;
that all the start dates are unique;

for the ‘Metering System’s Data Collector Appointments’ in the instruction:

that they are all for valid Data Collectors;
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 (Data Collector Appointments for different Registrations should be considered separately for the purpose of interpreting overlap);
that if one has a start date before the significant date, all other Data Collector Appointments for the same Registration must have start dates after the significant date;
that none have a start date earlier that the start date for their Registration;
that no Registrations will be left without a Data Collector Appointment if the instruction is applied;
that the start dates are unique for Data Collector Appointments that are for the same Registration;

for the ‘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 & Standard Settlement Configuration;
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator 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 Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator 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 Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘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 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator Appointments which will exist for this Registration if the instruction is applied;
that no Registrations will be left without an Energisation Status for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

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

that they are all for valid Distributors and Line Loss Factor Classes;
that the Line Loss Factor Class’s Distributor match the Metering System’s Distributor as determined by the first two digits of its MSID;
that they are all for 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 Data Aggregator Appointments which will exist if the instruction is applied;
that the Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

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

that they are all for valid GSP Groups;
that they are all for 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 Data Aggregator Appointments which will exist if the instruction is applied;
that the Metering System will not be left without a GSP Group for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s appointments;
that the GSP Group is appointed to the Distribution Business for the Metering System on the Effective From Settlement Date, where the Distribution Business is identified by the first 2 characters of the MSID;
that all the start dates are unique;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

If the instruction contains only a Data Aggregator Appointment record with a start and end date (with no related details) and the significant date is the same as the end date and a Data Aggregator Appointment exists on the system with the same start date and no end date:

Set the end date of the appointment to that supplied in the instruction;

Delete any relationships of the following type for the Metering System which start after the significant date:

Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group.

(Note that Data Aggregator Appointments and Registrations are not deleted as there cannot be any on the system, as they would overlap with the appointment being closed. Data Collector Appointments are not deleted as they are calendar day based).

Set the instructions status to ‘Applied’.

Otherwise:

If there is one or more relationships in the instruction and the Metering System doesn’t exist, create it.

Delete:

all the Metering System’s relationships of the following types which begin on or after the earlier of the significant date and the start date of the earliest relationship of the same type in the instruction:

Data Aggregator Appointment;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group;

all the Metering System’s Data Collector Appointment relationships where the Data Collector Appointment begins on or after the earlier of the significant date and the start date of the earliest Data Collector Appointment in the instruction that is for the same Registration.

Insert all the relationships of the following types in the instruction where, in the case of Registration, they do not already exist:

Registration;
Data Aggregator Appointment;
Data Collector Appointment;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group.

Delete:

all the Metering System’s relationships of the following types which do not overlap with a Data Aggregator Appointment:

Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group;

all the Metering System’s Registrations and all their Data Collector Appointments where the Registration does not have any Data Aggregator Appointments.

If, once all the relationship types associated with the instruction have been processed in this way, the Metering System is left without any details, delete it.

Set the instructions status to ‘Applied’.

6.3.5 Process 2.3 - Process Profile Class / SSC Details

Brief Description

This process receives, validates and stores a set of Profile Class and Standard Settlement Configuration details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include Profile Class and / or Standard Settlement Configuration details for a Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s relationships with Profile Class and Standard Settlement Configurations’ which overlap or start on or after the significant date and which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator;

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
For the Profile Class / Standard Settlement Configuration relationships 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 valid combinations of Valid Settlement Configuration Profile Class;
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s appointments;
that they are all for Registrations that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator Appointments which already exist for this Registration;
that no Registrations will be left without a valid combinations of Settlement Configuration and Profile Class for any Settlement Day within a Data Aggregator Appointment if the instruction is applied.
that all the start dates are unique;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s Profile Class and Standard Settlement Configuration relationships which begin on or after the earlier of the significant date and the start date of the earliest relationship in the instruction.

Insert all the Profile Classes and Standard Settlement Configuration relationships in the instruction.

Delete all the Metering System’s Profile Class and Standard Settlement Configuration relationships which do not overlap with a Data Aggregator Appointment.

Set the instruction’s status to ‘Applied’.

6.3.6 Process 2.4 - Process Data Collector Appointment Details

Brief Description

This process receives, validates and stores a set of Data Collector Appointment details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include the details of the Data Collector Appointments and associated details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s Data Collector Appointments’ which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator and either:

start on or after the significant date; or
start prior to the significant date and is the latest Data Collector Appointment on or prior to the significant date for the Registration in effect on the significant date.

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
for the ‘Metering System’s Data Collector Appointments’ in the instruction:

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

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s Data Collector Appointment relationships where the Data Collector Appointment begins on or after the earlier of the significant date and the start date of the earliest Data Collector Appointment in the instruction that is for the same Registration.

Insert all the Data Collector Appointment relationships in the instruction.

Set the instruction’s status to ‘Applied’.

6.3.7 Process 2.5 - Process Measurement Class Details

Brief Description

This process receives, validates and stores a set of Measurement Class details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include the details of the Measurement Class details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s relationships with Measurement Classes’ which overlap or start on or after the significant date and which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator;

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
For the Measurement Class relationships in the instruction:

that they are all for valid Measurement Classes;
that they are all for Registrations that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator Appointments which already exist for this Registration;
that no Registrations will be left without a Measurement Class for any Settlement Day within a Data Aggregator Appointment if the instruction is applied.
that all the start dates are unique;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s Measurement Class relationships which begin on or after the earlier of the significant date and the start date of the earliest relationship in the instruction.

Insert all the Measurement Class relationships in the instruction.

Delete all the Metering System’s Measurement Class relationships which do not overlap with a Data Aggregator Appointment.

Set the instruction’s status to ‘Applied’.

6.3.8 Process 2.6 - Process Energisation Status Details

Brief Description

This process receives, validates and stores a set of Energisation Status details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include the details of Energisation Status details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s relationships with Energisation Statuses’ which overlap or start on or after the significant date and which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator;

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
For the Energisation Status relationships in the instruction:

that they are all either ‘D’ or ‘E’;
that they are all for Registrations that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that none have a start date earlier 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator Appointments which already exist for this Registration;
that no Registrations will be left without an Energisation Status for any Settlement Day within a Data Aggregator Appointment if the instruction is applied.
that all the start dates are unique;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s Energisation Status relationships which begin on or after the earlier of the significant date and the start date of the earliest relationship in the instruction.

Insert all the Energisation Status relationships in the instruction.

Delete all the Metering System’s Energisation Status relationships which do not overlap with a Data Aggregator Appointment.

Set the instruction’s status to ‘Applied’.

6.3.9 Process 2.7 - Process GSP Group Details

Brief Description

This process receives, validates and stores a set of GSP Group details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include GSP Group details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator;

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
For the GSP Group relationships in the instruction:

that they are all for valid ‘GSP Groups’;
that they are all for Metering Systems that already exist in the system;
that they all overlap or start on or after the significant date;
that if one has a start date before the significant date, the rest must have start dates after the significant date;
that they all overlap with one or more Data Aggregator Appointments which already exist for this Metering System;
that no Data Aggregator Appointments will be left without a GSP Group for any Settlement Day if the instruction is applied;
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s appointments;
that the GSP Group is appointed to the Distribution Business for the Metering System on the Effective From Settlement Date, where the Distribution Business is identified by the first 2 characters of the MSID;
that all the start dates are unique.

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s GSP Group relationships which begin on or after the earlier of the significant date and the start date of the earliest relationship in the instruction.

Insert all the GSP Group relationships in the instruction.

Delete all the Metering System’s GSP Group relationships which do not overlap with a Data Aggregator Appointment.

Set the instruction’s status to ‘Applied’.

6.3.10 Process 2.8 - Process Line Loss Factor Class Details

Brief Description

This process receives, validates and stores a set of Line Loss Factor Class details for a Metering System from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include Line Loss Factor Class details for the Metering System as described below:

the significant date for the instruction;
all the ‘Metering System’s relationships with Line Loss Factor Classes’ which overlap or start on or after the significant date and which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator;

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business associated with the Metering System;
that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the instruction;
For the Line Loss Factor Class relationships in the instruction:

that they are all for valid Distributors and Line Loss Factor Classes;
that the Line Loss Factor Class’s Distributor match the Metering System’s Distributor as determined by the first two digits of its MSID;
that they are all for 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 Data Aggregator Appointments which will exist if the instruction is applied;
that the Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid instructions are applied as follows:

Delete all the Metering System’s Line Loss Factor Class relationships which begin on or after the earlier of the significant date and the start date of the earliest relationship in the instruction.

Insert all the Line Loss Factor Class relationships in the instruction.

Delete all the Metering System’s Line Loss Factor Class relationships which do not overlap with a Data Aggregator Appointment.

Set the instruction’s status to ‘Applied’.

6.3.11 Process 2.9 - Refresh PRS Metering System Details

Brief Description

This process receives, validates and stores a set of details for all Metering Systems within a distribution area from a PRS Agent.

Detail Processing Description

Data Content

Each instruction should include the details of the Metering System and its associated details as described below:

the significant date for the instruction;
for each Metering System:

all the ‘Metering System’s Registrations’ which overlap or start on or after the significant date and for which the Data Aggregator has an appointment;
all the ‘Metering System’s Data Aggregator Appointments’ for the Data Aggregator which overlap or start on or after the significant date;
all the ‘Metering System’s Data Collector Appointments’ which are relevant (as defined in Data Interfaces (reference 6)) to the Data Aggregator and either:

start on or after the significant date; or
start prior to the significant date and is the latest Data Collector Appointment on or prior to the significant date for the Registration in effect on the significant date;

all the ‘Metering System’s relationships with Profile Classes and Standard Settlement Configurations’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with Measurement Classes’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s Energisation Statuses’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with Line Loss Factor Classes’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator;
all the ‘Metering System’s relationships with GSP Groups’ which overlap or start on or after the significant date and which are relevant to the Data Aggregator.

Validation

The instruction is validated to ensure:

that the PRS Agent which sent the instruction is currently appointed to the distribution business that is the subject of the instruction;
for each Metering System in the instruction:

that the Metering System’s distributor’s PRS Agent (as determined by the first two digits of its MSID) matches the PRS Agent source of the refresh instruction;
for the ‘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 Data Aggregator Appointment;

for the ‘Metering System’s Data Aggregator Appointments’ in the instruction:

that they are all for this Data Aggregator;
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 date earlier than the start date for the Registration;
that none have a start or end date on or later than the start date of the subsequent Registration (if one exists) for the Metering System if the instruction is applied;
that none of the Appointments overlap each other;
that all the start dates are unique;
that there is no existing Data Aggregator Appointment which begins prior to the significant date and either doesn’t end or ends on or after the significant date and this Data Aggregator Appointment is not included in the instruction;

for the ‘Metering System’s Data Collector Appointments’ in the instruction:

that they are all for valid Data Collectors;
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 (Data Collector Appointments for different Registrations should be considered separately for the purpose of interpreting overlap);
that if one has a start date before the significant date, all other Data Collector Appointments for the same Registration must have start dates after the significant date;
that none have a start date earlier that the start date for their Registration;
that no Registrations will be left without a Data Collector Appointment if the instruction is applied;
that the start dates are unique for Data Collector Appointments that are for the same Registration;

for the ‘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 & Standard Settlement Configuration
that they are all for a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator 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 Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator 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 Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

for the ‘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 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 Metering System if the instruction is applied;
that they all overlap with one or more Data Aggregator 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 Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

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

that they are all for valid Distributors and Line Loss Factor Classes;
that the Line Loss Factor Class’s Distributor match the Metering System’s Distributor as determined by the first two digits of its MSID;
that they are all for 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 Data Aggregator Appointments which will exist if the instruction is applied;
that the Metering System will not be left without a Line Loss Factor Class for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that all the start dates are unique;

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

that they are all for valid GSP Groups;
that they are all for 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 Data Aggregator Appointments which will exist if the instruction is applied;
that the Metering System’s will not be left without a GSP Group for any Settlement Day within a Data Aggregator Appointment if the instruction is applied;
that the Metering System has a valid combination of Valid Settlement Configuration Profile Class and GSP Group for the period of the Data Aggregator’s appointments;
that the GSP Group is appointed to the Distribution Business for the Metering System on the Effective From Settlement Date, where the Distribution Business is identified by the first 2 characters of the MSID;
that all the start dates are unique.

Processing

Compare the details for each Metering System in the instruction against those already in the system. Produce a report detailing any changes which will be caused by applying the instruction.

For each Metering Systems in the instruction that did not fail any validation:

If there is one or more relationships in the instruction and the Metering System doesn’t exist, create it.

Delete:

all the Metering System’s relationships of the following types which begin on or after the earlier of the significant date and the start date of the earliest relationship of the same type in the instruction:

Data Aggregator Appointment;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group;

all the Metering System’s Data Collector Appointment relationships where the Data Collector Appointment begins on or after the earlier of the significant date and the start date of the earliest Data Collector Appointment in the instruction that is for the same Registration.

Insert all the relationships of the following types in the instruction where, in the case of Registration, they do not already exist:

Registration;
Data Aggregator Appointment;
Data Collector Appointment;
Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group.

Delete:

all the Metering System’s relationships of the following types which do not overlap with a Data Aggregator Appointment:

Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group;

all the Metering System’s Registrations and all their Data Collector Appointments where the Registration does not have any Data Aggregator Appointments.

If, once all the relationship types associated with the instruction have been processed in this way, the Metering System is left without any details, delete it.

For each Metering System associated with the Distribution Business in the instruction but not included in the instruction, remove any superfluous relationships for it as follows:

Delete:

all the Metering System’s Data Aggregator Appointments which begin on or after the significant date.
all the Metering System’s relationships of the following types which do not overlap with a Data Aggregator Appointment:

Profile Class;
Standard Settlement Configuration;
Measurement Class;
Energisation Status;
Line Loss Factor Class;
GSP Group;

all the Metering System’s Registrations and all their Data Collector Appointments where the Registration does not have any Data Aggregator Appointments.

If, once all the relationship types associated with the instruction have been processed in this way, the Metering System is left without any details, delete it.

If all Metering Systems in the instruction pass validation and are successfully processed, the instruction is marked as ‘applied’. Otherwise the user has the option of accepting or rejecting the refresh. This is done on the basis of a set of statistics that are maintained about the success of the refresh. Accepted refreshes are marked as applied; rejected refreshes are marked as discarded. This is described more fully in Data Interfaces (reference 6).

6.3.12 Process 2.10 - Process Demand Control Event data

Brief Description

This process receives, validates and stores data relating to Demand Control event received from a Distributor.

Detail Processing Description

Data Content

Each file should include Demand Control Event information as described below:

the Demand Control Event Id;
the start and end date and time of the Demand Control event
the Metering System Id(s) affected by the event, grouped by Profile Class Id

Validation

The data is validated to ensure:

that a Demand Control Id does not already exist in the NHHDA database;
that no duplicate Demand Control Ids are found in the file;
that an MSID is not reported in more than one Demand Control Event;
that the end date and time of a Demand Control Event is not earlier than the start date and time;
that a Demand Control Event Id is included in the file.

If any of the validation fails, the instruction is marked as ‘Failed’ and is subject to the Instruction Processing Problem Resolution as described in Data Interfaces (reference 6).

Processing

Valid files are applied as follows:

Insert all Demand Control Event information

6.3.13 Process 3.1 - Prepare Data Aggregation Run Schedule

Brief Description

Refer also to the definition of Process 4.11.2

This process allows suitably authorised NHH Data Aggregator users to schedule the Aggregation Runs covering the GSP Groups which, according to the Settlement Timetable published by the Market Domain Data Agent (reference 4), are required to be included in the Settlement of each Settlement Day.

Detail Processing Description

The user will specify the Settlement Date and Settlement Code for which an aggregation run is required, the GSP Group(s) to be included in the run, and the date and time at which the run should occur. The system will assign a Data Aggregation Run Number, and store the entered data as a Data Aggregation Run. It will also create associated occurrences of the GSP Group in Aggregation Run entity.

The run date and time and/or the set of GSP Groups may be amended for Data Aggregation Runs that have not yet taken place. The system will store any new run date and time in the Data Aggregation Run entity and any change in the set of GSP Groups to be included in the run in its GSP Group in Aggregation Run entities. Data Aggregation Runs that have not yet taken place may be deleted. The system will delete the Data Aggregation Run entity and all its GSP Group in Aggregation Run entities.

6.3.14 Process 3.2 - Perform Aggregation Run

Brief Description

This process performs a previously requested Aggregation Run at the scheduled time. The Metering Systems included are those which, according to the PRS Agent, lie within one of the GSP Groups associated with the Aggregation Run.

In the event that PRS and the Data Collector disagree over the GSP Group, Profile Class, or Standard Settlement Configuration of a Metering System, the PRS data will be treated as definitive. All such exceptions will be recorded for audit purposes.

Detail Processing Description

The process will be initiated at (or as soon as possible after) the time at which the Aggregation Run was scheduled. The system will determine the set of GSP Groups included in the Aggregation Run, and aggregate each of the GSP Groups as follows:

For each combination of Supplier, Line Loss Factor Class and Valid Measurement Requirement Profile Class, the system will maintain totals across all Metering Systems for:

Annualised Advances (AA);
the number of Metering Systems (NMA) contributing to Annualised Advances;
Estimated Annual Consumptions (ME) for non half hourly metered Metering Systems;
the number of non half hourly metered Metering Systems (NMME) contributing to Estimated Annual Consumptions;
the number of energised non half hourly metered Metering Systems (NMMDE) without either an Estimated Annual Consumption or Annualised Advance (and which therefore require a default EAC to be used);
Estimated Annual Consumptions (UE) for non half hourly unmetered Metering Systems;
the number of non half hourly unmetered Metering Systems (NMUE) contributing to Estimated Annual Consumptions;
the number of energised non half hourly unmetered Metering Systems (NMUDE) without an Estimated Annual Consumption (and which therefore require a default EAC to be used).

In order to do this, it will determine those Metering Systems for which:

the Metering System has a Registration to the Supplier for that Settlement Day;
the Data Aggregator is appointed to the Metering System for that Settlement Day;
the Metering System is associated with the Line Loss Factor Class for that Settlement Day;
the Metering System has a Settlement Register which is associated with the Valid Measurement Requirement Profile Class for that Settlement Day.

For each such Metering System, it will determine:

the Metering System’s Registration (according to PRS) on the settlement date and all of this Registration’s Data Collector appointments which begin on or before the current date.
the latest set of EACs/AAs for the standard settlement configuration applicable on the settlement date which each of these appointed Data Collectors has provided.
Select one of these sets of AAs or EACs as listed below in priority order:

the set of AAs from the Data Collector with the latest appointment to the Registration on or before the current date, from the set of Data Collectors who have provided one of these sets of AAs;
the latest set of EACs with, in the event of this not uniquely identifying a set, the set provided by the Data Collector with the later appointment to the Registration on or before the current date taking precedence

the Measurement Class (according to PRS) on the Settlement Day - (whether the Metering System is non half hourly metered or non half hourly unmetered);
the energisation status (according to PRS) on the Settlement Day - (whether the Metering System is energised or de-energised).

If neither an Annualised Advanced or Estimated Annual Consumption can be found in this way, or if an Annualised Advance is found but the Measurement Class (according to PRS) is unmetered, the Settlement Register is regarded as having no Estimated Annual Consumption or Annualised Advance and is therefore included in the NMUDE total if the Measurement Class (according to PRS) is unmetered and the NMMDE total if it is metered. Exception records will be written to the log to create an audit trail in such cases.

If a Metering System is de-energised (according to PRS), any EAC will be ignored. The consumption will be treated as zero, unless there is a non-zero AA, in which case this will be used, and an exception record will be written to the log to create an audit trail. The NMA will not include de-energised Metering Systems having a zero AA for all Measurement Requirements.

Once all Metering Systems for the GSP Group, Supplier, Line Loss Factor Class and Valid Measurement Requirement Profile Class have been processed, determine the default EACs as follows:

Determine:

the GSP Group Distributor and the GSP Group Profile Class Default EAC (GGPCDEAC) effective on the Settlement Day for the GSP Group and Profile Class being processed;
the average fraction of yearly consumption (AFYC) effective on the Settlement Day for the Valid Measurement Requirement Profile Class and GSP Group being processed;
the Threshold Parameter effective on the Settlement Day.

Default EAC for metered Metering Systems (DEM)

= (AA + ME)/(NMA + NMME) if NMA+NMME > Threshold Parameter

= GGPCDEAC * AFYC otherwise

Default EAC for unmetered Metering Systems (DEU)

= UE / NMUE if NMUE > a Threshold Parameter

= GGPCDEAC * AFYC otherwise

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

Supplier Purchase Matrix data will then be calculated as follows:

Data Item	Set To
SPM Total Annualised Advance	AA
SPM Total AA MSID Count	NMA
SPM Total Metered EAC	ME + NMMDE*DEM
SPM Total Metered EAC MSID Count	NMME + NMMDE
SPM Default EAC MSID Count	NMMDE
SPM Total Unmetered Consumption	UE + NMUDE*DEU
SPM Total Unmetered MSID Count	NMUE + NMUDE
SPM Default Unmetered MSID Count	NMUDE

An audit log will be maintained, showing which Estimated Annual Consumption or Annualised Advance value was used for each Metering System, and also identifying the following Exception Conditions encountered during calculation of the Supplier Purchase Matrix:

Mismatch of the Metering System’s Profile Class as advised by the PRS Agent and that advised by the Data Collector;
Mismatch of the Metering System’s GSP Group as advised by the PRS Agent and that advised by the Data Collector;
Mismatch of the Metering System’s Standard Settlement Configuration as advised by the PRS Agent and that advised by the Data Collector;
Mismatch of the Metering System’s Supplier Registration as advised by the PRS Agent and that advised by the Data Collector;
Mismatch of the Metering System’s Measurement Class as advised by the PRS Agent and that advised by the Data Collector;
Mismatch of the Metering System’s Energisation Status as advised by the PRS Agent and that advised by the Data Collector;
Missing EAC/AA for the Metering System resulting in a default EAC being used.
Unmetered Metering Systems with an AA;
De-energised Metering Systems with non-zero AA;
Metering System excluded due to missing³ Metering System details.

An NHHDC performance report will be created during Aggregation Runs to provide counts and sub-totals of EACs and AAs by settlement class, Supplier and NHHDC for a single settlement. The report will also indicate the NHHDC that was appointed last within the supplier registration (i.e. the agent that is responsible for the entire supplier registration). The data reported will include:

Supplier Id,
Default EAC
MSID Count,
Default Unmetered MSID Count,
Total AA MSID Count,
Total EAC MSID Count and
Total Unmetered MSID Count
Total Annualised Advance
Total EAC
Total Unmetered Consumption
A total will be included for each NHHDC, showing the total for all Suppliers.
A grand total will show a total for all Suppliers across all NHHDCs.

6.3.15 Process 3.2A - Perform Disconnection Aggregation Run

Where a Demand Control Event has occurred, the NHH Data Aggregator must perform an additional calculation to determine the amount of disconnected energy resulting from the event. A set of Disconnection Purchase Matrix data is calculated, based in the same principles as the Supplier Purchase Matrix data described in Process 3.2 but only for those MSIDs affected by the Demand Control Event.

The equivalent data items produced by this process are as follows:

Data Item	Set To
DPM Total Annualised Advance	AA
DPM Total AA MSID Count	NMA
DPM Total Metered EAC	ME + NMMDE*DEM
DPM Total Metered EAC MSID Count	NMME + NMMDE
DPM Default EAC MSID Count	NMMDE
DPM Total Unmetered Consumption	UE + NMUDE*DEU
DPM Total Unmetered MSID Count	NMUE + NMUDE
DPM Default Unmetered MSID Count	NMUDE

Similarly, a performance report will be created during the Aggregation Run to provide counts and sub-totals of EACs and AAs by settlement class, Supplier and NHHDC for a single settlement. The data reported will include:

Supplier Id,
Default EAC
Disconnected MSID Count,
Default Unmetered Disconnected MSID Count,
Total AA Disconnected MSID Count,
Total EAC Disconnected MSID Count and
Total Unmetered Disconnected MSID Count
Total Disconnected Annualised Advance
Total Disconnected EAC
Total Disconnected Unmetered Consumption
A total will be included for each NHHDC, showing the total for all Disconnected Suppliers.
A grand total will show a total for all Suppliers across all Disconnected NHHDCs.

6.3.16 Process 4.1 - Maintain Profile Class

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain Profile Classes and their associated GSP Group Profile Class Default EACs (as specified by the Distribution Businesses and distributed by the Market Domain Data Agent).

Detail Processing Description

A Profile Class Id and Profile Class Description must be specified for each Profile Class. The system will allow Profile Classes to be created and updated. It will also allow Profile Classes to be deleted, subject to the following restrictions:

a Profile Class cannot be deleted if it is associated with Valid Settlement Configuration Profile Classes, or occurrences of Profile Class in Registration or Metering System Profile Class (DC);
a warning will be issued if the Profile Class has GSP Group Profile Class Default EACs defined.

A GSP Group Id, Profile Class Id, Effective From Settlement Date and Researched Default EAC must be specified for each GSP Group Profile Class Default EAC. The system will allow them to be created, updated and deleted.

6.3.17 Process 4.2 - Maintain Supplier

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of Suppliers.

Detail Processing Description

A Supplier Id and Supplier Name must be specified. The system will allow Suppliers to be created, and their names updated. It will only allow a Supplier to be deleted if it has no associated Registrations, Registration (DC)s, or Supplier Purchase Matrix data.

6.3.18 Process 4.3 - Maintain Data Collector

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of Data Collectors.

Detail Processing Description

A Data Collector Id and Data Collector Name must be specified. The system will allow Data Collectors to be created, and their names updated. It will only allow a Data Collector to be deleted if it has no associated Data Collector appointments or other data.

Brief Description

This process allows suitably authorised NHH Data Aggregator users to specify the Average Fraction of Yearly Consumption for each Valid Measurement Requirement Profile Class for a given combination of Valid Settlement Configuration Profile Class and GSP Group.

Detail Processing Description

The system will validate that:

the fractions specified for a set sum to one;
that no Metering System will be left without a valid combination of Valid Settlement Configuration Profile Class and GSP Group following the change.

An Effective From Settlement Date and Effective To Settlement Date will be specified for each set of data.

A warning will be raised if the Average Fraction of Yearly Consumption value changes affect a Settlement Date that is on or before the latest Settlement Date for which a Final Initial Settlement Run has been run.

6.3.23 Process 4.6 - Maintain Distributor

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of Distributors and associated PRS Agent Appointments.

Note: Market Participant Roles of Distributor and PRS Agent can be considered to be a ‘pair item’ since they cannot exist separately.

Detail Processing Description

The system will allow Distributors to be created, updated and deleted.

To create a new Distributor, a Distributor Id and Distributor Name must be specified and a PRS Agent appointed.

The system will allow Distributor details to be updated. The “Distributor Short Code” must not be changed if there are Metering Systems with an identifier that begins with the “Distributor Short Code” in the system.

A Distributor must always have one and only one PRS Agent.

The system will also allow Distributors to be deleted. A Distributor may not be deleted if it has any associated active appointments, Line Loss Factor Classes, GSP Group (in GSP Group Distributor) or if there are Metering Systems with an identifier that begins with the “Distributor Short Code” in the system.

6.3.24 Process 4.7 - Maintain GSP Group

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of GSP Groups.

Detail Processing Description

A GSP Group Id and GSP Group Description must be specified.

The system will also allow details of the appointments of ISR Agents and Distributors to be specified. In each case, the appropriate Id will be selected from a list, and the Effective From Date and, optionally, Effective To Date specified.

The system will also allow GSP Groups and their appointments to be updated and deleted. It will only allow a GSP Group to be deleted if it has no associated occurrences of Metering System GSP Group, Metering System GSP Group (DC), or GSP Group in Aggregation Run.

6.3.25 Process 4.8 - Maintain Line Loss Classes

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of Line Loss Factor Classes.

Detail Processing Description

A Distributor Id must be selected, and a Line Loss Factor Class Id and Line Loss Factor Class Description specified. The system will allow Line Loss Factor Classes to be created, and their Descriptions to be updated. It will only allow a Line Loss Factor Class to be deleted if it has no associated Metering System Line Loss Classes or Supplier Purchase Matrix data.

6.3.26 Process 4.9 - Maintain PRS Agent

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of PRS Agents.

Note: Market Participant Roles of Distributor and PRS Agent can be considered to be a ‘pair item’ since they cannot exist separately.

Detail Processing Description

An PRS Agent Id and PRS Agent Name must be specified. The system will allow PRS Agents to be created, updated and deleted. It will only allow a PRS Agent to be deleted if it has no associated PRS Agent Appointments.

6.3.27 Process 4.10 - Maintain Threshold Parameter

Brief Description

This process allows suitably authorised NHH Data Aggregator users to maintain details of the Threshold Parameter.

Detail Processing Description

This is a system-wide parameter specifying the minimum number of Metering Systems required in a given cell of the Supplier Purchase Matrix before their average EAC/AA will be used as a default for Metering Systems without EAC/AA data. An Effective From Settlement Date will be specified for each value.

6.3.28 Process 4.11.1 – Load Market Domain Data Complete Set

Brief Description

This process allows suitably authorised NHH Data Aggregator users to load data from a file containing published Market Domain Data. The file may contain additional details not required for NHH Data Aggregation. Details loaded are:

Threshold Parameter
Market Participants, their Market Participant Roles (for NHHDA purposes this is limited to Supplier, NHH Data Collector, ISR Agent, PRS Agent, Distributor)
GSP Group Distributor
PRS Agent Appointment
ISR Agent Appointment
Line Loss Factor Classes
Profile Classes
Time Pattern Regimes
Standard Settlement Configurations, their Measurement Requirements, the Valid Settlement Configurations Profile Classes combinations and their Valid Measurement Requirement Profile Classes and Average Fractions of Yearly Consumptions

It will be possible to process the MDD file in order to identify any exceptions within the file without updating the MDD data held by the system. During this validation process exceptions will be identified and recorded where the file content would have failed the manual data load checks or referential integrity checks performed by the database. Any exceptions encountered during the load should be resolved by the Data Aggregator.

During the load of MDD files GSP Group related data in the file will only be loaded for those GSP Groups that are already known to the NHHDA database (this restriction does not apply to Line Loss Factor Classes and Valid Settlement Configuration Profile Classes).

Note: Market Participant Roles of Distributor and PRS Agent can be considered to be a ‘pair item’ since they cannot exist separately.

Detail Processing Description

Note that in this section data that is “already defined on the system” includes data from the load that has already been processed (excluding GSP Group).

The following data will be specified for each Threshold Parameter:

Threshold Parameter
Effective From Settlement Date {TPAR}

The process will insert new distinct Threshold Parameters not already on the database.

The only change permitted for a Threshold Parameter already defined on the system is:

modification of the Threshold Parameter (an exception will be raised if the parameter change affects a Settlement Date that is on or before the latest Settlement Date for which a Final Initial Settlement Run has been run).

The following data will be specified for each Supplier:

Supplier Id (from Market Participant Id and Market Participant Role Code)
Supplier Name (from Market Participant Name)

The process will insert Suppliers with new Supplier Ids contained in the file.

The only change permitted for a Supplier already defined on the system is:

modification of the Supplier Name

The following data will be specified for each NHH Data Collector:

Data Collector id (from Market Participant Id and Market Participant Role Code)
Data Collector Name (from Market Participant Name)

The process will insert NHH Data Collectors with new Data Collector Ids contained in the file.

The only change permitted for a NHH Data Collector already defined on the system is:

modification to the Data Collector Name

The following data will be specified for each Distributor:

Distributor Id (from Market Participant Id and Market Participant Role Code)
Distributor Name (from Market Participant Name)
Distributor Short Code

The process will insert Distributors with new Distributor Ids contained in the file.

The only changes permitted for a Distributor already defined on the system are:

modification to the Distributor Name
modification to the Distributor Short Code (but only if this code is not in use by any Metering System)

The following data will be specified for each PRS Agent:

PRS Agent Id (from Market Participant Id and Market Participant Role Code)
PRS Agent Name (from Market Participant Name)

The process will insert PRS Agents with new PRS Agent Ids contained in the file.

The only change permitted for a PRS Agent already defined on the system is:

modification to the PRS Agent Name

The following data will be specified for each ISR Agent:

ISR Agent Id (from Market Participant Id and Market Participant Role Code)
ISR Agent Name (from Market Participant Name)

The process will insert ISR Agents with new ISR Agent Ids contained in the file.

The only change permitted for an ISR Agent already defined on the system is:

modification to the ISR Agent Name

The following data will be specified for each GSP Group Distributor:

GSP Group Id
Effective From Settlement Date {GGD}
Effective To Settlement Date {GGD}
Distributor Id

The process will insert new distinct combinations of GSP Group Distributor contained in the file. It will validate that:

the GSP Group Id is already defined on the system
the Distributor Id is already defined on the system
the corresponding PRS Agent Appointment {PAA} exists for the same GSP Group

The only change permitted for a GSP Group Distributor which is already defined on the system is:

a change in the Distributor Id (the new Distributor Id must already be defined on the system)
a change to Effective To Settlement Date {GGD} but only if the Effective From Settlement Date {GGD} matches that already recorded.

The following data will be specified for each PRS Agent Appointment:

Distributor Id
Effective From Date {PAA}
Effective To Date {PAA}
PRS Agent Id

The process will load details of all PRS Agent Appointments with new distinct combinations of Distributor Id and Effective From Date {PAA} contained in the file. It will validate that:

the Distributor Id is already defined on the system
the PRS Agent Id is already defined on the system
the corresponding GSP Group Distributor appointment (GGD} exists for the same GSP Group

The only changes permitted for a PRS Agent Appointment are where an appointment having the same Distributor Id and Effective From Data (PAA} is already defined, in which case either:

the Effective To Date {PAA} may be set or modified

The following data will be specified for each ISR Agent Appointment:

GSP Group Id
Effective From Date {IAA}
Effective To Date {IAA}
ISR Agent Id

The process will load details of all ISR Agent Appointments with new distinct combinations of GSP Group Id and Effective From Date {IAA} contained in the file. It will validate that:

the GSP Group Id is already defined on the system
the ISR Agent Id is already defined on the system
there are no overlaps to appointments for any GSP Group

The only changes permitted for an ISR Agent Appointment are where an appointment having the same GSP Group Id and Effective From Data {IAA} is already defined, in which case either:

the ISR Agent Id may be modified, or,
the Effective To Date {IAA} may be set or modified

It will validate that:

there are no overlaps to appointments for any GSP Group Id

The following data will be specified for each Line Loss Factor Class excluding site specific import and site specific export LLF Classes:

Distributor Id
Line Loss Factor Class Id
Line Loss Factor Class Description

The process will load details of all Line Loss Factor Classes with new distinct combinations of Distributor Id and Line Loss Factor Class Id contained in the file. It will validate that:

the Distributor Id is already defined on the system

The only change permitted for a Line Loss Factor Class already defined on the system is:

modification of the Line Loss Factor Class Description

The following data will be specified for each Profile Class:

Profile Class Id
Profile Class Description

The process will load details of all Profile Classes with a new distinct Profile Class Id contained in the file.

The only change permitted for a Profile Class already defined on the system is:

modification to the Profile Class Description

The following data will be specified for each Time Pattern Regime:

Time Pattern Regime Id.

The process will load details of all new distinct Time Pattern Regime Ids contained in the file.

The following data will be specified for each Standard Settlement Configuration:

Standard Settlement Configuration Id;
Standard Settlement Configuration Description;
Time Pattern Regime Ids of the associated Measurement Requirements
Profile Class Ids of the Profile Classes for which the Standard Settlement Configuration is valid (Valid Settlement Configurations Profile Class);
Set of Average Fraction of Yearly Consumption data for each GSP Group and valid Profile Class.

The process will load details of all Standard Settlement Configurations contained in the file. It will validate that:

the Profile Class Ids are already defined on the system;
the set of Average Fractions of Yearly Consumption within each valid combination of Standard Settlement Configuration and Profile Class and GSP Group sum to one.

The only changes permitted for a Standard Settlement Configuration which is already defined on the system are:

the addition of one or more new sets of Average Fraction of Yearly Consumption data;
the modification of the Effective To Date of the AFYC;
modification to the values of Average Fraction of Yearly Consumption values within a set.

A check will be made to ensure that no metering system will be left without an AFYC for any date during the Data Aggregator’s appointments.

If any other details do not match those given in the file, the system will issue a warning report.

Note that this file will also be used by other Market Participants and by the ISRA system, and will therefore include additional data, which is not relevant to the NHHDA system, and which is not listed above.

During validation exceptions will be recorded. These exceptions will be identified as either warning exceptions or error exceptions.

Warning exceptions will not prevent the changes to the data being committed. Warning exceptions include:

data in the Data Aggregator’s database is not included in the MDD file;
changes will affect the aggregation results for a date prior to the latest final initial settlement run.

Error exceptions will prevent the changes to MDD data being committed. Error exceptions include any validation that would prevent the manual data changes being accepted or any change which would fail database integrity checks (e.g. missing parent entity).

If changes are to be committed they will only be done so if the validation did not identify any error type exception.

The NHHDA load module will produce a MDD load report containing any warnings, errors, and also details of whether the file was successfully applied. All database changes will also be logged in this report when the MDD changes are committed to the database.

6.3.29 Process 4.11.2 – Load Settlement Timetable

Brief Description

This process allows suitably authorised NHH Data Aggregator users to load data from a file containing the settlement timetable as published by the Market Domain Data Agent. The file may contain additional details not required for NHH Data Aggregation. Each distinct Settlement Run, Settlement Code combination will cause a Data Aggregation Run to be scheduled. The scheduled date may either be:

The date provided in the published Settlement Timetable, or,
Derived from the ISR Notification Deadline Date using a predefined number of working days (this value will be user configurable).

The automatic loading of dates will not remove Data Aggregation Runs that were originally created manually (that is, the run was originally created through the manual data entry form). Details loaded are:

Data Aggregation Runs

Detail Processing Description

The following data will be specified for each Data Aggregation Run:

Data Aggregation Run Number
Settlement Date (from Settlement Date)
Settlement Code (from Settlement Code)
Data Aggregation Run Date (either derived from ISR Notification Deadline Date provided, or, use the proposed value contained in Planned Data Aggregation Run Date)

To verify the settlement timetable provided the process will validate that:

the first Payment Date is less than or equal to the last Payment Date;
all Payment Dates are on or between the first and last Payment dates;
every Settlement Date is less than its Planned Data Aggregation Run Date;
every Planned Data Aggregation Run Date is less than its ISR Notification Deadline Date;
every ISR Notification Deadline Date is less than its Payment Date.

To verify the scheduled Data Aggregation Runs the process will validate that:

the Settlement Code is valid;
the Data Aggregation Run for that Settlement Code and Settlement Date has not already been run;
there is not already a Data Aggregation Run that was manually specified.

Updates are only allowed to Planned Data Aggregation Run Dates for which the Data Aggregation Run has not been run or where the planned data aggregation run was not entered manually.

6.3.30 Process 5 - Send Supplier Purchase Matrices

Brief Description

This process allows suitably authorised NHH Data Aggregator users to request the send of previously aggregated Supplier Purchase Matrices to the relevant ISR agents and Suppliers.

Detail Processing Description

The user will select a Data Aggregation Run which has been performed. The system will perform the following processing for each GSP Group aggregated in the Data Aggregation Run:

obtain all the GSP Group’s Supplier Purchase Matrix data (and where relevant, Disconnection Purchase Matrix data) which was aggregated in the Data Aggregation Run;
collate a Supplier Purchase Matrix Data (and Disconnection Purchase Matrix Data) file for the ISR Agent;
collate a Supplier Purchase Matrix Data (and Disconnection Purchase Matrix) file for each Supplier;
determine the GSP Group’s ISR Agent and send the file to them;
send the Supplier files.

The system will contain controls to ensure that data cannot be sent for a Data Aggregation Run which is not the latest for that Settlement Day, unless the user explicitly acknowledges and overrides a warning message.

6.3.31 Process 6 - Report on Exceptions in DC Data

Brief Description

This process allows suitably authorised NHH Data Aggregator users to request a report listing discrepancies between the data supplied by a Data Collector, and that received from PRS and other Data Collectors.

Detail Processing Description

The user will specify a Supplier Id and Data Collector Id. The user will have the option of restricting the coverage of the report to certain PRS Agent(s), by specifying their PRS Agent Id(s), and to a given range of dates, by specifying a From and To Date. The user will also be able to view, amend or delete scheduled exception runs. During an exception run the system will check that the Data Collector Id, Supplier Id and PRS Agent Id(s) have previously been entered onto the system, and then report on the following discrepancies:

Data Collector Appointments for that Data Collector, for which there is also a Registration to the specified Supplier (as reported by PRS), for which no Estimated Annual Consumption or Annualised Advance data has been received, that is:

Supplier registered to Metering System (according to PRS);
Data Aggregator appointed to the Registration (according to PRS);
Data Collector appointed to the Registration (according to PRS);
EAC with an Effective From Settlement Date within the Registration (according to PRS) not received from any appointed Data Collector;
AA with an Effective From Settlement Date within the Registration (according to PRS) not received from any appointed Data Collector;

The discrepancy will only be produced for a period defined by the overlapping date range between a settlement date range where there is a Data Aggregator Appointment and the date range requested for reporting.

Estimated Annual Consumptions received from that Data Collector in kWhs, for Metering Systems registered to the specified Supplier (as reported by PRS), for which there is no corresponding Data Collector Appointment and/or Data Aggregator Appointment, that is:

Supplier registered to Metering System (according to PRS);
EAC received from the Data Collector with an effective from settlement date within the Registration (according to PRS);
Data Collector is not currently appointed to the Registration and does not have an appointment to the Registration which ended after the EAC effective from date.

and/or:

Supplier registered to Metering System (according to the Data Collector);
EAC received from the Data Collector with an effective from settlement date within the Registration (according to the Data Collector);
Data Aggregator is not appointed to the Registration on the EAC effective from date;

The discrepancy will only be produced for a period defined by the overlapping date range between a settlement date range where there is a Data Aggregator Appointment and the date range requested for reporting.

Annualised Advances received from that Data Collector in kWhs, for Metering Systems registered to the specified Supplier (as reported by PRS), for which there is no corresponding Data Collector Appointment and/or Data Aggregator Appointment, that is:

Supplier registered to Metering System (according to PRS);
AA received from the Data Collector with an effective from settlement date within the Registration (according to PRS);
Data Collector is not currently appointed to the Registration and does not have an appointment to the Registration which ended after the AA effective from date.

and/or:

Supplier registered to Metering System (according to the Data Collector);
AA received from the Data Collector with an effective period which fully or partially overlaps with the Registration (according to the Data Collector);
Data Aggregator is not appointed to the Registration on during the period between the AA effective from date and the AA effective to date;

Non-zero Annualised Advances received from that Data Collector, for Metering Systems registered to the specified Supplier (as reported by PRS), for which the Metering System is de-energised, that is:

Supplier registered to Metering System (according to the PRS);
Data Aggregator appointed to the Registration (according to PRS);
non zero AA for the Metering System received from a Data Collector appointed to the Registration where the Meter Advance Period falls (partially or fully) within the Registration (according to PRS);
Metering System de-energised within the Meter Advance Period (according to the Data Collector);

Meter Advance Periods received from that Data Collector, for Metering Systems registered to the specified Supplier (as reported by PRS), which either overlap with Meter Advance Periods received from another Data Collector, or are not contiguous with the last Meter Advance Period sent by the previous Data Collector, that is:

Supplier registered to Metering System (according to PRS);
Data Aggregator appointed to the Registration (according to PRS);
Data Collector (Data Collector 1) appointed to the Registration of the Metering System (according to PRS);
Data Collector(2) (possibly Data Collector (1)) appointed to the Registration of the Metering System (according to PRS);
AA(1) for the Metering System received from Data Collector(1) and AA(2) (not AA(1)) received from Data Collector(2), where both AAs have a Meter Advance Period that falls fully or partially within the Registration (according to PRS);
Energised (according to PRS);

and one of the following is true:

there is a time gap between Meter Advance Periods for AA(1) and AA(2) and there are not any AAs received from a Data Collector appointed to the Registration (according to PRS) which fully or partially fall in this gap (the gap is only required to be trapped as an exception when the AAs either side of it are being inspected)
there is an overlap in the durations of Meter Advance Periods for AA(1) and AA(2) (but excluding the case when AA(1) and AA(2) are the same, i.e. have the same AA value and Meter Advance Period).and the overlap is within the same Data Aggregator Appointment;

Data Collector Appointments for the specified Data Collector, for which there is also a Registration to the specified Supplier (as reported by PRS), for which the data supplied by PRS and the Data Collector do not match, that is:

Supplier registered to Metering System (according to PRS);
Data Aggregator appointed to the Registration (according to PRS);
Data Collector appointed to the Registration of the Metering System (according to PRS);
PRS and Data Collector have different views of the Metering System’s relationships with any of the following during the Registration (according to PRS):

Supplier;
Measurement Class;
GSP Group;
Profile Class;
Energisation status;
Standard Settlement Configuration;

and the following is true:

EACs or AAs have been received from the Data Collector appointed to the Registration of the Metering System (according to PRS) within the exception period.

Note that for the purpose of this check:

it is only necessary for the values to match on a day to day basis. That means that if during the period of the check the Data Collector and PRS have the same value for these entities on each day then this is not treated as a discrepancy. This is true despite the fact that the relationships may have different effective from and to dates.
data received from one (either PRS or Data Collector) and no data received from the other is not treated as a discrepancy.

Data Collector Appointments for the specified Data Collector, for which there is also a Registration to the specified Supplier (according to the Data Collector), for which the data supplied by PRS and the Data Collector do not match, that is:

Supplier registered to Metering System (according to the Data Collector);
Some other Supplier registered to Metering System (according to PRS);
Data Aggregator appointed to the Registration (according to PRS);
Data Collector appointed to the Registration of the Metering System (according to PRS);

and the following is true:

EACs or AAs have been received from the Data Collector appointed to the Registration of the Metering System (according to PRS) within the exception period.

The system will also report the total number of Metering Systems failing each check and the total number of Metering Systems failing one or more checks.

The system will extract and store summarised details of exceptions in DC data which the NHHDA User can use for monthly performance reporting. The data to be stored will include:

Supplier ID;
Data Collector ID;
From Settlement Date;
To Settlement Date;
Count of Metering Systems with at least one exception for each exception type; and
Count of Metering Systems with at least one exception.

6.4 I/O Descriptions

Data Flow Name	From	To	Comments	Data Items
Average Fraction of Yearly Consumption	External entity r NHH Data Aggregator User	Process 4.5.4 Specify Average Fraction of Yearly Consumption	The average fraction of consumption for each Measurement Requirement in a particular combination of Profile Class and Standard Settlement Configuration.	Average Fraction of Yearly Consumption, Effective From Settlement Date {AFYC}, Effective To Settlement Date {AFYC}, GSP Group Id, Profile Class Id, Standard Settlement Configuration Id, Time Pattern Regime Id
Data Collector Details	External entity r NHH Data Aggregator User	Process 4.3 Maintain Data Collector	Details of Data Collectors.	Data Collector Id, Data Collector Name
Data Collector Exception Report	Process 6 Report on Exceptions in DC Data	External entity r NHH Data Aggregator User External entity j Supplier	Report showing, for a Data Collector, those Metering Systems for which there are inconsistencies in the data received from PRS and the Data Collector.	Data Collector Id, Data Collector Name, Effective From Settlement Date {MCR}, Effective From Settlement Date {MSGGDC}, Effective From Settlement Date {MSGG}, Effective From Settlement Date {MSMCDC}, Effective From Settlement Date {MSPCDC}, Effective From Settlement Date {PCR}, Effective From Settlement Date {RDC}, Effective From Settlement Date {REGI}, Effective From Settlement Date {SCDC}, Effective From Settlement Date {SCR}, GSP Group Id, Measurement Class Id, Metering System Id, Supplier Id, Exception Type, Number of Metering Systems failing one or more checks, PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id
Data Collector Exception Summary	Process 6 Report on Exceptions in DC Data	External entity r NHH Data Aggregator User	Report showing a summary of the ‘Data Collector Exception Report’ data flow. To be used for monthly performance reporting.	Data Collector Id, Supplier Id, Exception Type. Number of Metering Systems failing one or more checks
Demand Control Event	External entity Distribution Business	Process 2.10 Receive Demand Control Event	Details of Metering Systems subjected to a Demand Control Event	Demand Control Event Id, Start Date and Time, End Date and Time, Profile Class, Affected MSID(s)
Disconnection Purchase Matrix Data	Process 5 Send Supplier Purchase Matrices	External entity k ISR Agent	An extract for one GSP Group and Settlement (including reconciliation). Each extract contains aggregated totals for estimated annual consumptions and annualised advances for the GSP Group at Supplier, Profile Class, Line Loss Factor Class and Measurement Requirement level and is sent to the ISR Agent who is appointed to the GSP Group.	Data Aggregation Run Number, Data Aggregator Id, Distributor Id, GSP Group Id, Line Loss Factor Class Id, Profile Class Id, DPM Default EAC MSID Count, DPM Default Unmetered MSID Count, DPM Total AA MSID Count, DPM Total Annualised Advance, DPM Total EAC, DPM Total EAC MSID Count, DPM Total Unmetered Consumption, DPM Total Unmetered MSID Count, Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id, Time Pattern Regime Id
Distributor Details	External entity r NHH Data Aggregator User	Process 4.6 Maintain Distributor	Details of Distributors and PRS Agents appointed to the Distribution Business.	Distributor Id, Distributor Name, Distributor Short Code, Effective From Date {PAA}, Effective To Date {PAA}, PRS Agent Id
GSP Group Details and Appointments	External entity r NHH Data Aggregator User	Process 4.7 Maintain GSP Group	Details of GSP Groups including, for each one, the ISR Agent and the Distributor of the Distribution network in which it resides	Distributor Id, Effective From Date {IAA}, Effective From Settlement Date {GGD}, Effective To Date {IAA}, Effective To Settlement Date {GGD}, GSP Group Id, GSP Group Name, ISR Agent Id
ISR Agent Details	External entity r NHH Data Aggregator User	Process 4.4 Maintain ISR Agent	Details of ISR Agents.	ISR Agent Id, ISR Agent Name
Line Loss Factor Class Details	External entity r NHH Data Aggregator User	Process 4.8 Maintain Line Loss Classes	Details of Line Loss Factor Classes determined by Distributors and distributed by the Market Domain Data Agent.	Distributor Id, Line Loss Factor Class Description, Line Loss Factor Class Id
Market Domain Data Complete Set	External entity c Market Domain Data Agent	Process 4.11.1 Load Market Domain Data Complete Set	Published Market Domain Data	Average Fraction of Yearly Consumption, Data Collector Id, Data Collector Name, Distributor Id, Distributor Name, Distributor Short Code, Effective From Date {IAA}, Effective From Date {PAA}, Effective From Settlement Date {AFOYCS}, Effective From Settlement Date {GGD}, Effective From Settlement Date {TPAR}, Effective To Date {IAA}, Effective To Date {PAA}, Effective To Settlement Date {AFOYCS}, Effective To Settlement Date {GGD}, GSP Group Id, GSP Group Name, ISR Agent Id, ISR Agent Name, Line Loss Factor Class Description, Line Loss Factor Class Id, Profile Class Description, Profile Class Id, PRS Agent Id, PRS Agent Name, Standard Settlement Configuration Desc, Standard Settlement Configuration Id, Supplier Id, Supplier Name, Threshold Parameter, Time Pattern Regime Id
Metering System EAC/AA Data	External entity b NHH Data Collector	Process 1 Receive EAC/AA Data	A file of EAC and AA data calculated by the Data Collector. For each Metering System in the file there will be an EAC for each Settlement Register; an AA for each Settlement Register (optional); and other data held by the Data Collector for the Metering System, including a history of its GSP Groups and Profile Classes over the meter advance period.	Annualised Advance, Data Aggregator Id, Data Collector Id, Effective From Settlement Date {EACDC}, Effective From Settlement Date {MACDC}, Effective From Settlement Date {MSESDC}, Effective From Settlement Date {MSGGDC}, Effective From Settlement Date {MSMCDC}, Effective From Settlement Date {MSPCDC}, Effective From Settlement Date {RDC}, Effective From Settlement Date {SCDC}, Effective To Settlement Date {MACDC}, Energisation Status, Estimated Annual Consumption, GSP Group Id, Measurement Class Id, Metering System Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id, Time Pattern Regime Id
Profile Class Assignments	External entity r NHH Data Aggregator User	Process 4.5.3 Assign Configurations to Profile Classes	Details of which Standard Settlement Configurations are permitted for a Profile Class.	Profile Class Id, Standard Settlement Configuration Id
Profile Class Details Including Default EACs	External entity r NHH Data Aggregator User	Process 4.1 Maintain Profile Class	Details of Profile Classes including the default EACs determined by Distributors and distributed by the Market Domain Data Agent.	Effective From Settlement Date {GGPCDE}, GSP Group Id, Profile Class Description, Profile Class Id, Researched Default EAC
PRS Agent Details	External entity r NHH Data Aggregator User	Process 4.9 Maintain PRS Agent	Details of PRS Agents.	PRS Agent Id, PRS Agent Name
PRS Data Aggregator Appointment Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.2 Process Data Aggregator Appointment Details	A notification informing a NHH Data Aggregator of their appointment to a Metering System, containing Registration data relevant to the appointment. This includes changes of data over the course of the appointment.	Data Aggregator Id, Data Collector Id, Distributor Id, Effective From Settlement Date {DAA}, Effective From Date {DCA}, Effective From Settlement Date {ESR}, Effective From Settlement Date {MCR}, Effective From Settlement Date {MSGG}, Effective From Settlement Date {MSLLFC}, Effective From Settlement Date {PCR}, Effective From Settlement Date {REGI}, Effective From Settlement Date {SCR}, Effective To Settlement Date {DAA}, Energisation Status, GSP Group Id, Line Loss Factor Class Id, Measurement Class Id, Metering System Id, PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id
PRS Data Collector Appointment Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.4 Process Data Collector Appointment Details	A notification informing a NHH Data Aggregator of a change of Data Collector for a Metering System. The Instruction will also include details of any subsequent changes of Data Collector for that Metering System.	Data Aggregator Id, Data Collector Id, Effective From Date {DCA}, Effective From Settlement Date {REGI}, Metering System Id, PRS Agent Id
PRS Energisation Status Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.6 Process Energisation Status Details	A notification informing a NHH Data Aggregator of a change of Energisation Status for a Metering System. The Instruction will also include details of any subsequent changes of Energisation Status for that Metering System.	Data Aggregator Id, Effective From Settlement Date {ESR}, Effective From Settlement Date {REGI}, Energisation Status, Metering System Id, PRS Agent Id
PRS GSP Group Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.7 Process GSP Group Details	A notification informing a NHH Data Aggregator of a change of GSP Group for a Metering System. The Instruction will also include details of any subsequent changes of GSP Group for that Metering System.	Data Aggregator Id, Effective From Settlement Date {MSGG}, GSP Group Id, Metering System Id, PRS Agent Id
PRS Line Loss Factor Class Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.8 Process Line Loss Factor Class Details	A notification informing a NHH Data Aggregator of a change of Line Loss Factor Class for a Metering System. The Instruction will also include details of any subsequent changes of Line Loss Factor Class for that Metering System.	Data Aggregator Id, Distributor Id, Effective From Settlement Date {MSLLFC}, Line Loss Factor Class Id, Metering System Id, PRS Agent Id
PRS Measurement Class Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.5 Process Measurement Class Details	A notification informing a NHH Data Aggregator of a change of Measurement Class for a Metering System. The Instruction will also include details of any subsequent changes of Measurement Class for that Metering System.	Data Aggregator Id, Effective From Settlement Date {MCR}, Effective From Settlement Date {REGI}, Measurement Class Id, Metering System Id, PRS Agent Id
PRS Profile Class and/or SSC Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.3 Process Profile Class/SSC Details	A notification informing a NHH Data Aggregator of a change of Profile Class and/or Standard Settlement Configuration for a Metering System. The Instruction will also include details of any subsequent changes of Profile Class and/or Standard Settlement Configuration for that Metering System.	Data Aggregator Id, Effective From Settlement Date {PCR}, Effective From Settlement Date {REGI}, Effective From Settlement Date {SCR}, Metering System Id, PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id
PRS Refresh Metering System's Details	External entity q PRS Agent (via Process 2.1 Receive Registration Details)	Process 2.9 Refresh PRS Metering Systems Details	A complete refresh of all data for each Metering System within a Distribution Business. This data will be used to detect and correct any inconsistencies which may have arisen between the databases of the PRS and the NHHDA.	Data Aggregator Id, Data Collector Id, Distributor Id, Effective From Settlement Date {DAA}, Effective From Date {DCA}, Effective From Settlement Date {ESR}, Effective From Settlement Date {MCR}, Effective From Settlement Date {MSGG}, Effective From Settlement Date {MSLLFC}, Effective From Settlement Date {PCR}, Effective From Settlement Date {REGI}, Effective From Settlement Date {SCR}, Effective To Settlement Date {DAA}, Energisation Status, GSP Group Id, Line Loss Factor Class Id, Measurement Class Id, Metering System Id, PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id
Request to Report on Exceptions	External entity r NHH Data Aggregator User	Process 6 Report on Exceptions in DC Data	A request from the NHH Data Aggregator to produce a report showing differences between the data supplied by a given Data Collector, and that received from the PES Registration Service.	Data Collector Id, Effective From Settlement Date {Exception Report}, Effective To Settlement Date {Exception Report}, PRS Agent Id, Supplier Id
Request to Send SPM	External entity r NHH Data Aggregator User	Process 5 Send Supplier Purchase Matrices	A request for Supplier Purchase Matrices aggregated during a Data Aggregation Run to be sent to ISR Agents.	Data Aggregation Run Number
Settlement Run Schedule	External entity r NHH Data Aggregator User	Process 3.1 Prepare Data Aggregation Run Schedule	The Settlement Schedule, defining what Data Aggregation Runs are to be performed, for which GSP Groups, and at what times.	Data Aggregation Run Date, Data Aggregation Run Time, GSP Group Id, Settlement Code, Settlement Date
Settlement Timetable	External entity c Market Domain Data Agent	Process 4.11.2 Load Settlement Timetable	The published schedule of settlement activity proposing when Data Aggregation Runs might be performed. Used for planning the schedule of aggregation runs.	ISR Notification Deadline Date, Planned Data Aggregation Run Date, Settlement Code, Settlement Date
Standard Settlement Configuration Details	External entity r NHH Data Aggregator User	Process 4.5.2 Enter Standard Settlement Configurations	Details of Standard Settlement Configurations including their Measurement Requirements.	Standard Settlement Configuration Desc, Standard Settlement Configuration Id, Time Pattern Regime Id
Supplier Details	External entity r NHH Data Aggregator User	Process 4.2 Maintain Supplier	Details of licensed Suppliers.	Supplier Id, Supplier Name
Supplier Purchase Matrix Data	Process 5 Send Supplier Purchase Matrices	External entity k ISR Agent	An extract for one GSP Group and Settlement (including reconciliation). Each extract contains aggregated totals for estimated annual consumptions and annualised advances for the GSP Group at Supplier, Profile Class, Line Loss Factor Class and Measurement Requirement level and is sent to the ISR Agent who is appointed to the GSP Group.	Data Aggregation Run Number, Data Aggregator Id, Distributor Id, GSP Group Id, Line Loss Factor Class Id, Profile Class Id, SPM Default EAC MSID Count, SPM Default Unmetered MSID Count, SPM Total AA MSID Count, SPM Total Annualised Advance, SPM Total EAC, SPM Total EAC MSID Count, SPM Total Unmetered Consumption, SPM Total Unmetered MSID Count, Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id, Time Pattern Regime Id
Supplier’s SPM	Process 5 Send Supplier Purchase Matrices	External entity j Supplier	An extract for one Supplier for one GSP Group from a single settlement or reconciliation run. Each extract contains aggregated totals for estimated annual consumptions and annualised advances for the GSP Group at Supplier, Profile Class, Line Loss Factor Class and Measurement Requirement level and is sent to the Supplier.	Data Aggregation Run Number, Data Aggregator Id, Distributor Id, GSP Group Id, Line Loss Factor Class Id, Profile Class Id, SPM Default EAC MSID Count, SPM Default Unmetered MSID Count, SPM Total AA MSID Count, SPM Total Annualised Advance, SPM Total EAC, SPM Total EAC MSID Count, SPM Total Unmetered Consumption, SPM Total Unmetered MSID Count, Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id, Time Pattern Regime Id
Threshold Parameter	External entity r NHH Data Aggregator User	Process 4.10 Maintain Threshold Parameter	The Threshold Parameter is a system-wide parameter specifying the minimum number of Metering Systems required in a given cell of the Supplier Purchase Matrix before their average EAC/AA will be used as a default for Metering Systems without EAC/AA data.	Threshold Parameter, Effective From Settlement Date {TPAR}

Data Flow Name

From

Comments

Data Items

Average Fraction of Yearly Consumption

External entity r

NHH Data Aggregator User

Process 4.5.4

Specify Average Fraction of Yearly Consumption

The average fraction of consumption for each Measurement Requirement in a particular combination of Profile Class and Standard Settlement Configuration.

Average Fraction of Yearly Consumption, Effective From Settlement Date {AFYC}, Effective To Settlement Date {AFYC},

GSP Group Id, Profile Class Id, Standard Settlement Configuration Id, Time Pattern Regime Id

Data Collector Details

External entity r

NHH Data Aggregator User

Process 4.3

Maintain Data Collector

Details of Data Collectors.

Data Collector Id, Data Collector Name

Data Collector Exception Report

Process 6

Report on Exceptions in DC Data

External entity r

NHH Data Aggregator User

External entity j

Supplier

Report showing, for a Data Collector, those Metering Systems for which there are inconsistencies in the data received from PRS and the Data Collector.

Data Collector Id, Data Collector Name,

Effective From Settlement Date {MCR},

Effective From Settlement Date {MSGGDC}, Effective From Settlement Date {MSGG},

Effective From Settlement Date {MSMCDC},

Effective From Settlement Date {MSPCDC}, Effective From Settlement Date {PCR},

Effective From Settlement Date {RDC},

Effective From Settlement Date {REGI},

Effective From Settlement Date {SCDC},

Effective From Settlement Date {SCR},

GSP Group Id, Measurement Class Id,

Metering System Id, Supplier Id,

Exception Type, Number of Metering Systems failing one or more checks,

PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id

Data Collector Exception Summary

Process 6

Report on Exceptions in DC Data

External entity r

NHH Data Aggregator User

Report showing a summary of the ‘Data Collector Exception Report’ data flow. To be used for monthly performance reporting.

Data Collector Id, Supplier Id,

Exception Type.

Number of Metering Systems failing one or more checks

Demand Control Event

External entity Distribution Business

Process 2.10 Receive Demand Control Event

Details of Metering Systems subjected to a Demand Control Event

Demand Control Event Id,

Start Date and Time,

End Date and Time,

Profile Class,

Affected MSID(s)

Disconnection Purchase Matrix Data

Process 5

Send Supplier Purchase Matrices

External entity k

ISR Agent

An extract for one GSP Group and Settlement (including reconciliation).

Each extract contains aggregated totals for estimated annual consumptions and annualised advances for the GSP Group at Supplier, Profile Class, Line Loss Factor Class and Measurement Requirement level and is sent to the ISR Agent who is appointed to the GSP Group.

Data Aggregation Run Number,

Data Aggregator Id,

Distributor Id,

GSP Group Id, Line Loss Factor Class Id,

Profile Class Id, DPM Default EAC MSID Count,

DPM Default Unmetered MSID Count,

DPM Total AA MSID Count,

DPM Total Annualised Advance,

DPM Total EAC, DPM Total EAC MSID Count,

DPM Total Unmetered Consumption, DPM Total Unmetered MSID Count,

Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id,

Time Pattern Regime Id

Distributor Details

External entity r

NHH Data Aggregator User

Process 4.6

Maintain Distributor

Details of Distributors and PRS Agents appointed to the Distribution Business.

Distributor Id, Distributor Name,

Distributor Short Code,

Effective From Date {PAA},

Effective To Date {PAA},

PRS Agent Id

GSP Group Details and Appointments

External entity r

NHH Data Aggregator User

Process 4.7

Maintain GSP Group

Details of GSP Groups including, for each one, the ISR Agent and the Distributor of the Distribution network in which it resides

Distributor Id, Effective From Date {IAA}, Effective From Settlement Date {GGD},

Effective To Date {IAA},

Effective To Settlement Date {GGD},

GSP Group Id, GSP Group Name, ISR Agent Id

ISR Agent Details

External entity r

NHH Data Aggregator User

Process 4.4

Maintain ISR Agent

Details of ISR Agents.

ISR Agent Id,

ISR Agent Name

Line Loss Factor Class Details

External entity r

NHH Data Aggregator User

Process 4.8

Maintain Line Loss Classes

Details of Line Loss Factor Classes determined by Distributors and distributed by the Market Domain Data Agent.

Distributor Id,

Line Loss Factor Class Description, Line Loss Factor Class Id

Market Domain Data Complete Set

External entity c

Market Domain Data Agent

Process 4.11.1

Load Market Domain Data Complete Set

Published Market Domain Data

Average Fraction of Yearly Consumption, Data Collector Id, Data Collector Name, Distributor Id, Distributor Name, Distributor Short Code, Effective From Date {IAA}, Effective From Date {PAA}, Effective From Settlement Date {AFOYCS}, Effective From Settlement Date {GGD}, Effective From Settlement Date {TPAR}, Effective To Date {IAA}, Effective To Date {PAA}, Effective To Settlement Date {AFOYCS}, Effective To Settlement Date {GGD}, GSP Group Id, GSP Group Name, ISR Agent Id, ISR Agent Name, Line Loss Factor Class Description, Line Loss Factor Class Id, Profile Class Description, Profile Class Id, PRS Agent Id, PRS Agent Name, Standard Settlement Configuration Desc, Standard Settlement Configuration Id, Supplier Id, Supplier Name, Threshold Parameter, Time Pattern Regime Id

Metering System EAC/AA Data

External entity b

NHH Data Collector

Process 1

Receive EAC/AA Data

A file of EAC and AA data calculated by the Data Collector. For each Metering System in the file there will be an EAC for each Settlement Register; an AA for each Settlement Register (optional); and other data held by the Data Collector for the Metering System, including a history of its GSP Groups and Profile Classes over the meter advance period.

Annualised Advance,

Data Aggregator Id,

Data Collector Id, Effective From Settlement Date {EACDC}, Effective From Settlement Date {MACDC},

Effective From Settlement Date {MSESDC}, Effective From Settlement Date {MSGGDC}, Effective From Settlement Date {MSMCDC}, Effective From Settlement Date {MSPCDC}, Effective From Settlement Date {RDC},

Effective From Settlement Date {SCDC},

Effective To Settlement Date {MACDC}, Energisation Status,

Estimated Annual Consumption,

GSP Group Id, Measurement Class Id,

Metering System Id,

Profile Class Id, Standard Settlement Configuration Id, Supplier Id,

Time Pattern Regime Id

Profile Class Assignments

External entity r

NHH Data Aggregator User

Process 4.5.3

Assign Configurations to Profile Classes

Details of which Standard Settlement Configurations are permitted for a Profile Class.

Profile Class Id, Standard Settlement Configuration Id

Profile Class Details Including Default EACs

External entity r

NHH Data Aggregator User

Process 4.1

Maintain Profile Class

Details of Profile Classes including the default EACs determined by Distributors and distributed by the Market Domain Data Agent.

Effective From Settlement Date {GGPCDE},

GSP Group Id, Profile Class Description,

Profile Class Id, Researched Default EAC

PRS Agent Details

External entity r

NHH Data Aggregator User

Process 4.9

Maintain PRS Agent

Details of PRS Agents.

PRS Agent Id,

PRS Agent Name

PRS Data Aggregator Appointment Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.2

Process Data Aggregator Appointment Details

A notification informing a NHH Data Aggregator of their appointment to a Metering System, containing Registration data relevant to the appointment. This includes changes of data over the course of the appointment.

Data Aggregator Id,

Data Collector Id, Distributor Id, Effective From Settlement Date {DAA},

Effective From Date {DCA}, Effective From Settlement Date {ESR},

Effective From Settlement Date {MCR},

Effective From Settlement Date {MSGG},

Effective From Settlement Date {MSLLFC},

Effective From Settlement Date {PCR},

Effective From Settlement Date {REGI},

Effective From Settlement Date {SCR},

Effective To Settlement Date {DAA}, Energisation Status,

GSP Group Id, Line Loss Factor Class Id, Measurement Class Id,

Metering System Id,

PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id

PRS Data Collector Appointment Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.4

Process Data Collector Appointment Details

A notification informing a NHH Data Aggregator of a change of Data Collector for a Metering System. The Instruction will also include details of any subsequent changes of Data Collector for that Metering System.

Data Aggregator Id,

Data Collector Id, Effective From Date {DCA}, Effective From Settlement Date {REGI},

Metering System Id,

PRS Agent Id

PRS Energisation Status Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.6

Process Energisation Status Details

A notification informing a NHH Data Aggregator of a change of Energisation Status for a Metering System. The Instruction will also include details of any subsequent changes of Energisation Status for that Metering System.

Data Aggregator Id,

Effective From Settlement Date {ESR},

Effective From Settlement Date {REGI}, Energisation Status,

Metering System Id,

PRS Agent Id

PRS GSP Group Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.7

Process GSP Group Details

A notification informing a NHH Data Aggregator of a change of GSP Group for a Metering System. The Instruction will also include details of any subsequent changes of GSP Group for that Metering System.

Data Aggregator Id,

Effective From Settlement Date {MSGG},

GSP Group Id, Metering System Id,

PRS Agent Id

PRS Line Loss Factor Class Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.8

Process Line Loss Factor Class Details

A notification informing a NHH Data Aggregator of a change of Line Loss Factor Class for a Metering System. The Instruction will also include details of any subsequent changes of Line Loss Factor Class for that Metering System.

Data Aggregator Id,

Distributor Id, Effective From Settlement Date {MSLLFC},

Line Loss Factor Class Id,

Metering System Id,

PRS Agent Id

PRS Measurement Class Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.5

Process Measurement Class Details

A notification informing a NHH Data Aggregator of a change of Measurement Class for a Metering System. The Instruction will also include details of any subsequent changes of Measurement Class for that Metering System.

Data Aggregator Id,

Effective From Settlement Date {MCR},

Effective From Settlement Date {REGI}, Measurement Class Id,

Metering System Id,

PRS Agent Id

PRS Profile Class and/or SSC Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.3

Process Profile Class/SSC Details

A notification informing a NHH Data Aggregator of a change of Profile Class and/or Standard Settlement Configuration for a Metering System. The Instruction will also include details of any subsequent changes of Profile Class and/or Standard Settlement Configuration for that Metering System.

Data Aggregator Id,

Effective From Settlement Date {PCR},

Effective From Settlement Date {REGI},

Effective From Settlement Date {SCR},

Metering System Id,

PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id

PRS Refresh Metering System's Details

External entity q

PRS Agent

(via Process 2.1 Receive Registration Details)

Process 2.9

Refresh PRS Metering Systems Details

A complete refresh of all data for each Metering System within a Distribution Business. This data will be used to detect and correct any inconsistencies which may have arisen between the databases of the PRS and the NHHDA.

Data Aggregator Id,

Data Collector Id, Distributor Id, Effective From Settlement Date {DAA},

Effective From Date {DCA}, Effective From Settlement Date {ESR},

Effective From Settlement Date {MCR},

Effective From Settlement Date {MSGG},

Effective From Settlement Date {MSLLFC},

Effective From Settlement Date {PCR},

Effective From Settlement Date {REGI},

Effective From Settlement Date {SCR},

Effective To Settlement Date {DAA},

Energisation Status,

GSP Group Id,

Line Loss Factor Class Id, Measurement Class Id,

Metering System Id,

PRS Agent Id, Profile Class Id, Standard Settlement Configuration Id, Supplier Id

Request to Report on Exceptions

External entity r

NHH Data Aggregator User

Process 6

Report on Exceptions in DC Data

A request from the NHH Data Aggregator to produce a report showing differences between the data supplied by a given Data Collector, and that received from the PES Registration Service.

Data Collector Id, Effective From Settlement Date {Exception Report},

Effective To Settlement Date {Exception Report},

PRS Agent Id, Supplier Id

Request to Send SPM

External entity r

NHH Data Aggregator User

Process 5

Send Supplier Purchase Matrices

A request for Supplier Purchase Matrices aggregated during a Data Aggregation Run to be sent to ISR Agents.

Data Aggregation Run Number

Settlement Run Schedule

External entity r

NHH Data Aggregator User

Process 3.1

Prepare Data Aggregation Run Schedule

The Settlement Schedule, defining what Data Aggregation Runs are to be performed, for which GSP Groups, and at what times.

Data Aggregation Run Date,

Data Aggregation Run Time,

GSP Group Id, Settlement Code, Settlement Date

Settlement Timetable

External entity c

Market Domain Data Agent

Process 4.11.2

Load Settlement Timetable

The published schedule of settlement activity proposing when Data Aggregation Runs might be performed. Used for planning the schedule of aggregation runs.

ISR Notification Deadline Date, Planned Data Aggregation Run Date, Settlement Code, Settlement Date

Standard Settlement Configuration Details

External entity r

NHH Data Aggregator User

Process 4.5.2

Enter Standard Settlement Configurations

Details of Standard Settlement Configurations including their Measurement Requirements.

Standard Settlement Configuration Desc, Standard Settlement Configuration Id, Time Pattern Regime Id

Supplier Details

External entity r

NHH Data Aggregator User

Process 4.2

Maintain Supplier

Details of licensed Suppliers.

Supplier Id, Supplier Name

Supplier Purchase Matrix Data

Process 5

Send Supplier Purchase Matrices

External entity k

ISR Agent

An extract for one GSP Group and Settlement (including reconciliation).

Data Aggregation Run Number,

Data Aggregator Id,

Distributor Id,

GSP Group Id, Line Loss Factor Class Id,

Profile Class Id, SPM Default EAC MSID Count,

SPM Default Unmetered MSID Count,

SPM Total AA MSID Count,

SPM Total Annualised Advance,

SPM Total EAC, SPM Total EAC MSID Count,

SPM Total Unmetered Consumption, SPM Total Unmetered MSID Count,

Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id,

Time Pattern Regime Id

Supplier’s SPM

Process 5

Send Supplier Purchase Matrices

External entity j

Supplier

An extract for one Supplier for one GSP Group from a single settlement or reconciliation run.

Data Aggregation Run Number,

Data Aggregator Id,

Distributor Id,

GSP Group Id, Line Loss Factor Class Id,

Profile Class Id, SPM Default EAC MSID Count,

SPM Default Unmetered MSID Count,

SPM Total AA MSID Count,

SPM Total Annualised Advance,

SPM Total EAC, SPM Total EAC MSID Count,

SPM Total Unmetered Consumption, SPM Total Unmetered MSID Count,

Settlement Code, Settlement Date, Standard Settlement Configuration Id, Supplier Id,

Time Pattern Regime Id

Threshold Parameter

External entity r

NHH Data Aggregator User

Process 4.10

Maintain Threshold Parameter

The Threshold Parameter is a system-wide parameter specifying the minimum number of Metering Systems required in a given cell of the Supplier Purchase Matrix before their average EAC/AA will be used as a default for Metering Systems without EAC/AA data.

Threshold Parameter, Effective From Settlement Date {TPAR}

Note that certain flows which cross the system boundary are not included in the table above, because they summarise a number of flows on a lower level DFD:

Summarising Flow	Constituent Flows
Metering System (NHH) Registered Data	PRS Data Collector Appointment Details, PRS Energisation Status Details, PRS GSP Group Details, PRS Line Loss Factor Class Details, PRS Measurement Class Details, PRS Profile Class and/or SSC Details, PRS Data Aggregator Appointment Details, PRS Refresh Metering System Details
Market Domain Data	Data Collector Details, Distributor Details, GSP Group Details and Appointments, ISR Agent Details, Line Loss Factor Class Details, Profile Class Details including Default EACs, PRS Agent Details, Settlement Timetable, Standard Settlement Configs (Manually Entered), Supplier Details, Threshold Parameter
Standard Settlement Configs (Manually Entered)	Average Fraction of Yearly Consumption, Profile Class Assignments, Standard Settlement Configuration Details

6.5 External Entity Descriptions

ID	Ext. Entity	Description
b	NHH Data Collector	A Non-Half Hourly Data Collector is an organisation Qualified by the Panel and appointed by Suppliers to collect and process meter readings and to calculate Estimated Annual Consumptions and Annualised Advances.
c	Market Domain Data Agent	The Market Domain Data Agent provides a central point of co-ordination across the 1998 Trading Arrangements. It is responsible for the maintenance and distribution of Market Domain Data.
j	Supplier	A supplier of electricity.
k	ISR Agent	An Initial Settlement and Reconciliation (ISR) Agent is an agent of the Pool. They are appointed to administer Initial Settlement and Reconciliation for one or more GSP Groups.
q	PRS Agent	A PES Registration Service (PRS) Agent is an agent of the Pool. They are appointed to provide a Registration service for Metering Systems in one or more GSP Groups.
r	NHH Data Aggregator User	A Non-Half Hourly Data Aggregator is an organisation Qualified by the Panel and appointed by Suppliers to aggregate Estimated Annual Consumptions and Annualised Advances by Supplier and Settlement Class.

6.6 Data Store/Entity Cross Reference

ID	Data Store	Description	Entities
D1	Registration	This datastore contains data about the Registration of Metering Systems, including who the Supplier and Data Collector are.	Data Aggregator, Data Aggregator Appointment, Data Collector, Data Collector Appointment, Registration, Registration (DC), Supplier
D2	Consumption	This datastore contains the Estimated annual Consumptions and Annualised Advances for Metering Systems.	Estimated Annual Consumption (DC), Meter Advance Consumption (DC), Settlement Register (DC)
D3	Metering System	This datastore contains data about Metering Systems including their many time based relationships.	Line Loss Factor Class, Measurement Class, Metering System, Energisation Status in Registration, Metering System Energisation Status (DC), Metering System GSP Group, Metering System GSP Group (DC), Metering System Line Loss Factor Class, Measurement Class in Registration, Metering System Measurement Class (DC), Profile Class in Registration, Metering System Profile Class (DC), Settlement Configuration in Registration, Settlement Configuration (DC)
D4	Aggregation	This datastore contains data about data aggregation including Aggregation Runs and the calculated results.	Data Aggregation Run, GSP Group in Aggregation Run, GSP Group in Settlement, Settlement, Settlement Day, Supplier Purchase Matrix
D5	Settlement Configuration	This datastore contains data about Standard Settlement Configurations including the set of valid Settlement Configuration / Profile Class combinations.	Average Fraction of Yearly Consumption, GSP Group Profile Class Default EAC, Measurement Requirement, Profile Class, Standard Settlement Configuration, Time Pattern Regime, Valid Measurement Requirement Profile Class, Valid Settlement Configuration Profile Class
D6	GSP Group	This datastore contains data about GSP Groups and Distribution Businesses including Distributors, ISR Agents and PRS Agents.	Distributor, GSP Group, GSP Group Distributor, ISR Agent, ISR Agent Appointment, PRS Agent, PRS Agent Appointment
D7	Threshold Parameter	This datastore contains the Threshold Parameter. This is a system-wide parameter specifying the minimum number of Metering Systems required in a given cell of the Supplier Purchase Matrix before their average EAC/AA will be used as a default for Metering Systems without EAC/AA data.	Threshold Parameter
D2/1	Registration Instructions	This datastore represents the different repository areas for instruction files and status changes for instructions at various stages of instruction processing.	None (this is a working storage area).

6.7 Cross Reference To Trading and Settlement Processes

The high-level processes in the Trading and Settlement Process Model in Appendix A of the Operational Framework (reference 1) map directly to the Data Flow Diagrams (DFDs) for Non Half Hourly Data Aggregation (NHHDA). The table below summarises the mapping, and identifies the high-level processes and datastores in the Trading and Settlement Process Model which appear as external entities in the NHHDA DFDs :

Trading and Settlement Process Model		NHHDA Level 1 DFD Mapping
Process Number	Process Name	Name	Type
4, also datastore D2	Calculate EAC / AA from Meter Advance and old EAC	NHH Data Collector	External Entity
5	Aggregate non-hh data	Process 1 - Receive EAC/AA Data Process 2 - Receive Registration Updates Process 3 - Aggregate Annualised Consumption Data Process 5 - Send Supplier Purchase Matrices	Process
		NHH Data Aggregator User	External Entity
11, also datastore D3	Host PES Registration System	PRS Agent	External Entity

Note that other NHHDA processes and data flows are in support of the above core processes and as such are not explicitly included on the Trading and Settlement Process Model. In particular, the Trading and Settlement Process Model does not include the following flows of data to or from external entities outside the Non-Half Hourly Data Aggregator organisation:

Flow Name	From	To	Content of Flow
Market Domain Data	Market Domain Data Agent (External Entity)	NHHDA User (External Entity)	Market Domain Data (e.g. list of valid Data Collectors, list of valid Line Loss Factor Classes) for validating data received from PRS and Data Collectors. GSP Group Profile Class Default EACs for use in determining default EACs.
Market Domain Data Complete Set	Market Domain Data Agent (External Entity)	Process 4 – Maintain Market Domain Data	Market Domain Data (e.g. list of valid Data Collectors, list of valid Line Loss Factor Classes and so on) for validating data received from PRS and Data Collectors. GSP Group Profile Class Default EACs for use in determining default EACs. Valid combinations of Profile Class and Measurement Requirement for validating data received from PRS and Data Collectors; and values of Average Fraction of Yearly Consumption for use in determining default EACs.
Settlement Timetable	Market Domain Data Agent (External Entity)	Process 4 – Maintain Market Domain Data	The proposed schedule of settlement activity used by the data aggregator, in conjunction with their contractual obligations, to determine when they should carry out aggregation.
Data Collector Exception Report	Process 6 - Report on Exceptions in DC Data	Supplier, NHHDA User (External Entities)	Report of differences between NHH Data Collector and PRS views of Metering System data.

7 LOGICAL DATA MODEL

7.1 Purpose and Scope

1. Logical Data Modelling is a SSADM technique used to build a model of information requirements. The purpose of the technique is to identify and clearly define the data which is of interest to the business and the relationships between this data.

2. The Logical Data Model comprises:

a Logical Data Structure - that is a diagrammatic representation of the data which is of interest to the business;
Entity/Relationship Descriptions - that is a description of the data which is of interest to the business and the nature of the relationships between this data;

3. The model does not:

include entities required solely to support processing - the emphasis is currently very much on business entities. This means, for example that entities to monitor the receipt and sending of interface files are not included;
give any indication of how the data should physically be stored.

4. A brief explanation of Logical Data Structure notation is included in Appendix B. Further information about the SSADM Logical Data Modelling technique may be obtained in the SSADM V4 manuals (reference 3).

7.2 Logical Data Structure

For reasons of clarity, the LDS is split across two diagrams: the Core LDS and the Data Collector LDS. In general:

the Core LDS includes entities that represent Market Domain Data and data provided by the PRS Agents;
the Data Collector LDS includes entities that represent data provided by the Data Collectors.
the Metering System’s relationship to its Distributor (via its LDSO Short Code) is not shown in the diagrams or implemented as an explicit entity relationship.

7.2.1 Core LDS

7.2.2 Data Collector LDS

7.3 Entity Descriptions

p represents primary key,

* represents foreign key.

7.3.1 Average Fraction of Yearly Consumption

Description: A specification of the average fraction of consumption which is attributed to a particular Measurement Requirement, in the context of a particular GSP Group, Standard Settlement Configuration and Profile Class.

Contains Attributes

p * Standard Settlement Configuration Id

p * Profile Class Id

p * Time Pattern Regime Id

p * GSP Group Id

p Effective From Settlement Date {AFYC}

Effective To Settlement Date {AFYC}

Average Fraction of Yearly Consumption

7.3.2 Data Aggregation Run

Description: An aggregation calculation for a Settlement. The aggregation calculation results in Supplier Purchase Matrices for the GSP Groups included in the run.

Contains Attributes

p Data Aggregation Run Number

* Settlement Date

* Settlement Code

Data Aggregation Run Date

Data Aggregation Run Time

7.3.3 Data Aggregator

Description: An organisation that is Qualified by the Panel, and appointed by Suppliers to Metering Systems to perform the Data Aggregation service to the Pool through P&SA obligations on the Supplier.

Contains Attributes

p Data Aggregator Id

* Data Aggregator Id1

Data Aggregator Name

Data Aggregator Type

7.3.4 Data Aggregator Appointment

Description: The Data Aggregator appointed by a Supplier to a Metering System to aggregate the Metering System’s estimates of annual consumptions.

Contains Attributes

p * Metering System Id

p Effective From Settlement Date {DAA}

Effective To Settlement Date {DAA}

* Effective From Settlement Date {REGI}

* Data Aggregator Id

7.3.5 Data Collector

Description: An organisation that is Qualified by the Panel and appointed by Suppliers to one or more Metering Systems to periodically collect and process meter readings and derive estimates of annual consumptions and send the results to Data Aggregators.

Contains Attributes

p Data Collector Id

* Data Collector Id1

* Data Collector Id2

Data Collector Name

7.3.6 Data Collector Appointment

Description: A Supplier’s appointment of a Data Collector for a Registration of a Metering System. The appointment is for provision of data collection services (including collection and processing of meter readings and derivation of estimates of annual consumptions). It is effective from a calendar date and entails provision of these services for settlement of all days in the Supplier’s Registration of the Metering System (until the Supplier appoints a new Data Collector for the same Metering System Registration).

Contains Attributes

p * Metering System Id

p Effective From Date {DCA}

* Effective From Settlement Date {REGI}

* Data Collector Id

7.3.7 Disconnection Supplier Purchase Matrix

Description: The Disconnected Estimated Annual Consumption and Annualised Advance totals for a Supplier, associated with a Demand Control Event, for: a GSP Group, Profile Class, Line Loss Factor Class and Measurement Requirement (collectively known as Settlement Class).

Contains Attributes

p * Data Aggregation Run Number

p * Supplier Id

p * Profile Class Id

p * GSP Group Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

DPM Total EAC

DPM Total EAC MSID Count

DPM Default EAC MSID Count

DPM Total Unmetered Consumption

DPM Total Unmetered MSID Count

DPM Default Unmetered MSID Count

DPM Total Annualised Advance

DPM Total AA MSID Count

7.3.8 Distributor

Description: An organisation that owns and operates a distribution system.

Contains Attributes

p Distributor Id

Distributor Name

Distributor Short Code

7.3.9 Energisation Status in Registration

Description: The energisation status of a Metering System while registered to a Supplier.

Contains Attributes

p * Metering System Id

p * Effective From Settlement Date {REGI}

p Effective From Settlement Date {ESR}

Energisation Status

7.3.10 Estimated Annual Consumption (DC)

Description: A specific Data Collector's view of a Metering System's Settlement Register estimate of annual consumption.

This Estimate of Annual Consumption is usually based on the Settlement Register's meter advance over the Meter Advance Period. The exception to this is upon creation of Metering Systems and upon changes to their Standard Settlement Configuration.

Contains Attributes

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Metering System Id

p * Data Collector Id

p Effective From Settlement Date {EACDC}

Estimated Annual Consumption

7.3.11 GSP Group

Description: A distinct electrical system, consisting of all or part one or more distribution systems (each owned and operated by a Distributor) that are supplied from one or more Grid Supply Points for which total supply into the GSP Group can be determined for each half hour. (OF410)

Contains Attributes

p GSP Group Id

GSP Group Name

7.3.12 GSP Group Distributor

Description: The Distributor’s appointment to a GSP Group.

Contains Attributes

p * GSP Group Id

p Effective From Settlement Date {GGD}

Effective To Settlement Date {GGD}

Description: An agent of the Pool who may administer initial settlement and reconciliation of one or more GSP Groups.

Contains Attributes

p ISR Agent Id

ISR Agent Name

7.3.17 ISR Agent Appointment

Description: The Pool appointment of an ISR Agent to administer initial settlement and reconciliation for a GSP Group.

Contains Attributes

p * GSP Group Id

p Effective From Date {IAA}

Effective To Date {IAA}

* ISR Agent Id

7.3.18 Line Loss Factor Class

Description: A classification of Line Loss Factors, drawn up by a Distributor and distributed via the Market Domain Data Agent, which represents a set of Line Loss Factors and the times for which they are applicable.

Contains Attributes

p * Distributor Id

p Line Loss Factor Class Id

Line Loss Factor Class Description

7.3.19 Measurement Class

Description: A measurement classification of Metering System, which indicates how the consumption is measured. This is a domain which defines the set of valid values for the attribute.

Contains Attributes

p Measurement Class Id

Measurement Class Description

7.3.20 Measurement Class In Registration

Description: The Measurement Class of a Metering System while registered to a Supplier.

Energisation Status

Description: A classification of profile which represents an exclusive category of Customers whose consumption can be reasonably approximated to a common profile for the purpose of attributing an Estimated Annual Consumption or Annualised Advance to individual half hours for Settlement purposes.

Valid initial set is:

domestic, unrestricted

domestic, economy 7

non-domestic, non maximum demand, unrestricted

non-domestic, non maximum demand, economy 7

non-domestic, maximum demand, load factor 0 - 20%

non-domestic, maximum demand, load factor 20 - 30%

non-domestic, maximum demand, load factor 30 - 40%

non-domestic, maximum demand, load factor 40 - 100%

Contains Attributes

p Profile Class Id

Profile Class Description

7.3.31 Profile Class In Registration

Description: The Profile Class to which a Metering System is allocated while registered to a Supplier.

Contains Attributes

p * Metering System Id

p * Effective From Settlement Date {REGI}

p Effective From Settlement Date {PCR}

* Profile Class Id

7.3.32 PRS Agent

Description: The PES Registration Service (PRS) Agent for the Distribution Business. They are appointed to provide a Registration service for Metering Systems in one or more GSP Group.

Contains Attributes

p PRS Agent Id

* PRS Agent Id1

* PRS Agent Id2

PRS Agent Name

7.3.33 PRS Agent Appointment

Description: The appointment of a PRS Agent to provide a Registration service for a Distribution Business.

Contains Attributes

p * Distributor Id

* PRS Agent Id

Description: A day in local time (not GMT) on which electricity is traded and settled.

(Note: entity included only to provide context within this model.)

Contains Attributes

p Settlement Date

7.3.40 Settlement Register (DC)

Description: A Data Collector's view of a Metering System's Settlement Register.

A Settlement Register is a logical register of a Metering System to which consumption is required to be attributed for the purpose of Initial Settlement and Reconciliation. There is one Settlement Register per Measurement Requirement in the Metering System's Standard Settlement Configuration.

Contains Attributes

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Metering System Id

p * Data Collector Id

7.3.41 Standard Settlement Configuration

Description: A standard configuration, supported by Initial Settlement and Reconciliation, comprising a set of Time Pattern Regimes, which together ensure that consumption is being measured without duplication.

Contains Attributes

p Standard Settlement Configuration Id

Standard Settlement Configuration Desc

7.3.42 Supplier

Description: An organisation that may buy energy and supply it to a customer - each supply to a customer being (either physically or logically) measured by a Metering System. Each such supply must be registered with the Pool through the Supplier's Registration of the Metering System.

Contains Attributes

p Supplier Id

Supplier Name

7.3.43 Supplier Purchase Matrix

Description: The Estimated Annual Consumption and Annualised Advance totals for a Supplier for: a GSP Group, Profile Class, Line Loss Factor Class and Measurement Requirement (collectively known as Settlement Class).

Contains Attributes

p * Data Aggregation Run Number

p * Supplier Id

p * Profile Class Id

p * GSP Group Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

SPM Total EAC

SPM Total EAC MSID Count

SPM Default EAC MSID Count

SPM Total Unmetered Consumption

SPM Total Unmetered MSID Count

SPM Default Unmetered MSID Count

SPM Total Annualised Advance

SPM Total AA MSID Count

7.3.44 Disconnection Purchase Matrix

Description: The Disconnected Estimated Annual Consumption and Annualised Advance totals for a Supplier for: a GSP Group, Profile Class, Line Loss Factor Class and Measurement Requirement (collectively known as Settlement Class).

Contains Attributes

p * Data Aggregation Run Number

p * Demand Control Event Id

p * Supplier Id

p * Profile Class Id

p * GSP Group Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

DPM Total EAC

DPM Total EAC MSID Count

DPM Default EAC MSID Count

DPM Total Unmetered Consumption

DPM Total Unmetered MSID Count

DPM Default Unmetered MSID Count

DPM Total Annualised Advance

DPM Total AA MSID Count

7.3.45 Threshold Parameter

Description: EAC values for Metering System Settlement Registers without a valid EAC or AA provided by the appointed Data Collector are determined in one of two ways.

If it is statistically valid to use an average of the valid EACs/AAs that have been provided, this average is used. Otherwise the GSP Group Profile Class Default EAC (pro rated to take into consideration the average fraction of yearly consumption) is used.

The threshold parameter defines the number of valid EACs/ AAs that must have been provided for an average to be statistically valid.

Contains Attributes

p Effective From Settlement Date {TPAR}

Threshold Parameter

7.3.46 Time Pattern Regime

Description: A pattern of time representing the periods in a day when a Meter or Settlement Register is recording consumption. Each Time Pattern Regime is either statically controlled by a pre-defined set of clock intervals, or dynamically controlled through tele-switching.

(Note: entity included only to provide context within this model.)

Contains Attributes

p Time Pattern Regime Id

7.3.47 Valid Measurement Requirement Profile Class

Description: A Measurement Requirement within a Valid Settlement Configuration Profile Class.

Contains Attributes

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Profile Class Id

* Standard Settlement Configuration Id1

7.3.48 Valid Settlement Configuration Profile Class

Description: A rule defining the valid Standard Settlement Configurations for a Profile Class.

Contains Attributes

p * Profile Class Id

p * Standard Settlement Configuration Id

8 FUNCTION DESCRIPTIONS AND EVENTS

Average Fractions of Yearly Consumption updated

Implemented By Process

Specify Average Fraction of Yearly Consumption

8.1.5 Define Data Collectors

Description: This function allows details of Data Collectors to be defined and maintained.

Triggered by Event

Data Collector details deleted

Data Collector details entered

Data Collector details updated

Implemented By Process

Maintain Data Collector

8.1.6 Define Distributors

Description: This function allows details of Distributors to be defined and maintained.

Triggered by Event

Distributor details deleted

Distributor details entered

Distributor details updated

Implemented By Process

Maintain Distributor

8.1.7 Define GSP Groups

Description: This function allows details of GSP Groups, and of which ISR Agents, PRS Agents and Distributors are appointed to them, to be defined and maintained.

Triggered by Event

GSP Group Amended

GSP Group Deleted

GSP Group Entered

ISR Agent appointed to GSP Group

ISR Agent appointment deleted

PRS Agent appointed

PRS Agent appointment deleted

Distributor assignment to a GSP Group

Distributor assignment deleted

Implemented By Process

Maintain GSP Group

8.1.8 Define ISR Agents

Description: This function allows details of ISR Agents to be defined and maintained.

Triggered by Event

ISR Agent details deleted

ISR Agent details entered

ISR Agent details updated

Implemented By Process

Maintain ISR Agent

8.1.9 Define Line Loss Factor Classes

Description: This function allows details of Line Loss Factor Classes to be defined and maintained.

Triggered by Event

Line Loss Factor Class details deleted

Line Loss Factor Class details entered

Line Loss Factor Class details updated

Implemented By Process

Description: This function allows Standard Settlement Configurations to be defined, maintained, and their links to Profile Classes maintained. It also allows the maintenance of the list of Time Pattern Regimes.

Triggered by Event

Standard Sett Config assigned to Profile Class

Standard Settlement Configuration deleted

Standard Settlement Configuration entered

Standard Settlement Configuration updated

Standard Sett Config deassigned From Profile Class

Time Pattern deassigned From Standard Sett Config

Time Pattern assigned to Standard Sett Config

Implemented By Process

Maintain Standard Settlement Configuration

Assign Configurations to Profile Classes

Enter Standard Settlement Configurations

8.1.14 Define Suppliers

Description: This function allows details of Suppliers to be defined and maintained.

Triggered by Event

Supplier details deleted

Supplier details entered

Supplier details updated

Implemented By Process

Maintain Supplier

8.1.15 Define Threshold Parameter

Description: This function allows threshold parameters to be defined and maintained.

Triggered by Event

Threshold Parameter deleted

Threshold Parameter entered

Threshold Parameter updated

Implemented By Process

Maintain Threshold Parameter

8.1.16 Generate Supplier Purchase Matrices

Description: This function generates file(s) of Supplier Purchase Matrix data for a previously-performed Aggregation Run, and sends it to the appropriate ISR Agent(s).

Triggered by Event

** None **

Implemented By Process

Send Supplier Purchase Matrices

8.1.17 Load EAC/AA Data From Data Collector

Description: This function loads a file of EACs, AAs, and associated Metering System data received from a NHH Data Collector.

Triggered by Event

Metering System EAC & AA data received

Implemented By Process

Receive EAC/AA Data

8.1.18 Load Market Domain Data

Description: This function loads a file of containing published market domain data received from the Market Domain Data Agent.

Triggered by Event

Market domain data received

Implemented By Process

Load Market Domain Data Complete Set

Load Settlement Timetable

8.1.19 Load Metering System Data From PRS

Description: This function loads a file of Metering System Instructions received from a PRS Agent.

Triggered by Event

Change of Data Collector received

Change of Energisation Status received

Change of LLF Class received

Change of Profile Class and/or SSC received

Changes to GSP Group assignment received

Changes to Measurement Class received

Periodic refresh from PRS Agent received

Data Aggregation appointment end received

Data Aggregation appointment start received

Implemented By Process

Receive Registration Details

Process GSP Group Details

Process Line Loss Factor Class Details

Process Data Collector Appointment Details

Process Energisation Status Details

Process Measurement Class Details

Process Profile Class/SSC Details

Process Data Aggregator Appointment Details

Refresh PRS Metering System Details

8.1.20 Schedule Aggregation Run

Description: This function allows the scheduling of Aggregation Runs.

Triggered by Event

Data Aggregation run cancelled

Data Aggregation run amended

Data Aggregation run scheduled

Implemented By Process

Prepare Data Aggregation Run Schedule

8.2 Entity Event Matrix

Note: Measurement Class is not updated nor deleted. They are present from inception and are not subsequently changed as any such fundamental change to requirements would significantly change the whole of the definition of requirements defined in this document.

8.3 System Events

Archive Settlement Data

The decision is taken to archive to removable media all Settlement data which is no longer required for Settlement purposes. This will be all data which related to Settlement Days more than two years old.

Average Fractions of Yearly Consumption deleted

A set of Average Fraction of Yearly Consumption values are removed from the system. This event will occur, for example, when the data was entered in error, or when it has not been effective for more than two years and all the related settlement data has been archived off.

Average Fractions of Yearly Consumption entered

A set of Average Fraction of Yearly Consumption values are entered onto the system for a valid combination of Standard Settlement Configuration, Profile Class, and GSP Group.

Average Fractions of Yearly Consumption updated

An existing set of Average Fraction of Yearly Consumption values are updated.

Change of Data Collector received

Changes to the Data Collection appointment details for a Metering System are received from the PRS Agent.

Change of Energisation Status received

Changes to the Energisation Status details for a Metering System are received from the PRS Agent.

Change of LLF Class received

Changes to the Line Loss Factor Class details for a Metering System are received from the PRS Agent.

Change of Profile Class and/or SSC received

Changes to Profile Class and/or the Standard Settlement Configuration details for a Metering System are received from the PRS Agent.

Changes to GSP Group assignment received

Changes to the GSP Group assignment for a Metering System are received from the PRS Agent.

Changes to Measurement Class received

Changes to the Measurement Class details for a Metering System are received from the PRS Agent.

Data Aggregation appointment end received

The Non-Half Hourly Data Aggregator is notified when their appointment for a Metering System will end.

Data Aggregation appointment start received

The Non-Half Hourly Data Aggregator is notified of a new appointment for a Metering System, when it will start, and the Metering System details.

Data Aggregation run cancelled

The operator of the Non-Half Hourly Data Aggregation system cancels a data aggregation run that has not yet taken place.

Data Aggregation run amended

The operator of the Non-Half Hourly Data Aggregation system amends a data aggregation run that has not yet taken place by re-scheduling it and/or changing its set of GSP Groups.

Data Aggregation run scheduled

The operator of the Non-Half Hourly Data Aggregation system schedules a data aggregation run for a particular settlement day and GSP Group.

Data Collector details deleted

A Data Collector is removed from the system. This event will occur, for example, when a Data Collector code is entered in error, or when the Data Collector has stopped collecting readings for all Metering Systems processed by this Non-Half Hourly Data Aggregator for more than two years and the settlement data has been archived.

Data Collector details entered

Details of a new Data Collector are entered onto the system.

Data Collector details updated

Details of an existing Data Collector are updated.

Distributor assignment to a GSP Group

A Distributor is specified for a particular GSP Group.

Distributor assignment deleted

The link between a distributor and a GSP Group is removed from the system.

Distributor details deleted

The details for a Distributor are removed from the system. This may occur if the details were entered in error.

Distributor details entered

Details of a new Distributor are entered onto the system.

Distributor details updated

Details of an existing Distributor are updated.

GSP Group Amended

Details of an existing GSP Group are updated.

GSP Group Deleted

A GSP Group is deleted from the system. This event may occur if GSP Groups are reorganised, or if a GSP Group is entered in error.

GSP Group Entered

A new GSP Group is entered onto the system. This will occur at the start or trading, or if GSP Groups are reorganised.

ISR Agent appointed to GSP Group

An ISR Agent becomes active in a GSP Group from a specified date.

ISR Agent appointment deleted

An ISR Agent ceases to be active in a GSP Group from a specified date.

ISR Agent details deleted

The details for an ISR Agent are deleted from the system. This event will occur, for example, when a ISR Agent code is entered in error, or when the ISR Agent is no longer active.

ISR Agent details entered

Details of a new ISR Agent are entered onto the system.

ISR Agent details updated

Details of an existing ISR Agent are updated.

Line Loss Factor Class details deleted

A Line Loss Factor Class is removed from the system. This will occur when a class was entered in error; or two years after a class has last been used and all the settlement data has been archived.

Line Loss Factor Class details entered

The details for a Line Loss Factor Class are entered onto the system.

Line Loss Factor Class details updated

The details of an existing Line Loss Factor Class are updated.

Market domain data received

A new publication of Market Domain Data prepared by the Market Domain Data Agent is received.

Metering System EAC & AA data received

A set of Metering System EAC & AA data is received from a Non-Half Hourly Data Collector.

Periodic refresh from PRS Agent received

A refresh of the Metering System details are received from the PRS Agent.

Profile Class details deleted

A Profile Class is removed from the system. This event will occur, for example, when a Profile Class is entered in error, or when the profile class has not been effective for more than two years and all the related settlement data has been archived off.

Profile Class details entered

A new Profile Class is entered onto the system.

Profile Class details updated

Details of an existing Profile Class are updated.

PRS Agent appointed

A PRS agent becomes the source of Metering System details for a GSP Group from a specified date.

PRS Agent appointment deleted

A PRS Agent ceases to be the source of Metering System Registration details for a GSP Group from a specified date.

PRS Agent details deleted

The details of a PRS Agent are removed from the system

PRS Agent details entered

The details of a new PRS Agent are entered onto the system.

PRS Agent details updated

The details of an existing PRS Agent are updated.

Scheduled Data Aggregation run initiated

A Data Aggregation run is automatically initiated when the scheduled date and time for the run is reached.

Standard Sett Config assigned to Profile Class

A particular combination of Standard Settlement Configuration and Profile Class is specified as valid.

Standard Sett Config deassigned From Profile Class

A particular combination of Standard Settlement Configuration and Profile Class, which had previously been specified as valid, is removed from the system. This may be because it was originally marked as valid in error or because it was valid for a period which ended more than two years ago and data for all associated Settlement Days has now been archived off.

Standard Settlement Configuration deleted

A Standard Settlement Configuration is removed from the system. This event will occur, for example, when a Standard Settlement Configuration is entered in error or when the Standard Settlement Configuration has not been effective for more than two years and all the related settlement data has been archived off.

Standard Settlement Configuration entered

A new Standard Settlement Configuration is entered onto the system.

Standard Settlement Configuration updated

Details of an existing Standard Settlement Configuration are updated.

Supplier details deleted

A Supplier is removed from the system. This event will occur, for example, when a Supplier code is entered in error, or when the Supplier has not been trading in the market for more than two years and all the related settlement data has been archived

Supplier details entered

Details of a new Supplier are entered onto the system

Supplier details updated

Details of an existing Supplier are updated.

System Installation

Details of Measurement Classes are defined.

Threshold Parameter deleted

A Threshold Parameter is removed from the system. This event will occur, for example, when a Threshold Parameter is entered in error; or when a Threshold Parameter has not been used for more than two years and all associated Settlement data has been archived.

Threshold Parameter entered

A new Threshold Parameter is entered onto the system.

Threshold Parameter updated

The details for an existing Threshold Parameter are updated.

Time Pattern assigned to Standard Sett Config

A Time Pattern is assigned to a Standard Settlement Configuration. This event will typically occur as part of the process of defining a new Standard Settlement Configuration.

Time Pattern deassigned From Standard Sett Config

A Time Pattern is deassigned from a Standard Settlement Configuration, thus deleting a Measurement Requirement from the system. This event will typically occur only if an error is made while defining a Standard Settlement Configuration. Measurement Requirements will normally be deleted by deleting the associated Standard Settlement Configuration when it is no longer required.

9 USER ROLES

User Roles define the roles of on-line users and the activities they perform.

User Role	Activities Description
Market Domain Data Administrator	The activities of this job include the following: maintaining Market Domain Data (MDD) for the system, except data which has been used in a Final Initial Settlement.
Data Aggregation Administrator	The activities of this job include the following: scheduling data aggregation runs; initiating the send of data aggregation run results to ISR Agents.
Exception Administrator	The activities of this job include the following: requesting Data Collector exception reports; investigating & resolving unsuccessfully processed Instructions from PRS Agents and Data Collectors.
Superior Market Domain Data Administrator	The activities of this job include the following: maintaining MDD for the system ; making authorised changes to data used in a Final Initial Settlement .
System Operator	The activities of this job include the following: monitoring system operation; monitoring interface operation; monitoring system performance and capacity.
System Manager	The activities of this job include the following: create, modify and delete NHHDA users; managing system operation problems; managing interface operation problems; managing system performance and capacity problems; managing audit, security and control; managing backup and recovery; managing archive;

APPENDIX A DATA CATALOGUE

AA Percentage

The total volume of AAs as a percentage of the total volume for all MPANs in the SPM in a file, excluding unmetered energy.

Annualised Advance

A Data Collector's calculation of an annualised advance of a Metering System's settlement register.

Average Fraction of Yearly Consumption

The estimated fraction of consumption for Metering Systems in a profile class and standard settlement configuration which belong to a particular measurement requirement.

Data Aggregation Run Date

The date of a data aggregation run.

Data Aggregation Run Number

The unique number automatically allocated to a data aggregation run.

Data Aggregation Run Time

The time of a data aggregation run.

Data Aggregator Id

The identifier of a Data Aggregator.

Data Aggregator Name

The name of a Data Aggregator.

Data Aggregator Type

An indicator to show if the Data Aggregator is half hourly or non-half hourly.

Data Collector Id

The identifier of a Data Collector.

Data Collector Name

The name of a Data Collector.

Distributor Id

The identifier of a Distributor.

Distributor Name

The name of a Distributor.

Distributor Short Code

The short code used to identify a Distributor as an alternative to the Distributor Id. The Distributor Short Code forms the first two characters of Metering System Id.

Effective From Date {DCA}

The first calendar date that an appointment of a Data Collector to a Metering System is in effect.

Effective From Date {IAA}

The first calendar date that an appointment of an ISR Agent to a GSP group is in effect.

Effective From Date {PAA}

The first calendar date that an appointment of a PRS Agent to a Distribution Business is in effect.

Effective From Settlement Date {AFYC}

The first settlement date for which an average fraction of yearly consumption is effective.

Effective From Settlement Date {DAA}

The first settlement date that an appointment of a Data Aggregator to a Metering System is in effect.

Effective From Settlement Date {EACDC}

A Data Collector's view of the first settlement date for which an estimated annual consumption is effective. This date will be one day after the meter advance period that was used to calculate the estimated annual consumption (and corresponding annualised advance).

Effective From Settlement Date {ESR}

The first settlement date that an energisation status is in effect for a Metering System.

Effective From Settlement Date {Exception Report}

The start of the period for which the NHHDA user requires an exception report.

Effective From Settlement Date {GGD}

The first settlement date that a GSP group is within a Distributor's system.

Effective From Settlement Date {GGPCDE}

The first settlement date that an default EAC applies for a GSP group and profile class.

Effective From Settlement Date {MACDC}

The first settlement date in the meter advance period between two meter readings.

Effective From Settlement Date {MCR}

The first settlement date that a Metering System assumes a measurement class.

Effective From Settlement Date {MSESDC}

A Data Collector's view of the first settlement date that a Metering System assumes an energisation status.

Effective From Settlement Date {MSGGDC}

A Data Collector's view of the first settlement date that a Metering System is in a GSP group.

Effective From Settlement Date {MSGG}

The first settlement date that a Metering System is in a GSP group.

Effective From Settlement Date {MSLLFC}

The first settlement date that a Metering System assumes a line loss factor class.

Effective From Settlement Date {MSMCDC}

A Data Collector's view of the first settlement date that a Metering System assumes a measurement class.

Effective From Settlement Date {MSPCDC}

A Data Collector's view of the first settlement date that a Metering System assumes a profile class.

Effective From Settlement Date {PCR}

The first settlement date that a Metering System assumes a profile class.

Effective From Settlement Date {PCSSCR}

The first settlement date that a Metering System assumes a valid combination of profile class and standard settlement configuration. This data item is used in the Data Interfaces document (reference 6) and cross-checks to data items Effective From Settlement Date {PCR} and Effective From Date {SCR} in this document.

Effective From Settlement Date {RDC}

A Data Collector's view of the first settlement date of a Supplier's Registration to a Metering System.

Effective From Settlement Date {REGI}

The first settlement date of a Supplier's Registration to a Metering System.

Effective From Settlement Date {SCDC}

A Data Collector's view of the first settlement date that a Metering System assumes a standard settlement configuration.

Effective From Settlement Date {SCR}

The first settlement date that a Metering System assumes a standard settlement configuration.

Effective From Settlement Date {TPAR}

The first settlement date that a threshold parameter is in effect.

Effective To Date {IAA}

The last date that an appointment of an ISR Agent to a GSP group is in effect.

Effective To Date {PAA}

The last date that an appointment of an PRS Agent to a Distribution Business is in effect.

Effective To Settlement Date {AFYC}

The last settlement date for which an average fraction of yearly consumption is effective.

Effective To Settlement Date {DAA}

The last settlement date that an appointment of a Data Aggregator to a Metering System is in effect.

Effective To Settlement Date {Exception Report}

The end of the period for which the NHHDA user requires an exception report.

Effective To Settlement Date {GGD}

The last inclusive date that the distributor is operating a Distribution System within the referenced GSP Group.

Effective To Settlement Date {MACDC}

The last settlement date in the meter advance period between two meter readings.

Energisation Status

An energised status of energised or de-energised.

Estimated Annual Consumption

A Data Collector's calculation of an estimated annual consumption of a Metering System's settlement register.

Exception Type

A unique identifier for an exception type

GSP Group Id

The nationally unique identifier of a GSP Group.

GSP Group Name

The description of a GSP group.

ISR Agent Id

The nationally unique identifier of an ISR Agent.

ISR Agent Name

The name of an ISR agent.

ISR Notification Deadline Date

The date by which information required by the ISR Agent for a particular Settlement Run should be in their possession.

Line Loss Factor Class Description

The description of a line loss factor class.

Line Loss Factor Class Id

The identifier for a line loss factor class within a Distributor's system.

Measurement Class Description

The description of a measurement class.

Measurement Class Id

The identifier of a measurement class.

Metering System Id

The nationally unique identifier of a Metering System.

Number of De-Energised MS with Non-Zero AA

The total number of de-energised Metering Systems for which the Data Collector has non-zero Annualised Advances. This value is part of the Data Collector Exception Report.

Number of Metering Systems Failing One or More Checks

A count of the number of Metering Systems which have failed one or more of the consistency checks made between data received from the Data Collector and data received from the PRS. This value is part of the Data Collector Exception Report.

Number of Metering Systems with Unexpected EACs

The total number of Metering Systems for which the Data Collector has provided EAC data, but is not the appointed Data Collector according to PRS. This value is part of the Data Collector Exception Report.

Number of Metering Systems Without EAC

The total number of Metering Systems registered on PRS for which the Data Collector has failed to provide EAC data. This value is part of the Data Collector Exception Report.

Number of MS with Inconsistent GSP Group

The total number of Metering Systems for which the PRS and Data Collector views of the GSP Group are different. This value is part of the Data Collector Exception Report.

Number of MS with Inconsistent Measurement Class

The total number of Metering Systems for which the PRS and Data Collector views of the Measurement Class are different. This value is part of the Data Collector Exception Report.

Number of MS with Inconsistent Profile Class

The total number of Metering Systems for which the PRS and Data Collector views of the Profile Class are different. This value is part of the Data Collector Exception Report.

Number of MS with Inconsistent Registration

The total number of Metering Systems for which the PRS and Data Collector views of the Supplier Registration are different. This value is part of the Data Collector Exception Report.

Number of MS with Inconsistent SSC

The total number of Metering Systems for which the PRS and Data Collector views of the Standard Settlement Configuration are different. This value is part of the Data Collector Exception Report.

Planned Data Aggregation Run Date

The advisory date on which a data aggregation run is scheduled to start.

Profile Class Description

The description of a profile class.

Profile Class Id

The nationally unique identifier of a profile class.

PRS Agent Id

The nationally unique identifier of a PRS Agent.

PRS Agent Name

The name of a PRS Agent.

Researched Default EAC

The default estimated annual consumption for Metering Systems assuming a specific combination of GSP group and profile class.

Settlement Code

A code which, along with a settlement date, identifies an initial settlement or reconciliation published in the Pool's settlement timetable.

Settlement Date

The date on which energy is supplied and subsequently settled for through Pool initial settlement and reconciliation.

SPM Default EAC MSID Count

The number of default estimated annual consumptions that had to be used in the calculation of a supplier purchase matrix's total EAC.

SPM Default Unmetered MSID Count

The number of default EACs that had to be used in the calculation of a supplier purchase matrix's total unmetered consumption.

SPM Total AA MSID Count

The number of Metering Systems contributing to a supplier purchase matrix's total annualised advance and which are not de-energised with zero Annualised Advance for all Settlement Registers.

SPM Total Annualised Advance

The sum of annualised advances for Metering Systems contributing to a supplier purchase matrix.

SPM Total EAC

The sum of estimated annual consumptions for Metering Systems with a metered measurement class contributing to a supplier purchase matrix.

SPM Total EAC MSID Count

The number of Metering Systems contributing to a supplier purchase matrix's total EAC.

SPM Total Unmetered Consumption

The sum of estimated annual consumptions for Metering Systems with an unmetered measurement class contributing to a supplier purchase matrix.

SPM Total Unmetered MSID Count

The number of Metering Systems contributing to a supplier purchase matrix's total unmetered consumption.

Standard Settlement Configuration Desc

The description of a standard settlement configuration.

Standard Settlement Configuration Id

The nationally unique identifier of a standard settlement configuration.

Supplier Id

The nationally unique identifier of a supplier of electricity.

Supplier Name

The name of an electricity supplier.

Threshold Parameter

The minimum number of valid EACs/AAs that must be provided for averaging to be used as the mechanism for determining an EAC substitute for missing or invalid EAC/ AAs.

Time Pattern Regime Id

The nationally unique identifier of a time pattern regime.

APPENDIX B LOGICAL DATA STRUCTURE NOTATION

APPENDIX C DATA FLOW DIAGRAM NOTATION

Where data is provided by an External Entity other than the Data Aggregator, it is shown as entering the system directly from that External Entity if it is anticipated that the interface will be electronic, but as going via the Data Aggregator if it is anticipated that the data will be entered manually through on-line screens.

1 The Line Loss Factor Class is unique to each Distribution Business.

2 Although this is listed as a business event for NHHDA, the complete “End to End” process for this in Settlement is not complete.

3 ‘missing’ is intended to mean required data that the aggregator must have but for some reason doesn’t, as opposed to data that has not yet arrived from PRS

CONTENTS

Non Half Hourly Data Aggregation

Abstract

1 INTRODUCTION

1.1 Introduction

1.2 Purpose and Scope

1.3 Summary of the Document

1.4 Responsibilities

1.5 Terminology

2 PRINCIPLES AND OBJECTIVES

2.1 Principles

2.2 Business Objectives

2.3 System Objectives

3 CONSTRAINTS AND ASSUMPTIONS

3.1 Business Constraints and Assumptions

3.2 System Constraints and Assumptions

3.2.1 Scope

3.2.2 Operational

3.2.3 System Interfaces

3.2.4 End-User Interfaces

3.3 Project Constraints and Assumptions

4 BUSINESS DESCRIPTION

4.1 Introduction

4.2 Business Process Overview

4.3 System Overview

4.3.1 Receipt of Data from PRS Agents and Data Collectors

4.3.2 Data Aggregation and Sending Aggregated Results

4.3.3 Reporting Exceptions for Data Collectors and Suppliers

4.3.4 Maintenance of Market Domain Data

4.4 Scope

4.5 NHHDA Context

4.6 Business Events

4.6.1 Change of a Metering System’s Data Aggregator

4.6.2 New Metering System

4.6.3 Change of a Metering System’s Supplier

4.6.4 Change of a Metering System’s Data Collector

4.6.5 Change of a Metering System’s Standard Settlement Configuration

4.6.6 Change of a Metering System’s Profile Class

4.6.7 Change of a Metering System’s Measurement Class

4.6.8 Change of a Metering System’s GSP Group

4.6.9 Change of a Metering System’s Line Loss Factor Class

4.6.10 Change of a Metering System’s Energisation Status

4.6.11 Change of a Metering System’s Settlement Register EAC/AA

4.6.12 Market Domain Data Agent distributes a Change to Market Domain Data

4.6.13 Initial Settlement or Reconciliation run to take Place

4.6.14 Demand Control Event occurs

5 REQUIREMENTS CATALOGUE

5.1 Introduction

5.2 Key to the Requirements Catalogue

5.3 Functional Requirements

5.4 Non- Functional Requirements

5.5 Operational Requirements

5.6 Design Constraints

5.6.1 Design Constraint Requirements

6 DATA FLOW MODEL

6.1 Purpose and Scope

6.2 Data Flow Diagrams

6.2.1 Level 1 - Non Half Hourly Data Aggregation

6.2.2 Process 2 - Receive Registration Updates

6.2.3 Process 3 - Aggregate Annualised Consumption Data

6.2.4 Process 4 - Maintain Market Domain Data

6.2.5 Process 4.5 - Maintain Standard Settlement Configuration

6.2.6 Process 4.11 – Process Market Domain Data Files

6.3 Elementary Process Descriptions

6.3.1 Process 1 - Receive EAC/AA Data

6.3.2 Process 2 - Receive Registration Updates

6.3.3 Process 2.1 - Receive Registration Details

6.3.4 Process 2.2 - Process Data Aggregator Appointment Details

6.3.5 Process 2.3 - Process Profile Class / SSC Details

6.3.6 Process 2.4 - Process Data Collector Appointment Details

6.3.7 Process 2.5 - Process Measurement Class Details

6.3.8 Process 2.6 - Process Energisation Status Details

6.3.9 Process 2.7 - Process GSP Group Details

6.3.10 Process 2.8 - Process Line Loss Factor Class Details

6.3.11 Process 2.9 - Refresh PRS Metering System Details

6.3.12 Process 2.10 - Process Demand Control Event data

6.3.13 Process 3.1 - Prepare Data Aggregation Run Schedule

6.3.14 Process 3.2 - Perform Aggregation Run

6.3.15 Process 3.2A - Perform Disconnection Aggregation Run

6.3.16 Process 4.1 - Maintain Profile Class