Synopsis	This document describes the requirements for a system which supports the Initial volume allocation and subsequent reconciliation between Suppliers, by adjusting Suppliers’ energy volumes as meter data becomes available to replace estimates used in Initial Settlement.
Version	Version 24.0
Effective date	02 November 2023

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

Amendment History

Date	Version	Details of Change	Panel Committee Refs
26 June 2008	11.0	CP1209
1 August 2014	12.0	Document rebadged and updated for ORD005 – Electricity Market Reform. Directed by the Secretary of State.	Secretary of State
26 February 2015	13.0	CP1418 – February 2015 Release	SVG163/06
5 November 2015	14.0	P300, P305 – November 2015 Release	SVG177/03
30 June 2016	15.0	P315, June 2016 Release	SVG184/02
2 November 2017	16.0	CP1478, November 2017 Release	SVG193/05
		CP1484 November 2017 Release	Panel 266/06
28 February 2019	17.0	P344 – February 2019 Release	Panel 284C/01
29 March 2019	18.0	P369 – March 2019 Standalone Release	Panel 285/12
11 December 2019	19.0	11 December 2019 Standalone Release – CP1517	SVG224/02
1 April 2020	20.0	P354 - 1 April 2020 Standalone Release	SVG229/07
1 April 2021	21.0	P383 – 1 April 2021 Standalone Release	SVG241/04
30 June 2022	22.0	P375 – 30 June 2022 Standard Release	Panel 309/06
23 February 2023	23.0	P376 – 23 February 2023 Standard Release	Panel 312/04
02 November 2023	24.0	P395 – 02 November 2023 Standard Release	SVG271/07 ISG269/03

1. Introduction

1. The franchises for electricity supply held by Public Electricity Suppliers expired on 31 March 1998. As a consequence, all electricity customers became free to seek competitive supplies from 1 April 1998.

2. Accordingly, the Electricity Pool of England and Wales (the Pool) developed proposals for new arrangements for electricity trading and settlement to support the "1998 market". The 1998 Operational Framework (reference 1) was 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 was referred to as the Pool's 1998 Programme.

3. In November 1998, the New Electricity Trading Arrangements (NETA) were proposed. These put in place market-based trading like that in commodity markets and competitive energy markets elsewhere, and conformed to the Balancing and Settlement Code. Consequently, the Pool developed a further Programme of work to implement the new Trading Arrangements, which necessitated the need for a Supplier Volume Allocation Agent in order to determine the energy position of Suppliers. This required a development of the original Initial Settlement and Reconciliation system designed in 1998. The Stage 2 processes and systems for energy allocations were to continue under NETA, however the financial calculations performed by the ISRA would not.

4. The New Electricity Trading Arrangements required four specific changes to the Initial Settlement and Reconciliation system. These were:

4.1 NETA interfaces to Stage 2;

4.2 Multiple BM Units per GSP Group;

4.3 Splitting individual Half Hourly meter volumes between more than one Supplier;

4.4 Generator allocated volumes.

These requirements were implemented in two packages, the first covering NETA interfaces to Stage 2 and Generator allocated volumes and the second covering Multiple BM Unit and the Splitting of Half Hourly metering between Suppliers.

The initiation of the joint Ofgem/DTI BETTA (British Electricity Trading and Transmission Arrangements) project extends NETA to include Scotland. ISRA is required to settle on the Scottish GSP Groups, and take account of Scottish Regression Coefficients and Scottish Day Types.

1.1 Purpose and Scope

1. This document describes the requirements for a system which supports the Initial volume allocation and subsequent reconciliation between Suppliers, by adjusting Suppliers’ energy volumes as meter data becomes available to replace estimates used in Initial Settlement. This process comprises the Initial Settlement and Reconciliation Agency (ISRA) system, which is a nationally developed system, which could be run by individual ISR Agents for each GSP Group.

2. The ISRA system must work within the defined context of the New Electricity Trading Arrangements (NETA), and therefore this specification includes details of the interfaces between the Initial Settlement and Reconciliation Agency system and the other systems in NETA. The principles and structure of NETA are described in detail in the New Electricity Trading Arrangements (reference 18).

3. The specification is developed in accordance with the Required Amendments to Trading Stage 2 for NETA (reference 17). SSADM Version 4 has been used and, 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.

1.2 Summary of the Document

1. The User Requirements Specification (URS) comprises:

a statement of the high level principles and the objectives of the Initial Settlement and Reconciliation Agency system (ISRA);
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 ISRA;
supporting information, including the Required Data Flow Model, Logical Data Model, Data Catalogue, Function Descriptions, System Event Descriptions, and User Roles.

2. Principles and Objectives

2.1 Principles

The requirements of the Initial Settlement and Reconciliation Agency system (ISRA) all arise from a set of basic high level principles. The detailed requirements listed in the Requirements Catalogue section 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. Initial Settlement will provide an equitable initial allocation of energy volumes across Suppliers. This will be based on a combination of half hourly data and profiled estimates of consumption, both adjusted for line losses and corrected to total GSP Group demand for each half hour. (OF407(f))

2. Reconciliation is the means by which an equitable adjustment of Suppliers’ energy volumes can be achieved as meter data becomes available to replace the estimates used in the Initial Settlement process. (OF 407(g))

3. ISRA will ensure that the sum of the Suppliers’ energy volumes balances the total energy volume in every Settlement Period, within a GSP Group.

4. ISRA will generate reports for Suppliers and Distributor (including DUoS), Transmission Use of System (TUoS), and the SAA that detail the results of the calculations performed.

5. ISRA will support interfaces with all relevant parties and systems to facilitate the timely and accurate provision or receipt of data.

6. ISRA will be a fully auditable system and will be capable of storing and retrieving data to allow the review and, if necessary, the re-running of the calculations for any Settlement Day for at least two years after the Settlement Day.

7. ISRA will comply with Pool’s 1998 Programme security and control framework (reference 8) and the Pool’s 1998 Programme’s standard codes and naming conventions.

8. The design and implementation of ISRA shall not prevent the system, given an appropriate hardware environment, being operated to meet the prescribed settlement and reconciliation schedule.

9. The design and implementation of the ISRA will not adversely constrain the operation and performance of Existing Settlements or the production of TUoS charges.

2.2 Business Objectives

The major business objectives are:

1. to ensure an equitable allocation of Suppliers’ energy volumes by allocating differences between metered GSP Group Take and the total profiled and metered demand across Suppliers in a way which is not expected to favour any one Supplier or group of Suppliers;

2. to enable reconciliation of the Suppliers’ energy volumes, based on estimated consumption to those using actual meter readings obtained up to 2 years after the Settlement Day;

3. to provide Supplier energy volume information to enable the trading of electricity between Generators and Suppliers.

4. to supply the information required to enable the Market to clear between Generators and Suppliers for each Settlement Day in the same timescales as in the pre-NETA market.

2.3 System Objectives

The major system objectives of the Initial Settlement and Reconciliation Agency systems are:

1. to enable the ISRA process to be operated by ISR Agents as agents of the Pool;

2. to determine daily the Profile Coefficients for each half hour;

3. to provide the Daily Profile Coefficients to the Non-Half Hourly Data Collectors to support the calculation of EACs and Annualised Advances;

4. to enable the calculation of Supplier energy volumes, within a GSP Group for any Settlement Day, for at least 2 years afterwards;

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

6. to provide interfaces with the other systems in the Operational Framework (reference 1);

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

8. 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.

2.4 Project Objectives

The objectives of the project are to develop the Initial Settlement and Reconciliation Agency systems, notably:

1. to design and develop systems which satisfy the business requirements for the Initial Settlement and Reconciliation Agency functions of the New Electricity Trading Arrangements (NETA), as stated in this specification;

2. to ensure that the design of such systems is compatible with the 1998 technical architecture for the overall business requirement;

3. to design ISRA in such a way that functionally independent components (such as Daily Profile Production and Supplier Settlement and Reconciliation runs) may be run as independent systems;

4. to design and implement ISRA in such a way that an agent of the Pool may perform the calculations for a single GSP Group, independently of those for another GSP Group;

5. to design and implement ISRA in such a way that any ISR Agent may run the system for more than one GSP Group;

6. to define the interfaces with the Central Data Collection Agent (CDCA), the Data Collection systems, the Data Aggregators, the Host PES, the Settlement Administration Agent (SAA) systems and the National Electricity Transmission System Operator (NETSO) TUoS system;

7. to define the interfaces between the Daily Profile Production and Supplier Settlement and Reconciliation sub-systems;

8. to specify the requirements for standing data to be entered to the ISRA system including the capture of such data as is required to apply the profiles to the EACs in accordance with the defined functionality.

3. Constraints and Assumptions

The baseline for this specification is the Required Amendments to Trading Stage 2 for NETA, version 3.0 (reference 17) and the references below refer to paragraphs in that document, unless otherwise stated.

3.1 Business Constraints and Assumptions

1. Electricity trading between Generators and Suppliers will occur on the basis of energy allocations for each half hour period of each day.

2. The Pool will undertake Reconciliations between Suppliers for a Settlement Day, outside Initial Settlement timescales (OF Ref 407(g)).

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

4. Further reconciliations after the Final Reconciliation may occur within the framework of the disputes process (OF Ref 488).

5. The Settlement Timetable is published by the Pool in Agreed Procedure AP01 (reference 9). The timetable for Settlement and Reconciliation runs for the New Electricity Trading Arrangements will be published by the Pool in an Agreed Procedure. It will include the deadlines for ISRA’s feeder and other dependent systems.

3.2 System Constraints and Assumptions

3.2.1 Scope

1. The ISRA system has no knowledge of individual Metering Systems. It receives aggregated values of EACs/AAs by Settlement Class and of half hour readings by Consumption Component Class.

2. ISRA cannot ensure that for each Settlement Day, every Metering System is accounted for once and only once. This must be determined by 1998 systems other than ISRA, Non-Half Hourly Data Aggregation, for example. The ISRA system will not make any checks for completeness or duplication of metering systems within the data supplied by the Data Aggregators.

3. Where interconnection exists between two GSP Groups, this interconnection will be metered and the half hourly consumption data sent to the CDCA along with the FMS metering to allow determination of GSP Group Take (OF Ref 412 and 413). It is therefore outside the scope of ISRA.

4. Energy volumes associated with Metering Systems registered in CRA will be subtracted from the GSP Group Take by the CDCA before the GSP Group Take is passed to ISRA (for as long as this system continues).

5. ISRA is run on a Settlement Day basis, which is measured in local (clock) time. All times within the system are in local time unless they are explicitly stated to be in GMT.

3.2.2 Operational

1. The ISRA system will be operated by Initial Settlement and Reconciliation Agents. An ISR Agent can operate the system for one or more GSP Groups.

2. A Supplier Settlement and Reconciliation (SSR) Run is carried out for one, some or, by default, all GSP Groups to which the agent is appointed.

3. A Daily Profile Production Run is carried out for one, some or by default, all GSP Groups.

4. A GSP Group consists of one or more Distribution Systems, each owned and operated by a Distribution Business (OF Ref 411).

5. Where there is a failure to provide data for an SSR Run, data will be substituted to allow the Run to take place and appropriate reports produced.

3.2.3 System Interfaces

1. ISRA will receive data from its feeder systems (CDCA, Data Aggregation, PRS) in a timescale based upon the published Settlements timetable.

2. For each SSR and Daily Profile Production run, the most recent data provided for that Settlement Day, by its feeder systems will be used. Defaults will be used if data has not been received from any of the feeder systems.

3. If multiple versions of input data are received for an SSR or Profile Production Run, the latest version of the data received will be used.

4. The input data for any SSR or Daily Profile Production run will be retained for audit purposes.

5. ISRA will receive a full set of aggregated data from both the Half Hourly and the Non-Half Hourly Data Aggregators for each SSR run. For the Non-Half Hourly Data Aggregator, the set will be one Supplier Purchase Matrix entry per Supplier per Settlement Class, per GSP Group. For the Half Hourly Data Aggregator, the set will be one aggregated total per Consumption Component Class, per Supplier and per GSP Group if the HHDA in question has not implemented Multiple BM Units. Otherwise the set will be one aggregated to GSP Group, Supplier, Consumption Component Class, BM Unit and Settlement Period for those Suppliers and HHDAs who have implemented Multiple BM Units.

6. The Non-Half Hourly Data Aggregators supply the aggregated EACs and Annualised Advances, separately by Settlement Class and Supplier, to ISRA for profiling into half hour values for each Settlement Day. ISRA adjusts each of these profiled values by application of an appropriate Line Loss Factor.

7. Aggregated half hourly readings are sent to ISRA by the Half Hourly Data Aggregators with a separate total for line losses. Values supplied to ISRA by the Half Hourly Data Aggregators are supplied by either Consumption Component Class and Supplier if the Half Hourly Data Aggregator does not implement Multiple BM Units, and by BM Unit, Consumption Component Class and Supplier if he does implement Multiple BM Units, but not both.

8. Line Loss Factors will be provided periodically by each Distribution Business in an electronic format. It is assumed that a value will be supplied for each Line Loss Factor Class, Settlement Date and Settlement Period.

9. The definitive source for Line Loss Factor values is the Distribution Business (although these are distributed to ISRA by BSCCo).

10. NETSO TUoS system will receive the TUoS reports from all SSR Runs.

3.2.4 End-User Interfaces

1. ISRA standing data creation and changes (including NHH BM Unit Allocations) will be manually entered. In the case of disagreement with files supplied by Data Aggregators, standing data will be automatically updated by the ISRA software to agree with that provided by the DA.

2. Daily temperature data used for generating profiles will be manually entered.

3.2.5 Profile Production

1. The system will allow recalculation of Daily Profile Coefficients for a Settlement Day up until the time of the Final Initial Settlement run, for that day. It will be the responsibility of Data Collectors to perform any recalculation of EACs and AAs that may be required as a result.

2. It is assumed that recalculation of Daily Profile Coefficients will be a rare occurrence, as it would be caused by errors in the Regression Equations or Daily Parameter input.

3. The system will calculate separate profiles for each Time Pattern of each Standard Settlement Configuration supported by the settlement process. This will be done through the processes of Algorithmic Profiling, and Chunking (i.e. splitting a Profile for a Standard Settlement Configuration into separate ‘chunks’ for each Time Pattern). This will enable other 1998 systems to estimate consumption or calculate Annualised Advances for Settlement Registers, without the need for additional information concerning their switching behaviour.

4. The system will not contain additional functionality to support metering systems where:

two meters exist at one site where one meter measures off-peak or restricted hour electricity consumption (“switch load”) and the other measures the unrestricted consumption; or
a single meter exists where one register measures the “switch load” consumption while the other register measures the unrestricted consumption.

Instead, both types of metering system will be supported by assigning a distinct MSID and Standard Settlement Configuration to each meter or metering element.

1. The process of Chunking will be performed as part of Daily Profile Production, rather than as part of both the SSR and EAC systems, as described in Appendix A of the Operational Framework (reference 1). The results are identical but performing the process only once is more efficient.

2. The chunked profiles produced by the system will be 'normalised' so that the sum of the coefficients over a typical year would be one. This will ensure that the EACs and AAs calculated by the EAC system reflect the Average Annual Consumption for each Settlement Register, rather than the total for the metering system.

3.2.6 Supplier Settlement and Reconciliation

3.2.6.1 Non-Pooled Generation Processing

1. Suppliers will be allocated negative Deemed Take within a GSP Group for any half hour if the output from any Non Pooled Generation (NPG) which they may have exceeds their take.

3.2.6.2 GSP Group Correction

1. Unallocated Energy for a half hour period may be positive or negative (i.e. the Aggregated GSP Group Consumption may be less than or greater than the GSP Group Take) or zero.

2. The mechanism that compensates the consumption to exactly balance the GSP Group take is GSP Group Correction. GSP Group Correction will always be applied to at least one component of consumption.

4. Business Description

4.1 Introduction

1. This section describes the business process, scope and context of the Initial Settlement and Reconciliation Agency system (ISRA). The scope of the development project(s) to design and implement ISRA is not covered in this section.

2. The Business view of ISRA can be represented in a number of ways and this section contains:

the scope of ISRA in terms of the 1998 Programme Business Process Model (reference 1);
an overview of the Initial Settlement and Reconciliation Agency process;
diagrammatic representation of the context of ISRA in terms of its interfaces with trading parties, Pool organisations, NETA systems and other external systems;
the business events which affect ISRA.

4.2 ISRA Scope

1. The Initial Settlement and Reconciliation Agency (ISRA) system comprises the business processes that are required to calculate Suppliers’ energy volumes in the New Electricity Trading Arrangements. There are two distinct business processes:

Supplier Settlement and Reconciliation (SSR); and
Daily Profile Production

2. The high level processes in the Business Process Model in the Operational Framework (reference 1) map onto these systems as follows:

ISRA Sub-system	BPM Ref	BPM Process Name
Supplier Settlement and Reconciliation	8B	GSP Group Aggregation
	9/15	Deemed Take Calculation
	13/16	Determine Supplier Energy Volumes
Daily Profile Production	12 (part)	Profile Production (part)

BPM Process 12, Profile Production includes both the production of daily profiles by the ISR Agent and the annual production of generic profiles or regression equations, by the Profile Administrator. The ISRA process Daily Profile Production maps to the first of these functions.

4.3 System Overview

4.3.1 Supplier Settlement and Reconciliation

1. The Supplier Settlement and Reconciliation (SSR) sub-system comprises the business processes that are required to estimate each Supplier’s energy volumes within each BM Unit. The value of each Suppliers’ energy volumes within each BM Unit are passed to the Settlement Administration Agent (SAA) thereby allowing the Market to be cleared, for each Settlement Day, within the existing 29 day cycle.

2. The Central Data Collection Agent’s (CDCA) settlement system provides to the SAA the Generator energy volumes, the Station Demand energy volumes, the Interconnector energy volumes, and any energy volumes for customers registered in CRA. To make an Initial Settlement, a complete set of all GSP Group Supplier energy volumes is required, together with the CDCA’s data.

3. Initial Settlement is carried out using the best data available at the time and will include aggregated estimated meter reading data and aggregated actual meter reading data. This process is followed by a series of Reconciliation runs over a period of time (possibly up to two years). These Reconciliation runs use more complete actual data as it becomes available until near 100% actual data is available. It is assumed that Final Reconciliation will occur no later than 24 months after the Settlement Day.

4. Each Reconciliation run results in a completely new set of energy volume allocations between Suppliers for the Settlement Day for one or more GSP Groups included. This data is passed to the Settlement Administration Agent who then calculates the adjustments with respect to the previous run. The CDCA’s calculations are repeated for each of the ISR Agent’s Reconciliation runs. When a Dispute Final Settlement is to be made there may be a complete recalculation involving the CDCA and some or all ISR Agents, subject to the agreed disputes procedure. Normally this will be performed as part of the next Settlement run.

5. The processes of Initial Settlement and Reconciliation are practically identical. The Reconciliation process differs from the Initial Settlement process in that the quality of the data improves with each successive run.

6. Meter reading data is collected by Data Collectors, aggregated by the Data Aggregators and sent to the SSR system. The Line Loss Factor data is also made available to SSR from the Distributor in respect of non-half hourly data.

7. The CDCA‘s systems pass for each GSP Group for each half hour of a Settlement Day, the GSP Group Take. This data allows the Agent to calculate the Supplier energy volumes from the Supplier Deemed Take for the Settlement Day.

4.3.1.1 GSP Group Aggregation

1. Supplier Takes for each Settlement Day for a GSP Group are calculated using data provided by Data Aggregators.

2. Half Hourly Data Aggregators supply aggregated values where half hourly metering is installed or where they are provided by approved systems designed to estimate them for unmetered supplies. The Data Aggregators adjust the half hourly values for each metering system for line loss, aggregate the values for all half hourly metering systems for a Supplier, and supply the separate totals to SSR for each half hour.

3. Non-Half Hourly Data Aggregators are responsible for aggregation when there is no half hourly meter and a meter advance meter has been installed. Each meter advance metering system has one or more Estimated Annual Consumption (EAC) and Annualised Advance (AA) associated with it. The Non-Half Hourly Data Aggregators sum the EACs and AAs for each Supplier and valid Settlement Class and send the aggregated values to the ISR Agent. This data is termed the Supplier Purchase Matrix (SPM).

4. GSP Group Aggregation involves the calculation of a Supplier’s consumption for each half hour for a BM Unit by the application of the appropriate profile to Supplier Purchase Matrix cells. The SSR system uses profiling to derive consumption values for each half hour, for each BM Unit for each Supplier, for those of their customers that do not have half hourly metering installed. The profiled half hourly values are then adjusted for line loss.

5. The principle of the profiling process is to convert the annual consumption totals (EAC & AA) for each Settlement Class to half hourly estimates of consumption, using profiles of average consumption. The process of constructing these profiles is described in Daily Profile Production.

4.3.1.2 Deemed Take Calculation

1. It is required that the total calculated consumption (Deemed Take) for a GSP Group in a half hour exactly matches the actual metered imports to the Group from the Grid Supply Points (GSPs). To achieve this, the GSP totals for the Group are passed by the CDCA (who meters these through the FMS system) to the ISR Agent to allow the adjustment to be made. The ISR Agent then carries out a GSP Group Correction by pro-rating the Aggregated Deemed Takes for the Suppliers within the GSP Group up or down to match the GSP Group total supplied by the CDCA.

2. Not all components of the Deemed Take are included in the correction process. In general it is the profiled, line loss adjusted components (rather than half hourly metered values) that are subjected to correction and scaling factors can be applied to different components used in correction.

3. The result of this process is, for each GSP Group, a set of Deemed Takes for each BM Unit for each Supplier for each Settlement Period of the Settlement Day.

4.3.1.3 BM Unit SVA Gross Demand Calculation (for purposes of the CFD Arrangements)

1. In addition to the Deemed Take calculation reflecting net consumption, the gross half hourly demand (‘BM Unit SVA Gross Demand’) for each Supplier and BM Unit is calculated. The BM Unit SVA Gross Demand for a Supplier BM Unit is defined as the sum of the Corrected Component (CORC_iNj) for all Consumption Component Classes ‘N’ associated with Active Import. It follows from this definition that the BM Unit SVA Gross Demand will be adjusted for distribution losses and for GSP Group Correction (but will exclude any Active Export energy).

4.3.1.4 Determine Supplier Energy Volumes

1. The Supplier energy volumes are passed through to the SAA for processing.

4.3.1.5 Determine Quarterly Volumes

1. In relation to each calendar quarter, values required for a Supplier Quarterly Volume Report are calculated. This includes a sum of Supplier volume data for the Settlement Days in the quarter (as determined at First Reconciliation), adjusted for distribution losses and GSP Group Correction, along with the related number of Metering Systems averaged over the quarter.

4.3.2 Daily Profile Production

1. Profiles are produced for each Profile Class based on load research, and are supplied to the ISR Agent by the Profile Administrator(s).

2. For each Settlement Day, the ISRA Daily Profile Production system produces the Profile Coefficients required to calculate the consumption for each Profile Class. A profile is a set of regression equations (one for each half hour of the day) which can be evaluated to obtain a temperature-adjusted estimate of half hourly consumption (in kW over the half hour) for the Profile Class Average. Profile Coefficients for each GSP Group area are produced from these equations and these coefficients are then multiplied by EACs and AAs to calculate half hourly consumption.

3. The regression equations and class average consumption are provided to the Daily Profile Production system by the Profile Administrator; time of sunset for the GSP Group is provided by the Sunset Provider and the Sunset Variable may be derived; and the noon effective temperature for the GSP Group is calculated from temperature data provided by the Authorised Temperature Provider.

4. The production of the profiles is carried out once for each Settlement Day (except for any recalculations needed to correct errors, which may occur up until the Final Initial Settlement Run). The initial settlement run and subsequent reconciliation of that trading use the same set of Profile Coefficients. The calculation of AAs and EACs and the derivation of meter advances similarly use the previously produced sets of Profile Coefficients for each Settlement Day in the period under calculation.

4.4 ISRA Context

4.5 Business Events

The ISRA system is affected by the following business events:

1. Profile Production for Settlement Day

2. Initial Settlement for Settlement Day

3. Reconciliation for Settlement Day

4. Dispute Resolution for Settlement Day

5. Profile Changes

6. Profile Class Changes

7. Changes to Published Pool Market Domain Data

8. Settlement Timetable Published

9. Changes to Scaling Factors for GSP Group Correction

10. Supplier starts/stops trading in GSP Group

11. Data Aggregator starts/stops operating in GSP Group

12. Data Collector starts/stops operating in GSP Group

13. Changes to Line Loss Factor Classes

14. Start of trading on NETA Go-Live date

15. Changes to GSP Groups

16. Archiving events

17. Changes to BM Unit allocations

18. Start of trading on BETTA Go-Live date

19. Scottish Regression Coefficients End Date

Each business event triggers a number of external system events and each external system event relates to a number of detailed system events, as described in Function Description and Events, section 9. The events do not necessarily occur serially, nor is the order significant unless specifically stated or implicitly defined by logical relationships.

4.5.1 Profile Production for Settlement Day

This is a scheduled event and is triggered by a pre-determined, published Settlement Timetable. It will occur once for each Settlement Day. It triggers the following input system events:

1. Authorised Temperature Provider sends daily temperature parameters for Settlement Day to Profiling function, comprising:

Actual noon temperature entered.

2. Profiling function receives set of Sunset times for the GSP Group, comprising:

Sunset data loaded

3. Profiling function receives Teleswitch contact intervals (i.e. Teleswitch switching times) prepared by the Teleswitch Agent for Settlement Day, comprising:

Teleswitch Switching Times Available

4. Calendar data created covering the Settlement Day, comprising:

Day Type and Scottish Day Type specified for Settlement Day;

5. ISR Agent runs Profiling Run for Settlement Day, when events (1) to (4) completed, comprising:

Profiling Run.

Note that in practice the Sunset Data Loaded, Scottish Day Type and Day Type Specified for Settlement Day events may occur well in advance e.g. at the start of the year

4.5.2 Initial Settlement for Settlement Day

This is a scheduled event and is triggered by the published Settlement Timetable. It will occur more than once for each Settlement Day (although it will normally occur only once). It triggers the following input system events:

1. HH Data Aggregators send aggregated half hour meter consumptions and their associated line losses, comprising:

Aggregated Half Hour Data Available.

2. Non-HH Data Aggregators send Supplier Purchase Matrix EAC and AAs, comprising:

SPM Data Available.

3. CDCA sends GSP Group Take, comprising:

GSP Group Take available.

4. ISR Agent runs Initial Settlement process for Settlement Day, when events (1) to (3) completed comprising:

SSR Run Event.

The following output enquiry events are triggered:

1. The BM Unit Supplier Take Energy Volume Data File and BM Unit SVA Gross Demand Data File are sent to Settlement Administration Agent.

2. The Deemed Supplier Take report is sent to Transmission Use of System.

3. The GSP Group Consumption Totals report is produced and sent for each Supplier, with a variant also sent to BSCCo.

4.5.3 Reconciliation for Settlement Day

This is a scheduled event and is triggered by the published Reconciliation timetable. It will occur more than once for each Settlement Day. It triggers the following input system events:

1. HH Data Aggregators send aggregated half hour meter consumptions and their associated line losses, comprising:

Aggregated Half Hour Data Available.

2. Non-HH Data Aggregators send Supplier Purchase Matrix EAC and AAs, comprising:

SPM Data Available.

3. CDCA sends GSP Group Take data, comprising:

GSP Group Take available.

4. ISR Agent runs the Reconciliation process for Settlement Day, when events (1) to (3) completed comprising:

SSR Run Event.

The following output enquiry events are triggered:

1. The BM Unit Supplier Take Energy Volume Data File and BM Unit SVA Gross Demand Data File are sent to Settlement Administration Agent.

2. The Deemed Supplier Take report is sent to Transmission Use of System.

3. The GSP Group Consumption Total report is produced and sent for each Supplier, with a variant also set to BSCCo.

4.5.4 Dispute Resolution for Settlement Day

If a dispute occurs before the final reconciliation run, then the next Initial Settlement or Reconciliation run, according to the published Settlement Timetable will normally rectify any misallocation of funds between Suppliers or between Suppliers and Generators.

This is an ad-hoc event which may, either

affect both Suppliers and Generators, in which case the CDCA must provide amended Settlement data. A full Initial Settlement or Reconciliation Run may be run and the input and output events are the same as those for an Initial Settlement or Reconciliation for Settlement Day; or
affect only Suppliers within a GSP Group, in which case a Reconciliation run may be run and the input and output events are the same as those for Reconciliation for Settlement Day.

If the dispute occurs after the final reconciliation run, then ISRA must provide data to support the resolution of the dispute and this may involve the following system events and enquiries:

restore from archive; and
dispute reports produced; or
a full Initial Settlement run; or
a Reconciliation run.

4.5.5 Profile Changes

After the Trading Arrangements have been in use for some time, as a result of load research, a Profile Administrator makes changes to the underlying regression equations which are used to produce daily profiles. It triggers the following input system event:

1. Profile Administrator provides the Market Domain Data Agent and the ISR Agent with details of a profile change with the effective date, comprising:

Profile deleted;
Profile entered;
Profile updated;
Regression Equation deleted;
Regression Equation entered;
Regression Equation updated.

4.5.6 Profile Class Changes

After the Trading Arrangements have been in use for some time, it is agreed by Pool Members that changes are required to Profile Classes. This may involve introduction of new Profiles or removal of existing Profiles or changes to individual Profiles, supplied by the Profile Agent. It may also involve changes to the rules about which Standard Settlement Configurations may be assigned to a Profile Class. It triggers one or more of the following input system events:

1. Pool Members inform the Market Domain Data Agent who informs the ISR Agent of new Profile Classes, comprising:

Profile Class Entered;
Profile Class Updated.

2. Profile Administrator provides the Market Domain Data Agent and the ISR Agent with details of profiles for new Profile Classes, comprising:

Profile entered;
Profile updated;
Regression Equation entered;
Regression Equation updated.

3. Pool Members inform the Market Domain Data Agent who informs the ISR Agent of Profile Classes to be removed, comprising:

Profile Class Updated;
Profile Class deleted;
Profile updated;
Profile deleted;
Regression Equation updated;
Regression Equation deleted;
Standard Settlement Configuration deassigned from Profile Class.

4. Suppliers inform the Market Domain Data Agent who informs the ISR Agent of Standard Settlement Configurations which are valid for new Profile Class, comprising:

Standard Settlement Configuration assigned to Profile Class;
Standard Settlement Configuration entered;
Standard Settlement Configuration updated.

5. Pool Members inform the Market Domain Data Agent who informs the ISR Agent of changes to the rules governing the assignment of Standard Settlement Configurations to Profile Classes, comprising:

Standard Settlement Configuration assigned to Profile Class;
Standard Settlement Configuration deassigned from Profile Class;
Assignment to Profile Class Updated;
Standard Settlement Configuration deleted;
Standard Settlement Configuration entered;
Standard Settlement Configuration updated.

4.5.7 Changes to Published Pool Market Domain Data

The Pool Members agree that changes are required to the Pool Market Domain data, such as new timeswitch regimes are required, existing timeswitch regimes are to be withdrawn or changes to existing timeswitch regimes are required. It triggers the following input system event:

1. Amendments are sent to the Market Domain Data Agent who provides the ISR Agent with details of time patterns and the Standard Settlement Configurations affected and effective date, Settlement Day and Line Loss Factor Classes, comprising:

Pool Market Domain Data loaded;
Standard Settlement Configuration deleted;
Standard Settlement Configuration entered;
Standard Settlement Configuration updated;
Time Pattern assigned to Standard Settlement Configuration;
Time Pattern deassigned from Standard Settlement Configuration;
Time Pattern Regime deleted;
Time Pattern Regime entered;
Time Pattern Regime updated;
Clock Interval deleted;
Clock Interval entered;
Set of average Consumption Fractions entered;
Set of average Consumption Fractions updated;
Set of average Consumption Fractions deleted;
Teleswitch Register and Contact Rules entered;
Teleswitch Register and Contact Rules updated;
Teleswitch Register and Contact Rules deleted;
BM Unit details entered;
BM Unit details updated;
BM Unit details deleted;
Market Domain Data Complete Set loaded

4.5.8 Settlement Timetable Published

The Market Domain Data Agent distributes a new Settlement Timetable or changes to the existing timetable. It triggers the following input system event:

1. Amendments are sent to ISR Agent with details Settlement Codes and dates, comprising:

Settlement entered;
Settlement updated;
Settlement deleted;
Settlement Timetable loaded.

4.5.9 Changes to Scaling Factors

The Pool members agree that the scaling factors used in GSP Group Correction should be changed and amend the Pool Rules accordingly. It triggers the following input system event:

1. Pool Rules amendments sent to the Market Domain Data Agent are forwarded to the ISR Agent with details of scaling factor changes and effective date, comprising:

GSP Group Scaling Factors deleted;
GSP Group Scaling Factors entered;
GSP Group Scaling Factors updated.

4.5.10 Supplier starts/stops trading in GSP Group

A Supplier starts to trade within a GSP Group or stops trading within that GSP Group. This event is triggered by the wider Metering System Change of Supplier event. It triggers the following input system events:

1. Supplier provides the ISR Agent with details of GSP Group in which he will start trading and effective date, comprising:

Supplier details entered;
Supplier details updated;
Supplier starts trading in GSP Group;
Aggregator (half hourly and/or non-half hourly) assigned to GSP Group;
Data Collector details entered;
Data Collector details updated;
Data Collector appointed to GSP Group.

2. Supplier provides the ISR Agent with details of when he will cease trading and where, comprising:

Supplier details updated;
Supplier details deleted;
Supplier finishes trading in GSP Group;
Aggregator assignment deleted;
Data Collector in GSP Group deleted.

4.5.11 Data Aggregator starts/stops operating in GSP Group

A Data Aggregator starts to operate within a GSP Group or stops operating within that GSP Group. This event may be triggered by the wider Metering System Change of Supplier event or by a Supplier appointing a new Data Aggregator or changing an existing Data Aggregator. It triggers the following input system events:

1. The Supplier provides the ISR Agent with details of GSP Group in which his Data Aggregator(s) will start trading and effective date, comprising:

Aggregator (half hourly and/or non-half hourly) assigned to GSP Group.

2. The Supplier provides the ISR Agent with details of when his Data Aggregator(s) will cease trading and where, comprising:

Aggregator assignment deleted.

4.5.12 Data Collector starts/stops operating in GSP Group

A Data Collector starts to operate within a GSP Group or stops operating within that GSP Group. This event may be triggered by the wider Metering System Change of Supplier event or by a Supplier appointing a new Data Collector or changing an existing Data Collector. It triggers the following input system events:

1. The Supplier provides the ISR Agent with details of GSP Group in which his Data Collector(s) will start trading and effective date, comprising:

Data Collector details entered;
Data Collector details updated;
Data Collector appointed to GSP Group.

2. The Supplier provides the ISR Agent with details of when his Data Collector(s) will cease trading and where, comprising:

Data Collector details deleted;
Data Collector in GSP Group deleted.

4.5.13 Changes to Line Loss Factor Classes

A Distributor creates a new Line Loss Factor class, withdraws a Line Loss Factor Class, changes the factors associated with a Line Loss Factor Class or changes the status of Line Loss Factor Class. It triggers the following input system event:

1. Distributor sends changes to Line Loss Factor classes, with effective dates to the Market Domain Data Agent who forwards these on to the ISR Agent, which may comprise some or all of:

Line Loss Factor codes deleted;
Line Loss Factors deleted;
Line Loss Factor codes entered;
Line Loss Factors entered;
Line Loss Factor codes updated;
Line Loss Factors updated.

4.5.14 Start of Trading on 1 April 1998

Prior to the start of trading a number of input events must take place. At some scheduled time before the first Settlement run is due, this event will occur. It triggers the following input system event:

1. The basic GSP Group data is supplied by the Distributors and Suppliers for each GSP Group, comprising:

System installation;
GSP Group Entered;
Aggregator assigned to GSP Group;
Distributor assigned to GSP Group;
Clock Change entered;
Clock Change Updated;
Line Loss Factor codes entered;
Line Loss Factors entered;
Line Loss Factor codes updated;
Line Loss Factors updated.

2. The Market Domain Data Agent distributes the initial Settlement Timetable and other market domain data, comprising:

Settlement entered;
Settlement updated;
Pool Market Domain Data loaded;
Standard Settlement Configuration entered;
Standard Settlement Configuration updated;
Time Pattern assigned to Standard Settlement Configuration;
Time Pattern Regime entered;
Time Pattern Regime updated;
Clock Interval Entered;
GSP Group Scaling Factors entered;
GSP Group Scaling Factors updated
Teleswitch Register and Contact Rules entered;
Teleswitch Register and Contact Rules updated.

4.5.15 Changes to GSP Groups

As a result of agreement by Pool Members GSP Groups are reorganised, and a GSP Group is split or merged, or details for the GSP Group change. It triggers the following input system events:

1. New GSP Group data is supplied by the Distributors and Suppliers for each GSP Group, comprising:

GSP Group Entered and flagged as Scottish if necessary;
Aggregator assigned to GSP Group;
Distributor assigned to GSP Group;
GSP Group Scaling Factors entered;
GSP Group Scaling Factors updated.

2. Old GSP Group data is archived and removed, once there are no outstanding reconciliation runs for the old GSP Group, comprising:

Archive standing data;
Aggregator assignment deleted;
Distributor deassigned from GSP Group;
GSP Group Scaling Factors deleted;
GSP Group Deleted.

3. Changes in GSP Group assignments is supplied by the Distributors and Suppliers for each GSP Group, comprising:

Aggregator assigned to GSP Group;
Aggregator assignment deleted;
Distributor deassigned from GSP Group;
Distributor assigned to GSP Group;
GSP Group Scaling Factors entered;
GSP Group Scaling Factors updated;
GSP Group Scaling Factors deleted.

4.5.16 Archiving Events

This is a scheduled event, which involves the deletion of redundant data from the system. The data that is removed is subject to the following criteria (the Archive Criteria):

The data is for a Settlement Day for which a Final Reconciliation Run has been successfully completed;
The data relates to a Settlement Day that is older than the minimum archive period as defined in the Archiving Plan (Reference 20).

It is triggered by the following input system events:

1. ISR Agent runs the archive process for a Settlement Day or range of Settlement Days, comprising:

Archive Daily Profiles;
Archive SSR Daily Data.

2. ISR Agent purges data which is subject to the Archive Criteria, comprising:

Clock Change deleted;
Clock Interval deleted;
GSP Group Scaling Factors deleted;
Line Loss Factor Codes deleted;
Profile Class deleted;
Profile deleted;
Regression Equation deleted;
Standard Settlement Configuration deassigned from Profile Class;
Standard Settlement Configuration deleted;
Supplier details deleted;
Time Pattern Regime deleted.

4.5.17 Changes to NHH BM Unit Allocation

A Supplier makes changes to the NHH BM Unit allocations, comprising:

1. Non Half Hourly BM Unit Allocation entered.

2. Non Half Hourly BM Unit Allocation updated.

3. Non Half Hourly BM Unit Allocation deleted.

4.5.18 Specify Final Dispute Expected Aggregation

BSCCo notifies the ISR Agent of the specific Data Aggregators that are expected to submit data for a range of Settlement Dates in the event of a Dispute Final Run.

5. Requirements Catalogue

5.1 Introduction

The Requirements Catalogue is divided into four sections:

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

Below this, it is structured to map onto the nine high level principles described in Section 2.1, with some reorganisation for internal functional requirements:

Functional requirements:

1. ISRA must provide an equitable mechanism to determine energy allocations	} Internal functionality - } structured as:
2. Reconciliation adjustments	} 1. SSR run functionality, and
3. Energy Volumes must balance	} 2. Daily Profile Production functionality.
4. Reporting
5. Interface functionality.

Non-Functional requirements:

6. Audit and verifiability

7. Security and control

Operational Requirements:

8. Operations

Design Constraints:

9. Design constraints, including interface design constraints.

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 numbering within the Requirements Catalogue consists of a single digit for the high level principle or functional area that each requirement supports, followed by sequential numbering within principle or functional area.

Some of the requirements cannot be captured in full in a few sentences. In these cases the details are given in the annexe at the end of the Requirements Catalogue.

The last two columns record the source of each requirement, and its resolution. The following abbreviations are used in the last two columns:

BPM - Business Process Model (from the Operational Framework)
BRT - Business Requirements Team
CR - Change Request
DFD - Data Flow Diagram
EPD - Elementary Process Description
LDM - Logical Data Model
ISR UAG - ISR User Assurance Group (a group of experts set up to support the development of the ISRA URS)
OF nnn - refers to paragraphs in the Operational Framework (reference 1)
OF Appendix n - refers to appendices in the Operational Framework (reference 1)
PTF - Profiling Task Force (a group of experts set up to define and recommend the requirements for profiling)
SIR - Settlement Issue Report
UAC - User Assurance Co-ordination team

All abbreviations are listed in the Glossary (reference 10).

5.3 Functional Requirements

The Functional Requirements are organised into four groups, according to the high level principles they support and the area of functionality to which they relate:

Internal functionality requirements, supporting high level principles 1-3, subdivided into:
- Supplier Settlement and Reconciliation run functionality
- Daily Profile Production System functionality.
Reporting and Interface requirements, subdivided into:
- Reporting requirements, supporting high level principle 4.
- Interface functionality, supporting high level principle 5.

5.3.1 Functional Requirements - Supplier Settlement and Reconciliation Runs

These requirements support the following three high level functional principles:

3. ISRA will ensure that the sum of the Suppliers’ energy values, balances the total energy in every Settlement Period, within a GSP Group.

The requirements in this subsection cover the functionality needed in the main system to run Initial Settlement and Reconciliation: those in the next subsection cover the functionality within the Daily Profile Production system.

Requirement number	Status	Description	Source of requirement	Resolution and cross reference
1.1	M	For each Settlement for a Settlement Day, ISRA must use data supplied by the CDCA; the Half Hourly (HH) Data Aggregators and the Non-HH Data Aggregators	OF Appendix A, CR R2585	Level 0 DFD
1.2	M	For any Settlement, the most recent, validated data received for the Settlement Day must be used. This includes data from Data Aggregators that has failed validation solely due to a conflict with the standing data. If such a conflict occurs, the software must produce an exception report indicating the error. The ISR software must then modify the standing data for that Settlement Day only, to agree with that provided by the Data Aggregator and re-load and validate the data, in accordance with Agreed Procedures.	BRT, SIR R605 CR R2985 (SIR R2180)	EPD 1.4.1
1.3	M	If there is a failure to submit data within the prescribed timescales for a settlement run from the CDCA; the HH Data Aggregators; or the Non-HH Data Aggregators the ISR Agent must substitute identified default data in accordance with Agreed Procedures. An exception report must be produced identifying the data defaulted. Indicative default processing is described in process 1.4.1 of the Data Flow Model.	Security and Control Framework & BRT, CR R2585	EPD 1.4.1
1.4	M	For each Settlement Day, the system must permit one or more Settlements. A Settlement requires an Initial Settlement or a Reconciliation run. The calculations performed for each Reconciliation run are the same as in Initial Settlement, but use more recently received data.	OF 407(e) 485, 486	DFDs 1.1 and 1.4 – identical processes for each run
1.5	M	ISRA must be capable of storing standing data which is required for validation of input files, as defined by the following entities on the LDM: Supplier Supplier in GSP Group Data Aggregator Data Aggregator Registration Distributor Line Loss Factor Class BM Unit for a Supplier in a GSP Group NHH BM Unit Allocations. Screens will be available for entering and updating this data. Data entered must be validated as described in processes 1.3.1, 1.3.2, 1.3.4, 1.3.5, 1.3.6, 1.3.8, 1.3.9 and 1.3.10 of the Data Flow Model. Additionally, a facility will be available for electronically loading Line Loss Factor Class data and BM Unit for a Supplier in a GSP Group from files prepared by the Market Domain Data Agent.	Security and Control Framework CR R2641 CR R1335	LDM EPDs 1.3.1, 1.3.2, 1.3.4, 1.3.5, 1.3.6 1.3.8 1.3.9 and 1.3.10. EPD 2.6
1.6	M	The system must store data relating to the latest Settlement and its associated SSR Run for each Settlement Day, for subsequent reporting. The data to be stored is defined by the following entities on the LDM: Aggregated DA Supply Period Consumption, GSP Group Take, Settlement Period Line Loss Factor Class, Aggregated Supplier Period Consumption, BM Unit Period Consumption, Period Supplier Energy Volumes, Supplier Purchase Matrix, Profiled SPM and CDCA Settlement GSP Group.	ISR UAG, Change Requests 011 and 063 CR R2585	LDM
1.7	M	For each SSR run, the system must determine values of profiled consumption for each Supplier, by BM Unit using the Supplier Purchase Matrix, Period Profile Class coefficients, and the NHH BM Unit allocations. The processing must be as described in processes 1.4.8.1 and 1.4.8.2 of the Data Flow Model.	OF 459, Change Request 011, 058 CR R2641	EPDs 1.4.8.1, 1.4.8.2
1.8	M	For each SSR run, the system must calculate the line losses associated with the profiled consumption, using Line Loss Factors provided by the Distributor (BSCCo sends the Line Loss Factors provided by the Distributor to ISRA). The processing must be as described in process 1.4.8.3 of the Data Flow Model.	OF 476	EPD 1.4.8.3
1.9	M	For each SSR run, ISRA must calculate GSP Group Correction Factors, as described in process 1.4.9.1 of the Data Flow Model, and apply it to appropriate components of all BM Units’ consumption, in order to ensure that no demand measured at a Grid Supply Point within the GSP Group is left unattributed to Suppliers.	OF 407(f), 479, 480 and 4 CR 058, CR R2641	EPD 1.4.9.1
1.91	M	For each SSR run, ISRA must issue GSP Group Correction Factors to the SVA Aggregation Service for use in SVA_AS_F001	CP1517	EPD 1.4.9.1
1.10	M	The calculation of GSP Group Correction Factors in ISRA must be configurable using scaling factors, as described in process 1.4.9.1.	UAC	EPD 1.4.9.1
1.11	M	ISRA must facilitate the maintenance of the GSP Correction Factor scaling factors, as described in EPD 1.3.3 of the Data Flow Model.	UAC	EPD 1.3.3
1.12	M	For each Supplier Settlement and Reconciliation run, the system must sum all of the components of consumption to calculate the Deemed Take for each BM Unit, as described in process 1.4.9.2 of the Data Flow Model.	OF 483 CR R2641	EPD 1.4.9.2
1.13	M	In calculating the Deemed Take for each BM Unit, the system must treat any Non-Pooled Generation for that BM Unit as negative consumption, and must thus reduce their Deemed Take.	OF 418(a) CR R2641	EPD 1.4.9.3
1.14	M	The total Deemed Take over all BM Units in the GSP Group must balance with the GSP Group Take supplied by the CDCA.	OF 407 (f) & BRT CR R2585, CR R2641	EPD 1.4.9.1
1.15	M	If any Supplier should be left with a negative Deemed Take in a GSP Group due to Non-Pooled Generation, ISRA will report a negative consumption total to the SAA where generation exceeds consumption for a Supplier in a GSP Group.	OF 418(b) CR R2626	EPD 1.4.9.2
1.16		This Requirement is no longer used.
1.17		This Requirement is no longer used.
1.18	M	Any energy for which no BM Unit has been specified, or for which an invalid BM Unit has been specified, will be allocated to the Base BM Unit for that Supplier and GSP Group (it should be noted that a Base BM Unit is the same as a Default BM Unit). If no Base BM Unit exists (despite the rule that Suppliers will register a Base BM Unit in CRA for all GSP Groups), the SSR Run process will produce an error message and the Run will continue with that data excluded from the Settlement. A warning will be produced when energy in an invalid BM Unit is reallocated to the Base BM Unit.	CR R2641	EPD 1.4.8.2
1.19	M	The system must be capable of calculating half hourly gross demand for each BM Unit for use by the Settlement Administration Agent	CFD
1.20	M	The system must be capable of calculating quarterly Supplier volume data for use by BSCCo	P315	EPD 1.2.12

5.3.2 Functional Requirements - Daily Profile Production System

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
2.1	M	For each GSP Group and trading day, the system must calculate a set of period Profile Class coefficients to be used for each permitted combination of Profile Class, Standard Settlement Configuration and time pattern regime.	OF 459-460, Security and Control Framework	EPDs 2.3.1 to 2.3.4
2.2	M	For non Switched Load Profile Classes, the period Profile Class coefficients must be determined by calculating basic Period Profile Coefficients as described in process 2.3.2 of the Data Flow Model, and then chunking these as described in process 2.3.4	OF 459-460	EPD 2.3.2, 2.3.4
2.3	M	For Switched Load Profile Classes, the period Profile Class coefficients must be determined by: calculating basic Period Profile Coefficients for both the Base and Switched Load profiles as described in process 2.3.2 of the Data Flow Model. combining the two as described in process 2.3.3 chunking the resultant profile as described in process 2.3.4.	OF 465	EPD 2.3.2, 2.3.3, 2.3.4
2.4	D	The algorithmic profiling process (2.3.3 in the Data Flow Model) should produce separate profiles for the Switched Load and Base Load components, and pass both of them to the chunking process. This is to allow future modification of process 2.3.3 to model switching diversity (i.e. the random element programmed into teleswitches), which causes the low and normal register profiles to overlap, without impacting the chunking process.	PTF Change Request 233	Logical Design
2.5	M	The system must be capable of storing Profile Class data, as defined by the Profile Class and Profile entities of the LDM. Screens must be available for entering and updating this data. Data entered must be validated as described in process 2.5.1 of the Data Flow Model.	OF 462	EPD 2.5.1
2.6	M	The system must be capable of storing regression equation data, as defined by the Profile Set, GSP Group Average EAC, Profile Regression Equation Set, Period Regression Equation and Regression Coefficient entities of the LDM. Data entered must be validated as described in process 2.5.2. of the Data Flow Model.	OF 459 & 461 Change Request 049	LDM EPD 2.5.2
2.7	M	The system must be capable of storing Standard Settlement Configuration data, as defined by the following entities on the data model: Standard Settlement Configuration Measurement Requirement Time Pattern Regime Clock Interval Valid Measurement Requirement Profile Class Valid Settlement Configuration Profile Class Teleswitch Register Rule Teleswitch Contact Rule An interface must be available for loading this data, as described in requirement 5.5.14. Screens must also be available for entering and updating this data. Data entered must be validated as described in processes 2.2.1 to 2.2.5 and 2.2.8 to 2.2.9 of the Data Flow Model.	PTF Change Request 290v4, CR R1335	LDM EPD 2.2.7 EPDs 2.2.1-5 2.2.8-2.2.9
2.8	M	The system must have an interface to a Teleswitch Agent, enabling it to capture a file of teleswitch contact intervals for each UTC (i.e. GMT) day, reflecting the actual teleswitch messages broadcast by the Central Teleswitch Control Unit for that day to teleswitched metering systems, as described in process 2.2.6 of the Data Flow Model.	PTF Change Request 365 Change Request 290v4	EPD 2.2.6
2.9	M	The system must provide screens for browsing, entering, updating and deleting teleswitch contact intervals, as described in process 2.2.10 of the Data Flow Model.	PTF Change Request 290v4	EPD 2.2.10
2.10	M	For any DPP run, the system must use the most recently submitted teleswitch data. If there is a failure to submit the teleswitch data for a Settlement Day, prior to the first Settlement run for that day, defaults in accordance with Agreed Procedures must be substituted. The manual interface for entering teleswitch contact intervals must be used for this.	BRT Change Request 290v4	Logical Design
2.11	H	If teleswitch data for a Settlement Day does not exist prior to the first Settlement run for that day, defaults in accordance with Agreed Procedures must be substituted. The ISRA Operator must enter into the system the Settlement Date which is to be used as a substitute. The system will automatically pick up the appropriate data based on that default Settlement Date. Default processing is only required under exceptional conditions and this should be made clear to the operator through appropriate warnings and an exception report.	BRT, Change Request 232 Change Request 290v4	Logical Design
2.12	M	The system must be capable of storing data relating to GSP Groups, as defined by entity GSP Group on the LDM. Screens must be available for entering and updating this data, as specified in process 2.1.1 of the Data Flow Model.	ISR UAG	EPD 2.1.1
2.13	M	The system must be capable of storing calendar and daily parameter data, as defined by entities Settlement, Settlement Day, Daily Profile Parameters and Clock Time Change on the LDM.	PTF	LDM
2.14	M	The system must provide screens for entering and updating calendar details, as described in process 2.1.2 of the Data Flow Model. Additionally, a facility will be available for electronically loading Settlement Day data, i.e. Day Type and Season Id , from a file prepared by the Market Domain Data Agent.	PTF, CR R1335	EPD 2.1.2 EPD 2.6
2.15	M	The system must provide screens for entering daily temperature data and calculating noon-effective temperatures, as described in process 2.1.3 of the Data Flow Model.	PTF	EPD 2.1.3
2.16	M	The system must provide a mechanism for loading a file of sunset times for each GSP Group, as described in process 2.1.4 of the Data Flow Model.	PTF	EPD 2.1.4
2.17	M	The system must permit the profiles for a given day and GSP Group to be recalculated with corrected input data, prior to the final run of Initial Settlement. The calculation process is described in process 2.3 of the Data Flow Model.	PTF	EPD 2.3.1 to 2.3.4
2.18	M	The system must be capable of generating and storing Period Time Pattern State data for a given day, based upon the Clock Intervals and the teleswitch intervals. The process must be as described in process 2.3.1 of the Data Flow Model.	ISR UAG, PTF	EPD 2.3.1
2.19	M	The system must be capable of storing Standard Settlement Configurations which define switching times in either GMT and clock (local) time, in order to allow GMT and local time patterns to be profiled with the same accuracy.	Change Request 052	EPDs 2.2.2, 2.2.5, 2.2.7 & 2.3.1
2.20	M	The system must be capable of deriving teleswitch register intervals from the teleswitch contact intervals provided by the Teleswitch Agent, using a set of teleswitch register and contact rules supplied by Suppliers as part of Market Domain Data.	PTF Change Request 290v4	EPD 2.3.1
2.21	M	The system must be capable of using Scottish Regression Coefficients between BETTA Start Date and Scottish Regression Coefficients End Date, and of using the Scottish Day Type.	BETTA
2.22	M	The system must be capable of generating time pattern states for dummy HH SSCs based on mapping information provided by the Distributor	P300

5.3.3 Reporting Requirements

These requirements support the following high level principle:

4. ISRA will generate reports for Suppliers and Distributor (including DUoS), NETSO TUoS, and the PFA, that detail the results of the calculations performed.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
4.1		This Requirement is no longer used.
4.2	M	ISRA must provide a report of deemed Supplier Consumptions to NETSO Transmission Use of System (TUoS). To facilitate the calculation of dispute charges, ISRA must additionally include in this report these deemed Supplier Consumptions split by corrected (i.e. subject to group correction) and non corrected (i.e. not subject to group correction) consumption. To facilitate the calculation of Transmission Network Use of System (TNUoS) charges, ISRA must additionally include in this report these deemed Supplier Consumptions split between half hourly and non-half hourly consumption for each Supplier Balancing Mechanism Unit (BM Unit). To support the disapplication of Network Charges for Storage Facilities, the report will also include daily and period gross demand from Storage Facilities and Corrected daily and period gross HH demand. Further details are given in the description of elementary process 1.4.9.4 in the Data Flow Model.	OF BPM, OF Table 4.1 (process 20), OF Appendix A, CR R1255 Appendix I, SVAA RF 19	EPD 1.4.9.4
4.3	M	ISRA must be able to produce one report per Supplier from each SSR run, detailing the results from the deemed take calculation and the data used to derive them. Specifically, the reports must give details of: non-HH energy volume data (aggregated EACs and AAs) used in the calculation for the Settlement run the non-HH energy volumes, by consumption class, after profiles and line losses have been applied HH energy volume data (aggregated HH meter data) used in the calculation for the Settlement run Calculations of deemed take, including GSP correction time and date stamps of each of the relevant data files used in the SSR run. Profile Production, Data Aggregation, and CDCA file set runs used to derive input data for the run, in terms of Settlement Dates, Run Numbers and types, Data Aggregator and type, CDCA Set number and other identification fields as appropriate Details of GSP Group Consumption Totals both before and after GSP Group Correction.	ISR UAG, OF Appendix A, Change Request 088 CR479	EPDs 1.2.1 to 1.2.5.
4.4	M	ISRA must produce Supplier and Data Collector reports detailing the results of the profiling calculations, as follows: Standing Profile Data Report Daily Profile Data Report Standard Settlement Configuration Report Teleswitch Contact Interval Data Report The details of each of these are given in the description of elementary process 2.4.1 in the Data Flow Model.	PTF Change Request 290v4	EPD 2.4.1
4.5	M	All reports produced by ISRA must be made available in both man and machine readable formats. All reports must be made available in both printed and electronic form.	EPFAL, ISR UAG	Logical Design
4.6	D	ISRA should provide ad hoc reporting facilities for all data for Suppliers and other authorised recipients. These reports must be available in both man and machine readable format and in printed and electronic form.	BRT	Logical Design
4.7	M	ISRA must be able to produce one report per Supplier for each SSR Run detailing Distribution Use of System (DUoS) for non-half hourly metering systems. Each Supplier only receives the report relating to him. The Distribution Business receives reports relating to all Suppliers using Line Loss Factor Classes in his domain. Specifically, the DUoS report must, for each Supplier, give details of: GSP Group Settlement (Settlement Date and Settlement Code) Line Loss Factor Class (Distributor and Line Loss Factor Class Id). Within each Line Loss Factor Class, the report must give all combinations of: Profile Class Standard Settlement Configuration Time Pattern Regime. Within each combination of Valid Settlement Configuration Profile Class and Time Pattern Regime, the report must give details of: Supplier Purchase Matrix Total - Estimated Consumption {Estimated Annual Consumption or Unmetered Consumption}, and - Actual Consumption {Annualised Advance} Counts of the total number of MSIDs for each of these. For each Settlement Period, the report must also give details of: Profiled Supplier Energy Volume Totals. In addition, the report must give - for each Settlement Period and Consumption Component Class - the GSP Group Correction Factor and GSP Group Correction Scaling Factor.	Change Requests 011, 088 and 344	EPD 1.4.9.5
4.8		This Requirement is no longer used.
4.9		This Requirement is no longer used.
4.10		This Requirement is no longer used.
4.11	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.	CR R1177	Physical Design
4.12	M	ISRA must provide a report of BM Unit Supplier Take Energy Volume Data to SAA for each SSR run, giving details of allocated energy volumes for a Settlement Day by GSP Group, Supplier, BM Unit and Settlement Period.	CR R2641	EPD 1.4.13.2
4.13	M	ISRA must provide to those Suppliers who are implementing BM Units a Supplier BM Unit Report, containing details of the Supplier’s valid BM Units, NHH BM Unit allocations, the HH consumption/generation data input into the system and the combined HH and NHH consumption/generation by BM Unit and Consumption Component Class calculated by the SSR run.	CR R2641	EPD 1.2.7

5.3.4 Interface Functionality Requirements

These requirements support the following high level principle:

5. ISRA will support interfaces with all relevant parties and systems to facilitate the timely and accurate provision or receipt of data.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
5.1	M	ISRA must support the automated and manual interfaces described in the Data Flow Model, as follows: 1. Inputs from: Data Aggregators (HH) Data Aggregators (non-HH) Distributor Central Data Collection Agent ISR Agent Market Domain Data Agent Profile Administrator Teleswitch Agent 2. Outputs to: Suppliers Distributor TUoS Settlement Administration Agent Non HH Data Collector(s) Details of the data items passed across each interface are given in the I/O Descriptions (External Data Flow Descriptions) in the Data Flow Model.	OF BPM, OF Appendix A Change Requests 007, 156, 365, 290v4, R1318 and R1335 CR R2585	Data Flow Model - external interfaces
5.2	M	ISRA infrastructure must enable secure and timely external transfer of data - both inputs and outputs. It must keep track of all data which is sent to and received from outside ISRA. It must ensure that data sent, is sent as soon as possible after it is created.	Security and Control Framework	Physical design
5.3	M	ISRA must validate any incoming data whenever possible and report any errors to the source of the data, as specified in the following processes of the Data Flow Model: 1.1.1 to 1.1.5, 1.3.1 to 1.3.7, 1.5 2.1.1 to 2.1.4, 2.2.1 to 2.2.10, 2.5.1, 2.5.2 2.6.	Security and Control Framework Change Requests 290v4, R1318 and R1335	EPDs 1.1.1-5, 1.3.1-7, 1.5. 2.1.1-4, 2.2.1-10, 2.5.1-2, 2.6.
5.4	M	ISRA’s interfaces for input and output data must comply with 1998 specifications of units of measure, that is the interfaces must be consistent in their use of units of measure (such as MWh) as appropriate.	1998 Design Authority Change Request 130	Logical Design
5.5	M	ISRA must have a facility to input profiling parameters, e.g. time of sunset, calendar details, and temperature. The values input must be validated and processed by ISRA as described in Processes 2.1.2 to 2.1.4 of the Data Flow Model.	OF 461	EPDs 2.1.2 to 2.1.4
5.6	M	ISRA must have a facility to receive and load profile regression equations electronically provided by the Profile Administrator. These equations must vary by season and day type. The equations must be validated by ISRA against the list of data items given in Process 2.5.2 of the Data Flow Model.	OF 458 (b), Security and Control Framework	EPD 2.5.2
5.7	M	ISRA must be able to accept changes to existing profiles and new profiles electronically after 1 April 1998. These must be validated as described in Process 2.5.1 of the Data Flow Model.	OF 466, Security and Control Framework	EPD 2.5.1
5.8	M	ISRA must be able to accept Time/Teleswitching data electronically supplied for profile pre-processing that varies by day.	UAG Change Request 290v4	EPD 2.2.5, 2.2.6
5.9	M	ISRA must have a facility to receive and process Line Loss Factors electronically supplied by the Distributor. ISRA must validate these Line Loss Factors, as described in Process 1.1.2 of the Data Flow Model.	OF 476, Security and Control Framework	EPD 1.1.2
5.10	M	ISRA must validate Settlements data electronically received from the CDCA, as described in Process 1.1.1 of the Data Flow Model.	Security and Control Framework CR R2585	EPD 1.1.1
5.11	M	ISRA must validate aggregated half hourly meter data received electronically from Data Aggregators, as described in Process 1.1.3 of the Data Flow Model.	Security and Control Framework	EPD 1.1.3
5.12	M	ISRA must validate Supplier Purchase Matrix data (non-HH aggregated EACs and AAs) received electronically from Non-HH Data Aggregators, as described in Process 1.1.4 of the Data Flow Model.	Security and Control Framework	EPD 1.1.4
5.13	M	ISRA must provide daily totals of Profile Coefficients electronically to Data Collector for use in the EAC System as defined in process 2.4.2 of the Data Flow Model. Each Data Collector must receive data only for those GSP Groups in which they are active. In order to enable this, the system must provide a facility for specifying which Data Collectors are appointed in each GSP Group.	OF Appendix A	EPD 2.4.2 EPD 2.1.5
5.14	M	ISRA must have a facility to load a file of Standard Settlement Configurations and associated data prepared by the Market Domain Data Agent. The data must be validated and loaded as described in process 2.2.7 of the Data Flow Model.	ISR UAG Change Requests 156 and R1335	EPD 2.2.7
5.15	M	In addition to requirement 5.0, ISRA must have a facility to enable the Standard Settlement Configurations and associated data prepared by the Market Domain Data Agent, to be entered manually (see requirement 2.0)	PTF Change Request 156, 290v4	EPDs 2.2.1 to 2.2.5, 2.2.8, 2.2.9
5.16	M	In addition to requirement 5.13, ISRA must have the facility to allow the ISR Agent to produce daily totals of Profile Coefficients for a specified GSP Group and for each Settlement Day in a range of Settlement Days, in response to a request from a Data Collector.	Change Request 7 (Implementation Team) Change Request 316	EPD 2.4.2
5.17		This Requirement is no longer used
5.18		This Requirement is no longer used
5.19	M	ISRA must be able to receive and load Settlement Timetable data from a file prepared by the Market Domain Data Agent. The data must be validated as described in Process 1.5 of the Data Flow Model. No automatic deletions must be allowed as part of the load process.	CR R1318	EPD 1.5
5.20	M	ISRA must be able to receive and load Settlement Day and Line Loss Factor Class data from a file prepared by the Market Domain Data Agent. The data must be validated as described in Process 2.6 of the Data Flow Model. No automatic deletions must be allowed as part of the load process.	CR R1335	EPD 2.6
5.21	M	ISRA must be able to receive and load Stage 2 BM Unit registration data from a file prepared by the Market Domain Data Agent. The data must be validated as described in Process 2.6 of the Data Flow Model. No automatic deletions must be allowed as part of the load process.	CR R2641	EPD 1.6
5.22	M	ISRA must be able to receive and hold NHH BM Unit allocations from Suppliers.	CR R2641	EPD 1.3.8
5.23	M	ISRA must accept and use data from only one file per GSP Group per SSR Run from each Data Aggregator. This file may be in BM Unit format or non-BM Unit format.	CR R2641	EPD 1.1.3
5.24	M	All interfaces with NETA central service providers, CDCA and SAA, must generate acknowledgement receipts. This is an operational requirement rather than a software requirement.	CR R2585	EPD 1.1 to EPD 1.6
5.25	M	ISRA must store an audit record of any standing data changes resulting from files received electronically from HH Data Aggregators or from Non-HH Data Aggregators as described in Processes 1.1.3 and 1.1.4 of the Data Flow Model respectively.	CP1093	E.P.D 1.1.3, E.P.D 1.1.4
5.26	M	ISRA must have the facility to load Final Dispute Expected Aggregation data from a file provided by BSCCo as described in Process 1.3.10 of the Data Flow Model	CP1478	EPD 1.3

5.4 Non-Functional Requirements

The non-functional requirements for ISRA are in essence those concerned with Audit, Security and Control. Operational requirements and Design Constraints are covered in separate sections.

5.4.1 Audit Requirements

These requirements support the following principle:

Audit requirements will impact ISRA in the following areas:

audit and control of data used which is entered on-line through a manual interface;
the final data aggregation, deemed take and purchase calculations;
production of reports for Suppliers and auditors showing data used in production of purchase calculations;
retention of inputs used in calculation of deemed take and Supplier Purchases;
indication of which Existing Settlement run provided the pricing data for a Supplier Purchase calculation.

There are some requirements that support the principle that ISRA should be able to re-create the results of any of its calculation processes when repeated with the same input data. They are included here with the Audit requirements, as they support the same high-level principle.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
6.1	M	ISRA must apply version controls to all data received. It must ensure that all data received has date and version stamps attached to it, identifying the SSR run and settlement day to which it relates (for data supplied in support of an SSR run).	Pool Auditor CR309	Logical Design
6.2	M	ISRA must store the following timestamps against incoming data: File Creation Timestamp (to ensure files are loaded in correct order) File Received Timestamp (date and time at which file was detected in input directory, for audit purposes) File Processed Timestamp (date and time at which file was processed, for audit purposes)	Pool Auditor CR309	Logical Design
6.3	M	ISRA must perform checks that the date and version stamps on data received are consistent with each other and with the data, and report any discrepancies to the party supplying the data.	Pool Auditor	Logical Design
6.4	M	ISRA must apply version controls to all data that it outputs. It must ensure that all data output has date and version stamps attached to it, identifying the SSR run and settlement day to which it relates (for data supplied in support of an SSR run), and the date and time at which it was output by ISRA.	Pool Auditor	Logical Design
6.5	M	ISRA must undertake validation and checking wherever practical and possible for reasonableness, range or actual value and must produce appropriate error, warning and inconsistency reports. (Refer also to the more specific validation requirements, listed in the interfaces section of the Requirements Catalogue and to requirement 6.13 and 6.14 below.)	Security and Control Framework	Detailed in interfaces requirements
6.6	M	ISRA must be designed to facilitate the common use of coding between the Existing Settlement and the ISRA System, in particular for Supplier Codes and Pool Member Codes.	EPFAL	Common codes (to be defined)
6.7	M	ISRA must supply sufficient information (including the CDCA Set Number) to SAA to enable them to reconcile ISRA output with the output from CDCA.	EPFAL, Security and Control Framework	Detailed in reporting requirements
6.8		This Requirement is no longer used.
6.9	M	For all reports produced by ISRA, it must be clear what input data was used and to which trading day the report relates	Pool Auditor	Logical Design
6.10	M	The data defining particular SSR runs must be sufficient to allow the run to be linked to the relevant CDCA run that provided certain of the data used.	Pool Auditor, Security and Control Framework	LDM
6.11	M	The system must facilitate the re-performance of program calculations including provision of electronic data to the Pool Auditor.	Pool Auditor, Security and Control Framework	Logical Design
6.12	M	An audit trail must be provided for the SSR run process.	Security and Control Framework	Physical design
6.13	M	ISRA must archive the data for that trading day if that day is subject to the Archive Criteria.	Security and Control Framework	Function ‘Archive ISRA Data’
6.14	M	ISRA must enable dispute final reconciliation runs to be performed up to 24 months after the final reconciliation, subject to appropriate authorisation and controls.	Security and Control Framework	(Logical Design)
6.15	M	The system must be capable of holding the standing data that is entered into ISRA through a manual on-line interface for as long as it is valid and for as long as required to support Reconciliation runs up to 24 months.	Pool Auditor	(Logical Design)
6.16	M	ISRA must check that the values of all numeric fields input to the system lie within pre-defined valid ranges. If they do not, the system must either refuse to accept the data, or issue a warning message, as defined during Logical Design. This check must also be applied to key calculated values, as defined during Logical Design. It must be possible to specify the valid range for each attribute at the time the system is installed.	Pool Auditor, ISR Expert Group	Logical Design
6.17	H	ISRA must provide an on-line screen allowing the ISRA Operations Supervisor to change the valid range for each numeric field (see requirement 6.17). An Effective Date must be supplied for each change, in order to allow the valid ranges to change over time.	ISR Expert Group	Logical Design
6.18		This Requirement is no longer used.
6.19	M	ISRA must facilitate read access to: all source code and program structures all data held in the system.	Pool Auditor	Logical Design
6.20	H	ISRA should provide ad hoc reporting facilities for all data for audit purposes. These reports must be available in both man and machine readable format and in printed and electronic form.	Pool Auditor	Logical Design
6.21	M	Standing data produced during Daily Profile Production to be used for a Settlement Day must be finalised prior to the final run of Initial Settlement and under normal circumstances must not be updated thereafter. Thus the Daily Profile Production run cannot be rerun after final Initial Settlement.	BRT, Change Request 094	Logical Design
6.22	M	Standing data errors that are identified after the Initial Settlement run must only be corrected through a rigorous change control procedure in accordance with Agreed Procedures. ISRA must provide facilities to enable such data to be changed only with suitable authorisation. It is recognised that changes to some data items after the Initial Settlement run may invalidate the Period Profile Class Coefficients and Daily Profile Coefficients that have been calculated.	BRT & Pool Auditor Change Request 310	Logical Design
6.23	M	Standing data changes made through the change control procedure mentioned in 6.6.22 must result in the automatic production of an audit report. The audit report should indicate where a change to a standing data item may invalidate one or more sets of Period Profile Class Coefficients or Daily Profile Coefficients.	BRT & Pool Auditor Change Request 310	Logical Design

5.4.2 Security and Control Requirements

The requirements in this group support the following principle:

7. ISRA will comply with Pool’s 1998 Programme security and control framework and the Pool’s 1998 Programme’s standard codes and naming conventions.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
7.1	M	The technological infrastructure used for ISRA must provide secure and timely data and information transfers between constituent modules of ISRA, as well as between ISRA and the external modules.	Security and Control Framework	Physical design
7.2	M	Controls must be provided to ensure that data is transferred completely between separate ISRA modules; data systems that receive data from ISRA can check that the data has been completely and accurately received; and different versions of transferred data can be accurately identified and tracked.	Pool Auditor, Security and Control Framework	Physical design
7.3	H	ISRA should be compliant with BS7799 (Code of Practice for Information Security Management).	Security and Control Framework	Physical design
7.4	M	Appropriate facilities must be provided to allow the archival (and retrieval) of all input data files received by ISRA from feeder systems. This data must be retained for a minimum of twenty-eight months.	Security and Control Framework	Function ‘Archive ISRA Data’ and Physical design
7.5	M	Appropriate facilities must be provided to allow the archival (and retrieval) of all data entered directly into the system by the ISR Agent. This data must be retained for a minimum of twenty-eight months.	Security and Control Framework	Function ‘Archive ISRA Data’ and Physical design
7.6	D	Appropriate facilities should be provided to allow the archival (and retrieval) of all output files generated during the operation of the system. This data should be retained for a minimum of twenty-eight months.	Security and Control Framework	Function ‘Archive ISRA Data’ and Physical design
7.7	M	ISRA must provide facilities to control access and operation rights of users and groups of users, e.g. to modify any data received into the system (Exact access rules and controls to be defined, in conjunction with the owners of the data).	Pool Auditor, Security and Control Framework	Logical and Physical Design
7.8	M	Where changes are made to standing data, 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 the change; - the nature of the change; and - the date and time of the change. Access control for such facilities must be commensurate with the risk. Management controls and procedures (such as Service Level Agreements) must be in place to ensure changes are made in a timely fashion.	Pool Auditor, Security and Control Framework	Logical and Physical Design
7.9	D	ISRA should monitor for possible attempts to breach security, and should be able to report on them. (Exact monitoring rules to be agreed and defined.)	Pool Auditor, Security and Control Framework	Logical and Physical Design
7.10	M	ISRA must provide audit facilities to track any changes to data between Initial Settlement and any of the subsequent reconciliation runs for any trading day. These trails should only be output when specifically requested by a suitably authorised operator.	Audit team, Security and Control Framework	Logical Design
7.11	M	ISRA must be able to supply data from archive for any trading day up to twenty-eight months later, in printed and electronic form, both to support the disputes procedure and for Audit purposes.	OF 488 Pool Auditor	Logical Design
7.12	D	ISRA should retain all input data and software used for a trading day until twenty-eight months after the trading day, in a form in which it can readily be reused to repeat an SSR run for the trading day, both to support the disputes procedure and for Audit purposes.	OF 488 Pool Auditor	Logical Design
7.13	M	ISRA must retain all input data and software used for a trading day until two years after the trading day, such that it is easily accessible and in a form in which it can be reused to repeat an SSR run for the trading day.	Pool Auditor	Logical Design
7.14	D	ISRA should retain, on-line, all input and output data for a trading day until two years after the trading day.	Pool Auditor	Logical Design
7.15	M	ISRA must provide access controls on data input, with controllable access levels allowing greatest security to be maintained for only the most critical data.	Pool Auditor	Logical Design
7.16	M	ISRA must provide access controls on reporting, with controllable access levels allowing greatest security to be maintained for only the most sensitive reports.	Pool Auditor	Logical Design
7.17	M	ISRA must support the 1998 programme in ensuring the consistency of shared standing data across all 1998 systems.	Pool Auditor	Logical Design
7.18		This Requirement is no longer used.
7.19		This Requirement is no longer used.
7.20		This Requirement is no longer used.
7.21		This Requirement is no longer used.
7.22		This Requirement is no longer used.
7.23		This Requirement is no longer used.
7.24		This Requirement is no longer used.
7.25	M	All reports produced by ISRA must be made available in both man and machine readable formats. All reports must be made available in both printed and electronic form.	EPFAL, ISR UAG	Logical Design
7.26		This Requirement is no longer used.
7.27	M	Performance Measurement for Non Half hourly Data Aggregators must include reports of the number of times aggregators fail to send SPM files and Performance Measurement for Half hourly Data Aggregators must include reports of the number of times aggregators fail to send HH metering files.	Change Request 231	Logical Design

5.5 Operational Requirements

5.5.1 Operational Requirements

These requirements support the following principle:

8. The design and implementation of ISRA shall not prevent the system, given an appropriate hardware environment, being operated to meet the prescribed settlement and reconciliation schedule.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
8.1	M	It must be possible to run ISRA Final Reconciliation for any Settlement Day, up to 24 months after the Settlement Day.	OF 488 ISR UAG	Logical and Physical Design
8.2	M	It must be possible to rerun ISRA for any settlement day, up to 24 months after the Settlement Day.	OF 488 ISR UAG	Logical and Physical Design
8.3	D	Beyond Final Reconciliation, it should be possible to do runs of ISRA, in support of the disputes procedure or for audit purposes up to 7 years after the Settlement Day.	OF 488 ISR UAG	Logical and Physical Design
8.4	M	ISRA must not permit reconciliation runs after Final Reconciliation for any reason other than: audit in support of disputes procedures.	OF 488 ISR UAG	Logical and Physical Design
8.5	M	The set of calculations in ISRA to apply profile shapes and line losses, calculate the deemed take for each BM Unit must be performed in discrete units, called runs. Each run of SSR must process the data for the selected GSP Groups for a single whole settlement day. A settlement day is measured in local clock time.	OF 459, 479, 482, 483 Change Request 058	LDM and EPDs 1.4.1 to 1.4.13
8.6	M	ISRA must be able to process specified volumes of business events (indicated in the annexe) e.g. receipt of data from Data Aggregators, when run in the proposed hardware and software environment.	OF 204, 205	Physical design
8.7	M	ISRA must be able to process specified volumes of settlement (indicated in the annexe) e.g. number of Suppliers, number of timeswitch instructions, when run in the proposed hardware and software environment.	OF 205	Physical design
8.8	M	ISRA must be able to process specified volumes of standing data, detailed and explained in the annexe, e.g. profiles, when run in the proposed hardware and software environment. ISRA must be able to achieve this without breaching any software limits, array limits, or performance requirements.	URS Team	Physical design
8.9	M	The ISRA 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 an SSR run or in a day. For example the number of Suppliers, or the number of time patterns, could vary greatly between SSR runs executed on the same day.	URS Team	Physical design
8.10	M	The ISRA system and its proposed hardware and software environment must be scaleable, i.e. must not prevent volumes of data in excess of those specified in the annexe being processed, and must not cause the cost to escalate out of proportion to the increase in the volumes of data and of processing.	URS Team	Physical design
8.11	M	ISRA must be able to meet the published Settlement Timetable. A schedule of runs must be defined by Pool members, but is expected to be set at 1 Settlement and 4 Reconciliation runs for each Settlement Day.	OF 493, Change Request 94	Physical design
8.12	M	ISRA must, in a working day, be able to complete 3 days of Settlement Runs to allow for weekends.	ISR Expert Group	Physical Design
8.13	H	To allow for one day bank holidays ISRA should be capable of performing 24 runs (3 days) during a working day.	ISR Expert Group	Physical design
8.14	D	To allow for the major bank holidays, ISRA should be capable of performing 30 runs (4 days) during a working day.	ISR Expert Group	Physical design
8.15	M	Each run of SSR must use the most recent data available at the time from the Half Hourly and Non-HH Data Aggregators.	OF 485	EPDs 1.1.3, 1.1.4
8.16	M	ISRA must always be able to complete the Final Initial Settlement run, and deliver the required data to SAA to allow Settlement within agreed timescales. In doing this ISRA must operate within the constraint of the published Settlements Timetable.	OF 432	Physical design, Settlement Timetable to be defined
8.17	M	ISRA must make available the validated daily profile totals to the Non-HH Data Collectors for each GSP Group, for each Settlement Day, for all settlement classes in use on the Settlement Day, in accordance with the published Settlement Timetable.	ISR UAG	Physical design
8.18	M	For each Settlements Class on each Settlement Day, the ISRA daily profile totals must be the exact sum of the half hourly Profile Coefficients.	OF Appendix A, ISR UAG	EPD 2.4.2
8.19	M	The half hourly profile weights used by ISRA to profile the aggregated EAC and AA data must be reported to Suppliers on a daily basis.	OF 408, ISR UAG	EPD 2.4.1
8.20	M	ISRA must ensure that profile weights for a Settlement Day are not amended after Final Initial Settlement.	ISR UAG	EPD 2.3.1
8.21	M	If one or more Data Aggregators (or other Suppliers of data required for an SSR run) fail to supply valid, timely, and complete data, ISRA must default the data as described in process 1.4.1 and issue a report as outlined in that process.	BRT	EPD 1.4.1
8.22	M	The language to be used for all user interfaces in ISRA must be English.	URS Team	Later stages of ISRA development
8.23	M	The ISRA system must meet defined service levels such that the system can satisfy the operational, scalability and capacity requirements stated in this section. The system must be able to run on every business day, it must be capable of running for every calendar day, for each type of Settlement.	URS Team	Logical and Physical Design
8.24	M	The ISRA system must provide facilities e.g. (backup, restore and restarting of jobs) to allow recovery following hardware failure or other unexpected errors.	Security & Control Framework	Logical and Physical Design

The full definition and the physical attributes of the interfaces with external component systems will be available at the end of the Logical Design stage.

5.6 Design Constraints

5.6.1 Design Constraints - Interfaces and Effect on Related Systems

These requirements support the following principle:

9. The design and implementation of the ISRA will not adversely constrain the operation and performance of Central Data Collection Systems or the production of TUoS charges.

Requirement number	Status	Description	Source of requirement	Resolution / Cross reference
9.1	M	ISRA, its software, its proposed hardware, and its interfaces, must be compatible with the Systems architecture.	OF Section 6	Logical and Physical Design, Systems architecture when defined
9.2	M	There must be no loss of data or detrimental effect on any other systems when ISRA is unavailable.	URS Team	Physical design
9.3	M	ISRA software, its proposed hardware, and its interfaces, must not compromise the integrity of the Trading Arrangements- their business processes, software, data, and their operating environment.	OF 304d	Existing systems and processes, and later stages of development of ISRA

5.7 Annex To Requirements Catalogue

5.7.1 Capacity requirements

Requirements Catalogue entries 8.8.6 to 8.8.8 state that ISRA must be able to process the volumes of business events, settlement data and standing data that will be imposed by the 1998 trading arrangements. This annex sets out those capacity requirements in more detail.

The ISRA system capacity requirements are described in three ways:

Estimates of total data storage capacity for 2 years within a GSP Group, showing total number of occurrence of each entity which must be held for 2 years
Estimates of input flows
Estimates of output flows.

5.7.1.1 Total Capacity Requirements

The data storage capacity requirements of the ISRA are shown in the following table. Four figures are given for the number of occurrences of each entity that will need to be held in the ISRA system:

expected initial volumes
a mandatory capacity, twice the initial expected volumes
a desirable capacity, based on 10x expected initial volumes
a desirable capacity, based on the maximum volume of data envisaged

For some of the larger values, the abbreviation “m” is used to denote millions.

Footnote references are explained at the end of the table.

Appendix F gives the underlying estimates from which these figures have been derived.

Non-functional considerations, such as maintaining version histories for data and maintaining audit trails will also impose additional capacity requirements. No allowance has been made for these in the figures give in this table.

Entity (grouped by data source)	Initial Volumes	Mandatory (Initial x2)	Desirable (Initial x10)	Desirable (based on max vols)	Footnote
1. Data Received From the SSA
GSP Group Take	70,176	140,352	701,760	350,880
SSA Settlement Runs	1,462	2,924	14,620	7,310
2. Other Daily Input Data
Daily Profile Parameters	731	1,462	7,310	731
Supplier Data Aggregation	254,388	508,776	2,543,880	29,240,000	**
Supplier Purchase Matrix	136 m	272 m	1,362 m	175,440 m	**
Teleswitch Contact Interval	3,840	7,680	38,400	131,072
Aggregated Supplier DA Period Consumption	80 m	160 m	800 m	7,017 m	**
3. Data received From Distributors
Line Loss Factor Class	15	30	150	150
Settlement Period Line Loss Factor Class	70,176	140,352	701,760	1,754,400
4. Data Received from the Profile Administrator
Day Types (Regression equations)	7	14	70	20
Period Regression Equation	15,120	30,240	151,200	3,840,000
Profile Regression Equation Set	315	630	3,150	80,000
Seasons (Regression Equations)	5	10	50	10
5. Data received from the Market Domain Data Agent (‘Pool Market Domain Data’)
BM Unit for Supplier in GSP Group	450	900	4500	4000
Clock Intervals	2,140	4,280	21,400	8,000
Consumption Component Class	19	38	190	50
Day Types (Clock Intervals)	7	14	70	20
Measurement Quantity	4	8	40	10
Measurement Requirement	1,070	2,140	10,700	4,000
Profile	9	18	90	20
Profile Classes	8	16	80	20
Seasons (Clock Intervals)	5	10	50	100
Settlement	4,386	8,772	17,544	7,310
Settlement Class	4,284	8,568	42,840	800,000
Standard Settlement Configuration	482	964	4,820	2,500
Teleswitch Contact Rule	1140	2280	11,400	163,840
Teleswitch Register Rule	640	1,280	6,400	40,960
Teleswitch Group	320	640	3,200	4096
Teleswitch Time Pattern Regime	640	1,280	6,400	8,192
Time Pattern Regime	1,070	2,140	10,700	4,000
Valid Measurement Requirement Profile Class	2,142	4,284	21,420	16,000
Valid Standard Settlement Configuration Profile Class	820	1,640	8,200	4,000
6. Calculated Data
Basic Period Profile Coefficients	315,792	631,584	3,157,920	14,035,200	*
Combined Period Profile Coefficients	12.5 m	25 m	125 m	70 m	*
Daily Profile Coefficients	1,565,802	3,131,604	15,658,020	11,696,000	*
GSP Group Correction Factor	210,528	421,056	2,105,280	350,880	*
Period Profile Class Coefficients	75 m	150 m	750 m	561 m	*
Period Supplier Purchase	1,017,552	2,035,104	10,175,520	7,017,600	*
Period Time Pattern State	37.5 m	75 m	375 m	140 m	*
Teleswitch Interval	960	1,920	9,600	32,768	*
Aggregated BM Unit Period Consumption	37 m	74 m	370 m	1,754 m	*
Aggregated Supplier Period Consumption	37 m	74 m	370 m	1,754 m	*
7. ISRA Standing Data
Data Aggregator Registration	58	116	580	4,000
Data Aggregators (HH)	29	58	290	2,000
Data Aggregators (Non HH)	15	30	150	2,000
Data Collectors (Non HH)	100	200	1,000	2,000
Distributor	4	8	40	40
GSP Group	1	12	12	12
GSP Group Corr Scaling Factor	29	57	285	75
GSP Group Distributor	6	12	60	60
NHH BM Unit Allocation	139	278	1390	7246
SSR Run Type	6	12	60	10
Supplier	29	58	290	200
Supplier In GSP Group	29	58	290	400
Clock Time Change	4	8	40	4
8. Data generated for runs
Profile Production Run	1,462	2,924	14,620	7,310
Settlement	4,386	8,772	43,860	7,310
Settlement Day	731	1,462	7,310	731
Settlement Period	35,088	70,176	350,880	35,088
SSR Run	4,386	8,772	43,860	7,310

Footnotes

* Derived data for individual runs, which need not be kept 'on-line' once the SSR or DPP run to which it relates has been completed, provided that it is easily recreatable and available for reporting and audit purposes.

** Input data, to which the same conditions apply, and which must also be available for use as 'default' when no data has been received from a feeder system for a specific run.

5.7.1.2 Estimates of Input Flows

The ISRA system capacity requirements in terms of the flows of data into the system is shown in the following table. It is derived from figures given in Appendix F. Some of the columns require some explanation:

the second column contains ‘e’ if flow is electronic and ‘m’ if flow is manual (‘e/m’ if it can be both)
the third column gives the number of feeder systems which may supply data
initial capacity (Column 4) is used to determine the mandatory requirement: the system must be able to cope with twice this amount
maximum capacity (Column 5) is used to determine the desirable capacity requirement: the system should be able to cope with this amount, or 10 time the initial capacity, whichever is the greater
column 6 shows the timeframe to which the estimates relate, e.g. per run, per year
The final column contains ‘E’ for estimated values and ‘A’ for actual values.

Flows In	E/M	No. of source systems	Initial Capacity	Maximum Capacity	Per	Source	Reason / notes	A/E
1. Daily Profile Production
Actual Noon Temperature	m	1	1	1	Profile Production run	URS team	per GSP Group	E
Calendar details	m	1	2	2	annum	URS team	per GSP Group	E
GSP Group details	m	1	1	5	annum	URS team	1-5 per GSP Group	E
Profile Class Details	m	1	1	5	annum	URS team	per GSP Group	E
Profiling Run Request	m	1	1	1	Profile Production run	URS team	per GSP Group	E
Regression Equations	e	1	1	5	annum	URS team	assume all regression equations reissued once per annum, initially( 17,520 entries per occurrence) Max = assume all reissued 5 times per annum ( each occurrence 192,000 entries)	E
Standing Configuration Data (TPR, MR, SSC changes)	e	1	2	100	annum	URS team	per GSP Group	E
Teleswitch Contact Interval	e	1	3,840	131,072	UTC Day	URS team		E
Time of sunset	e	1	365	366	annum	URS team		E
2. Supplier Settlement and Reconciliation
Settlement data	e	1	48	50	SSR Run	URS team		E
Line Loss Class Factors	e	1	40,320	58 m	annum	URS team	assume all reissued once per year, so max may be = LLF Classes(2-50)* Settlmt Periods in day(48)* day types(7-20)* seasons (5-100) per GSP Group	E
SPM Data	e	Init:12 Max: 400	6,426	1.2 m	Non HH DA Run	URS team	See entity sheet	E
LL Adjusted Aggregated Meter Data (HH)	e	Init:29 Max: 2000	15,312	1.2 m	HH DA Run	URS team	1 per Supplier, per CCC, per BM Unit, per HH Data Aggregator, per HH, for HH CCCs only. Initially: 29 Suppliers 11 CCCs 1 HH DA Maximum: 200 Suppliers 25 CCCs HH DAs (48 periods per entry)	E
Standing Data Changes	m	1	10	100	annum	URS team	assume 10% standing data changes per annum	E
Report Parameters	m	1	1	1	SSR Report Run	URS team	per GSP Group	E
Request for SSR Run	m	1	1	1	SSR Run	URS team	per GSP Group	E

5.7.1.3 Estimates of Output Flows

The ISRA system capacity requirements in terms of the flows of data out of the system is shown in the following table. It is derived from figures given in Appendix F. Three of the columns require a little explanation:

initial capacity (Column 4) is the basis for the mandatory requirement: the system must be able to cope with twice this amount
maximum capacity (Column 5) is the basis for the desirable capacity requirement: the system should be able to cope with this amount, or 10 times the initial capacity, whichever is the greater
column 6 shows the timeframe to which the estimates relate, e.g. per SSR run.
column 8 indicates whether the capacity requirements are actual (A) or estimated (E).

Note: All of the capacity figures in the table are per GSP Group.

Flows Out	Recipients	Number of Recipients	Initial Capacity	Maximum Capacity	Per	Source	A/E
Daily Profile Totals	NHHDC	Init =12 Max=400	1	1	Profile Production Run	URS Team	E
Profiling Reports	Suppliers + NHHDCs	Init:29 +12 Max: 200 +400	1	1	Profile Production Run	URS Team	E
TUoS Report	NETSO TUoS	1	1	1	SSR Run	URS Team	A
SSR Reports	Suppliers	Init: 29 Max: 400	7	17	SSR Reports Run	URS Team	E
Pool Reports	Pool	1	3	15	Quarter	URS Team	E
Pool Reports	Pool	1	1	1	Adhoc	URS Team	E
Error reports	DA Supplier Distributor	29 29 1	10	50	DPP or SSR Run	URS Team	E
DUoS Report	Distributor Suppliers	5 29	34	34	SSR Run	URS Team	E

5.7.1.4 BM Unit Capacity Requirements

The ISRA system capacity requirements in terms of BM Units are such that the software should be able to support 4000 Supplier BM Units. The number of these that are Additional BM Units as opposed to Base BM Units depends upon the number of Stage 2 Suppliers. The ISRA system allows for a maximum of 200 Suppliers, requiring 200*12 = 2400 Base BM Units. The minimum number of Stage 2 BM Units available for use in the Balancing Mechanism is therefore 4000 – 2400 =1600. If the number of Suppliers was only 100, the number of additional BM Units available for use would increase to 4000 – 1200=2800.

6. DATA FLOW MODEL

6.1 Purpose and Scope

1. The ISR Data Flow Model describes the processes which comprise the Initial Settlement and Reconciliation Agency (ISRA) system. It also details the flows of data between these processes, and those to and from organisations or processes which are outside the scope of ISRA (External Entities).

2. The model provides a view of the functionality required of the ISRA system for each GSP Group. It is a logical not a physical model and shows, for example, what data is required from an external entity not how it is obtained.

3. The model consists of:

a series of Data Flow Diagrams - a top level diagram which is decomposed into a number of lower level, more-detailed diagrams;
a cross reference between the top level Data Flow Model and the Business Process Model in the Operational Framework (reference 1);
descriptions of the Elementary Processes (EPDs), that is the processes which appear on the lowest level diagrams;
descriptions of the dataflows to and from the external entities;
descriptions of the datastores, including cross references to the relevant entities in the Logical Data Structure;
descriptions of the external entities.

4. Descriptions of the data items populating the data flows is given in Appendix B.

5. A key to the Data Flow Diagram notation used is given in Appendix D.

Definitions of terms and the mathematical notation used in the process descriptions can be found in the Glossary (reference 10).

6.2 Data Flow Diagrams and Elementary Process Descriptions

6.2.1 Initial Settlement and Reconciliation Agency

6.2.2 Process 1 - Supplier Settlement and Reconciliation

6.2.3 Process 1.1 - Marshal Incoming Data

This set of processes runs intermittently, on the receipt of incoming data, to validate and load the data ready for use in the main SSR calculations (process 1.4). As stated in the system assumptions section, SSR expects the data to be provided in accordance with the published settlement timetable.

6.2.3.1 Process 1.1.1 - Validate Settlements Data

This process performs data marshalling of data from the CDCA system. The data is GSP group data and CDCA Set Number.

The incoming data will be validated to ensure:

Physical integrity
Any data for Settlement Dates and times which are already within the system must be a later version than that in the system
The data has the correct number of Settlement Periods
The data is for the correct GSP Group(s)
That the file, if it is for a Scottish GSP Group, will not be loaded if the Settlement date is before the BETTA start date¹.

Any invalid data or rounding discrepancies will be reported to the CDCA and the ISR Agent. If any of the discrepancies are greater than the tolerances the files will be rejected for processing.

If the data is valid, then the GSP Group Take and CDCA Set Number will be written to the Trading Day Data datastore.

6.2.3.2 Process 1.1.2 - Validate Line Loss Factors

This process performs data marshalling of Line Loss Factors from the Distributor. It is expected that this data will be sent annually.

The incoming data will be validated to ensure:

Physical integrity
The files are received in the correct sequence
Any data for Settlement dates and times which are already within the system must be a later version than that in the system
The data has the correct number of Settlement Periods
The data is for the correct distributor(s)
The data is for the correct line loss factor classes

Any invalid data or out of sequence files will be reported to the Distributor and the ISR Agent.

If the data is valid, the data will be written to the Trading Day Data datastore.

6.2.3.3 Process 1.1.3 - Validate HH Data

This process performs data marshalling of aggregated half hourly meter data from the Half Hourly Data Aggregator. The file that is sent by the Half Hourly Data Aggregator will depend on whether Additional BM Units have been implemented. If they have, the HHDA will send a BM Unit Aggregated Half Hour Data File (D0298) to ISRA, whereas if they have not, the HHDA will send an Aggregated Half Hour Data File (D0040). The HHDA, however, will not send both for a given Settlement and GSP Group. Where a Demand Control Event has occurred, the HHDA may submit a separate Demand Disconnection Volume Data (D0376) reporting those volumes associated with any disconnection. The received data must be aggregated to GSP Group, Supplier, Consumption Component Class, BM Unit and Settlement Period.

The incoming data will be validated to ensure:

The file is not a null file
Physical integrity
Any data for Settlement dates and times which are already within the system must be a later version than that in the system
The data has the correct number of Settlement Periods
The data is for the correct GSP Group(s)
The file is from an expected Data Aggregator, i.e. a Data Aggregator who has an appointment to the GSP Group on the Settlement Date for which the data relates. If not, an exception entry will be written.
The file only contains data for the expected set of Suppliers, i.e. only Suppliers who have an association with the Data Aggregator on the Settlement Date / GSP Group combination of the file. If not then an exception entry will be written.
The file contains data for the full set of expected Suppliers, i.e. all Suppliers who have an association with the Data Aggregator on the Settlement Date / GSP Group combination of the file. If not then an exception entry will be written.
That the combination of Supplier and GSP Group has a valid Base BM Unit. If not then the file will be loaded into the flat files and a warning produced.
That there is no duplicated Supplier / GSP Group / consumption component class combinations.
That the additional BM Units referenced in the D0298 flow are valid. If not then the file will be loaded into the flat files and a warning produced.
That the file, if it is for a Scottish GSP Group, will not be loaded if the Settlement date is before the BETTA start date.
Any Standing Data changes resulting from the file load will be stored as an audit record.

Any invalid data will be reported to the HH Data Aggregator, ELEXON and the ISR Agent.

If the data is valid, the data will then undergo the following validation checks:

The total consumption volume per file will be compared to the equivalent total from the comparator data and the difference calculated.
The total MSID count per file will be compared to the equivalent total from the comparator data and the difference calculated.

If this difference lies outside of tolerances set by BSCCo, the file will be quarantined pending confirmation from the HH Data Aggregator that the variance is correct.

If the data passes the validation checks, the data will be written to the Supplier HH Demand datastore, with the consumption component class set appropriately.

6.2.3.4 Process 1.1.4- Validate SPM Data

This process performs data marshalling of Supplier purchase matrix data (including any Disconnection purchase matrix data) from the Non-Half Hourly Data Aggregator.

The incoming data will be validated to ensure:

The file is not a null file
Physical integrity
Any data for Settlement dates and times which are already within the system must be a later version than that in the system
The data is for the correct GSP Group(s)
The file is from an expected Data Aggregator, i.e. a Data Aggregator who has an appointment to the GSP Group on the Settlement Date for which the data relates. If not, an exception entry will be written.
The file only contains data for the expected set of Suppliers, i.e. only the Suppliers who have an association with the Data Aggregator on the Settlement Date / GSP Group combination of the file. If not then an exception entry will be written.
The file contains data for the full set of expected Suppliers, i.e. all Suppliers who have an association with the Data Aggregator on the Settlement Date / GSP Group combination of the file. If not then an exception entry will be written.
The data is for the correct Profile Classes
The data is for the correct line loss factor classes
The data is for the correct measurement requirements
That the combination of Supplier and GSP Group has a valid Base BM Unit. If not then the file will be loaded into the flat files and a warning produced.
That for each combination of Supplier and GSP Group the file contains no more than one instance of a particular Profile Class / distributor / line loss factor class / Standard Settlement Configuration / time pattern regime combination.
That there is no duplicated Supplier / GSP Group / consumption component class combinations.
That the file, if it is for a Scottish GSP Group, will not be loaded if the Settlement Date is before the BETTA start date.
Any Standing Data changes resulting from the file load will be stored as an audit record.

Any invalid data will be reported to the Non-Half Hourly Data Aggregator system and the ISR Agent.

If the data is valid, the data will then undergo the following validation checks:

The total consumption volume per file will be compared to the equivalent total from the comparator data and the difference calculated.
The total MSID count per file will be compared to the equivalent total from the comparator data and the difference calculated.

If this difference lies outside of tolerances set by BSCCo, the file will be quarantined pending confirmation from the Non-Half Hourly Data Aggregator that the variance is correct.

If the data passes the validation checks, the data will be written to the Trading Day Data datastore.

6.2.3.5 Process 1.1.5- Validate Revised GSP Takes

This process is no longer used.

6.2.3.6 Process 1.1.6- Validate Mapping Data for HH Aggregated Metering Systems

This process performs data marshalling of Mapping Data for HH Aggregated Metering Systems from the Distributor.

The incoming data will be validated to ensure:

Physical integrity
The LLFC and SSC information is valid against that held in Market Domain Data

If the data is valid, the data will be written to the Trading Day data store.

6.2.3.7 Process 1.1.7 – Manage Disconnected MSIDs and Estimated Half Hourly Demand Volumes

This process performs data marshalling of information relating to Disconnected MSIDs and Estimated Half Hourly Demand Volumes from the NETSO.

The incoming data will be validated for physical integrity, and if valid will be issued to HH and NHH Data Collectors for use in their data processing activities.

6.2.4 Process 1.2 - Produce SSR Supplier Reports

6.2.4.1 Process 1.2.1 - Supplier Purchase Matrix report.

This process produces a report for each Supplier, containing details of the Supplier Purchase Matrix occurrences used in the calculation for the most recent settlements run.

In addition, this process also produces a GSP Group Market Matrix Report, created by summing Supplier Purchase Matrix reports over all Suppliers and Data Aggregators. This report is provided to BSCCo.

6.2.4.2 Process 1.2.2 - HH Demand report

This process produces a report for each Supplier, containing details of all the half hourly demand for a Supplier by consumption component class. This will include the profiled and actual demand. If there is any NHH consumption for a GSP Group, then records for all NHH CCCs will be output for that GSP Group.

6.2.4.3 Process 1.2.3 - Deemed Take report

This process produces a report for each Supplier, containing details of the deemed take calculations, including GSP Group Correction.

6.2.4.4 Process 1.2.4 - Supplier Purchases report

This process produces a report for each Supplier, containing details of the Supplier Deemed Take and GSP Group Take for each Settlement Period and the settlement variables used to generate them. The Supplier Purchases values will be set to zero.

The Report includes both derived GSP Group totals and those supplied by the CDCA.

This process will be invoked after each settlement run.

6.2.4.5 Process 1.2.5 - GSP Group Consumption Totals report

This process produces a report for each Supplier, containing GSP Group consumption totals both before and after GSP correction, for GSP Groups in which the Supplier is active. This process will be invoked after each settlement run. If there is any NHH consumption for a GSP Group, then records for all NHH CCCs will be output for that GSP Group.

In addition, this process also produces a variant of the report (BSCCo GSP Group Consumption Totals report) with the same detailed content but omitting the recipient Supplier Id information. This report is generated for Initial Settlement, Final Reconciliation and Dispute Final runs only, and is made available to BSCCo.

6.2.4.6 Process 1.2.6 – Create Recalculated GSP Group Correction Factors Report

This process is no longer used.

6.2.4.7 Process 1.2.7 – Supplier BM Unit report

This process produces a report for each Supplier containing details of the Supplier’s valid BM Units, GSP Group/BM Unit/Profile Class/Standard Settlement Configuration mappings and consumption/generation by BM Unit and Consumption Component Class. If there is any NHH consumption for a GSP Group, then records for all NHH CCCs will be output for that GSP Group.

6.2.4.8 Process 1.2.8 – Supplier Disconnection Matrix report

This contains details of the Disconnection Purchase Matrix occurrences used in the calculation for the specified Settlement Run, i.e. detailed input data from individual NHH Data Aggregators.

6.2.4.9 Process 1.2.9 – HH Demand Disconnection report

This contains details of HH Demand Disconnection values for a Supplier by consumption component class used in the specified Settlement Run. This includes the profiled and actual demand separately: Part 1 of the report contains the result of the GSP Group Aggregation Process; Part 2 contains the detailed input data from HH Data Aggregators.

6.2.4.10 Process 1.2.10 – GSP Group Demand Disconnection report

This contains details of the total disconnected deemed take summed over all Suppliers for each Settlement Period for each Consumption Component Class and GSP Group before and after GSP Group Correction. If a GSP Group Consumption Component Class has no consumption (as distinct from zero consumption), it is omitted. This allows suppliers to verify that the GSP Group Correction Factor has been correctly calculated.

6.2.4.11 Process 1.2.11 – Supplier BM Unit Demand Disconnection report

This contains details of the Supplier’s valid BM Units, Non-Half Hourly BM Unit Allocations, the Half Hourly demand disconnection energy data input into the system and the combined Half Hourly and Non-Half Hourly demand disconnection energy by BM Unit and Consumption Component Class calculated by the SSR run.

6.2.4.12 Process 1.2.12 – Supplier Quarterly Volume Report

This contains a sum of Suppliers’ energy volumes for the Settlement Days in a calendar quarters, as determined at First Reconciliation, along with the average number of related Metering Systems over the same time period. The data is reported per Supplier and by eight Supplier Volume Reporting Groups, comprising a combination of specified Consumption Component Classes and Profile Classes.

6.2.4.13 Process 1.2.13 – Supplier BM Unit Non Chargeable Demand

This contains the volume of demand allocated to a Supplier BM Unit in a Settlement Period which relates to electricity consumed by a generating plant or battery storage operating under a Generation Licence. This volume is deducted from the Supplier BM Unit Gross demand for the purposes of calculating Final Consumption Levy Charges.

6.2.5 Process 1.3 - Update SSR Standing Data

6.2.5.1 Process 1.3.1 - Maintain Supplier Details

This process will allow the ISR Agent to enter and update details of Suppliers. The Id and Name will be specified for each Supplier.

The system will not allow a Supplier to be deleted if any consumption has been allocated to that Supplier.

Supplier details can be archived only when all consumption allocated to that Supplier has been archived.

6.2.5.2 Process 1.3.2 - Assign Suppliers to GSP Groups

This process will allow the ISR Agent to define and amend links between Suppliers and GSP Groups. An Effective From Date and optionally an Effective To Date will be specified for each link. The purpose of entering this data is to allow validation of SPM data received from data aggregators.

6.2.5.3 Process 1.3.3 - Maintain GSP correction Scaling Factors

This process will allow the GSP correction scaling factors used by the SSR system to be entered, updated and deleted where authorised via the appropriate change control procedure.

Each scaling factor will be for a particular Consumption Component Class and effective from date.

6.2.5.4 Process 1.3.4 - Maintain Line Loss Factor codes

This process will allow line loss factor classes to be entered, updated and deleted where authorised via the appropriate change control procedure.

i. Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.6).

6.2.5.5 Process 1.3.5 - Specify Distributor for GSP Group

This process will allow the Distributors in each GSP Group to be specified. The GSP Group Id, Distributor Id and Effective Date will be specified for each assignment.

There must always be at least one distributor assigned to a GSP Group.

The system will not allow a distributor assignment to be changed or deleted except where authorised via the appropriate change control procedure.

6.2.5.6 Process 1.3.6 - Specify Aggregator for GSP Group

This process will allow the Half Hourly and Non-Half Hourly Data Aggregator for each combination of GSP Group and Supplier to be specified. The GSP Group Id, Supplier Id, Data Aggregator Id, and Effective From and Effective To Date will be specified.

The system will not allow an aggregator assignment to be changed or deleted except where authorised via the appropriate change control procedure.

6.2.5.7 Process 1.3.7 - Maintain Settlement Timetable

This process will allow details of the published Settlement Timetable to be entered, updated and deleted. Settlements for a range of Settlement Dates, Settlement Codes, Planned SSR Run Dates and Payment Dates are generated.

The system will not allow a Settlement to be amended or deleted if any SSR Run or SSA Settlement Run for the Settlement Day have taken place, and have not yet been archived off.

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 1.5).

6.2.5.8 Process 1.3.8 – Assign NHH BM Units

A Valid Settlement Configuration Profile Class is allocated to a BM Unit for Supplier in GSP Group.

The user adds a new Non-Half Hourly BM Unit Allocation by specifying the GSP Group Id, Supplier Id, BM Unit Id and Effective From Settlement Date of the BM Unit for Supplier in GSP Group, the Valid Settlement Configuration Profile Class (VSCPC) and the Non-Half Hourly BM Unit Allocation Effective From Settlement Date {NHHBMUA} and optionally the Non-Half Hourly BM Unit Allocation Effective To Settlement Date {NHHBMUA}.

The Non-Half Hourly BM Unit Allocation is permitted if:

the BM Unit for Supplier in GSP Group exists
the Valid Settlement Configuration Profile Class exists
the effective date range of the Non-Half Hourly BM Unit Allocation for a combination of GSP Group, Supplier and VSCPC does not overlap any other Non-Half Hourly BM Unit Allocation for the same GSP Group, Supplier and VSCPC (i.e. the combination of GSP Group, Supplier and VSCPC is assigned to only one BM Unit on any one settlement day)
the effective date range of the Non-Half Hourly BM Unit Allocation is not outside the effective date range of the BM Unit for Supplier in GSP Group.
the effective date range of the of the Non-Half Hourly BM Unit Allocation for a combination of GSP Group, Supplier and VSCPC has valid average fraction of yearly consumption data for that period.

6.2.5.9 Process 1.3.9 – Enter BM Units Manually

A BM Unit is manually entered for a Supplier in a GSP Group. The user enters the BM Unit Id, GSP Group Id, Supplier Id, Base BM Unit Flag, the Effective From Settlement Date and optionally the Effective To Settlement Date. Any GSP Group and Supplier combination can be chosen, not just those Suppliers trading in a GSP Group. For a Scottish GSP Group, the Effective From Settlement Date must be on or after the BETTA Start Date.

6.2.5.10 Process 1.3.10 – Maintain Final Dispute Expected Aggregation

This process will allow a user to specify the Half Hourly and Non-Half Hourly Data Aggregators associated with a Dispute Final Settlement Run, in order to ensure that a correct and complete set of aggregated data is received in time for the Run. The Data Aggregator Id, GSP Group and Effective From and Effective To Date will be specified.

In normal practice this information will be loaded from a file prepared by BSCCo and provided to the ISR Agent. Once loaded, the information may be modified further by the ISR Agent as required by BSCCo.

6.2.6 Process 1.4 - Run SSR

6.2.6.1 Process 1.4.1 - Invoke Run

This process will check that the necessary data has been collected for the Settlement Day, i.e. that the appropriate occurrences of the following data items exist:

Settlement;

CDCA Data (GSP Group Take, CDCA Initial Settlement Run);

Supplier Data Aggregation (half hourly data) for all assigned data aggregators;

Supplier Data Aggregation (non-half hourly data) for all assigned data aggregators;

Line Loss Factor Data; and

Profile Production Run.

If any data is missing, determine the action to be taken from the following table. Otherwise, the SSR run will be started:

Data Item	Action
Line Loss Factors	This situation should not arise as Line Loss Factors are published by the distributor in advance and do not have a ‘effective to’ date. If the file does not contain data for a Line Loss Factor Class which is valid, the file will still be loaded, but any SSR runs requiring the missing data will use a standard default value of 1 (i.e. no line loss). This will be reported in an exceptions report.
Settlement	The ISRA Operator must select a Settlement Run (i.e. a Settlement Date and Settlement Code) entered in the Settlement Calendar, otherwise a run cannot be invoked.
CDCA Data (GSP Group Take, SSA Initial Settlement Run)	The run cannot proceed without consistent and complete CDCA Data. If such CDCA Data is not available, the ISRA Operator must select another Settlement Day from which the substitute CDCA data will be taken, as instructed by the Pool Executive Committee (PEC) or its nominated agent. The substitute GSP Group Take and SSA Initial Settlement Run data must all be consistent (i.e. for the same Settlement Day, Settlement Code and CDCA Set Number).
Non Half Hourly Aggregated Data	The ISRA Operator will be prompted to select the Data Aggregation data to be used as a default for all missing Data Aggregation files. If a file was quarantined following the validation checks and the Non-Half Hourly Data Aggregator did not confirm whether the file was correct or incorrect, the ISRA Operator will be able to select this quarantined file to use instead of default data.
Half Hourly Aggregated Data	If data from a HH Data Aggregator has not been received, the ISRA system will continue on the basis of the data selected by the ISR Agent, and will raise an exception report for any data it was expecting and had not received. ISRA will not automatically substitute data, but it must allow the ISR Agent to select a set of historic HH data for a specific Data Aggregator which is to be used for a specific run (e.g. data supplied for an earlier Settlement for the same Settlement Day; or data supplied for another ‘appropriate’ Settlement Day). The ISR Agent will determine what data should be substituted based on Agreed Procedures. If a file was quarantined following the validation checks and the Half Hourly Data Aggregator did not confirm whether the file was correct or incorrect, the ISRA Operator will be able to select this quarantined file to use instead of default data. If no substitute data can be found, the ISRA Operator can let the run proceed without any HH Aggregated Data.
Profile Production Run	No default action is taken - the run will fail.

A report will be produced detailing the data used and warning of any missing data.

The ISRA system will check that the all files received from Data Aggregators are expected for the designated run. If there is an unexpected file, the system will give the ISR Agent the option of continuing with the run. If the ISR Agent continues with the SSR run, the ISRA system will ignore the file and its data when performing the SSR run and will issue a warning message giving details.

The ISRA system will check that the latest file that it has received from each Data Aggregator for each GSP Group for the SSR run contains data for all the Suppliers expected to be in the file. If there is a file that does not contain data for all expected Suppliers, the system will update the standing data and continue with the SSR run.

The ISRA system will check that the latest file it has received from each Data Aggregator for each GSP Group for the SSR Run only contains data from Suppliers expected to be in the file. If there is a file that contains data for unexpected Suppliers, the system will update the standing data and continue with the SSR run.

Except for the case where default data has been specified, the ISRA system should only use data from the latest Data Aggregation run for the Settlement Date, Settlement Code and GSP Group for each Data Aggregator.

6.2.7 Process 1.4.8 - Profile & Line Loss Adjust SPM

6.2.7.1 Process 1.4.8.1 - Profile SPM Data

This process applies the profiles to the Supplier purchase matrix data to produce half hourly consumption estimates for each Supplier and Settlement Class. The half hourly estimates are summed by Data Aggregator and written to the Supplier HH Demand datastore.

For each Supplier, calculate the estimated consumption for each half hour for each Supplier and Settlement Class:

Suppliers’ Profiled Consumption based on EACs’:

_{$SPC [Total EAC]_{sljtpm} = \sum_{a} (SPM [Total EAC]_{saptlm} \times {PPCC}_{ptj})$}

Suppliers’ Profiled Consumption based on AAs’:

_{$SPC [Total AA]_{sljtpm} = \sum_{a} (SPM [Total AA]_{saptlm} \times {PPCC}_{ptj})$}
Suppliers’ Profiled Consumption for unmetered supplies’:

_{$SPC [Total Unmetered]_{sljtpm} = \sum_{a} (SPM [Total Unmetered]_{saptlm} \times {PPCC}_{ptj})$}

6.2.7.2 Process 1.4.8.2 - Aggregate Profiled Data

This process aggregates the profiled values produced in EPD 1.4.8.1 into values for the following Consumption Component Classes for each BM Unit and Line Loss Factor Class. The appropriate BM Unit to aggregate the profiled SPM data into is derived from the BM Unit for Supplier in GSP Group entity and the Non-Half Hourly BM Unit Allocation entity. Where the Valid Profile Class Settlement Configuration from the profiled SPM data for each Supplier in the GSP Group has a BM Unit allocated for the Settlement Day, then this BM Unit is used. If there is no BM Unit allocated then the Base BM Unit for the Supplier in GSP Group is used. If the Valid Profile Class Settlement Configuration from the profiled SPM data for a Supplier in the GSP Group does not have a BM Unit allocated for the Settlement Day and the Supplier in GSP Group does not have a Base BM Unit defined, a warning message is logged in the Exception Report and those energy values are excluded from the SSR Run.

For Consumption Class (n) = ‘Profiled HH import based on EACs’:

_{$C_{nij} = \sum_{lmpt} SPC [Total EAC]_{ilmjpt}$}

where the SSC sum (m) is over only those SSCs with SSC Type set to “Import”

For Consumption Class (n) = ‘Profiled HH Export based on EACs’:

_{$C_{nij} = \sum_{lmpt} SPC [Total EAC]_{ilmjpt}$}

where the SSC sum (m) is over only those SSCs with SSC Type set to “Export”

For Consumption Class (n) = ‘Profiled HH import based on AAs’:

_{$C_{nij} = \sum_{lmpt} SPC [Total AA]_{ilmjpt}$}

where the SSC sum (m) is over only those SSCs with SSC Type set to “Import”

For Consumption Class (n) = ‘Profiled HH Export based on AAs’:

_{$C_{nij} = \sum_{lmpt} SPC [Total AA]_{ilmjpt}$}

where the SSC sum (m) is over only those SSCs with SSC Type set to “Export”

For Consumption Class (n) = ‘Profiled HH consumption for unmetered supplies’:

_{$C_{nij} = \sum_{lmpt} SPC [Total Unmetered]_{ilmjpt}$}

6.2.7.3 Process 1.4.8.3 - Adjust for Line Losses

This process applies the class line losses to the profiled consumption estimates calculated by process 1.8.1. This will be summed by BM Unit to create values for five line loss consumption classes (C). The appropriate BM Unit is derived from the BM Unit for Supplier in GSP Group entity and the Non-Half Hourly BM Unit Allocation entity. Where the Valid Profile Class Settlement Configuration from the profiled SPM data for each Supplier in the GSP Group has a BM Unit allocated for the Settlement Day, then this BM Unit is used. If there is no BM Unit allocated then the Base BM Unit for the Supplier in GSP Group is used. If the Valid Profile Class Settlement Configuration from the profiled SPM data for a Supplier in the GSP Group does not have a BM Unit allocated for the Settlement Day and the Supplier in GSP Group does not have a Base BM Unit defined, a warning message is logged in the Exception Report and those energy values are excluded from the SSR Run.

For consumption class (n) = ‘Line losses due to profiled HH import based on EACs’:

_{$C_{nij} = \sum_{l} (({LLF}_{ilj} - 1)  \times \sum_{pmt} (SPC [Total EAC]_{ilmjpt}))$}

where the SSC sum is over only those SSCs with SSC Type set to “Import”

For consumption class (n) = ‘Line losses due to profiled HH export based on EACs’:

_{$C_{nij} = \sum_{l} (({LLF}_{ilj} - 1)  \times \sum_{pmt} (SPC [Total EAC]_{ilmjpt}))$}

where the SSC sum is over only those SSCs with SSC Type set to “Export”

For consumption class (n) = ‘Line losses due to profiled HH import based on AAs’:

_{$C_{nij} = \sum_{l} (({LLF}_{ilj} - 1)  \times \sum_{pmt} (SPC [Total AA]_{ilmjpt}))$}

where the SSC sum is over only those SSCs with SSC Type set to “Import”

For consumption class (n) = ‘Line losses due to profiled HH export based on AAs’:

_{$C_{nij} = \sum_{l} (({LLF}_{ilj} - 1)  \times \sum_{pmt} (SPC [Total AA]_{ilmjpt}))$}

where the SSC sum is over only those SSCs with SSC Type set to “Export”

For consumption class (n) = ‘Line losses due to profiled HH consumption for unmetered supplies’:

_{$C_{nij} = \sum_{l} (({LLF}_{ilj} - 1)  \times \sum_{pmt} (SPC [Total Unmetered]_{ilmjpt}))$}

6.2.8 Process 1.4.9 - Calculate Deemed Take

6.2.8.1 Process 1.4.9.1 - Calculate & Apply GSP Group Correction

This will, on a half hourly basis, adjust appropriate consumption components to ensure that the total consumption from this system equals the actual GSP Group Take provided by SSA.

The requirement as expressed in the Operational Framework (reference 1) is to apply GSP Group Correction only to Line Loss Factored profiled consumption. However, the system will support a more general mechanism, in which a weight W_n is specified for each Consumption Component Class n, specifying the degree to which it is to be corrected.

To calculate C_nijs the values for each Consumption Component Class, BM Unit and Settlement Period in the Aggregated BM Unit Period Consumption entity are summed across BM Unit to create values for Consumption Component Class, Supplier and Settlement Period:

_{$C_{nsj} = \sum_{i} C_{nij} $}

Where C_nijrefers to values for all BM Units within a Consumption Component Class and Settlement Period which are assigned to a particular Supplier in the GSP Group.

The unadjusted consumption for Consumption Component Class n, C_nj, is given by summing C_nsj across Suppliers:

_{$C_{nj} = \sum_{s} C_{nsj}$}

Any demand in the following Consumption Component Classes will be subtracted during the summation, as it is generation:

half hourly Non-Pooled Generation for metering systems with metering system specific line loss
half hourly Non-Pooled Generation for metering systems without metering system specific line loss
line losses attributed to half hourly Non-Pooled Generation for metering systems with metering system specific line loss
line losses attributed to half hourly Non-Pooled Generation for metering systems without metering system specific line loss

Next, for each Settlement Period in the trading day, the GSP Group Correction Factor CF_gj is calculated as follows:

_{${GSP Group Correction Factor}_{j} = 1 + \frac{{GSP Group Take}_{j} - \sum_{n} C_{nj}}{\sum_{n} C_{nj} ´ W_{n}}$ GSP Group Correction Factor" rSub { size 8{j} } } size 12{ {}=1+ { {"GSP Group Take" rSub { size 8{j} } size 12{- Sum cSub { size 8{n} } {C rSub { size 8{ ital "nj"} } } }} over { Sum cSub { size 8{n} } {C rSub { size 8{ ital "nj"} } ´W rSub { size 8{n} } } } } }} {}}

where C_nj is the unadjusted consumption for Consumption Component Class n, and W_n is the associated GSP Group Correction Scaling Factor. The rule given above for subtracting demand falling within ‘generation’ Consumption Component Classes must also be applied to this equation.

The GSP Group Correction Factors will be validated against tolerances set by BSCCo. If a GSP Group Correction Factor lies outside of this tolerance, the SSR run is aborted.

Following this, the total consumption volume per GSP Group will be compared to suitable comparator data and the variance calculated. If this variance lies outside of tolerances set by BSCCo, the SSR run is halted and the breach raised with BSCCo. If the breach is deemed by BSCCo to be valid, the SSR run will continue; otherwise it is aborted.

Following this, the GSP Group Take volumes will be compared to the total consumption volumes and the variance calculated. If this variance lies outside of tolerances set by BSCCo, the SSR run is halted and the breach raised with BSCCo. If the breach is deemed by BSCCo to be valid, the SSR run will continue; otherwise it is aborted.

The GSP Correction Factor is then applied by setting the appropriate field (either Corrected Supplier Consumption or Corrected Line Loss Component) of each row in the Supplier HH Demand datastore as follows:

{Corrected Component}_{nj} = C_{nj} ´ (1 + ({CF}_{gj} - 1) ´ W_{n})

Corrected Component" rSub { size 8{ ital "nj"} } } size 12{ {}=C rSub { size 8{ ital "nj"} } ´ $ 1+ \( ital "CF" rSub { size 8{ ital "gj"} } -1 $ ´W rSub { size 8{n} } \) }} {}

Note: it is expected that the SSR system will initially be configured with values of W_n restricted to zero and one. GSP Correction will then not be applied at all to those components with zero scaling factors, and will be applied equally to the others.

If Σ (C_nj x W_n) equals zero, the system must fail with an error message.

ⁿ

6.2.8.2 Process 1.4.9.2 - Calculate Deemed Supplier Take

For each Supplier and each Settlement Period in the trading day being processed, calculate the Unadjusted Supplier Deemed Take as the sum of Corrected Supplier Consumption and Corrected Line Loss Component for all Demand Component Classes in the Supplier HH Demand datastore.

Any demand in the following Consumption Component Classes will be subtracted during the summation, as it is generation:

half hourly Non-Pooled Generation for metering systems with metering system specific line loss
half hourly Non-Pooled Generation for metering systems without metering system specific line loss
line losses attributed to half hourly Non-Pooled Generation for metering systems with metering system specific line loss
line losses attributed to half hourly Non-Pooled Generation for metering systems without metering system specific line loss

This Unadjusted Deemed Supplier Take is written to the Deemed Take datastore along with the GSP Group Id, the Supplier Id and the Settlement Period.

If any Supplier records a total output from any Non Pooled Generation, which they may have, which exceeds their take, the Supplier will register a negative Supplier Deemed Take.

This will be implemented by setting variables as follows:

Supplier Deemed Take = Unadjusted Supplier Deemed Take

SPILL_j = 0

SGT_sj = 0

TGT_j = 0

6.2.8.3 Process 1.4.9.3 - Adjust for Non-Pooled Generation Spill

This process is no longer used.

6.2.8.4 Process 1.4.9.2 - Calculate BM Unit SVA Gross Demand

For each Supplier, BM Unit and each Settlement Period in the trading day being processed calculate the BM Unit SVA Gross Demand as the sum of Corrected Supplier Consumption and Corrected Line Loss Component recorded for Active Import Component Classes in the Supplier HH Demand datastore.

6.2.8.5 Process 1.4.9.4 - Produce TUoS Report

This will produce a report of deemed Supplier take by Supplier. The report will include: SSR run date, SSR run number, SSR run type, Settlement Date, for each GSP Group a deemed take by Supplier (in MWh) for each half hour, and for each Supplier a split between half hourly and non-half hourly metering data at the BM Unit level. To support the calculation of dispute charges, the report will also include daily and period Supplier deemed take broken down into Corrected Supplier deemed take (deemed take attributable to supplies which are subject to group correction) and Non-Corrected Supplier deemed take. To support the disapplication of Network Charges for Storage Facilities, the report will also include daily and period gross demand from Storage Facilities and Corrected daily and period gross HH demand.

6.2.8.6 Process 1.4.9.5 - Produce DUoS Report

This will produce a report of aggregated data by Settlement Class (summed over Data Aggregators) for Suppliers and Distributors. The Supplier report will contain the data for one Supplier only. The Distributor report will contain the data for all Suppliers associated with the Distributor in all the GSP Groups that they are active in. The report will include: total consumption (i.e. sum of actual, estimated and unmetered consumption) for each half hour per valid combination of Profile Class, Standard Settlement Configuration and Time Pattern Regime, per Line Loss Factor Class, per Supplier. The report also contains Correction Factor data.

Where aggregated HH data has been submitted by a HH Data Aggregator for Measurement Classes F and G, this function will use the LLFC/SSC mapping information provided by the relevant Distributor to translate the data provided per Distributor and Line Loss Factor Class into data per Distributor and SSC for inclusion in the DUoS Report.

6.2.8.7 Process 1.4.9.6 - Produce Aggregated Disconnected DUoS Report

The report will include: Profiled DPM total consumption (i.e. sum of actual, estimated and unmetered disconnected consumption) for each half hour per valid combination of Profile Class, Standard Settlement Configuration and Time Pattern Regime, per Line Loss Factor Class, per Supplier. The report also contains Correction Factor data.

6.2.8.8 Process 1.4.9.7 - Produce Aggregated Embedded Network DUoS Report

This will produce a report of aggregated data by Settlement Class (summed over Data Aggregators) for Suppliers and Embedded Distributors. The Supplier report will contain the data for one Supplier only. The Distributor report will contain the data for all Suppliers associated with the Distributor in the Embedded Network that they are active in.

The report will include: Profiled DPM total consumption (i.e. sum of actual, estimated and unmetered consumption) for each half hour per valid combination of Profile Class, Standard Settlement Configuration and Time Pattern Regime, per Line Loss Factor Class, per Supplier. The report also contains Correction Factor data.

6.2.9 Process 1.4.13 - Determine Supplier Energy Allocations

This process retrieves the deemed take from the Deemed Take datastore, and sets the Supplier Purchase per GSP Group per Supplier per half hour to zero. i.e.:

Supplier Purchase_gsj = Deemed Supplier Take_gsj * (1 + TLM_j) * (1 + LRM_j) * PSP_j

Where TLM_j = 0

LRM_j = 0

PSP_j = 0

Such that:

Σ_sjSupplier Purchases_gsj = 0

The Supplier energy allocations is then used to produce the BM Unit Supplier Take Energy Volume Data File which is sent to the Settlement Administration Agent.

The BM Unit Supplier Take Energy Data File contains details of Period Supplier Deemed Take for each Supplier and GSP Group in each Settlement Period. Each combination of Supplier and GSP Group is labelled with the BM Unit Id of the relevant base BM Unit.

Where a Demand Control Event has occurred for a Settlement Period, this process retrieves the disconnected deemed take from the Deemed Take data store and determines the Period Supplier Deemed Take for inclusion in the BM Unit Disconnected Supplier Take Energy Volume Data File sent to the Settlement Administration Agent.

6.2.10 Process 1.5 – Load Settlement Timetable

This process loads a file containing the Settlement Timetable as published by the Market Domain Data Agent. The file may contain additional details not required by the Supplier Settlement and Reconciliation and Daily Profile Production processes. No automatic deletions will be performed as part of this process.

The incoming data will be validated to ensure the following:

Physical integrity of the file.
Settlement Calendar data to be loaded must be the same or a later version than that in the system.

If validation is not successful, the file is rejected and an exception report is generated.

If validation is successful, the file is loaded into the system. For each Settlement details contained in the file, the following processing is performed:

i. Updates to existing Settlements will not be permitted if there has been a corresponding SSR Run, or if SSA Data has been loaded for the Settlement.

ii. Only the Payment Date and Planned SSR Run Date may be updated for existing Settlements.

iii. The Planned SSR Run Date is an optional data item. If it is provided, it must be less than or equal to the Payment Date. If it is not provided, it will be defaulted to the Payment Date.

iv. All Payment Dates are on or between the First Payment Date and Last Payment Date specified in the file.

v. Any data processing which will update existing data on the system will be recorded as a warning in an exception report.

If any of the validation described above fails, a corresponding warning message will be written to the exception report, and the data for that Settlement not loaded. However, the loading of other valid Settlement data from the file will be allowed to continue.

6.2.11 Process 1.6 – Load BM Unit for Supplier in GSP Group Details

This process loads a file containing the BM Unit for a Supplier in a GSP Group details, as published by the Market Domain Data Agent. The file may contain additional details not required by the Supplier Settlement and Reconciliation and Daily Profile Production processes. No automatic deletions will be performed as part of this process.

The incoming data will be validated to ensure the following:

Physical integrity of the file.

If validation is not successful, the file is rejected and an exception report is generated.

If validation is successful, the file is loaded into the system. For each Settlement details contained in the file, the following processing is performed:

The BM Unit for Supplier in GSP Group Effective Dates will be checked to ensure that they do not overlap with any other instances with the same BM Unit Id.
The BM Unit can be associated with more than one Supplier and GSP Group combinations, but can be associated with only one combination on each Settlement Day.
The Effective Date ranges of the Base BM Units for a combination of Supplier and GSP Group do not overlap.
For a Scottish GSP Group, the Effective From Settlement Date must be on or after the BETTA Start Date

If any of the validation described above fails, a corresponding warning message will be written to the exception report, and the data for that Settlement not loaded (although processing will continue in order to detect any other errors in the file).

6.2.12 Process 2 - Daily Profile Production

6.2.13 Process 2.1 - Enter Parameter Data

6.2.13.1 Process 2.1.1 - Enter GSP Group Details

This process will allow the ISR Agent to add and delete entries from the list of valid GSP Groups. Not only are the Group Ids maintained but also the period of validity during which they are the responsibility of the ISR Agent.

When a GSP Group is deleted:

i) the system will validate that there is no daily profile data for the GSP Group. Such data must be archived off before deleting the GSP Group.

ii) the system will validate that there is no settlement data for the GSP Group. Such data must be archived before the GSP Group can be deleted.

iii) the system will delete any regression equations defined only for the GSP Group. A warning prompt will be displayed in this case.

6.2.13.2 Process 2.1.2 - Enter Calendar Details

This process will allow the ISR Agent to enter or revise the following calendar data for any day for which no Final Initial Settlement Run has yet taken place.

i) Day Type, Scottish Day Type and Season Id for each Settlement Day;

ii) Clock Time Changes.

Note that Settlement Day data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.6).

6.2.13.3 Process 2.1.3 - Calculate Noon Effective Temperature

This process will allow the ISR Agent to enter or revise the Noon Actual Temperature in degrees Fahrenheit for any day for which no Final Initial Settlement Run has yet taken place. A Noon Effective Temperature will be derived as follows:

NET_d = 0.57AT_d + 0.28AT_d-1 + 0.15AT_d-2

6.2.13.4 Process 2.1.4 - Enter Time of Sunset

This process will allow the ISR Agent to upload a file of sunset times. The system will check that no Final Initial Settlement Run has yet taken place for any of the Settlement Days concerned.

6.2.13.5 Process 2.1.5 - Enter Data Collector Details

This process will allow the ISR Agent to specify details of Data Collectors, and for which GSP Groups they need to receive daily Profile Coefficient data.

6.2.14 Process 2.2 - Record Time Patterns

6.2.14.1 Process 2.2.1 - Enter Settlement Configurations

This process will allow the ISR Agent to enter, update and delete Standard Settlement Configurations. A Standard Settlement Configuration Id, Description and Standard Settlement Configuration Type will be specified for each configuration. If the Standard Settlement Configuration is teleswitched, a Tele-switch User Id and Tele-switch Group Id will be specified. The system will not permit the Tele-switch User Id and Tele-switch Group Id to be updated if there are Teleswitch Time Pattern Regimes associated with the same combination of Tele-switch User Id and Tele-switch Group Id. The Standard Settlement Configuration Type will default to ‘I’ (Import), but can be change to ‘E’ (Export). If the Standard Settlement Configuration Type flag is updated, a warning message is output to inform that the results of future SSR runs or reruns will be affected.

Note that Settlement Configuration data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.2 Process 2.2.2 - Enter Time Patterns

This process will allow the ISR Agent to enter, update and delete Time Pattern Regimes. Each regime will be identified by an Id. The ISR Agent will specify whether each regime is teleswitched or not. If it is, a Tele-switch User Id and Tele-switch Group Id will be specified. The system will not permit the Tele-switch User Id and Tele-switch Group Id to be updated if there are Standard Settlement Configurations associated with the same combination of Tele-switch User Id and Tele-switch Group Id.

The ISR Agent will specify if the Time Pattern Regime is in Clock (local) time or GMT. The system will not permit the GMT Indicator to be updated if the Time Pattern Regime is linked to a Standard Settlement Configuration via a Measurement Requirement.

Note that Time Pattern data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.3 Process 2.2.3 - Assign Time Patterns to Configurations

This process will allow the ISR Agent to assign and deassign Time Pattern Regimes to a Standard Settlement Configuration (i.e. create or delete occurrences of Measurement Requirement). The system will not permit the Time Pattern Regimes for a Standard Settlement Configuration to be amended if the Standard Settlement Configuration is assigned to any Profile Classes. The Tele-switch User Id and Tele-switch Group Id for a Teleswitch Time Pattern Regime must match that of the Standard Settlement Configuration. All Time Pattern Regimes assigned to the Standard Settlement Configuration must either all be in Clock (local) time or GMT, i.e. a mixture of Clock (local) time or GMT is not permitted.

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.4 Process 2.2.4 - Assign Configurations to Profile Classes

This process will allow the ISR Agent to assign or deassign Standard Settlement Configurations to a Profile Class, or to update an existing link between them. Standard Settlement Configurations can only be assigned or unassigned to a Profile Class when this does not result in a change to the set of effective Valid Settlement Configuration Profile Classes for a Settlement Day which has already had a Final Initial Settlement Run.

When assigning a Standard Settlement Configuration to a Profile Class, the process will create an occurrence of Valid Settlement Configuration Profile Class, and an occurrence of Valid Measurement Requirement Profile Class for each Measurement Requirement of the Standard Settlement Configuration. If the Profile Class has the Switched Load Profile Class Indicator set, the user will also be required to specify which Measurement Requirements represent Switched Load (i.e. have the Switched Load Indicator set).

When deassigning a Standard Settlement Configuration from a Profile Class, the process will delete the Valid Settlement Configuration Profile Class and all dependent occurrences of Valid Measurement Requirement Profile Class, Daily Profile Coefficient, and Period Profile Class Coefficient.

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.5 Process 2.2.5 - Enter Clock Intervals

This process will allow the ISR Agent to define the clock interval(s) associated with each Time Pattern Regime. The system will only allow Clock Intervals to be defined for non teleswitched time patterns. Each clock interval will be specified in terms of the following attributes:

i) Start Date (day and month)

ii) End Date (day and month)

iii) Start Time

iv) End Time

v) Day of the Week

For example, a Time Pattern Regime for Summer Sunday afternoons might require a single Clock Interval with Start Date 1st June, End Date 31st August, Start Time 14:00, End Time 18:00, and day Sunday.

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.6 Process 2.2.6 - Load Teleswitch Contact Intervals

This process loads a file of daily Teleswitch Contact Intervals (i.e. Teleswitch contact switching times) prepared by the Teleswitch Agent for a single 24 hour day (i.e. midnight to midnight in UTC / GMT). The file of Teleswitch Contact Intervals reflects the actual Teleswitch messages broadcast by the Central Teleswitch Control Unit (CTCU) to Suppliers’ teleswitched metering systems for the day. Note that the data in one UTC file may affect two Settlement Dates. The process will validate that:

i) the combination of Tele-switch User Id and Tele-switch Group Id are already defined within a Standard Settlement Configuration on the system. If it is not, the data will be loaded for possible future use, and the process will issue a warning report;

ii) no Final Initial Settlement Run has yet taken place using any of the Teleswitch data. If it has, the data will be rejected;

iii) the file contains data for every combination of Tele-switch User Id and Tele-switch Group Id associated with one or more Standard Settlement Configurations which are effective on the Settlement Day (as determined by the Effective From Settlement Dates of the Valid Settlement Configuration Profile Classes defined on the system). If it does not, the file is considered incomplete and will be rejected in full; and

iv) for each unique Teleswitch Date, Teleswitch User, Teleswitch Group and Teleswitch Contact combination in a UTC file there is no overlapping or duplication of Teleswitch Contact Interval Effective Times. If there is, the whole file will be rejected.

If any data is rejected, the process will generate an exception report.

6.2.14.7 Process 2.2.7 - Load Pool Market Domain Data

This process reads a file of Standard Settlement Configuration data prepared by the Market Domain Data Agent, and loads any which are not already defined on the system or contain updates.

Standard Settlement Configuration and Time Pattern Regime data is processed according to the following:

i) any amendment affecting a Settlement date for which a Final Initial Settlement Run has occurred must be authorised and, if successful, will generate an audit report. This excludes Effective To Settlement Date amendments to a date after the most recent Final Initial Settlement Run;

ii) any data processing which will update data already defined on the system will be recorded as a warning in an exception report. This excludes Average Fraction of Yearly Consumption Effective To Settlement Date amendments provided the date does not precede the most recent Final Initial Settlement Run;

iii) counts of the total number of records that are updated and entered in the system will be recorded in an exception report;

iv) the file contains details of all existing Standard Settlement Configuration details and Time Pattern Regime details defined on the system. A single warning will be issued if a Standard Settlement Configuration or Time Pattern Regime and associated data is completely missing. Otherwise, individual warnings will be produced for all missing associated data. These warning messages are reported in the exception Report and will not prevent the file from loading.

v) the validation of the file will continue in the event of file rejection due to a validation failure, with appropriate messages written to the exception report. However, no changes will be applied to the system.

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

i) Id, Description and Standard Settlement Configuration Type;

ii) Time Pattern Regime Ids of the associated Measurement Requirements;

iii) Profile Class Ids of the Profile Classes for which the Standard Settlement Configuration is valid with associated Effective From Date Settlement Date and Effective To Settlement Date;

iv) Switched Load Indicators for each Measurement Requirement within each valid Profile Class;

v) One or more sets of Average Fraction of Yearly Consumption data for each GSP Group and valid Profile Class;

vi) Tele-switch User Id and Tele-switch Group Id for teleswitched Standard Settlement Configurations.

The process will load details of any Standard Settlement Configurations which are not already defined on the system, or which contain permitted updates. It will validate that:

i) the Profile Class Ids are already defined on the system;

ii) the Average Fractions of Yearly Consumption within each valid combination of Standard Settlement Configuration and Profile Class and GSP Group sum to one;

iii) the Switched Load Indicator is set for one or more Measurement Requirements for each combination of a Standard Settlement Configuration with a Switched Load Profile Class;

iv) the Switched Load Indicator is not set for any Measurement Requirement in any combination of a Standard Settlement Configuration with a non-Switched Load Profile Class;

v) all Time Pattern Regimes linked to a Standard Settlement Configuration are either all in Clock (local) time or all in GMT;

vi) if creating a Measurement Requirement, the combination of Tele-switch User Id and Tele-switch Group Id are the same for the Teleswitch Time Pattern Regime and Standard Settlement Configuration;

vii) at least one Teleswitch Register Rule exists for every Teleswitch Time Pattern Regime;

viii) there must be at least one Average Fraction of Yearly Consumption Set for a Valid Settlement Configuration Profile Class. However, the set(s) need not necessarily cover every Settlement Date for which the Valid Settlement Configuration Profile Class is effective;

ix) the Average Fractions of Yearly Consumption within each valid combination of Standard Settlement Configuration and Profile Class and GSP Group do not overlap between identical combinations. Gaps between Average Fractions of Yearly Consumption sets related to a Valid Settlement Configuration Profile Class and its effective period are permitted.

The following changes are permitted for a Standard Settlement Configuration which is already defined on the system, subject to the specified validation:

i) a change to the Standard Settlement Configuration description;

ii) a change to the SSC Type;

if the SSC Type flag is updated, a warning message is output to inform that the results of future SSR runs or reruns will be affected;

iii) a change to the Tele-switch User Id and Tele-switch Group Id;

if the Standard Settlement Configuration is linked to any Time Pattern Regimes via associated Measurement Requirements, then all Time Pattern Regimes associated with the Standard Settlement Configuration must change their Tele-switch User Id and/or Tele-switch Group Id during the file load;

iv) new Measurement Requirements for the Standard Settlement Configuration;

provided that the Time Pattern Regime is already defined on the system, or has been created during the file load;
provided the Tele-switch User and Tele-switch Group Id are the same for the Tele-switched Time Pattern Regime and Standard Settlement Configuration, taking into account any updates to the Time Pattern Regime and/or Standard Settlement Configuration;
provided that all associated Time Pattern Regimes, taking into account any updates to the Time Pattern Regimes, are either all local time or all GMT, i.e. a mix of local time and GMT time is not allowed;

v) new Valid Settlement Configuration Profile Classes and associated Valid Measurement Requirement Profile Classes;

provided that the Profile Class is already defined on the system;
provided that the file contains a Valid Measurement Requirement Profile Class for each Time Pattern Regime associated with the Standard Settlement Configuration;
provided that the file contains at least one valid set of Average Fractions of Yearly Consumption for every Valid Settlement Configuration Profile Class.
for Switched Load Profile Classes, one or more associated Valid Measurement Requirement Profile Classes has the Switched Load Indicator set;
for Non-switched Load Profile Classes, no associated Valid Measurement Requirement Profile Classes has the Switched Load Indicator set;

vi) a change to the Effective To Date for one or more Valid Settlement Configuration Profile Classes;

vii) a change to the Switched Load Indicator for one or more Valid Measurement Requirement Profile Classes;

for Switched Load Profile Classes, one or more associated Valid Measurement Requirement Profile Classes has the Switched Load Indicator set;
for Non-switched Load Profile Classes, no associated Valid Measurement Requirement Profile Classes has the Switched Load Indicator set;

viii) one or more new sets of Average Fraction of Yearly Consumption data;

provided that the Average Fraction of Yearly Consumption Set for a combination of Standard Settlement Configuration, Profile Class, Time Pattern Regime and GSP Group do not overlap other identical combinations. Date gaps between Average Fraction of Yearly Consumption Sets related to a Valid Settlement Configuration Profile Class are permitted;
provided that the Average Fractions of Yearly Consumption within each valid combination of Standard Settlement Configuration, Profile Class, GSP Group and Effective From Date sum to one;

ix) a change to the Average Fraction of Yearly Consumption Set’s Effective To Settlement Date;

provided the Average Fraction of Yearly Consumption Set for a combination of Standard Settlement Configuration, Profile Class, Time Pattern Regime and GSP Group do not overlap other identical combinations. Date gaps between Average Fraction of Yearly Consumption Sets relating to a specific Valid Settlement Configuration Profile Class are permitted;
provided that the change does not affect the Average Fraction of Yearly Consumption coverage of a Non Half Hourly BM Unit Allocation. A warning will be logged if the change leaves any Non Half Hourly BM Unit Allocation without complete Average Fraction of Yearly Consumption coverage.

x) a change to the Average Fraction of Yearly Consumption value for one or more Average Fraction of Yearly Consumption details

provided that the Average Fractions of Yearly Consumption within each valid combination of Standard Settlement Configuration, Profile Class, GSP Group and Effective From Date still sum to one.

The file will also contain the following data for each Time Pattern Regime:

i) the Time Pattern Regime Id;

ii) the Teleswitch/Clock Indicator, specifying whether the Time Pattern is teleswitched or timeswitched;

iii) if it is teleswitched, the Tele-switch User Id, Tele-switch Group Id and Teleswitch Register Rule(s) associated with a set of Teleswitch Contact Rules;

iv) if it is timeswitched, one or more Clock Intervals, each defined in terms of the Day of the Week, Start and End Day and Month, and Start and End Time.

v) the GMT Indicator, specifying whether the Time Pattern is in GMT or not.

The following changes are permitted for a Time Pattern Regime which is already defined on the system, subject to the specified validation:

i) a change to the GMT Indicator:

if the Time Pattern Regime is linked to a Standard Settlement Configuration via an associated Measurement Requirement, then all Time Pattern Regimes associated with the Standard Settlement Configuration must also change their GMT Indicators during the file load;

ii) a change to the Tele-switch Group Id and/or Tele-switch User Id;

provided that the new Tele-switch User and Tele-switch Group is either an existing combination for a Standard Settlement Configuration or will be an existing combination after the file load;
if the Time Pattern Regime is linked to a Standard Settlement Configuration via an associated Measurement Requirement, then all Time Pattern Regimes associated with the Standard Settlement Configuration and the Standard Settlement Configuration must change their Tele-switch Group id and/or Tele-switch User Id during the file load;

iii) new Tele-switch Contact Rules;

provided there are no duplicate Register Rule Id and Tele-switch Contact Code combinations within the set of Tele-switch Contact Rules;

iv) a change to the Tele-switch Contact Rule;

v) new set of Clock Intervals for Clock-switched Time Pattern Regime.

The validation for automated amendment of Standard Settlement Configuration and Time Pattern Regime data will the same as the validation for the manual data entry process, as defined in processes 2.2.1 to 2.2.6, 2.2.8 and 2.2.9.

6.2.14.8 Process 2.2.8 - Specify Average Fraction of Yearly Consumption

This process will allow the ISR Agent to specify the Average Fraction of Yearly Consumption (AFYC_pt) for each Valid Measurement Requirement Profile Class for a given combination of Valid Settlement Configuration Profile Class and GSP Group. The system will validate that the fractions specified sum to one and that there is Average Fraction of Yearly Consumption coverage for all Non Half Hourly BM Unit Allocations. An Effective Date will be specified for each set of data.

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.9 Process 2.2.9 - Enter Teleswitch Register and Contact Rules

This process will allow the ISR Agent to browse, enter, update or delete a Teleswitch Register Rule and associated Teleswitch Contact Rule(s) for a Teleswitch Time Pattern Regime. At least one Teleswitch Register Rule must exist at all times for a Teleswitch Time Pattern Regime. Each Teleswitch Register Rule and associated Teleswitch Contact Rule will be specified in terms of the following attributes:

i) Tele-switch Time Pattern Regime Id

ii) Tele-switch Register Rule Id

iii) Tele-switch Contact Code

iv) Tele-switch Contact Rule

Note that this data will normally be loaded from a file prepared by the Market Domain Data Agent (see process 2.2.7). This manual process is required as a backup, and possibly for minor amendments.

6.2.14.10 Process 2.2.10 - Enter Teleswitch Contact Interval Details

This process will allow the ISR Agent to browse, enter, update or delete details associated with a Teleswitch Contact Interval. Each Teleswitch Contact Interval will be specified in terms of the following attributes:

i) Tele-switch User Id

ii) Tele-switch Group Id

iii) Start Date and Time {Tele-switch Contact Interval}

iv) End Date and Time {Tele-switch Contact Interval}

v) Tele-switch Contact Code

vi) Tele-switch Contact State

Note that this data will normally be loaded from a file prepared by Teleswitch Agent (see process 2.2.6). This manual process is required as a backup, and possibly for minor amendments.

6.2.15 Process 2.3 - Calculate Daily Profiles

6.2.15.1 Process 2.3.1 - Determine Time Pattern State

This process is triggered by a request from the ISR Agent to calculate Profile Coefficients for a Settlement Day. If coefficients have already been calculated for the Settlement Day, the operator will be required to confirm that a recalculation is intended. The system will validate that the Final Initial Settlement Run has not yet taken place for the Settlement Day.

This process will convert the Clock Intervals and Teleswitch Intervals for each Time Pattern Regime into a vector of Period Register On State Indicators for the day.

The following processing will be performed:

6.2.15.1.1 Convert Teleswitch Contact Intervals to Teleswitch Intervals

This process will derive Teleswitch Intervals, i.e. the switching times for each active Settlement register, from the Teleswitch Contact Intervals provided by the Teleswitch Agent.

The processing performed is as follows:

i) for each Teleswitch Group, identify the Standard Settlement Configuration(s) to which it relates from the set of Standard Settlement Configuration defined on the system;

ii) identify the Time Pattern Regimes associated with each Standard Settlement Configuration from the set of Teleswitch Time Pattern Regimes defined on the system;

iii) for each set found:

a) retrieve all Teleswitch Contact Intervals for the appropriate Teleswitch Group and Settlement Day;

b) process all these records in chronological order, using the Teleswitch Contact Rules and Teleswitch Register Rules to determine the state of the Time Pattern Regimes after the start of each Teleswitch Contact Interval;

c) store this information on the database as one or more Teleswitch Intervals.

An additional check is made for the erroneous condition where there are no Settlement registers recording consumption for an unrestricted Standard Settlement Configuration, as follows:

i) for each teleswitched Standard Settlement Configuration, if all Measurement Requirements has its Switched Load Indicator set, then the Standard Settlement Configuration is restricted, otherwise the Standard Settlement Configuration is unrestricted;

ii) if the Standard Settlement Configuration is unrestricted, then at least one Time Pattern Regime linked to the Standard Settlement Configuration must be switched on in every Settlement Period during the Settlement Day;

iii) if the validation fails, an exception report is produced.

6.2.15.1.2 Round Clock Intervals and Teleswitch Intervals

This process will be performed for each Standard Settlement Configuration as follows:

Determine the Measurement Requirements and associated Clock Intervals and Teleswitch Intervals for the Standard Settlement Configuration. Consider in chronological order each spot time on which one or more of these Intervals starts or ends.

If the spot time is not a Settlement Period boundary, then determine the following for the set of Intervals ‘I’ which start or end at that spot time:

i) the Unrounded Duration UDI of each Interval, in minutes, prior to any rounding;

ii) the Rounded Up Duration RUDI of the Interval after rounding, calculated on the assumption that the spot time is rounded to the following Settlement Period boundary. If the Interval ends on the spot time in question, RUDI is calculated using the rounded start time, which has already been calculated.

If the Interval starts on the spot time, then the end time has not yet been rounded, and so RUD_I must be calculated on the assumption that the end time will be rounded to the nearest Settlement Period boundary. If the end time is at 15 minutes past the hour, then it must be rounded back to the previous hour; if the end time is at 45 minutes past the hour, then it must be rounded forward to the next hour;

iii) the Rounded Down Duration RDDI of the Interval is calculated as for RUDI, but on the assumption that the spot time is rounded to the previous Settlement Period boundary;

All Interval start and end times which fall on that spot time will then be rounded to the same Settlement Period boundary, according to the following rules:

i) if the number of Intervals for which RUD_I<0 is less than the number of Intervals for which RDD_I<0, then round to the next Settlement Period boundary.

Conversely, if the number of Intervals for which RUD_I<0 is greater than the number of Intervals for which RDD_I<0, then round to the previous Settlement Period boundary; else;

ii) if the number of Intervals for which RUD_I=0 is less than the number of Intervals for which RDD_I=0, then round to the next Settlement Period boundary.

Conversely, if the number of Intervals for which RUD_I=0 is greater than the number of Intervals for which RDD_I=0, then round to the previous Settlement Period boundary; else;

iii) if Σ_I(RUD_I-UD_I)² < Σ_I(RDD_I-UD_I)², then round to the next Settlement Period boundary. Conversely, if Σ_I(RUD_I-UD_I)² > Σ_I(RDD_I-UD_I)², then round to the previous Settlement Period boundary; else;

iv) round to the previous Settlement Period boundary.

After each spot time has been rounded, check whether any of the Intervals ending at that time now has a duration of zero. If so, advance the end time for that Interval to the next Settlement Period boundary.

6.2.15.1.3 Convert GMT Intervals to Local Time and Process Local Time Intervals during Clock Change Days

This process will take account of whether the Time Pattern Regime is GMT or clock (local) time and will convert GMT times to local half hours. It must also take account of the clock change (long and short) days.

6.2.15.2 Process 2.3.2 - Evaluate Regression Equations

The following processing is to be performed for each GSP Group.

Retrieve the date, day type, Scottish day type, time of sunset and noon effective temperature. Convert the time of sunset to the sunset variable i.e. minutes after 1800 GMT, which may be negative.

Based on the date and Season Id, retrieve the correct set(s) of regression equations for each Profile Class.

For England and Wales GSP Groups, select Regression Coefficients (a) whose Day Type matches the Day Type selected from Settlement Day, and (b) whose Scottish Regression Flag set to “No”.

For Scottish GSP Groups, select Regression Coefficients (a) whose Day Type matches the Scottish Day Type selected from Settlement Day and, (b) whose Scottish Regression Flag is set to “Yes” (if the Settlement Date is greater than or equal to the BETTA Start Date, but less than or equal to the BETTA Regression Coefficients End Date), or whose Scottish Regression Flag is set to “No” (in all other cases).

Where Scottish Regression Coefficients (i.e. those with Scottish Regression Flag set to “Yes”) are used in a DPP run, an entry will be created in the exception log to indicate this.

There will be one set of forty-eight regression equations for each Profile Class, plus one or more shorter sets for Switched Load Profile Classes. Retrieve also the Group Average Annual Consumption for each profile. (Note that these group averages are provided by the Profile Administrator as an average for all customers in the Profile Class.)

Evaluate each regression equations using the Day of the Week, sunset variable and noon effective temperature. Divide through to convert to Profile Coefficients:

_{$ProfileCoefficient= \frac{Evaluated Regression Equation}{Group Average Annual Consumption ´ 2000}$ Profile Coefficient=" { { size 10{"Evaluated Regression Equation"}} over { size 10{"Group Average Annual Consumption "´" 2000"}} } }} {}}

If there is a clock change on the day, the system will manipulate those profiles with length 48 periods to the appropriate length, using the following algorithm:

For additional periods (eg. 25 hour day) use linear interpolation. If the extra hour(s) correspond to periods n to n+m then the profile coefficients (pcs) for these periods will be calculated as follows:

pc(n+i) = pc(n-1) + [pc(n+m+1)-pc(n-1)] * (i+1)/(m+2)

for 0 <= i <= m.

As an example, if the clocks go back an hour at 2 a.m., the above formula would be used with n=5 and m=1 to derive values for the 5^th and 6^th Settlement Periods in the day.

The above formula doesn’t cope with the clock going back at midnight, because pc(n+m+1) is undefined in this case. In this case, use linear extrapolation rather than linear interpolation, as follows:

pc(n+i) = pc(n-1) + [pc(n-1)-pc(n-2)] * (i+1).

For missing periods (e.g. a 23 hour day), assume the profile coefficients for the remaining hours are unaltered, i.e. the missing hour is removed and the profile coefficients for the remaining periods are the same as for a 24 hour day.

Any negative Basic Period Profile Coefficient should be reset to zero and a warning message written on a report to the ISR Agent.

5.2.15.3 Process 2.3.3 - Combine Base and Switched Load Profiles

This process creates a set of Combined Period Profile Coefficients for each combination of:

i) GSP Group;

ii) Settlement Day; and

iii) Valid combination of Standard Settlement Configuration and Profile Class, for a Switched Load Profile Class.

For each of the above combination, a set of Average Fractions of Yearly Consumption (AFYCs) is required. If AFYCs are not available for a particular combination, that combination is omitted from the profiling run.

The algorithm is as follows:

i) Identify the Valid Measurement Requirement Profile Classes which record the Switched Load. For each Valid Measurement Requirement Profile Class, retrieve the values of Period Time Pattern State Qtj (0 for off, or 1 for on) for each Settlement Period. Perform the following sub-processes:

a) Create an unmodified switching pattern for the Switched Load by combining the values of Period Time Pattern State for each Settlement Period Qtj for all the relevant Valid Measurement Requirement Profile Classes. A Settlement Period is considered to be “on” if one or more Period Time Pattern States retrieved is on; an “off” period is when none of the Period Time Pattern States retrieved is “on”.

b) Create a modified switching pattern for the Switched Load, initially setting it to the same as the unmodified switching pattern, and then modifying it as follows:

Determine if the modified switching pattern satisfies any of the following conditions:

the Switched Load is “on” for less than two half hours in the Settlement Day;
the Switched Load is “on” for more than 47 half hours in the Settlement Day;
the Switched Load is “on” for the entire Settlement Day.

If any of the above conditions are satisfied, then amend the modified switching pattern by applying the following rules:

in the instance where the Switched Load is “off” all day, switch the first two half hours of the Settlement Day to “on”;
in the instance of where the Switched Load is “on” for only a single half hour, switch the next half hour to “on”. If the single half hour is the last half hour, then switch the previous half hour to “on”.
in the instance where the Switched Load is “on” for more than 47 half hours, switch all the half hours after the 47th “on” period to “off”;
in the instance where the Switched Load is “on” all day (given the above case, this could only be on a short day), switch the last half hour to “off”.

a) Using the modified switching pattern, label the “on” periods as follows:

Identify the longest continuous block of “off” periods in the Settlement Date. In the case where the Settlement Day both begins and ends with “off” periods, this should be regarded as a single block for this purpose.

Label the “on” periods in sequence, numbered from 1 upwards. The numbering usually starts from the first “on” period immediately following the block of “off” periods identified above. If this block consists of separate periods at the start and end of the Settlement Day, start the numbering with the first “on” period of the Settlement Day. This will provide the total number of Settlement Periods in which any of the switched load registers is on.

If there is no “off” period in the Settlement Day (i.e. switched load is on throughout the day), start the numbering with the first period of the Settlement Day.

If there is more than one continuous block of “off” periods with the same longest duration, identify the longest continuous block of “on” periods in the Settlement Day and start the numbering with the first period of this block.

If there is more than one continuous block of “on” periods with the same longest duration, identify the last such block occurring during the Settlement Day and start the numbering with the first period of this block.

i) Using the modified switching pattern, count the number of “on” periods to obtain the duration, and retrieve the set of Basic Period Profile Coefficients with the same duration. If the Profile Class does not have a profile with the correct duration, then issue a warning message, and do not process this Standard Settlement Configuration further.

ii) Calculate a Switched Load Profile Coefficient for the regime by moving Profile Coefficients determined in (ii) into the low register “on” periods using the combined switching pattern and the sequence order determined in (i).

iii) Retrieve the set of Basic Period Profile Coefficients for the Base Load (i.e. the profile with the same duration as the Settlement Day itself).

iv) Using the modified switching pattern, calculate the fraction Hpt of the low register consumption for the regime that can be regarded as Base Load. This fraction is defined as the sum of the Base Load Profile Coefficients in the “on” periods in the Settlement Day, divided by the sum in the “off” periods in the Settlement Day.

v) Using the unmodified switching pattern, produce Low and Normal Register profile coefficients for the regime, by combining the Switched Load profile (calculated in iii), and the Base Load profile (calculated in iv), as follows:

In “On” Periods:

Low Register Profile Coefficient = Base Profile * Base Fraction +

Switched Profile * Switched Fraction

Normal Register Profile Coefficient = 0

In “Off” Periods:

Low Register Profile Coefficient = 0

Normal Register Profile Coefficient = Base Profile * Base Fraction

where the Base Fraction is the fraction of consumption for the regime that is attributable to Base Load, and the Switched Fraction is the fraction attributable to Switched Load. These fractions can be determined in terms of the Average Fractions of Yearly Consumption AFYC_pt as follows:

_{$\begin{matrix} Base Fraction= ({1+H}_{pt}) ´ \sum_{normal timeslots} {AFYC}_{pt} \\ Swi tched Fraction= (\sum_{low timeslots} {AFYC}_{pt}) - H_{pt} ´ \sum_{normal timeslots} {AFYC}_{pt} \end{matrix}$ Base Fraction=" $ "1+H" rSub { size 8{"pt"} } $ ´ Sum cSub { size 8{"normal timeslots"} } { size 12{"AFYC" rSub { size 8{"pt"} } } } }} {} #
size 12{ size 10{"Swi""tched Fraction=" left ( Sum cSub { size 7{"low timeslots"}} {} " AFYC" rSub {"pt"} right )-H rSub { size 8{"pt"} } ´ Sum cSub { size 8{"normal timeslots"} } { size 12{"AFYC" rSub { size 8{"pt"} } } } }} {}
} } {}}

where the normal timeslots are all those occurrences of Valid Measurement Requirement Profile Class which do not have the Switched Load Indicator set, and low timeslots are all those occurrences of Valid Measurement Requirement Profile Class which do have the Switched Load Indicator set.

Any negative Low or Normal Register Profile Coefficient should be reset to zero and a warning message written on a report to the ISR Agent.

6.2.15.4 Process 2.3.4 - Chunk Profiles

This process creates a set of Period Profile Class Coefficients for each combination of:

i) GSP Group;

ii) Settlement Day; and

iii) Valid Measurement Requirement Profile Class.

The algorithm is as follows:

i) Retrieve the Profile Coefficients for the Settlement Day and Profile Class. If the Profile Class has the Switched Load Profile Class Indicator set, the appropriate coefficients are the Normal Register Profile Coefficients or the Low Register Profile Coefficients, depending upon whether the Switched Load Indicator is set for the Valid Measurement Requirement Profile Class. Otherwise, they are the Basic Period Profile Coefficients for the single Profile assigned to the Profile Class.

ii) Retrieve the occurrences of entity Period Time Pattern State, and the associated values of the Period Register On State Indicator, for the Valid Measurement Requirement Profile Class.

iii) For each Settlement Period, calculate the Period Profile Class Coefficients as follows:

PPCC_ptj = PC_ptj * Q_tj / AFYC_pt

iv) where PC_ptj are the coefficients determined in (i); Q_tj are the Period Register On State Indicators retrieved in (ii); and AFYC_pt is the Average Fraction of Yearly Consumption for the Valid Measurement Requirement Profile Class.

6.2.16 Process 2.4 - Produce Profile Reports

6.2.17 Process 2.4.1 - Produce Supplier & DC Profile Reports

This process will produce the following reports:

i) A Standing Profile Data report for one or all GSP Groups. Data items are as follows:

For each GSP Group and Profile Class

GSP Group Id

Profile Class Id

Profile Class Description

Switched Load Profile Class Indicator

For each GSP Group and Profile Class and Profile

Profile Id

Profile Description

Effective From Settlement Date {PROF}

Effective To Settlement Date {PROF}

For each GSP Group and Profile Class and Profile and Profile Regression Equation Set

Day Type Id

Season Id

Group Average Annual Consumption Regression Coefficients x 48

ii) A Daily Profile Data report for a given Settlement Day and one or all GSP Groups. Data items are as follows:

For each GSP Group

GSP Group Id

Time of Sunset

Actual Noon Temperature

Effective Noon Temperature

Sunset Variable

For each GSP Group and Profile

Profile Class Id

Profile Id

for each Settlement Period

Period Profile Coefficient Value

For each GSP Group and Valid Settlement Configuration Profile Class

Profile Class Id

Standard Settlement Configuration Id

for each Settlement Period

Normal Register Profile Coefficient

Low Register Profile Coefficient

For each GSP Group and Valid Measurement Requirement Profile Class

Profile Class Id

Standard Settlement Configuration Id

Time Pattern Regime Id

for each Settlement Period

Profile Coefficient Value

Period Register On State Indicator

iii) A Standard Settlement Configuration report. Data items are as follows:

For each Valid Settlement Configuration Profile Class

Profile Class Id

Profile Class Description

Switched Load Profile Class Indicator

Standard Settlement Configuration Id

Standard Settlement Configuration Description

For each Valid Measurement Requirement Profile Class

Time Pattern Regime Id

Switched Load Indicator

Average Fraction of Yearly Consumption

GMT Indicator

Tele-switch/Clock Indicator

Tele-switch User Id

Tele-switch Group Id

Tele-switch Switch Id

For each Clock Interval of each Valid Measurement Requirement Profile Class:

Day of the Week Id

Start Day

Start Month

End Day

End Month

Start Time

End Time

For each Teleswitch Interval of each Valid Measurement Requirement Profile Class:

Start Time

End Time

iv) A Teleswitch Contact Interval Data report. Data items are as follows:

For each Teleswitch Group:

Tele-switch User Id

Tele-switch Group Id

For each Teleswitch Contact Interval:

Tele-switch Contact Code

Start Date and Time {Tele-switch Contact Interval}

End Date and Time {Tele-switch Contact Interval}

Tele-switch Contact State

By default, Standing Profile Data reports and Standard Settlement Configuration reports will be sent to all Suppliers and Data Collectors. The Daily Profile Data reports will be sent only to Suppliers, except in the case of a Demand Control Event, when the report will also be issued to NHH Data Collectors. The Teleswitch Contact Interval Data report will be generated for all Suppliers, but only distributed to them by the ISR Agent only upon their request.

6.2.18 Process 2.4.2 - Extract Data for EAC Calculator

This process will produce a data file for each Data Collector showing the daily total Profile Coefficient for every Valid Measurement Requirement Profile Class for a given Settlement Day and those GSP Groups to which the Data Collector is appointed. For those GSP Groups excluded from the Profile Production Run, it will include data from the most recent previous extract runs in the extract file. It will also allow the selection of EAC data for a Range of Settlement Days.

It will also allow the ISR Agent to produce a data file for a Data Collector showing the daily total Profile Coefficient for every Valid Measurement Requirement Profile Class for each Settlement Day in a range of Settlement Days, and for a specific GSP Group. This will be used when a new Data Collector is appointed to a MSID in the GSP Group and will be initiated by the ISRA Operator.

6.2.19 Process 2.5 - Enter Profiles

6.2.19.1 Process 2.5.1 - Enter Profile Details

This process will allow the ISR Agent to enter, update and delete Profile Classes. An indicator will be entered to specify whether or not each Profile Class is a Switched Load Profile Class.

It will also read a file of Profile Classes prepared by the Market Domain Data Agent which will load new Profile Classes and any amendments to existing ones into the system.

The process will also allow one or more profiles to be defined for each Profile Class. A duration in Settlement Periods will be defined for each profile.

The system will validate profile data as follows:

i) a non Switched Load Profile Class can only have one profile of duration 48 Settlement Periods;

ii) no Final Initial Settlement Run has yet taken place for the Settlement Date of the Date Effective of the Profile and Profile Class;

iii) a Switched Load Profile Class must have one profile of duration 48 Settlement Periods, and one or more profiles of duration less than 48 Settlement Periods.

6.2.19.2 Process 2.5.2 - Enter Regression Equations

This process will allow regression equations to be entered for each profile. The following data items will be required for each regression equation;

i) Profile Class to which it applies;

ii) season to which it applies;

iii) effective date;

iv) regression coefficients for the number of Settlement Periods given by the duration of the profile;

v) Group Average Annual Consumption (MWh).

The system will validate that no Final Initial Settlement Run has yet taken place for the Settlement Date of the Date Effective of the regression equations.

6.2.20 Process 2.6 – Load Market Domain Data Complete Set

This process loads data from a file containing published Market Domain Data prepared by the Market Domain Data Agent. The file may contain additional details not required by the Supplier Settlement and Reconciliation and Daily Profile Production processes. No automatic deletions will be performed as part of this process.

The incoming data will be validated to ensure:

Physical Integrity
The data is from the Electricity Pool originator

If either of these conditions is not satisfied the data file will be rejected and the load will fail. A message is written to a log to indicate that the load has failed. An exception report is generated for the ISR Agent.

Once validated, Settlement Day, Line Loss Factor Class and BM Unit data is processed according to the following:

i. any amendment affecting a Settlement date for which a Final Initial Settlement Run has occurred must be authorised and, if successful, will generate a Standing Data Audit report;

ii. any data processing which will update existing data on the system will be recorded as a warning in an exception report;

iii. counts of the number of record types that are updated and inserted will be recorded in an exception report;

iv. the file contains details of all existing Settlement Day and Line Loss Factor Class Details defined on the system. A warning will be issued if Settlement Day and Line Loss Factor Class data is missing. These warning messages are reported in the exception report and will not prevent the file from loading.

v. the processing of the file will continue in the event of file rejection due to a validation failure, with appropriate messages written to the exception report. However, no changes will be applied to the ISRA system.

The following data will be specified in the file for each Settlement Day:

i. the Settlement Date of the data;

ii. the Day Type Id associated with the Settlement Day;

iii. the Season Id specifying the season associated with the Settlement date.

Validation will take place on the Settlement Day data to ensure that the Day Type Id and Season Id values are valid. No other specific validation is performed.

The following data will be specified in the file for each Line Loss Factor Class:

i. Distributor Id of the Market Participant;

ii. Market Participant Role Code;

iii. Line Loss Factor Class Id;

iv. Metering System Specific Line Loss Factor Class Indicator;

v. Effective From Settlement Date of the Line Loss Factor Class;

vi. Effective To Settlement Date of the Line Loss Factor Class.

The following validation will be performed on Line Loss Factor Class data:

i. The Line Loss Factor Class must belong to a valid distributor.

ii. If the combination of Line Loss Factor Class and Distributor already exists on the system then the date range for which the new combination is effective must not overlap the date range of the existing combinations.

iii. Only General Line Loss Factor Classes Import/Export will be loaded (Metering System Specific Line Loss Factor Class Indicator type ‘A’ and ‘C’).

iv. The Effective To Settlement Date must be greater than, or equal to, the Effective From Settlement Date.

If the Effective To Settlement Date is amended to an earlier date and this results in instances of Settlement Period Line Loss Factor falling outside the Effective Period of the Class, a warning message is written to the exception report.

6.3 External Entity Descriptions

ID	Ext. Entity	Description
d	Authorised Temperature Provider	The source for all the temperature data.
a	Distribution Business	The distributor who is responsible for the operation of a distribution network.
c	Electricity Pool	The Electricity Pool of England and Wales.
o	HH Data Aggregator	The system which aggregates meter readings or estimates of meter readings for all half hourly meters and the unmetered supplies which are treated as half hourly meters.
k	ISR Agent	The Pool approved agent responsible for operating the ISRA system.
q	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.
r	Sunset Provider	The body responsible for providing the time of sunset for each day.
p	Non-HH Data Aggregator	The system which aggregates EACs and AAs for all non half hourly meters and the unmetered supplies which are treated as non half hourly meters.
b	Non-HH Data Collector	An organisation Qualified in accordance with BSCP537 (Reference 21) to periodically collect and process meter readings and derive consumptions.
g	Settlement Administration Agent	The body responsible for energy allocations and associated systems to allow payments to be made to Trading Parties.
i	Profile Administrator	The Pool approved agent responsible for performing research into patterns of electricity usage.
f	Central Data Collection Agent	The agent responsible for the development and operation of the Central Data Collection systems.
j	Supplier	A supplier of electricity.
e	Teleswitch Agent	The Pool Agent responsible for providing a daily file of Teleswitch contact intervals reflecting the actual Teleswitch messages broadcast by the Central Teleswitch Control Unit to Suppliers’ teleswitched metering systems for the day.
h	TUoS	Transmission Use of System. Calculates charges made by the NETSO for use of the super grid.
l	HH Data Collector	An organisation Qualified in accordance with BSCP537 (Reference 21) to collect and process HH meter readings.

6.4 I/O Descriptions

The table below gives an elementary description of all the data flows into and out of the ISRA system, i.e. between ISRA and its external entities.

The attributes for each flow are listed in the data flow descriptions section of this document.

Data Flow Name	From	To	Comments
Actual GSP Group Take	External entity f Central Data Collection Agent	Process 1.1.1 Validate Settlements Data	The GSP group take for the Settlement Day, as calculated by the SSA, for each half hour of the Settlement Day.
Actual Noon Temperature	External entity k ISR Agent	Process 2.1.3 Calculate Noon Effective Temperature	The arithmetic average of noon temperature as measured at representative weather stations within the GSP Group area.
Average Fraction of Yearly Consumption	External entity k ISR Agent	Process 2.2.8 Specify Average Fraction of Yearly Consumption	The estimated fraction of consumption for a Profile Class and Measurement Requirement used in Profile Production, with the dates on which it is effective.
BM Unit Supplier Take Energy Volume Data File	Process 1.4.13.2 Generate BM Unit Supplier Take Energy Volume Data File	External Entity g Settlement Administration Agent	The Period Supplier Deemed Take for each BM Unit in each Settlement Period.
BM Unit Gross Demand Data File	Process 6.2.8.3 Produce BM Unit Gross Demand Data File	External entity g Settlement Administration Agent	A report of Gross Demand for each BM Unit required by the SAA for EMR reporting
BM Unit Non Chargeable Demand	Process 1.2.13 – Produce BM Unit Non Chargeable Demand	External entity g Settlement Administration Agent	A report of Non Chargeable Demand for each Supplier BM Unit required by the SAA for EMR reporting
BM Unit Disconnected Supplier Take Energy Volume Data File	Process 1.4.13.2 Generate BM Unit Supplier Take Energy Volume Data File	External Entity g Settlement Administration Agent	The Period Disconnected Supplier Deemed Take for each BM Unit in each Settlement Period.
BM Unit Aggregated Half Hour Data File	External Entity o HH Data Aggregator	Process 1.1.3 Validate HH data	Contains details of half hourly energy volumes broken down by BM Unit.
BM Unit Aggregated Half Hour Disconnection Data File	External Entity o HH Data Aggregator	Process 1.1.3 Validate HH data	Contains details of half hourly disconnected energy volumes broken down by BM Unit.
BSCCo GSP Group Consumption Totals Report	Process 1.2.5 Create GSP Group Consumption Totals Report	External entity e Electricity Pool	This report contains GSP Group Consumption Totals for consumption component classes both before and after GSP Group correction. This report also contains Total MSID Counts for Consumption Component Classes. It is sent to BSCCo and contains all GSP Groups in which any Suppliers are active on the settlement date and consumption component classes for which there was consumption.
Calendar Details	External entity k ISR Agent	Process 2.1.2 Enter Calendar Details	Contains details of the Clock Change dates and Day Types.
Changes to aggregator assignments	External entity k ISR Agent	Process 1.3.6 Specify Aggregator for GSP Group	Indicates to SSR which Data Aggregators will be providing data for which Suppliers.
Changes to NHH BM Unit allocations	External Entity k ISR Agent	Process 1.3.8 Assign NHH BM units	Updates the allocation of Valid Settlement Configuration Profile Class to a NHH BM Unit
Changes to BM Unit Details	External entity k ISR Agent External entity q Market Domain Data Agent	Process 1.3.9 Enter BM Units Manually	Updates BM Unit details.
Changes to distributor assignments	External entity k ISR Agent	Process 1.3.5 Specify Distributor for GSP Group	Allocates a Distributor to a GSP Group.
Changes to line loss factor codes	External entity k ISR Agent	Process 1.3.4 Maintain line loss factor codes	Updates to the list of Line Loss Factor Codes that SSR uses for validation.
Changes to scaling factors	External entity k ISR Agent	Process 1.3.3 Maintain GSP correction scaling factors	Updates to the GSP Group correction scaling factors.
Changes to supplier details	External entity k ISR Agent	Process 1.3.1 Maintain supplier details	Updates to the list of Suppliers for which SSR expects to receive data.
Clock Intervals	External entity k ISR Agent	Process 2.2.5 Enter Clock Intervals	Updates to the Time Pattern Regime details held in SSR.
Daily Profile Data Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity j Supplier External entity l NHH Data Collector	A report for Suppliers detailing all of the Daily Profile Class Coefficients produced for the specified Settlement Day.
Daily Profile Total Extract	Process 2.4.2 Extract Data For EAC Calculator	External entity b Non-HH Data Collector	The sum of the daily Profiles for each Settlement Class for the Settlement Day. This is to enable the EAC calculation system to produce Annualised Advances. This extract is run as a one-off when a new DC is appointed to a GSP Group.
Daily Profile Totals	Process 2.4.2 Extract Data For EAC Calculator	External entity b Non-HH Data Collector	The sum of the daily Profiles for each Settlement Class for the Settlement Day. This is to enable the EAC calculation system to produce Annualised Advances.
Data Collector Details	External entity k ISR Agent	Process 2.1.5 Enter Data Collector Details	Changes to the Data Collectors and their appointments to GSP Groups.
Deemed Take Report	Process 1.2.3 Create Deemed Take Report	External entity j Supplier	For each Supplier, this report details their Deemed Take by GSP Group for each half hour as calculated by the most recent SSR run for the Settlement Day.
Disconnected MSIDs and Estimated Half Hourly Demand Volumes	External entity t NETSO	Process 1.1.7 Manage Disconnected MSIDs and Estimated Half Hourly Demand Volumes	Details of MSIDs subject to Demand Disconnection under Demand-Side Balancing Reserve arrangements, along with estimated disconnection volumes
Disconnected MSIDs and Estimated Half Hourly Demand Volumes	Process 1.1.7 Manage Disconnected MSIDs and Estimated Half Hourly Demand Volumes	External entity b Non-HH Data Collector	Details of MSIDs subject to Demand Disconnection under Demand-Side Balancing Reserve arrangements, along with estimated disconnection volumes
Disconnected MSIDs and Estimated Half Hourly Demand Volumes		External entity l HH Data Collector
Disconnection Supplier Purchase Matrix Data	External entity p Non-HH Data Aggregator	Process 1.1.4 Validate SPM Data	Aggregated Disconnected Estimated Annual Consumptions for a Supplier and GSP Group on a Settlement Day. This data is produced on request by a non-half hourly Data Aggregator.
DUoS Report	Process 1.4.9.5 Produce DUoS Report	External entity j Supplier
DUoS Report	Process 1.4.9.5 Produce DUoS Report	External entity a Distribution Business
Extract Request	External entity k ISR Agent	Process 2.4.2 Extract Data For EAC Calculator
GSP Group Consumption Totals Report	Process 1.2.5 Create GSP Group Consumption Totals Report	External entity j Supplier	This report contains GSP Group Consumption Totals for consumption component classes both before and after GSP Group correction. This report also contains Total MSID Counts for Consumption Component Classes. It is sent to Suppliers and only contains GSP Groups in which the Supplier was active on the settlement date and consumption component classes for which there was consumption.
GSP Group Details	External entity k ISR Agent	Process 2.1.1 Enter GSP Group Details	Updates to the list of GSP Group Ids processed by this instance of the SSR system and the periods of validity during which they are the responsibility of the ISR Agent.
GSP Group Market Matrix Report	Process 1.2.4 Create Supplier Purchase Report	External entity e Electricity Pool	A report indicating the aggregated Estimated Annual Consumption values used for an SSR Run across all Suppliers.
GSP Group Supplier Assignment	External entity k ISR Agent	Process 1.3.2 Assign Suppliers to GSP Groups	Updates to the relationships between Suppliers and GSP Groups.
GSP Group Take Demand Disconnection Report	Process 1.2.10 GSP Group Take Demand Disconnection Report	External entity j Supplier	A report detailing the total deemed take summed over all Suppliers for each Settlement Period affected by Demand Disconnection
HH Demand Report	Process 1.2.2 Create HH Demand Report	External entity j Supplier	A report for each Supplier detailing the aggregated demand for each Consumption Component Class by GSP Group by half hour.
[HK] HH Demand Disconnection Report	Process 1.2.9 HH Demand Disconnection Report	External entity j Supplier	A report detailing HH Demand Disconnection values for a Supplier by Consumption Component Class
Line Loss Class Factors	External entity a Distribution Business	Process 1.1.2 Validate Line Loss Factors	The Line Loss Factors for each non metering system specific Line Loss Class.
LL Adjusted Aggregated Meter Data	External entity o HH Data Aggregator	Process 1.1.3 Validate HH Data	The aggregated meter readings and estimates as provided by the half hourly Data Collector.
Mapping Data for HH Aggregated Metering Systems	External entity a Distribution Business	Process 1.1.6 Validate Mapping Data for HH Aggregated Metering Systems	Details of mapping between LLFC and SSC for a distributor for HH consumption
Market Domain Data Complete Set	External entity q Market Domain Data Agent	Process 2.6 Load Market Domain Data Complete Set	The published Market Domain Data, i.e. the complete set of data which defines the environment of the Trading Arrangements.
Pool Market Domain Data	External entity q Market Domain Data Agent	Process 2.2.7 Load Pool Market Domain Data	Data distributed by the Market Domain Data Agent, which is required by ISRA.
Profile Class Assignments	External entity k ISR Agent	Process 2.2.4 Assign Configurations to Profile Classes	Details of which Standard Settlement Configurations are permitted for a Profile Class, and of the split of annual consumption between the Measurement Requirements.
Profile Class Details	External entity k ISR Agent External entity q Market Domain Data Agent	Process 2.5.1 Enter Profile Details	Details of Profile Classes and their associated Profiles, entered by the ISR Agent, or loaded via a file prepared by the Market Domain Data Agent.
Profiling Run Request	External entity k ISR Agent	Process 2.3.1 Determine Time Pattern State	A request issued to the system by the ISR Agent for daily profiles to be calculated for a Settlement Day.
Regression Equations	External entity i Profile Administrator	Process 2.5.2 Enter Regression Equations	A file of Regression Equations for use in demand profiling, prepared by the Profile Administrator.
Report Parameters	External entity k ISR Agent	Process 1.2.1 Create Supplier Purchase Matrix Report	Identifiers of the GSP Group, Supplier and Settlement Date for which a report is required.
Report Parameters	External entity k ISR Agent	Process 1.2.3 Create Deemed Take Report	Identifiers of the GSP Group, Supplier and Settlement Date for which a report is required.
Report Parameters	External entity k ISR Agent	Process 1.2.2 Create HH Demand Report	Identifiers of the GSP Group, Supplier and Settlement Date for which a report is required.
Report Parameters	External entity k ISR Agent	Process 1.2.4 Create Supplier Purchase Report	Identifiers of the GSP Group, Supplier and Settlement Date for which a report is required.
Report Parameters	External entity k ISR Agent	Process 1.2.5 Create GSP Group Consumption Totals Report	Identifiers of the GSP Group and Settlement Date for which a report is required.
Request for SSR Run	External entity k ISR Agent	Process 1.4.1 Invoke Run	The initiation of an SSR run for a specified Settlement Day.
Settlement Timetable	External entity k ISR Agent	Process 1.3.7 Maintain Settlement Timetable	Details of the overall Settlement timetable and the Settlement Codes, Planned SSR Run Dates and Payment Dates for each Settlement Date, entered by the ISR Agent.
Settlement Timetable	External entity q Market Domain Data Agent	Process 1.5 Load Settlement Timetable	Details of the overall Settlement timetable and the Settlement Codes, Planned SSR Run Dates and Payment Dates for each Settlement Date loaded from a file prepared by the Market Domain Data Agent.
Specify Final Dispute Expected Aggregation	External entity k ISR Agent	Process 1.3.10 Maintain Final Dispute Expected Aggregation	Indicates to SSR which Data Aggregators will be providing data in relation to a Dispute Final Run.
Standard Configuration Details	External entity k ISR Agent	Process 2.2.1 Enter Settlement Configurations	Details of a Standard Settlement Configuration, entered by the ISR Agent.
Standard Settlement Configuration Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity j Supplier	A report for suppliers of the Standard Settlement Configurations in effect on a given Settlement Day.
Standard Settlement Configuration Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity b Non-HH Data Collector	A report for suppliers of the Standard Settlement Configurations in effect on a given Settlement Day.
Standing Profile Data Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity j Supplier	A report of the Regression Equations used to produce profile data for a given Settlement Day.
Standing Profile Data Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity b Non-HH Data Collector	A report of the Regression Equations used to produce profile data for a given Settlement Day.
Supplier BM Unit Demand Disconnection Report	Process 1.2.11 Supplier BM Unit Demand Disconnection Report	External entity j Supplier	A report for each Supplier giving details of the Suppliers valid BM Units, GSP Group/BM Unit/PC/SSC mappings, and disconnected consumption/generation by BM unit and CCC
Supplier BM Unit Non-Chargeable Demand	Process 1.2.13 Supplier BM Unit Non Chargeable Demand	External entity g Settlement Administration Agent	A report with details of BM Units with Non-Chargeable demand.
Supplier BM Unit Report	Process 1.2.7 Create Supplier BM Unit Report	External Entity j Supplier	A report for each Supplier giving details of the Suppliers valid BM Units, GSP Group/BM Unit/PC/SSC mappings, and consumption/generation by BM unit and CCC.
Supplier’s Demand Disconnection Volume Data File	External Entity o HH Data Aggregator	Process 1.1.3 Validate HH data	Contains details of half hourly disconnected energy volumes.
[HK] Supplier Disconnection Matrix report	Process 1.2.8 Supplier Disconnection Matrix Report	External entity j Supplier	A report detailing Disconnection Purchase Matrix occurrences used in the specified Settlement Run
Supplier Purchase Matrix Data	External entity p Non-HH Data Aggregator	Process 1.1.4 Validate SPM Data	Aggregated Estimated Annual Consumptions for a Supplier and GSP Group on a Settlement Day. This data is produced on request by a non-half hourly Data Aggregator.
Supplier Purchase Matrix Report	Process 1.2.1 Create Supplier Purchase Matrix Report	External entity j Supplier	A report indicating the aggregated Estimated Annual Consumption values used for an SSR Run and Supplier.
Supplier Purchase Report	Process 1.2.4 Create Supplier Purchase Report	External entity j Supplier	A report indicating Supplier Purchases by GSP Group for an SSR Run and Supplier.
Supplier Quarterly Volume Report	Process 1.2.12 Create Supplier Quarterly Volume Report	External entity e Electricity Pool	A report indicating the quarterly volumes and average number of Metering Systems for each Supplier
Teleswitch Contact Interval Details	External entity k ISR Agent	Process 2.2.10 Enter Teleswitch Contact Intervals	Details of Teleswitch contact intervals, entered by the ISR Agent
Teleswitch Contact Interval Data Report	Process 2.4.1 Produce Supplier & DC Profile Reports	External entity j Supplier	A report of the Teleswitch Contact Intervals used during the DPP run for a given Settlement Day.
Teleswitch Contact Intervals	External entity e Teleswitch Agent	Process 2.2.6 Load Teleswitch Contact Intervals	A file of Teleswitch contact intervals, prepared by the Teleswitch Agent.
Teleswitch Register and Contact Rules	External entity k ISR Agent	Process 2.2.9 Enter Teleswitch Register and Contact Rules	Details of Teleswitch register and contact rules provided by Suppliers, entered by the ISR Agent.
Time of Sunset	External entity r Sunset Provider	Process 2.1.4 Enter Time of Sunset	A file of sunset times for a GSP Group, prepared by the ISR Agent.
Time Pattern Assignments	External entity k ISR Agent	Process 2.2.3 Assign Time Patterns to Configurations	Amendments to the list of Time Pattern Regimes which define a Standard Settlement Configuration, entered by the ISR Agent.
Time Pattern Details	External entity k ISR Agent	Process 2.2.2 Enter Time Patterns	Amendments to the standing Time Pattern Regime data, entered by the ISR Agent.
TUoS Report	Process 1.4.9.4 Produce TUoS Report	External entity h TUoS	A report of Deemed Take required by the NETSO in order to calculate Transmission Use of System Charges.

Line Loss Factor Class Id

SSR Run Number

Settlement Date

Supplier Id

6.5.5 Aggregated Consumption and Line Loss

From/To:

Data store D1/3 Supplier HH Demand

to Process 1.4 Run SSR

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

6.5.6 Aggregated Supplier Take

From/To:

Process 1.4 Run SSR

to Data store D1/4 Supplier Purchases

Process 1.4.9.2 Calculate Deemed Supplier Take

to Data store D1/4 Supplier Purchases

Data Items:

GSP Group Id

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

Unadjusted Supplier Deemed Take

6.5.7 Amendment to Profile Run Status

From/To:

Process 2.3 Calculate Daily Profiles

to Data store D2 Daily Profiles

Process 2.3.4 Chunk Profiles

to Data store D2 Daily Profiles

Data Items:

GSP Group Id

Profile Production Run Number

Settlement Date

6.5.8 Average Fraction of Yearly Consumption

From/To:

External entity k ISR Agent

to Process 2.2.8 Specify Average Fraction of Yearly Consumption

Data Items:

Average Fraction of Yearly Consumption

Effective From Settlement Date {AFOYCS}

Effective To Settlement Date {AFOYCS}

GSP Group Id

Profile Class Id

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.9 Base Load Class Profile

From/To:

Process 2.3.2 Evaluate Regression Equations

to Data store D2 Daily Profiles

Data Items:

Period Profile Coefficient Value

Profile Class Id

Profile Id

Profile Production Run Number

Settlement Date

Settlement Period Id

6.5.10 Base Load Profile

From/To:

Data store D2 Daily Profiles

to Process 2.3.3 Combine Base and Switched Load Profiles

Data Items:

Period Profile Coefficient Value

Profile Class Id

Profile Id

Settlement Date

Settlement Period Id

6.5.11 BM Unit Supplier Take Energy Volume Data File

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity g Settlement Administration Agent

Process 1.4 Run SSR

to External entity g Settlement Administration Agent

Process 1.4.13.2 Generate BM Unit Supplier Take Energy Volume Data File

to External entity g Settlement Administration Agent

Process 1.4.13 Determine Supplier Energy Allocations

to External entity g Settlement Administration Agent

Data Items

BM Unit Identifier

CDCA Set Number

CDCA Settlement Date

GSP Group

GSP Group Id

Period BM Unit Total Allocated Volume

Run Type Code

Settlement Code

Settlement Date

Settlement Period Id

SSR Run Date

SSR Run Number

Supplier Id

6.5.12 BM Unit Aggregated HH Data File

From/To:

External entity o HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity o HH Data Aggregator

to Process 1.1 Marshal Incoming Data

Process 1.1 Marshal Incoming Data

to Data store D1/3 Supplier HH Demand

External entity o HH Data Aggregator

to Process 1.1.3 Validate HH Data

Process 1.1.3 Validate HH Data

to Data store D1/3 Supplier HH Demand

Data Items:

Aggregated BM Unit Energy

Aggregated BM Unit Line Losses

BM Unit Id

Consumption Component Class Id

Data Aggregator HH MSID Count

GSP Group

Run Number

Run Type Code

Settlement Code

Settlement Date

Settlement Period Id

Supplier Id

6.5.13 BM Unit SVA Gross Demand Data File

From/To:

Process 6.2.8.3 Produce BM Unit Gross Demand Data File

to External entity g Settlement Administration Agent

Data Items

BM Unit Identifier

CDCA Set Number

CDCA Settlement Date

GSP Group

GSP Group Id

BM Unit SVA Gross Demand

Run Type Code

Settlement Code

Settlement Date

Settlement Period Id

SSR Run Date

SSR Run Number

Supplier Id

6.5.14 Calculation Values

From/To:

Data store D1/3 Supplier HH Demand

to Process 1.4 Run SSR

Data store D1/3 Supplier HH Demand

to Process 1.4 Run SSR

Constituent Data Flows:

Aggregated Profiled HH Values

GSP Group Corrected HH values

6.5.15 Calendar Details

From/To:

External entity k ISR Agent

to Process 2.1.2 Enter Calendar Details

Data Items:

Change Date

Day Type Id

GMT Time

Post Change Local Time

Season Id

6.5.16 Changes to aggregator assignments

From/To:

External entity k ISR Agent

to Process 1.3.6 Specify Aggregator for GSP Group

Data Items:

Data Aggregation Type

Data Aggregator Id

Effective From Settlement Date {DAIGG}

Effective To Settlement Date {DAIGG}

GSP Group Id

Supplier Id

6.5.17 Changes to distributor assignments

From/To:

External entity k ISR Agent

to Process 1.3.5 Specify Distributor for GSP Group

Data Items:

Distributor Id

Effective From Settlement Date {GGD}

Effective To Settlement Date {GGD}

GSP Group Id

6.5.18 Changes to BM Unit details

From/To:

External entity k ISR Agent

to Process 1.3 Update SSR Standing Data

External entity k ISR Agent

to Process 1.3.9 Enter BM Units Manually

External entity q MDD Agent

to Process 1.3 Update SSR Standing Data

Data Items:

BM Unit Id

Effective From Settlement Date {BMUIGG}

GSP Group Id

Supplier Market Participant Id

Supplier Market Participant Role Code

Effective To Settlement Date {BMUIGG}

Base BM Unit Flag

6.5.19 Changes to line loss factor codes

From/To:

External entity k ISR Agent

to Process 1.3.4 Maintain line loss factor codes

Data Items:

Distributor Id

Effective From Settlement Date {LLFC}

Line Loss Factor Class Id

6.5.20 Changes to NHH BM Unit allocations

From/To:

External entity k ISR Agent

to Process 1.3.8 Assign NHH BM Units

Data Items:

BM Unit Id

Effective From Settlement Date {BMUIGG}

Effective From Settlement Date {NHHBMUA}

Profile Class Id

Standard Settlement Configuration Id

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {NHHBMUA}

6.5.21 Changes to scaling factors

From/To:

External entity k ISR Agent

to Process 1.3.3 Maintain GSP correction scaling factors

Data Items:

Consumption Component Class Id

Effective From Settlement Date {GGCSF}

GSP Group Correction Scaling Factor

6.5.22 Changes to supplier details

From/To:

External entity k ISR Agent

to Process 1.3.1 Maintain supplier details

Data Items:

Supplier Id

Supplier Name

6.5.23 Clock Intervals

From/To:

External entity k ISR Agent

to Process 2.2 Record Time Patterns

External entity k ISR Agent

to Process 2.2.5 Enter Clock Intervals

Data Items:

Day of the Week Id

End Day

End Month

End Time

Start Time

Start Day

Start Month

Time Pattern Regime Id

6.5.24 Combined Load Regime Profile

From/To:

Process 2.3.3 Combine Base and Switched Load Profiles

to Data store D2 Daily Profiles

Data store D2 Daily Profiles

to Process 2.3.4 Chunk Profiles

Data Items:

Normal Register Profile Coefficient

Low Register Profile Coefficient

Profile Class Id

Profile Id

Profile Production Run Number

Settlement Date

Settlement Period Id

6.5.25 Daily Data for Reporting

From/To:

Data store D1/1 Trading Day Data

to Process 1.2 Produce SSR Supplier Reports

Constituent Data Flows:

Line Losses for Reporting

SPM Data for Report

GSP Group Takes and Correction Factors

Settlement Period Labels

6.5.26 Daily Parameters

From/To:

Data store D2/1 Daily Parameters

to Process 2.3 Calculate Daily Profiles

Data store D2/1 Daily Parameters

to Process 2.4 Produce Profile Reports

Data store D2/1 Daily Parameters

to Process 2.3.2 Evaluate Regression Equations

Data store D2/1 Daily Parameters

to Process 2.4.1 Produce Supplier & DC Profile Reports

Data Items:

Actual Noon Temperature

Day Type Id

GSP Group Id

Noon Effective Temperature

Season Id

Settlement Date

Time of Sunset

6.5.27 Daily Price Data

This Data Flow is no longer required.

6.5.28 Daily Profile Data Report

From/To:

Process 2.4.1 Produce Supplier & DC Profile Reports

to External entity j Supplier

Data Items:

Actual Noon Temperature

GSP Group Id

Low Register Profile Coefficient

Noon Effective Temperature

Normal Register Profile Coefficient Period Profile Coefficient Value

Period Register On State Indicator

Profile Class Id

Profile Id

Profile Production Run Number

Standard Settlement Configuration Id Sunset Variable

Time Pattern Regime Id

Time of Sunset

6.5.29 Daily Profile Total Extract

From/To:

Process 2.4.2 Extract Data For EAC Calculator

to External entity b Non-HH Data Collector

Data Items:

Data Collector Id

Daily Profile Coefficient

GSP Group Id

Profile Class Id

Profile Production Run Number

Settlement Date

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.30 Daily Profile Totals

From/To:

Process 2 Daily Profile Production

to External entity b Non-HH Data Collector

Process 2.4 Produce Profile Reports

to External entity b Non-HH Data Collector

Process 2.4.2 Extract Data For EAC Calculator

to External entity b Non-HH Data Collector

Data Items:

Data Collector Id

Daily Profile Coefficient

GSP Group Id

Profile Class Id

Profile Production Run Number

Settlement Date

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.31 Daily Profiles

From/To:

Data store D2 Daily Profiles

to Process 2.4 Produce Profile Reports

Process 2.3 Calculate Daily Profiles

to Data store D2 Daily Profiles

Data store D2 Daily Profiles

to Process 2.4.1 Produce Supplier & DC Profile Reports

to Process 1 Supplier Settlement and Reconciliation

Data store D3 Shared Standing Data

to Process 2.3 Calculate Daily Profiles

Data store D3 Shared Standing Data

to Process 2.3.2 Evaluate Regression Equations

Data store D3 Shared Standing Data

to Process 1.1 Marshal Incoming Data

Data store D3 Shared Standing Data

to Process 1.1.1 Validate Settlements Data

Data store D3 Shared Standing Data

to Process 1.1.2 Validate Line Loss Factors

Data store D3 Shared Standing Data

to Process 1.1.3 Validate HH Data

Data Items:

Change Date

GMT Time

Post Change Local Time

6.5.37 Day Type

From/To:

Process 2.1.2 Enter Calendar Details

to Data store D2/1 Daily Parameters

Process 2.6 Load Market Domain Data Complete Set

to Data store D2/1 Daily Parameters

Data Items:

Day Type Id

Season Id

Settlement Date

6.5.38 Deemed Supplier Take

From/To:

Data store D1/4 Supplier Purchases

to Process 1.4 Run SSR

Data store D1/4 Supplier Purchases

to Process 1.4.9.4 Produce TUoS Report

Data store D1/4 Supplier Purchases

to Process 1.4.9 Calculate Deemed Take

Data Items:

GSP Group Id

Period Supplier Deemed Take

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

6.5.39 Deemed Take for Reporting

From/To:

Data store D1/4 Supplier Purchases

to Process 1.2 Produce SSR Supplier Reports

Data store D1/4 Supplier Purchases

to Process 1.2.3 Create Deemed Take Report

Data Items:

Aggregated Supplier Consumption

GSP Group Id

Period Supplier Deemed Take

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

Unadjusted Supplier Deemed Take

6.5.40 Deemed Take Report

From/To:

Process 1.2.3 Create Deemed Take Report

to External entity j Supplier

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Corrected Supplier Consumption

Corrected Supplier Line Loss

GSP Group Correction Factor

GSP Group Id

GSP Group Name

Period Supplier Deemed Take

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

Supplier Period Weighted Consumption

Total Period NPG Spill

Total Period Weighted Consumption

Unadjusted Supplier Deemed Take

6.5.41 DUoS Report

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity j Supplier

Process 1.4.9 Calculate Deemed Take

to External entity a Distribution Business

Process 1.4.9 Calculate Deemed Take

to External entity j Supplier

Process 1.4.9.5 Produce DUoS Report

to External entity j Supplier

Process 1.4.9.5 Produce DUoS Report

to External entity a Distribution Business

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Consumption Component Class Id

Consumption Component Indicator

Daily Profiled SPM Total Annualised Advance

Daily Profiled SPM Total EAC

Data Aggregation Type

Distributor Id

Distributor Name

GSP Group Correction Factor

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Line Loss Factor Class Id

Measurement Quantity Id

Metered/Unmetered Indicator

Pool Member Id

Profile Class Id

Profiled SPM Consumption (repeating group of 50)

SPM Default EAC MSID Count

SPM Total AA MSID Count

SPM Total Annualised Advance Report Value

SPM Total All EACs

SPM Total EAC MSID Count

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Code Description

Settlement Date

Settlement Period Id

Settlement Period Label

Standard Settlement Configuration Id

Supplier Id

Supplier Name

Time Pattern Regime Id

6.5.42 Existing line loss factor codes

From/To:

Data store D1/2 SSR Standing Data

to Process 1.3.4 Maintain line loss factor codes

Data store D1/2 SSR Standing Data

to Process 2.6 Load Market Domain Data Complete Set

Data Items:

Distributor Id

Line Loss Factor Class Id

6.5.43 Existing scaling factors

From/To:

Data store D1/2 SSR Standing Data

to Process 1.3.3 Maintain GSP correction scaling factors

Data Items:

Consumption Component Class Id

Effective From Settlement Date {GGCSF}

GSP Group Correction Scaling Factor

6.5.44 Existing Supplier details

From/To:

Data store D1/2 SSR Standing Data

to Process 1.3.1 Maintain supplier details

Data store D1/2 SSR Standing Data

to Process 1.3.2 Assign Suppliers to GSP Groups

Data store D1/2 SSR Standing Data

to Process 1.3.8 Assign NHH BM Units

Data store D1/2 SSR Standing Data

to Process 1.3.9 Enter BM Units Manually

Data Items:

Supplier Id

Supplier Name

6.5.45 Extract Request

From/To:

External entity k ISR Agent

to Process 2.4.2 Extract Data For EAC Calculator

External entity k ISR Agent

to Process 2.4 Produce Profile Reports

Data Items:

Data Collector Id

GSP Group Id

Settlement Date

6.5.46 GSP Correction Factors

From/To:

Process 1.4 Run SSR

to Data store D1/1 Trading Day Data

Process 1.4.9.1 Calc & Apply GSP Group Correction

to Data store D1/1 Trading Day Data

Process 1.4.9 Calculate Deemed Take

to Data store D1/1 Trading Day Data

Data Items:

Consumption Component Class Id

GSP Group Correction Factor

GSP Group Id

SSR Run Date

SSR Run Number

Settlement Period Id

6.5.47 GSP Group Assignments

From/To:

External entity j Supplier

to External entity k ISR Agent

Constituent Data Flows:

Changes to aggregator assignments

Data Collector Details

GSP Group Supplier Assignment

6.5.48 GSP Group Codes

From/To:

Data store D3 Shared Standing Data

to Process 1 Supplier Settlement and Reconciliation

Data store D3 Shared Standing Data

to Process 1.1 Marshal Incoming Data

Data store D3 Shared Standing Data

to Process 1.3 Update SSR Standing Data

Data store D3 Shared Standing Data

to Process 1.1.3 Validate HH Data

Data store D3 Shared Standing Data

to Process 1.1.1 Validate Settlements Data

Data store D3 Shared Standing Data

to Process 1.1.4 Validate SPM Data

Data store D3 Shared Standing Data

to Process 1.3.2 Assign Suppliers to GSP Groups

Data Items:

GSP Group Id

6.5.49 GSP Group Consumption Totals For Reporting

From/To:

Data store D1/3 Supplier HH Demand

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data store D1/3 Supplier HH Demand

to Process 1.2 Produce Supplier Reports

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Corrected Supplier Consumption

Corrected Supplier Line Loss

Supplier Id

MSID Count

6.5.50 GSP Group Consumption Totals Report

From/To:

Process 1.2.5 Create GSP Group Consumption Totals Report

to External entity j Supplier

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Consumption Component Indicator

Corrected Supplier Consumption

Corrected Supplier Line Loss

Data Aggregation Type

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

MSID Count

6.5.51 GSP Group Corrected HH values

From/To:

Process 1.4.9.1 Calc & Apply GSP Group Correction

to Data store D1/3 Supplier HH Demand

Data store D1/3 Supplier HH Demand

to Process 1.4.9.2 Calculate Deemed Supplier Take

Data store D1/3 Supplier HH Demand

to Process 1.4.9 Calculate Deemed Take

Data Items:

Consumption Component Class Id

Corrected Supplier Consumption

Corrected Supplier Line Loss

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

6.5.52 GSP Group Correction Scaling Weights

From/To:

Data store D1/2 SSR Standing Data

to Process 1.4.9.1 Calc & Apply GSP Group Correction

Data store D1/2 SSR Standing Data

to Process 1.4.9 Calculate Deemed Take

Data store D1/2 SSR Standing Data

to Process 1.2 Produce SSR Supplier Reports

Data Items:

Consumption Component Class Id

GSP Group Correction Scaling Factor

6.5.53 GSP Group Details

From/To:

External entity k ISR Agent

to Process 2.1.1 Enter GSP Group Details

Data Items:

GSP Group Id

6.5.54 GSP Group Name

From/To:

Data store D3 Shared Standing Data

to Process 1 Supplier Settlement and Reconciliation

From/To:

Data store D3 Shared Standing Data

to Process 2.3 Calculate Daily Profiles

Data store D3 Shared Standing Data

to Process 2.3.2 Evaluate Regression Equations

Data store D3 Shared Standing Data

to Process 2.3.4 Chunk Profiles

Data store D3 Shared Standing Data

to Process 2.3.3 Combine Base and Switched Load Profiles

Data Items:

GSP Group Id

6.5.59 GSP Groups For Reporting

From/To:

Data store D1/2 SSR Standing Data

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data store D1/2 SSR Standing Data

to Process 1.2 Produce SSR Supplier Reports

Data Items:

GSP Group Id

GSP Group Correction Scaling Factor

6.5.60 HH Demand Report

From/To:

Process 1.2.2 Create HH Demand Report

to External entity j Supplier

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

CDCS Extract Number

Consumption Component Class Id

Consumption Component Indicator

Corrected Supplier Consumption

Corrected Supplier Line Loss

Data Aggregation Type

Data Aggregator HH MSID Count

Data Aggregator Id

Data Aggregator Name

Distributor Id

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

6.5.61 HH Values by Supplier

From/To:

Data store D1/3 Supplier HH Demand

to Process 1.4 Run SSR

Data store D1/3 Supplier HH Demand

to Process 1.2 Produce SSR Supplier Reports

Data store D1/3 Supplier HH Demand

to Process 1.4.9.1 Calc & Apply GSP Group Correction

Data store D1/3 Supplier HH Demand

to Process 1.4.9 Calculate Deemed Take

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

GSP Group Id

SSR Run Number

Settlement Date

Settlement Period Id

6.5.62 Line Loss Class Factors

From/To:

External entity a Distribution Business

to Process 1 Supplier Settlement and Reconciliation

External entity a Distribution Business

to Process 1.1 Marshal Incoming Data

External entity a Distribution Business

to Process 1.1.2 Validate Line Loss Factors

Data Items:

Distributor Id

Line Loss Factor

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

6.5.63 Line Loss Class Id

From/To:

Data store D1/2 SSR Standing Data

to Process 1.1.2 Validate Line Loss Factors

Data store D1/2 SSR Standing Data

to Process 1.1.4 Validate SPM Data

Data Items:

Distributor Id

Line Loss Factor Class Id

6.5.64 Line Loss Factors for Trading Day

From/To:

Data store D1/1 Trading Day Data

to Process 1.4.8.3 Adjust for Line Losses

Data store D1/1 Trading Day Data

to Process 1.4.8 Profile & Line Loss Adjust SPM

Data Items:

Distributor Id

Line Loss Factor

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

6.5.65 Line Losses for Reporting

From/To:

Data store D1/1 Trading Day Data

to Process 1.2.2 Create HH Demand Report

Data Items:

Distributor Id

Line Loss Factor

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

Settlement Period Label

6.5.66 LL Adjusted Aggregated Meter Data

From/To:

External entity o HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity o HH Data Aggregator

to Process 1.1 Marshal Incoming Data

Process 1.1 Marshal Incoming Data

to Data store D1/3 Supplier HH Demand

External entity o HH Data Aggregator

to Process 1.1.3 Validate HH Data

Process 1.1.3 Validate HH Data

to Data store D1/3 Supplier HH Demand

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Data Aggregation Run Number

Data Aggregation Type

Data Aggregator HH MSID Count

Data Aggregator Id

GSP Group Id

Settlement Code

Settlement Date

Settlement Period Id

Supplier Id

6.5.67 LL Adjusted HH Profiled Values

From/To:

Process 1.4 Run SSR

to Data store D1/3 Supplier HH Demand

Process 1.4.8.3 Adjust for Line Losses

to Data store D1/3 Supplier HH Demand

Process 1.4.8 Profile & Line Loss Adjust SPM

to Data store D1/3 Supplier HH Demand

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

GSP Group Id

SSR Run Number

Settlement Date

Supplier Id

6.5.68 Low Register State

From/To:

Data store D2 Daily Profiles

to Process 2.3.3 Combine Base and Switched Load Profiles

Data Items:

Period Register On State Indicator

Settlement Date

Settlement Period Id

Time Pattern Regime Id

6.5.69 Market Domain Data

From/To:

External entity q Market Domain Data Agent

to External entity k ISR Agent

Constituent Data Flows:

Clock Intervals

Calendar Details

GSP Group Details

Profile Class Details

Standing Configuration Data

Changes to distributor assignments

Changes to line loss factor codes

Changes to scaling factors

Changes to supplier details

Settlement Timetable

Teleswitch Register and Contact Rules

6.5.70 Market Domain Data Complete Set

From/To:

External entity q Market Domain Data Agent

to Process 2 Daily Profile Production

External entity q Market Domain Data Agent

to Process 2.6 Load Market Domain Data Complete Set

Data Items:

Day Type Id

Distributor Id

Effective From Settlement Date {LLFC}

Effective To Settlement Date {LLFC}

Line Loss Factor Class Id

Market Participant Role Code

Metering System Specific Line Loss Factor Class Id

Settlement Date

Season Id

6.5.71 Measurement Requirement Period State

From/To:

Data store D2 Daily Profiles

to Process 2.3.4 Chunk Profiles

Data Items:

Period Register On State Indicator

Settlement Date

Settlement Period Id

Time Pattern Regime Id

6.5.72 NHH BM Unit Allocations

From/To:

Data Store D1/2 SSR Standing Data

To Process 1.2.7 Create Supplier BM Unit Report

Data Items:

BM Unit Id

Effective From Settlement Date {BMUIGG}

Effective From Settlement Date {NHHBMUA}

Profile Class Id

Standard Settlement Configuration Id

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {NHHBMUA}

6.5.73 Non Switched Load Class Profile

From/To:

Process 2.3.2 Evaluate Regression Equations

to Data store D2 Daily Profiles

Data store D2 Daily Profiles

to Process 2.3.4 Chunk Profiles

Data Items:

Period Profile Coefficient Value

Profile Class Id

Profile Id

Profile Production Run Number

Settlement Date

Settlement Period Id

From/To:

External entity q Market Domain Data Agent

to Process 2 Daily Profile Production

External entity q Market Domain Data Agent

to Process 2.2 Record Time Patterns

External entity q Market Domain Data Agent

to Process 2.2.7 Load Pool Market Domain Data

Data Items:

Average Fraction of Yearly Consumption

Day of the Week Id

Effective From Settlement Date {AFOYCS}

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {AFOYCS}

Effective To Settlement Date {VSCPC}

End Day

End Month

End Time

Start Time

GMT Indicator

GSP Group Id

Profile Class Id

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Standard Settlement Configuration Type

Start Day

Start Month

Switched Load Indicator

Tele-switch Contact Code

Tele-switch Contact Rule

Tele-switch Group Id

Tele-switch Register Rule Id

Tele-switch User Id

Tele-switch/Clock Indicator

Time Pattern Regime Id

6.5.78 Profile Class Assignments

From/To:

External entity k ISR Agent

to Process 2.2.4 Assign Configurations to Profile Classes

Data Items:

Profile Class Id

Standard Settlement Configuration Id

Switched Load Indicator

Time Pattern Regime Id

6.5.79 Profile Class Details

From/To:

External entity k ISR Agent

to Process 2.5 Enter Profiles

External entity k ISR Agent

to Process 2.5.1 Enter Profile Details

External entity q Market Domain Data Agent

to Process 2 Daily Profile Production

External entity q Market Domain Data Agent

to Process 2.5 Enter Profiles External entity q Market Domain Data Agent

to Process 2.5.1 Enter Profile Details

Data Items:

Profile Class Description

Profile Class Id

Profile Description

Profile Id

Profile Settlement Periods

Effective From Settlement Date {PROF} Effective To Settlement Date {PROF} Switched Load Profile Class Ind

6.5.80 Profile Run Status

From/To:

Data store D2 Daily Profiles

to Process 1 Supplier Settlement and Reconciliation

Data store D2 Daily Profiles

to Process 1.4 Run SSR

Data store D2 Daily Profiles

to Process 1.4.1 Invoke Run

Data Items:

GSP Group Id

Profile Production Run Number

Settlement Date

6.5.81 Profiled SPM Data

From/To:

Process 1.4.8.1 Profile SPM data

to Data store D1/3 Supplier HH Demand

Data store D1/3 Supplier HH Demand

to Process 1.4.8.2 Aggregate Profiled Data

Process 1.4.8 Profile & Line Loss Adjust SPM

to Data store D1/3 Supplier HH Demand

Process 1.4 Run SSR

to Data store D1/3 Supplier HH Demand

Data store D1/3 Supplier HH Demand

to Process 1.4.9 Calculate Deemed Take

Data store D1/3 Supplier HH Demand

to Process 1.4.9.5 Produce DUoS Report

Data store D1/3 Supplier HH Demand

to Process 1.4.8.3 Adjust for Line Losses

Data Items:

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Measurement Quantity Id

Profile Class Id

Profiled SPM Total Annualised Advance

Profiled SPM Total EAC

Profiled SPM Total Unmetered Consumption

SSR Run Number

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.82 Profiles by Time Pattern

From/To:

Data store D2 Daily Profiles

to Process 1 Supplier Settlement and Reconciliation

Data store D2 Daily Profiles

to Process 1.4 Run SSR

Data store D2 Daily Profiles

to Process 1.4.8.1 Profile SPM data

Data store D2 Daily Profiles

to Process 1.4.8 Profile & Line Loss Adjust SPM

Data Items:

GSP Group Id

Period Profile Coefficient Value

Profile Class Id

Settlement Date

Settlement Period Id

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.83 Profiles by Timeslot

From/To:

Process 2.3.4 Chunk Profiles

to Data store D2 Daily Profiles

Data Items:

GSP Group Id

Measurement Quantity Id

Period Profile Coefficient Value

Profile Production Run Number

Settlement Date

Settlement Period Id

Time Pattern Regime Id

6.5.84 Profiling Data

From/To:

External entity k ISR Agent

to Process 2 Daily Profile Production

Constituent Data Flows:

Clock Intervals

Extract Request

Parameter Changes

Profile Class Details

Profiling Run Request

Standing Configuration Data

Teleswitch Contact Interval Details

6.5.85 Profiling Reports

From/To:

Process 2 Daily Profile Production

to External entity j Supplier

Process 2.4 Produce Profile Reports

to External entity j Supplier

Constituent Data Flows:

Daily Profile Data Report

Standard Settlement Configuration Report

Standing Profile Data Report

Teleswitch Contact Interval Data Report

6.5.86 Profiling Run Request

From/To:

External entity k ISR Agent

to Process 2.3 Calculate Daily Profiles

External entity k ISR Agent

to Process 2.3.1 Determine Time Pattern State

Data Items:

Settlement Date

GSP Group Id

6.5.87 Profiling & line loss Data

From/To:

Data store D1/1 Trading Day Data

to Process 1.4 Run SSR

Constituent Data Flows:

Line Loss Factors for Trading Day

SPM data for trading day

6.5.88 Regime Identifiers

From/To:

Data store D1 Time Regimes

to Process 1 Supplier Settlement and Reconciliation

Data store D1 Time Regimes

to Process 1.1 Marshal Incoming Data

Data store D1 Time Regimes

to Process 1.1.4 Validate SPM Data

Data Items:

Profile Class Id

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.89 Register State

From/To:

Process 2.3 Calculate Daily Profiles

to Data store D2 Daily Profiles

Process 2.3.1 Determine Time Pattern State

to Data store D2 Daily Profiles

Data Items:

Period Register On State Indicator

Settlement Date

Settlement Period Id

Time Pattern Regime Id

6.5.90 Regression Equations

From/To:

External entity i Profile Administrator

to Process 2 Daily Profile Production

External entity i Profile Administrator

to Process 2.5 Enter Profiles

Data store D2/3 Profiles

to Process 2.3 Calculate Daily Profiles

Data store D2/3 Profiles

to Process 2.4 Produce Profile Reports

Data store D2/3 Profiles

to Process 2.3.2 Evaluate Regression Equations

Data store D2/3 Profiles

to Process 2.4.1 Produce Supplier & DC Profile Reports

External entity i Profile Administrator

to Process 2.5.2 Enter Regression Equations

Data Items:

Day Type Id

Effective From Settlement Date {PSET}

GSP Group Id

Group Average Annual Consumption

Profile Class Id

Profile Id

Regression Coefficient

Regression Coefficient Type

Season Id

Settlement Period Id

6.5.91 Report Parameters

From/To:

External entity k ISR Agent

to Process 1 Supplier Settlement and Reconciliation

External entity j Supplier

to External entity k ISR Agent

External entity k ISR Agent

to Process 1.2 Produce SSR Supplier Reports

External entity k ISR Agent

to Process 1.2.1 Create Supplier Purchase Matrix Report

External entity k ISR Agent

to Process 1.2.3 Create Deemed Take Report

External entity k ISR Agent

to Process 1.2.2 Create HH Demand Report

External entity k ISR Agent

to Process 1.2.4 Create Supplier Purchase Report

External entity k ISR Agent

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data Items:

GSP Group Id

Settlement Date

Supplier Id

6.5.92 Request for SSR Run

From/To:

External entity k ISR Agent

to Process 1 Supplier Settlement and Reconciliation

External entity k ISR Agent

to Process 1.4 Run SSR

External entity k ISR Agent

to Process 1.4.1 Invoke Run

Data Items:

Data Aggregation Run Number Data Aggregation Type

Data Aggregator Id GSP Group Id

SSA Settlement Run Number

SSA Settlement Run Type Id

SSR Run Type Id

Settlement Code

Settlement Date

6.5.93 Sett Period Profile Data

From/To:

Data store D2 Daily Profiles

to Process 2 Daily Profile Production

From/To:

Data store D1/1 Trading Day Data

to Process 1.2.3 Create Deemed Take Report

Data store D1/1 Trading Day Data

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data Items:

Settlement Date

Settlement Period Id

Settlement Period Label

6.5.98 Settlement Period Profile Data

From/To:

Process 2 Daily Profile Production

to Data store D2 Daily Profiles

Constituent Data Flows:

Amendment to Profile Run Status

6.5.99 Settlement Timetable

From/To:

External entity q Market Domain Data Agent

to Process 1 Supplier Settlement and Reconciliation

External entity k ISR Agent

to Process 1.3.7 Maintain Settlement Timetable

External entity q Market Domain Data Agent

to Process 1.5 Load Settlement Timetable

Data Items:

Settlement Code

Settlement Date

Planned SSR Run Date

Payment Date

6.5.100 Shared Standing Data

From/To:

Data store D3 Shared Standing Data

to Process 2 Daily Profile Production

Constituent Data Flows:

Data Collector Registrations

Dates of Clock Change

GSP Groups

6.5.101 [Split] Pool Funds Report

This Data Flow is no longer required. It is replaced by the BM Unit Supplier Take Energy Volume Data File.

6.5.102 SPM Data for Report

From/To:

Data store D1/1 Trading Day Data

to Process 1.2.1 Create Supplier Purchase Matrix Report

Data Items:

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Measurement Quantity Id

Profile Class Id

SPM Total Annualised Advance

SPM Total EAC

SPM Total Unmetered Consumption

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.103 SPM data for trading day

From/To:

Data store D1/1 Trading Day Data

to Process 1.4.8.1 Profile SPM data

Data store D1/1 Trading Day Data

to Process 1.4.8 Profile & Line Loss Adjust SPM

Data Items:

Data Aggregator Id

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Measurement Quantity Id

Profile Class Id

SPM Total Annualised Advance

SPM Total EAC

SPM Total Unmetered Consumption

SSR Run Number

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.104 SPM Totals for Trading Day

From/To:

Data store D1/1 Trading Day Data

to Process 1.4.9 Calculate Deemed Take

Data store D1/1 Trading Day Data

to Process 1.4.9.5 Produce DUoS Report

Data Items:

Line Loss Factor

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

6.5.105 SSR Reports

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity j Supplier

Process 1.2 Produce SSR Supplier Reports

to External entity j Supplier

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Corrected Supplier Consumption

Corrected Supplier Line Loss

Distributor Id

GSP Group Correction Factor

GSP Group Correction Scaling Factor

GSP Group Id

Line Loss Factor

Line Loss Factor Class Id

Measurement Quantity Id

Pool Selling Price

Profile Class Id

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

Transmission Loss Multiplier

Transmission Losses Reconciliation Multiplier

Constituent Data Flows:

DUoS Report

Deemed Take Report

HH Demand Report

Supplier Purchase Matrix Report

Supplier Purchase Report

GSP Group Consumption Totals Report

6.5.106 SSR Run Status

From/To:

Process 1 Supplier Settlement and Reconciliation

to Data store D4 SSR Runs

Data store D4 SSR Runs

to Process 2 Daily Profile Production

Data store D4 SSR Runs

to Process 2.2 Record Time Patterns

Data store D4 SSR Runs

to Process 2.1 Enter Parameter Data

Data store D4 SSR Runs

to Process 2.3 Calculate Daily Profiles

Data store D4 SSR Runs

to Process 2.5 Enter Profiles

Data store D4 SSR Runs

to Process 2.3.1 Determine Time Pattern State

Data store D4 SSR Runs

to Process 2.1.4 Enter Time of Sunset

Data store D4 SSR Runs

to Process 2.1.3 Calculate Noon Effective Temperature

Data store D4 SSR Runs

to Process 2.1.2 Enter Calendar Details

Data store D4 SSR Runs

to Process 2.2.1 Enter Settlement Configurations

Data store D4 SSR Runs

to Process 2.2.4 Assign Configurations to Profile Classes

Data store D4 SSR Runs

to Process 2.2.7 Load Pool Market Domain Data

Process 1.4 Run SSR

to Data store D4 SSR Runs

Data store D4 SSR Runs

to Process 1.3 Update SSR Standing Data

Data store D4 SSR Runs

to Process 2.5.1 Enter Profile Details

Data store D4 SSR Runs

to Process 2.5.2 Enter Regression Equations

Data store D4 SSR Runs

to Process 2.6 Load Market Domain Data Complete Set

Data store D4 SSR Runs

to Process 1.3.2 Assign Suppliers to GSP Groups

Data store D4 SSR Runs

to Process 1.3.3 Maintain GSP correction scaling factors

Data store D4 SSR Runs

to Process 1.3.4 Maintain line loss factor codes

Data store D4 SSR Runs

to Process 1.3.5 Specify Distributor for GSP Group

Data store D4 SSR Runs

to Process 1.3.6 Specify Aggregator for GSP Group

Data store D4 SSR Runs

to Process 1.3.7 Maintain Settlement Timetable

Data store D4 SSR Runs

to Process 1.5 Load Settlement Timetable

Process 1.4.1 Invoke Run

to Data store D4 SSR Runs

Data Items:

GSP Group Id

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Date

6.5.107 SSR Run Data

From/To:

Data store D1/5 SSR Runs

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data store D1/5 SSR Runs

to Process 1.2 Produce SSR Supplier Reports

Data store D1/5 SSR Runs

to Process 1.2.7 Create Supplier BM Unit Report

Data Items:

Settlement Code

SSR Run Type Id

SSR Run Date

SSR Run Number

Settlement Date

6.5.108 Standard Configuration Details

From/To:

External entity k ISR Agent

to Process 2.2.1 Enter Settlement Configurations

Data Items:

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Tele-switch Group Id

Tele-switch User Id

Standard Settlement Configuration Type

6.5.109 Standard Configurations

From/To:

Data store D1 Time Regimes

to Process 2.4 Produce Profile Reports

Data store D1 Time Regimes

to Process 2.4.1 Produce Supplier & DC Profile Reports

Data Items:

Day of the Week Id

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {VSCPC}

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Tele-switch Group Id

Tele-switch User Id

6.5.110 Standard Settlement Configuration Report

From/To:

Process 2 Daily Profile Production

to External entity b Non-HH Data Collector

Process 2.4 Produce Profile Reports

to External entity b Non-HH Data Collector

Process 2.4.1 Produce Supplier & DC Profile Reports

to External entity j Supplier

Process 2.4.1 Produce Supplier & DC Profile Reports

to External entity b Non-HH Data Collector

Data Items:

Average Fraction of Yearly Consumption

Day of the Week Id

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {VSCPC}

End Day

End Month

End Time

End Time {Tele-switch Interval}

Start Time

Start Time {Tele-switch Interval}

GMT Indicator

Profile Class Description

Profile Class Id

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Start Day

Start Month

Switched Load Indicator

Switched Load Profile Class Ind

Tele-switch Group Id

Tele-switch Switch Id

Tele-switch User Id

Tele-switch/Clock Indicator

Time Pattern Regime Id

6.5.111 Standing Configuration Data

From/To:

External entity k ISR Agent

to Process 2.2 Record Time Patterns

Constituent Data Flows:

Average Fraction of Yearly Consumption

Profile Class Assignments

Standard Configuration Details

Time Pattern Assignments

Time Pattern Details

Teleswitch Register and Contact Rules

6.5.112 Standing Data Changes

From/To:

External entity k ISR Agent

to Process 1 Supplier Settlement and Reconciliation

External entity k ISR Agent

to Process 1.3 Update SSR Standing Data

Constituent Data Flows:

Changes to aggregator assignments

Changes to distributor assignments

Changes to line loss factor codes

Changes to scaling factors

Changes to supplier details

GSP Group Supplier Assignment

Settlement Timetable

6.5.113 Standing Data for DUoS Report

From/To:

Data store D1/2 SSR Standing Data

to Process 1.4.9.5 Produce DUoS Report

Data store D1/2 SSR Standing Data

to Process 1.4.9 Calculate Deemed Take

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Consumption Component Class Id

Consumption Component Indicator

Data Aggregation Type

Metered/Unmetered Indicator

6.5.114 Standing Data for Reporting

From/To:

Data store D1/2 SSR Standing Data

to Process 1.2 Produce SSR Supplier Reports

Data store D1/2 SSR Standing Data

to Process 1.2.1 Create Supplier Purchase Matrix Report

Data store D1/2 SSR Standing Data

to Process 1.2.2 Create HH Demand Report

Data store D1/2 SSR Standing Data

to Process 1.2.3 Create Deemed Take Report

Data store D1/2 SSR Standing Data

to Process 1.2.4 Create Supplier Purchase Report

Data store D1/2 SSR Standing Data

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Change Date

Consumption Component Class Id

Consumption Component Indicator

Data Aggregation Type

Measurement Quantity Id

Metered/Unmetered Indicator

Pool Member Id

Post Change Local Time

Settlement Period Id

Supplier Id

Supplier Name

6.5.115 Standing Data for Run

From/To:

Data store D1/2 SSR Standing Data

to Process 1.4 Run SSR

Constituent Data Flows:

Data Aggregator Assignments

GSP Group Correction Scaling Weights

Standing Data for DUoS Report

6.5.116 Standing Data for Validation

From/To:

Data store D1/2 SSR Standing Data

to Process 1.3 Update SSR Standing Data

Constituent Data Flows:

Existing line loss factor codes

Existing scaling factors

Existing supplier details

6.5.117 Standing Profile Data Report

From/To:

Process 2 Daily Profile Production

to External entity b Non-HH Data Collector

Process 2.4 Produce Profile Reports

to External entity b Non-HH Data Collector

Process 2.4.1 Produce Supplier & DC Profile Reports

to External entity j Supplier

Process 2.4.1 Produce Supplier & DC Profile Reports

to External entity b Non-HH Data Collector

Data Items:

Day Type Id

Effective From Settlement Date {PROF}

Effective To Settlement Date {PROF}

GSP Group Id

Group Average Annual Consumption

Profile Class Description

Profile Class Id

Profile Description

Profile Id

Regression Coefficient

Regression Coefficient Type

Season Id

Switched Load Profile Class Ind

6.5.118 Standing Regime Data

From/To:

Data store D1 Time Regimes

to Process 2 Daily Profile Production

Constituent Data Flows:

Standard Configurations

Timeslot Times

6.5.119 Substitute SSA Data

From/To:

External entity c Electricity Pool

to External entity k ISR Agent

6.5.120 Supplier and GSP Group Purchases

From/To:

Process 1.4 Run SSR

to Data store D1/4 Supplier Purchases

Data store D1/4 Supplier Purchases

to Process 1.4.13 Determine Supplier Purchases

Data Items:

Daily GSP Group Purchases

GSP Group Id

Period GSP Group Purchases

Period Supplier Purchase Total

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

6.5.121 Supplier and Line Loss details

From/To:

Data store D1/2 SSR Standing Data

to Process 1.1 Marshal Incoming Data

Constituent Data Flows:

Line Loss Class Id

Supplier Codes

6.5.122 Supplier BM Unit Report

From/To:

Process 1.2.7 Create Supplier BM Unit Report

to External entity j Supplier

Data items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated BM Unit Energy

Aggregated BM Unit Line Losses

BM Unit Id

Consumption Component Class Id

Consumption Component Indicator

Corrected BM Unit Energy

Corrected BM Unit Line Losses

Daily Aggregated BM Unit Energy

Daily Aggregated BM Unit Line Losses

Daily Corrected BM Unit Energy

Daily Corrected BM Unit Line Losses

Daily DA HH MSID Count

Daily Period BM Unit Total Allocated Volume

Daily Uncorrected Period BM Unit Total Allocated Volume

Data Aggregation Type

Data Aggregator HH MSID Count

Data Aggregator Id

Data Aggregator Name

Base BM Unit Flag

Base BM Unit Reason Code

GSP Group

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

Period BM Unit Total Allocated Volume

Profile Class Id

Report Parameters

Run Number

Run Type Code

Settlement Code

Settlement Code Description

Settlement Date

Settlement Period Id

Settlement Period Label

SSR Run BM Unit Id

SSR Run Date

SSR Run Number

SSR Run Type Id

Standard Settlement Configuration Id

Supplier Id

Supplier Name

Uncorrected Period BM Unit Total Allocated Volume

User Name

6.5.123 Supplier Codes

From/To:

Data store D1/2 SSR Standing Data

to Process 1.1.4 Validate SPM Data

Data store D1/2 SSR Standing Data

to Process 1.1.3 Validate HH Data

Data Items:

GSP Group Id

Supplier Id

6.5.124 Supplier Demand for Reporting

From/To:

Data store D1/3 Supplier HH Demand

to Process 1.2 Produce SSR Supplier Reports

Data store D1/3 Supplier HH Demand

to Process 1.2.2 Create HH Demand Report

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

Supplier Id

6.5.125 Supplier Energy Allocations

From/To:

Data store 1/3 Supplier HH Demand

to Process 1.2 Produce SSR Supplier Reports

Data store D1/3 Supplier HH Demand

to Process 1.2.7 Create Supplier BM Unit Report

Data Items:

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

Supplier Id

6.5.126 Supplier Purchase Matrix Data

From/To:

External entity p Non-HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity p Non-HH Data Aggregator

to Process 1.1 Marshal Incoming Data

External entity p Non-HH Data Aggregator

to Process 1.1.4 Validate SPM Data

Data Items:

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

6.5.127 Supplier Purchase Matrix Report

From/To:

Process 1.2.1 Create Supplier Purchase Matrix Report

to External entity j Supplier

Data Items:

Data Aggregation Run Number

Data Aggregator Id

Data Aggregator Name

Distributor Id

GSP Group Id

GSP Group Name

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

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.128 Supplier Purchase Report

From/To:

Process 1.2.4 Create Supplier Purchase Report

to External entity j Supplier

Data Items:

Daily Supplier Purchase Total

Daily GSP Group Purchases

GSP Group Id

GSP Group Take

Period GSP Group Purchases

Period Supplier Deemed Take

Period Supplier Purchase Total

Pool Member Id

Pool Selling Price

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Date

Settlement Period Id

Supplier Id

6.5.129 Supplier Purchases for Reporting

From/To:

Data store D1/4 Supplier Purchases

to Process 1.2 Produce SSR Supplier Reports

Data store D1/4 Supplier Purchases

to Process 1.2.4 Create Supplier Purchase Report

Data Items:

Daily GSP Group Purchases

GSP Group Id

Period GSP Group Purchases

Period Supplier Purchase Total

SSR Run Number

Settlement Date

Settlement Period Id

Supplier Id

6.5.130 Switched Load Class Profile

From/To:

Process 2.3.2 Evaluate Regression Equations

to Data store D2 Daily Profiles

Data Items:

Period Profile Coefficient Value

Profile Class Id

Profile Id

Profile Production Run Number

Settlement Date

Settlement Period Id

From/To:

External entity e Teleswitch Agent

to Process 2 Daily Profile Production

External entity e Teleswitch Agent

to Process 2.2 Record Time Patterns

External entity e Teleswitch Agent

to Process 2.2.6 Load Teleswitch Contact Intervals

Data Items:

Date (Midnight to Midnight UTC)

Effective Time(UTC)

Start of Day Tele-switch On Indicator

Tele-switch Contact Code

Tele-switch On Indicator

Tele-switch Contact State

Tele-switch Group Id

Tele-switch User Id

6.5.135 Teleswitch Register and Contact Rules

From/To:

External entity k ISR Agent

to Process 2.2.9 Enter Teleswitch Register and Contact Rules

Data Items:

Tele-switch Contact Code

Tele-switch Contact Rule

Tele-switch Group Id

Tele-switch Register Rule Id

Tele-switch Time Pattern Regime Id

Tele-switch User Id

6.5.136 Teleswitch Times

From/To:

Process 2.3 Calculate Daily Profiles

to Data store D1 Time Regimes

Data store D1 Time Regimes

to Process 2.4 Produce Profile Reports

Process 2.3.1 Determine Time Pattern States

to Data store D1 Time Regimes

Data store D1 Time Regimes

to Process 2.4.1 Produce Supplier and DC Profile Reports

Data Items:

End Time {Tele-switch Interval}

Settlement Date

Start Time {Tele-switch Interval}

Time Pattern Regime Id

6.5.137 Temperature Data

From/To:

External entity d Authorised Temperature Provider

to External entity k ISR Agent

6.5.138 Time of Sunset

From/To:

External entity r Sunset Provider

to Process 2 Daily Profile Production

External entity r Sunset Provider

to Process 2.1 Enter Parameter Data

External entity r Sunset Provider

to Process 2.1.4 Enter Time of Sunset

Data Items:

GSP Group Id

Settlement Date

Time of Sunset

6.5.139 Time Pattern Assignments

From/To:

External entity k ISR Agent

to Process 2.2.3 Assign Time Patterns to Configurations

Data Items:

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.140 Time Pattern Details

From/To:

External entity k ISR Agent

to Process 2.2.2 Enter Time Patterns

Data Items:

GMT Indicator

Tele-switch Group Id

Tele-switch User Id

Tele-switch/Clock Indicator

Time Pattern Regime Id

6.5.141 Time Regime Data

From/To:

Process 2 Daily Profile Production

to Data store D1 Time Regimes

Constituent Data Flows:

Teleswitch Times

Validated Clock Intervals

Validated Configuration Data

Validated Teleswitch Contact Interval Details

Validated Teleswitch Contact Intervals

Teleswitch Times

6.5.142 Timeslot Times

From/To:

Data store D1 Time Regimes

to Process 2.3 Calculate Daily Profiles

Data store D1 Time Regimes

to Process 2.3.1 Determine Time Pattern State

Data Items:

Day Type Id

End Date and Time {Tele-switch Contact Interval}

End Time

Start Time

Season Id

Start Date and Time {Tele-switch Contact Interval}

Tele-switch Contact Code

Tele-switch Contact State

Tele-switch Group Id

Tele-switch Register Rule Id

Tele-switch User Id

Time Pattern Regime Id

6.5.143 Trading Day Data

From/To:

Process 1.1 Marshal Incoming Data

to Data store D1/1 Trading Day Data

Constituent Data Flows:

Validated GSP Group Take

Validated Line Loss Factors

Validated Price Data

Validated SPM

6.5.144 Trigger

From/To:

Process 1.4.1 Invoke Run

to Process 1.4.8.1 Profile SPM data

Process 1.4.8.3 Adjust for Line Losses

to Process 1.4.9 Calculate Deemed Take

Process 1.4.9.5 Produce DUoS Report

to Process 1.4.13 Determine Supplier Purchases

Process 1.4.8 Profile & Line Loss Adjust SPM

to Process 1.4.9.1 Calc & Apply GSP Group Correction

Process 1.4.9.1 Calc & Apply GSP Group Correction

to Process 1.4.9.2 Calculate Deemed Supplier Take

Process 1.4.9.2 Calculate Deemed Supplier Take

to Process 1.4.9.4 Produce TUoS Report

Process 1.4.1 Invoke Run

to Process 1.4.8 Profile & Line Loss Adjust SPM

Process 1.4.8 Profile & Line Loss Adjust SPM

to Process 1.4.9 Calculate Deemed Take

Process 1.4.8.1 Profile SPM data

to Process 1.4.8.2 Aggregate Profiled Data

Process 1.4.8.2 Aggregate Profiled Data

to Process 1.4.8.3 Adjust for Line Losses

Process 1.4.9.4 Produce TUoS Report

to Process 1.4.9.5 Produce DUoS Report

6.5.145 TUoS Report (HH/NHH Split)

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity h TUoS

Process 1.4 Run SSR

to External entity h TUoS

Process 1.4.9.4 Produce TUoS Report

to External entity h TUoS

Process 1.4.9 Calculate Deemed Take

to External entity h TUoS

Data Items:

BM Unit Id

Corrected Daily BMU Gross HH Demand

Corrected Period BMU Gross HH Demand

Daily Corrected Supplier Deemed Take

Daily BMU Gross HH Storage Demand

Daily HH Allocated Volume

Daily NHH Allocated Volume

Daily Non-Corrected Supplier Deemed Take

Daily Supplier Deemed Take

Default BM Unit Flag

GSP Group Id

GSP Group Name

GSP Group Take

Period BMU Gross Storage Demand

Period BMU HH Allocated Volume

Period BMU NHH Allocated Volume

Period Corrected Supplier Deemed Take

Period Non-Corrected Supplier Deemed Take

Period Supplier Deemed Take

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Label

Supplier Id

From/To:

Process 1.3.5 Specify Distributor for GSP Group

to Data store D1/2 SSR Standing Data

Data Items:

Distributor Id

Effective From Settlement Date {GGD}

Effective To Settlement Date {GGD}

GSP Group Id

6.5.150 Updates to line loss factor codes

From/To:

Process 1.3.4 Maintain line loss factor codes

to Data store D1/2 SSR Standing Data

Process 2.6 Load Market Domain Data Complete Set

to Data store D1/2 SSR Standing Data

Data Items:

Distributor Id

Effective From Settlement Date {LLFC}

Line Loss Factor Class Id

6.5.151 Updates to scaling factors

From/To:

Process 1.3.3 Maintain GSP correction scaling factors

to Data store D1/2 SSR Standing Data

Data Items:

Consumption Component Class Id

Effective From Settlement Date {GGCSF}

GSP Group Correction Scaling Factor

6.5.152 Updates to Standing Data

From/To:

Process 1.3 Update SSR Standing Data

to Data store D1/2 SSR Standing Data

Constituent Data Flows:

Updates to aggregator assignments

Updates to distributor assignments

Updates to line loss factor codes

Updates to scaling factors

Updates to supplier details

Validated GSP Group Supplier Assignments

6.5.153 Updates to supplier details

From/To:

Process 1.3.1 Maintain supplier details

to Data store D1/2 SSR Standing Data

Data Items:

Supplier Id

Supplier Name

6.5.154 Validated Assignments

From/To:

Process 2.2.3 Assign Time Patterns to Configurations

to Data store D1 Time Regimes

Data Items:

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.155 Validated Average Fraction of Yearly Consumption

From/To:

Process 2.2.8 Specify Average Fraction of Yearly Consumption

to Data store D1 Time Regimes

Data Items:

Average Fraction of Yearly Consumption

Effective From Settlement Date {AFOYCS}

Effective To Settlement Date {AFOYCS}

GSP Group Id

Profile Class Id

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.156 Validated Clock Change

From/To:

Process 2.1.2 Enter Calendar Details

to Data store D3 Shared Standing Data

Data Items:

Change Date

GMT Time

Post Change Local Time

6.5.157 Validated Clock Intervals

From/To:

Process 2.2 Record Time Patterns

to Data store D1 Time Regimes

Process 2.2.5 Enter Clock Intervals

to Data store D1 Time Regimes

Data Items:

Day of the Week Id

End Day

End Month

End Time

Start Time

Start Day

Start Month

Time Pattern Regime Id

6.5.158 Validated Configuration Data

From/To:

Process 2.2 Record Time Patterns

to Data store D1 Time Regimes

Constituent Data Flows:

Validated Assignments

Validated Average Fraction of Yearly Consumption

Validated Configuration Details

Validated Pool Market Domain Data

Validated Profile Class Assignments

Validated Teleswitch Register and Contact Rules

Validated Time Patterns

6.5.159 Validated Configuration Details

From/To:

Process 2.2.1 Enter Settlement Configurations

to Data store D1 Time Regimes

Data Items:

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {VSCPC}

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Tele-switch Group Id

Tele-switch User Id

6.5.160 Validated Data Collector Details

From/To:

Process 2.1.5 Enter Data Collector Details

to Data store D3 Shared Standing Data

Data Items:

Data Collector Id

Data Collector Name

Effective From Date {DCIGG}

Effective To Date {DCIGG}

6.5.161 Validated GSP Group Details

From/To:

Process 2.1.1 Enter GSP Group Details

to Data store D3 Shared Standing Data

Data Items:

GSP Group Id

Effective From Date {IAA}

Effective To Date {IAA}

6.5.162 Validated GSP Group Supplier Assignments

From/To:

Process 1.3.2 Assign Suppliers to GSP Groups

to Data store D1/2 SSR Standing Data

Data Items:

Effective From Settlement Date {SIGG}

Effective To Settlement Date {SIGG}

GSP Group Id

Supplier Id

6.5.163 Validated GSP Group Take

From/To:

Process 1.1.1 Validate Settlements Data

to Data store D1/1 Trading Day Data

Data Items:

Daily GSP Group Purchases

GSP Group Id

GSP Group Take

Period GSP Group Purchases

SSA Settlement Date

SSA Settlement Run Number

Settlement Period Id

6.5.164 Validated Line Loss Factors

From/To:

Process 1.1.2 Validate Line Loss Factors

to Data store D1/1 Trading Day Data

Data Items:

Distributor Id

Line Loss Factor

Line Loss Factor Class Id

Settlement Date

Settlement Period Id

6.5.165 Validated Parameter Changes

From/To:

Process 2.1 Enter Parameter Data

to Data store D2/1 Daily Parameters

Constituent Data Flows:

Day Type

Noon Effective Temperature

6.5.166 Validated Pool Market Domain Data

From/To:

Process 2.2.7 Load Pool Market Domain Data

to Data store D1 Time Regimes

Data Items:

Average Fraction of Yearly Consumption

Day of the Week Id

Effective From Settlement Date {AFOYCS}

Effective From Settlement Date {VSCPC}

Effective To Settlement Date {AFOYCS}

Effective To Settlement Date {VSCPC}

End Day

End Month

End Time

Start Time

GMT Indicator

GSP Group Id

Profile Class Id

Standard Settlement Configuration Desc

Standard Settlement Configuration Id

Standard Settlement Configuration Type

Start Day

Start Month

Switched Load Indicator

Tele-switch Contact Code

Tele-switch Contact Rule

Tele-switch Group Id

Tele-switch Register Rule Id

Tele-switch User Id

Tele-switch/Clock Indicator

Time Pattern Regime Id

6.5.167 Validated Price Data

This Data Flow is no longer required.

6.5.168 Validated Profile Class Assignments

From/To:

Process 2.2.4 Assign Configurations to Profile Classes

to Data store D1 Time Regimes

Data Items:

Profile Class Id

Standard Settlement Configuration Id

Switched Load Indicator

Time Pattern Regime Id

6.5.169 Validated Profile Details

From/To:

Process 2.5 Enter Profiles

to Data store D2/3 Profiles

Process 2.5.1 Enter Profile Details

to Data store D2/3 Profiles

Data Items:

Profile Class Description

Profile Class Id

Profile Description

Profile Id

Profile Settlement Periods

Effective From Settlement Date {PROF} Effective To Settlement Date {PROF} Switched Load Profile Class Ind

6.5.170 Validated Regression Equations

From/To:

Process 2.5 Enter Profiles

to Data store D2/3 Profiles

Process 2.5.2 Enter Regression Equations

to Data store D2/3 Profiles

Data Items:

Day Type Id

GSP Group Id

Group Average Annual Consumption

Profile Class Id

Profile Id

Regression Coefficient

Regression Coefficient Type

Season Id

Settlement Date

Settlement Period Id

6.5.171 Validated Settlement Timetable

From/To:

Process 1.3 Update SSR Standing Data

to Data store D1/1 Trading Day Data

Process 1.3.7 Maintain Settlement Timetable

to Data store D1/1 Trading Day Data

Process 1.5 Load Settlement Timetable

to Data store D1/1 Trading Day Data

Data Items:

Settlement Code

Settlement Date

Planned SSR Run Date

Payment Date

6.5.172 Validated Shared Standing Data

From/To:

Process 2 Daily Profile Production

to Data store D3 Shared Standing Data

Process 2.1 Enter Parameter Data

to Data store D3 Shared Standing Data

Constituent Data Flows:

Validated Clock Change

Validated Data Collector Details

Validated GSP Group Details

6.5.173 Validated SPM

From/To:

Process 1.1.4 Validate SPM Data

to Data store D1/1 Trading Day Data

Data Items:

Data Aggregator Id

Distributor Id

GSP Group Id

Line Loss Factor Class Id

Profile Class Id

SPM Total Annualised Advance

SPM Total EAC

SPM Total Unmetered Consumption

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.174 Validated Teleswitch Contact Interval Details

From/To:

Process 2.2 Record Time Patterns

to Data store D1 Time Regimes

Process 2.2.10 Enter Teleswitch Contact Interval Details

to Data store D1 Time Regimes

Data Items:

End Date and Time {Tele-switch Contact Interval}

Start Date and Time {Tele-switch Contact Interval}

Tele-switch Contact Code

Tele-switch Contact State

Tele-switch Group Id

Tele-switch User Id

6.5.175 Validated Teleswitch Contact Intervals

From/To:

Process 2.2 Record Time Patterns

to Data store D1 Time Regimes

Process 2.2.6 Load Teleswitch Contact Intervals

to Data store D1 Time Regimes

Data Items:

Date (Midnight to Midnight UTC)

Effective Time(UTC)

Start of Day Tele-switch On Indicator

Tele-switch Contact Code

Tele-switch On Indicator

Tele-switch Contact State

Tele-switch Group Id

Tele-switch User Id

6.5.176 Validated Teleswitch Register and Contact Rules

From/To:

Process 2.2 Record Time Patterns

to Data store D1 Time Regimes

Process 2.2.9 Load Teleswitch Register and Contact Rules

to Data store D1 Time Regimes

Data Items:

Tele-switch Contact Code

Tele-switch Contact Rule

Tele-switch Group Id

Tele-switch Register Rule Id

Tele-switch Time Pattern Regime Id

Tele-switch User Id

6.5.177 Validated Time of Sunset

From/To:

Process 2.1 Enter Time of Sunset

to Data store D2/1 Daily Parameters

Process 2.1.4 Enter Time of Sunset

to Data store D2/1 Daily Parameters

Data Items:

GSP Group Id

Settlement Date

Time of Sunset

6.5.178 Validated Time Patterns

From/To:

Process 2.2.2 Enter Time Patterns

to Data store D1 Time Regimes

Data Items:

GMT Indicator

Tele-switch Group Id

Tele-switch User Id

Tele-switch/Clock Indicator

Time Pattern Regime Id

6.5.179 Valid SSC and PC Details

From/To:

Data store D1 Time Regimes

to Process 1.3.8 Assign NHH BM Units

Data Items:

Profile Class Id

Standard Settlement Configuration Id

Switched Load Indicator

Time Pattern Regime Id

6.5.180 Supplier Disconnection Matrix Report

From/To:

Process 1.2.8 Create Supplier Disconnection Matrix Report

to External entity j Supplier

Data Items:

Data Aggregation Run Number

Data Aggregator Id

Data Aggregator Name

Distributor Id

GSP Group Id

GSP Group Name

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

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Standard Settlement Configuration Id

Supplier Id

Time Pattern Regime Id

6.5.181 Aggregated Disconnected DUoS Report

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity j Supplier

Process 1.4.9 Calculate Deemed Take

to External entity a Distribution Business

Process 1.4.9 Calculate Deemed Take

to External entity j Supplier

Process 1.4.9.6 Produce Aggregated Disconnected DUoS Report

to External entity j Supplier

Process 1.4.9.6 Produce Aggregated Disconnected DUoS Report

to External entity a Distribution Business

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Consumption Component Class Id

Consumption Component Indicator

Daily Profiled DPM Total Annualised Advance

Daily Profiled DPM Total EAC

Data Aggregation Type

Distributor Id

Distributor Name

GSP Group Correction Factor

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Line Loss Factor Class Id

Measurement Quantity Id

Metered/Unmetered Indicator

Pool Member Id

Profile Class Id

Profiled DPM Consumption (repeating group of 50)

DPM Default EAC MSID Count

DPM Total AA MSID Count

DPM Total Annualised Advance Report Value

DPM Total All EACs

DPM Total EAC MSID Count

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Code Description

Settlement Date

Settlement Period Id

Settlement Period Label

Standard Settlement Configuration Id

Supplier Id

Supplier Name

Time Pattern Regime Id

6.5.182 GSP Group Demand Disconnection Consumption Totals Report

From/To:

Process 1.2.10 Create GSP Group Consumption Totals Report

to External entity j Supplier

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Consumption Component Indicator

Corrected Supplier Consumption

Corrected Supplier Line Loss

Data Aggregation Type

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

MSID Count

6.5.183 Supplier BM Unit Demand Disconnection Report

From/To:

Process 1.2.11 Create Supplier BM Unit Demand Disconnection Report

to External entity j Supplier

Data items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated BM Unit Energy

Aggregated BM Unit Line Losses

BM Unit Id

Consumption Component Class Id

Consumption Component Indicator

Corrected BM Unit Energy

Corrected BM Unit Line Losses

Daily Aggregated BM Unit Energy

Daily Aggregated BM Unit Line Losses

Daily Corrected BM Unit Energy

Daily Corrected BM Unit Line Losses

Daily DA HH MSID Count

Daily Period BM Unit Total Allocated Volume

Daily Uncorrected Period BM Unit Total Allocated Volume

Data Aggregation Type

Data Aggregator HH MSID Count

Data Aggregator Id

Data Aggregator Name

Base BM Unit Flag

Base BM Unit Reason Code

GSP Group

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

Period BM Unit Total Allocated Volume

Profile Class Id

Report Parameters

Run Number

Run Type Code

Settlement Code

Settlement Code Description

Settlement Date

Settlement Period Id

Settlement Period Label

SSR Run BM Unit Id

SSR Run Date

SSR Run Number

SSR Run Type Id

Standard Settlement Configuration Id

Supplier Id

Supplier Name

Uncorrected Period BM Unit Total Allocated Volume

User Name

6.5.184 Aggregated Embedded Network Disconnected DUoS Report

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity a Distribution Business

Process 1.4 Run SSR

to External entity j Supplier

Process 1.4.9 Calculate Deemed Take

to External entity a Distribution Business

Process 1.4.9 Calculate Deemed Take

to External entity j Supplier

Process 1.4.9.7 Produce Aggregated Embedded Network Disconnected DUoS Report

to External entity j Supplier

Process 1.4.9.7 Produce Aggregated Embedded Network Disconnected DUoS Report

to External entity a Distribution Business

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

BSC Trading Party Id

Consumption Component Class Id

Consumption Component Indicator

Daily Profiled DPM Total Annualised Advance

Daily Profiled DPM Total EAC

Data Aggregation Type

Distributor Id

Distributor Name

Embedded Distributor Id

Embedded Distributor Name

GSP Group Correction Factor

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Line Loss Factor Class Id

Measurement Quantity Id

Metered/Unmetered Indicator

Pool Member Id

Profile Class Id

Profiled DPM Consumption (repeating group of 50)

DPM Default EAC MSID Count

DPM Total AA MSID Count

DPM Total Annualised Advance Report Value

DPM Total All EACs

DPM Total EAC MSID Count

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Code Description

Settlement Date

Settlement Period Id

Settlement Period Label

Standard Settlement Configuration Id

Supplier Id

Supplier Name

Time Pattern Regime Id

6.5.185 Disconnected MSIDs and Estimated Half Hourly Demand Volumes

From/To:

External entity t NETSO

to Process 1.1.7 Manage Disconnected MSIDs and Estimated Half Hourly Demand Volumes

Process 1.1.7 Manage Disconnected MSIDs and Estimated Half Hourly

to External entity l HH Data Collector

Process 1.1.7 Manage Disconnected MSIDs and Estimated Half Hourly

to External entity b NHH Data Collector

Data items:

Demand Control Event Id

Start Date and Time

End Date and Time

Estimated HH Demand Disconnection Volume

Measurement Quantity Id

Metering System Id

Supplier Id

6.5.186 HH Demand Disconnection Report

From/To:

Process 1.2.9 HH Demand Disconnection Report

to External entity j Supplier

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated Supplier Disconnected Consumption

Aggregated Supplier Disconnected Line Loss

CDCS Extract Number

Consumption Component Class Id

Consumption Component Indicator

Corrected Supplier Disconnected Consumption

Corrected Supplier Disconnected Line Loss

Data Aggregation Type

Data Aggregator HH Disconnected MSID Count

Data Aggregator Id

Data Aggregator Name

Distributor Id

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

Supplier Id

Supplier Name

6.5.187 Supplier’s Demand Disconnection Volume Data File

From/To:

External entity o HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity o HH Data Aggregator

to Process 1.1 Marshal Incoming Data

Process 1.1 Marshal Incoming Data

to Data store D1/3 Supplier HH Demand

External entity o HH Data Aggregator

to Process 1.1.3 Validate HH Data

Process 1.1.3 Validate HH Data

to Data store D1/3 Supplier HH Demand

Data Items:

Aggregated Supplier Disconnection Consumption

Aggregated Supplier Disconnection Line Loss

Consumption Component Class Id

Data Aggregation Run Number

Data Aggregation Type

Data Aggregator HH Disconnected MSID Count

Data Aggregator Id

GSP Group Id

Settlement Code

Settlement Date

Settlement Period Id

Supplier Id

6.5.188 Disconnection Purchase Matrix Data

From/To:

External entity p Non-HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity p Non-HH Data Aggregator

to Process 1.1 Marshal Incoming Data

External entity p Non-HH Data Aggregator

to Process 1.1.4 Validate SPM Data

Data Items:

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

6.5.189 BM Unit Aggregated HH Demand Disconnection Data File

From/To:

External entity o HH Data Aggregator

to Process 1 Supplier Settlement and Reconciliation

External entity o HH Data Aggregator

to Process 1.1 Marshal Incoming Data

Process 1.1 Marshal Incoming Data

to Data store D1/3 Supplier HH Demand

External entity o HH Data Aggregator

to Process 1.1.3 Validate HH Data

Process 1.1.3 Validate HH Data

to Data store D1/3 Supplier HH Demand

Data Items:

Aggregated BM Unit Demand Disconnection Energy

Aggregated BM Unit Demand Disconnection Line Losses

BM Unit Id

Consumption Component Class Id

Data Aggregator HH Disconnected MSID Count

Demand Control Event Id

Start Date and Time

End Date and Time

GSP Group

Run Number

Run Type Code

Settlement Code

Settlement Date

Settlement Period Id

Supplier Id

6.5.190 BM Unit Disconnected Supplier Take Energy Volume Data File

From/To:

Process 1 Supplier Settlement and Reconciliation

to External entity g Settlement Administration Agent

Process 1.4 Run SSR

to External entity g Settlement Administration Agent

Process 1.4.13.2 Generate BM Unit Supplier Take Energy Volume Data File

to External entity g Settlement Administration Agent

Process 1.4.13 Determine Supplier Energy Allocations

to External entity g Settlement Administration Agent

Data Items

BM Unit Identifier

CDCA Set Number

CDCA Settlement Date

GSP Group

GSP Group Id

Period BM Unit Total Allocated Disconnected Volume

Run Type Code

Settlement Code

Settlement Date

Settlement Period Id

SSR Run Date

SSR Run Number

Supplier Id

6.5.191 Mapping Data for HH Aggregated Metering Systems

From/To:

External entity a Distribution Business

to Process 1 Supplier Settlement and Reconciliation

External entity a Distribution Business

to Process 1.1 Marshal Incoming Data

External entity a Distribution Business

to Process 1.1.6 Validate Mapping Data for HH Aggregated Metering Systems

Data Items:

Distributor Id

Line Loss Factor Class Id

Standard Settlement Configuration Id

Standard Settlement Configuration Description

Effective From Date

Effective To Date

Time Pattern Regime Id

Day of the Week Id

Start Day

Start Month

End Day

End Month

Start Time

End Time

6.5.192 Supplier Quarterly Volume Report

From/To:

Process 1.2.12 Supplier Quarterly Volume Report

to External entity e Electricity Pool

Data Items:

Quarter Id

Settlement Run From Date

Settlement Run End Date

Number of Settlement Runs in Quarter

Number of Settlement Days in Report

Supplier Id

Supplier Volume Reporting Group

Quarterly Average MPAN Count

Quarterly Volume in MWh

6.5.193 BSCCo GSP Group Consumption Totals Report

From/To:

Process 1.2.5 Create GSP Group Consumption Totals Report

to External entity e Electricity Pool

Data Items:

AA/EAC Indicator

Actual/Estimated Indicator

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Consumption Component Class Id

Consumption Component Indicator

Corrected Supplier Consumption

Corrected Supplier Line Loss

Data Aggregation Type

GSP Group Correction Scaling Factor

GSP Group Id

GSP Group Name

Measurement Quantity Id

Metered/Unmetered Indicator

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Settlement Period Id

Settlement Period Label

MSID Count

6.5.194 GSP Group Market Matrix Report

From/To:

Process 1.2.1 Create Supplier Purchase Matrix Report

to External entity e Electricity Pool

Data Items:

Data Aggregation Run Number

Data Aggregator Id

Data Aggregator Name

Distributor Id

GSP Group Id

GSP Group Name

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

SSR Run Date

SSR Run Number

SSR Run Type Id

Settlement Code

Settlement Date

Standard Settlement Configuration Id

Time Pattern Regime Id

6.5.195 Specify Final Dispute Expected Aggregation

From/To:

External entity k ISR Agent

to Process 1.3.10 Maintain Final Dispute Expected Aggregation

Data Items:

Data Aggregation Type

Data Aggregator Id

Blanket NHH Indicator

Effective From Settlement Date {FDEDA}

Effective To Settlement Date {FDEDA}

GSP Group Id

6.5.196 Updates to Final Dispute Expected Aggregation

From/To:

Process 1.3.10 Maintain Final Dispute Expected Aggregation

to Data store D1/2 SSR Standing Data

Data Items:

Data Aggregation Type

Data Aggregator Id

Blanket NHH Indicator

Effective From Settlement Date {FDEDA}

Effective To Settlement Date {FDEDA}

GSP Group Id

6.5.197 Final Dispute Expected Aggregation

From/To:

Data store D1/2 SSR Standing Data

to Process 1.4.1 Invoke Run

Data Items:

Data Aggregation Type

Data Aggregator Id

Blanket NHH Indicator

Effective From Settlement Date {FDEDA}

Effective To Settlement Date {FDEDA}

GSP Group Id

6.5.198 Supplier BM Unit Non Chargeable Demand

From/To:

Process 1.2.13 Supplier BM Unit Non Chargeable Demand

to External entity g Settlement Administration Agent

Data Items:

SSR Run Type Id

Settlement Date

BM Unit Id

Settlement Period

Period BM Unit Non-chargeable Demand

7. LOGICAL DATA STRUCTURE

7.1 Purpose and Scope

1. The ISRA Logical Data Model describes the data of interest to the Supplier Settlements and Reconciliation (SSR) and the Daily Profile Production Systems.

2. The model covers the groupings of data items which are required by ISRA to perform the processes within their scope and some entities which are required to define the structure and relationships of the data but which are not processed by ISRA. These latter entities will be processed by other 1998 component systems.

3. The model consists of:

3.1. A Logical Data Structure (diagram);

3.2. Entity Descriptions, including indications of the source of data items and where they are used;

3.3. List of the main attributes for each entity. The primary key attributes are indicated by ‘p’, foreign key attributes are indicated by an asterisk (*) and optional attributes are indicated by 'o'.

3.4. An Entity-Datastore cross reference in Section 8.

Descriptions of the data items populating the entities is given in Appendix B. A key to the LDS notation used in the diagram in Appendix C.

7.2 Initial Settlement and Reconciliation Agency

Entity Descriptions

7.2.1 Note to the reader

It can be seen that in the entity descriptions that are included in the Initial Settlement and Reconciliation Agency System data model, that the names of some of the data items are replicated. The replication occurrences take the form of the original data item name suffixed with a number - usually 1, 2 or 11. This is a feature of the Select SSADM Professional Version 4.01 CASE tool used to build the data model, in which primary keys in a master entity are automatically transferred to a detail entity as foreign keys.

For the purposes of understanding, the reader is advised to take note only of the first listed data item (to see whether it is prime/foreign/optional/ordinary) and to ignore any subsequently listed occurrences.

7.2.2 Aggregated Supplier DA Period Consumption

Description: The aggregated HH metered consumption, Non-Pooled Generation or line loss for a supplier, within a GSP Group, by BM Unit (optional), Consumption Component Class and Settlement Period. The BM Unit value is allowed to be optional as this metered consumption, Non-Pooled Generation or line loss will then be allocated to the Base BM Unit by the Settlement Run.

The Consumption Component Class determines what the Aggregated Supplier Consumption or Aggregated Supplier Line Loss actually represents.

Contains Attributes

p * GSP Group Id

p * Data Aggregator Id

p * Data Aggregation Run Number

p * Supplier Id

p * Settlement Date

p * Settlement Code

p * Settlement Period Id

p * Consumption Component Class Id

p * BM Unit Id as Specified by HH Data Aggregator

Data Aggregator HH MSID Count

o Aggregated BM Unit Energy

o Aggregated BM Unit Line Losses

* Data Aggregation Type

* Settlement Date1

7.2.3 Aggregated BM Unit Period Consumption

Description: The aggregated profiled consumption or Line Loss derived for a BM Unit, by Consumption Component Class, for a Settlement Period. Aggregated consumption is calculated separately for each Consumption Component Class; the line loss consumption components are aggregated separately.

The Consumption Component Class determines which type the BM Unit consumption or line loss represents.

Corrected BM Unit Energy is derived by applying the GSP Group Correction Factor to the appropriate consumption components; Corrected Line Losses Component is derived by applying the GSP Group Correction Factor to the appropriate line loss components.

Contains attributes

p * SSR Run BM Unit Id

p * Consumption Component Class Id

p * GSP Group Id

p * SSR Run Number

p * Settlement Period Id

p * Supplier Id

p * Settlement Date

p * Settlement Code

Aggregated BM Unit Energy

Aggregated BM Unit Line Losses

Corrected BM Unit Energy

Corrected BM Unit Line Losses

7.2.4 Aggregated Supplier Period Consumption

Description: The aggregated profiled consumption or Line Loss derived for a supplier, within a GSP Group, by Consumption Component Class, for a Settlement Period. Aggregated consumption is calculated separately for each Consumption Component Class; the line loss consumption components are aggregated separately.

Aggregated supplier consumption is derived from one of:

a) applying profiles to aggregated EACs and summing across Settlement Classes and Data Aggregators for each Supplier or

b) applying profiles to aggregated Annualised Advances and summing across Settlement Classes and Data Aggregators, for each Supplier.

Aggregated Supplier Line Loss is derived from adjusting the profiled consumption for each Line Loss Class and summing across Settlement Classes and Data Aggregators, for the Supplier.

The Consumption Component Class determines which type the supplier consumption or line loss represents.

Corrected Supplier Consumption is derived by applying the GSP Correction Factor to the appropriate consumption components; Corrected Line Loss Component is derived by applying the GSP Group Correction Factor to the appropriate line loss components.

Contains Attributes

p * GSP Group Id

p * Supplier Id

p * Settlement Date

p * Settlement Period Id

p * Consumption Component Class Id

p * SSR Run Number

p * Settlement Code

Aggregated Supplier Consumption

Aggregated Supplier Line Loss

Corrected Supplier Consumption

Corrected Supplier Line Loss

* Settlement Date1

7.2.5 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 * GSP Group Id

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Effective From Settlement Date {AFOYCS}

* Profile Class Id1

* Standard Settlement Configuration Id1

* Effective From Settlement Date {VSCPC}

Average Fraction of Yearly Consumption

Description: The 'on' interval of a clock based Time Pattern Regime. Clock Intervals for a Time Pattern Regime are defined in terms of Date Blocks, Days of the Week and Time Blocks (GMT start and end times). The time blocks do not necessarily lie on a half hour boundary.

Contains Attributes

p * Time Pattern Regime Id

p * Start Time

p * Day of the Week Id

p * Start Day

p * Start Month

p * End Day

p * End Month

* End Time

7.2.10 Clock Time Change

Description: A change in the clock time protocol being used.

Contains Attributes

p Change Date

GMT Time

Post Change Local Time

7.2.11 Clock Time Pattern Regime

Description: A Time Pattern Regime associated with a clock-switched Standard Settlement Configuration.

Contains Attributes

p Time Pattern Regime Id

7.2.12 Combined Period Profile Coefficient

Description: A profile coefficient which when applied to an annualised advance value (EAC or AA) supplies an estimate of consumption for a specific Settlement Period. A Combined Profile Coefficient is derived for each valid combination of Switched Load Profile Class (a Profile Class which has at least one switched load Profile) and Standard Settlement Configuration, and includes both the base and switched load components.

Contains Attributes

p * GSP Group Id

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Settlement Date

p * Settlement Period Id

Normal Register Profile Coefficient

Low Register Profile Coefficient

* Settlement Date1

* Effective From Settlement Date {VSCPC}

7.2.13 Consumption Component Class

Description: The class of Half Hourly Consumption and Non-Pool Generation which has been calculated or aggregated. Consumption is summed/calculated in each of these different components in order that the GSP Group Correction Factor can be applied (or not, as required) to each. The classes are dependent upon valid combinations of the attributes specified, i.e. whether the consumption is:

1) for Half Hourly or Non Half Hourly

2) for Metered or Unmetered supply,

3) Actual / estimated consumption,

4) Based on AA or EAC calculation,

5) Metering System Specific Line Loss, Non Metering System Specific Line Loss or base consumption,

6) Active Import or Active Export.

The Half Hourly classes are further dependant upon whether the half hourly demand associated with a site is above or below 100kW. There will be two Consumption Component Classes for each Half Hourly Metered Consumption/Losses for actual or estimated readings; one for sites above 100kW, and one for sites below 100kW. Note that this relates to Active Import Consumption Component Classes only.

Initially, only combinations of the following will have the Scaling Factor set to 1 i.e. have the GSP Group Correction Factor applied:

Non-half hourly; metered or unmetered; actual/ estimated; EAC/AA; base consumption/non-metering system specific line loss; active import/ active export.

Contains Attributes

p Consumption Component Class Id

Data Aggregation Type

Metered/Unmetered Indicator

Actual/Estimated Indicator

AA/EAC Indicator

Consumption Component Indicator

* Measurement Quantity Id

7.2.14 Daily Profile Coefficient

Description: The sum of all Period Profile Class Coefficients for a Settlement Day, within GSP Group, for a Profile Class and Measurement Requirement combination.

Contains Attributes

p * GSP Group Id

p * Settlement Date

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

Daily Profile Coefficient

* Settlement Date1

7.2.15 Daily Profile Parameters

Description: For each GSP Group, values must be supplied for a number of parameters for each Settlement Day. These are substituted into the Period Regression Equations to calculate the Basic Period Profile Coefficients. The parameters include:

Deemed Time of Sunset

Actual Noon Temperature

The deemed time of sunset is known and can be specified up to a year in advance. Actual Noon Temperature cannot be specified until the day following the Settlement Day. Noon Effective Temperature is derived from the average of Actual Noon Temperature over a number of days.

Contains Attributes

p * GSP Group Id

p * Settlement Date

Time of Sunset

Actual Noon Temperature

Noon Effective Temperature

7.2.16 Data Aggregator

Description: An organisation that is Qualified in accordance with BSCP537 (Reference 21) to perform half hourly or non half hourly data aggregation.

Contains Attributes

p Data Aggregator Id

Data Aggregator Name

7.2.17 Data Aggregator In GSP Group

Description: Record of Data Aggregator agreement to perform data aggregation for a supplier for an aggregation type by GSP Group.

Contains Attributes

p * GSP Group Id

p * Supplier Id

p * Data Aggregator Id

p Data Aggregation Type

p Effective From Settlement Date {DAIGG}

o Effective To Settlement Date {DAIGG}

Description: A day of the week (e.g. Saturday), forming part of the definition of a Clock Interval.

Contains Attributes

p Day of the Week Id

7.2.22 Day Type

Description: A type of day, used to determine which set of regression equations and which time patterns are valid on a specific Settlement Day.

Valid Initial Set: Saturday, Sunday, Weekday

Contains Attributes

p Day Type Id

7.2.23 Distributor

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

Contains Attributes

p Distributor Id

7.2.24 GSP Group

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

Contains Attributes

p GSP Group Id

GSP Group Name

7.2.25 GSP Group Average EAC

Description: The average Estimated Annual Consumption attributable to Metering Systems in a Profile Class, by profile within a GSP Group.

Contains Attributes

p * GSP Group Id

p * Profile Class Id

p * Profile Id

p * Effective From Settlement Date {PSET}

Group Average Annual Consumption

7.2.26 GSP Group Correction Factor

Description: The factor by which the total deemed take for each Supplier, calculated by ISRA, must be corrected in order to equal the GSP Group Take from the GSPs in the GSP Group. The GSP Group Correction Factor for a Settlement Period is derived from the total take for the GSP Group and the aggregated consumption. The total take for a GSP Group for a Settlement Period is supplied by the SSA.

Contains Attributes

p * GSP Group Id

p * SSR Run Number

p * Settlement Date

p * Settlement Code

p * Settlement Period Id

GSP Group Correction Factor

* Settlement Date1

7.2.27 GSP Group Correction Scaling Factor

Description: A specification of the degree to which a GSP Group Correction Factor is applied to a Consumption Component Class. Currently, the values are 0 (not applied) and 1 (applied). However, future values are accommodated for, such as between 0 and 1 (partially applied) and greater than 1 (over-applied).

Contains Attributes

Description: A quantity which may be measured by registers of Metering Systems. Valid initial set is:

i) Active kWh Import

ii) Active kWh Export

iii) Reactive kVArh Import

iv) Reactive kVArh Export

Only the first two are relevant to Initial Settlement and Reconciliation.

Contains Attributes

p Measurement Quantity Id

Direction Of Energy Flow

7.2.33 Measurement Requirement

Description: A Standard Settlement Configuration requirement for consumption to be measured during a Time Pattern Regime.

Contains Attributes

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

7.2.34 Non-Half Hourly BM Unit Allocation

Description: A Valid Settlement Configuration Profile Class allocated to a BM Unit for Supplier in GSP Group.

Contains Attributes

p * BM Unit Id

p * Effective From Settlement Date {BMUIGG}

p Effective From Settlement Date {NHHBMUA}

p * Profile Class Id

p * Standard Settlement Configuration Id

o Effective To Settlement Date {NHHBMUA}

7.2.35 Period Profile Class Coefficient

Description: A Profile Coefficient which when applied to an annualised advance value (EAC or AA) supplies an estimate of consumption for a specific Settlement Period. A Period Profile Class Coefficient is derived for a valid Profile Class within Time Pattern Regime, taking into account any switched load and chunking.

Contains Attributes

p * GSP Group Id

p * Settlement Date

p * Settlement Period Id

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

Period Profile Coefficient Value

* Settlement Date1

7.2.36 Period Regression Equation

Description: A Regression Equation and associated Regression Coefficients for a Settlement Period (1 to 50) within a Profile and GSP Group, for a season and day type combination. When evaluated using GSP Group and Settlement Date specific parameters, the regression equation produces a Period Profile Coefficient. The Regression Equation may change over time.

Contains Attributes

p * Profile Class Id

p * Profile Id

p * Effective From Settlement Date {PSET}

p * Day Type Id

p * Season Id

p * Settlement Period Id

7.2.37 Period Supplier Purchase

Description: The total value of purchases for a Supplier within a GSP Group, for a Settlement Period derived during a specific SSR Run for the Settlement Day.

Contains Attributes

p * GSP Group Id

p * SSR Run Number

p * Supplier Id

p * Settlement Date

p * Settlement Code

p * Settlement Period Id

Period Supplier Deemed Take

Period Supplier Purchase Total

Unadjusted Supplier Deemed Take

* Settlement Date1

7.2.38 Period Time Pattern State

Description: The state of a Time Pattern Regime during a Settlement Period, indicating whether the time pattern is 'On' or not. The indicator is derived from a Clock Interval or Teleswitch Interval.

Contains Attributes

p * Time Pattern Regime Id

p Standard Settlement Configuration Id

p Settlement Date

p Settlement Period Id

Period Register On State Indicator

7.2.39 Profile

Description: A pattern of consumption of electricity, by half hour, across a year. The shape of the profile is defined by sets of Profile Coefficients, which are derived by evaluating Regression Equations.

Profiles for Economy 7 Profile Classes are either for switched load or base load.

Contains Attributes

p * Profile Class Id

p Profile Id

Profile Description

Profile Settlement Periods

Effective From Settlement Date {PROF}

o Effective To Settlement Date {PROF}

7.2.40 Profile Class

Description: A group of customers whose consumption can be reasonably approximated to a common profile for Settlement purposes.

Valid initial set is:

domestic unrestricted

domestic economy 7

non-domestic unrestricted

non-domestic economy 7

four different load factor bands for non-domestic maximum demand meters.

Contains Attributes

p Profile Class Id

Profile Class Description

Switched Load Profile Class Ind

7.2.41 Profile Production Run in GSP Group

Description: An occurrence of a run of the profile production process for a GSP Group and Settlement Day.

Contains Attributes

p * GSP Group Id

p * Settlement Date

p Profile Production Run Number

7.2.42 Profile Regression Equation Set

Description: The set of regression equations for a profile, for a season and day type combination. The equations may change over time.

Contains Attributes

p * Profile Class Id

p * Profile Id

p * Effective From Settlement Date {PSET}

p * Day Type Id

p * Season Id

7.2.43 Profile Set

Description: A set of data for a Profile, comprising one or more Profile regression Equation Sets, and a GSP Group Average EAC for each GSP Group.

Contains Attributes

p * Profile Class Id

p * Profile Id

p Effective From Settlement Date {PSET}

7.2.44 Profiled SPM

Description: The set of data created by applying half hourly profiles to the EAC, AA and Unmetered Totals in a SPM.

Contains Attributes

p * Supplier Id

p * GSP Group Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Profile Class Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Settlement Date

p * Settlement Code

p * Settlement Period Id

Profiled SPM Total Annualised Advance

Profiled SPM Total EAC

Profiled SPM Total Unmetered Consumption

* Settlement Date1

7.2.45 Regression Coefficient

Description: Regression Coefficients derived from multiple ordinary least squares linear regression analyses of the effects of temperature, time of sunset and day of week on the average demand (kW) per customer in a defined group, at each half-hour of the day in different periods of the year. The effect of season is catered for by deriving a set for each season and therefore it does not appear as a parameter in the equation.

Contains Attributes:

p * Profile Class Id p * Profile Id p * Effective From Settlement Date{PSET} p * Day Type Id p * Season Id p * Settlement Period Id p * Regression Coefficient Type Regression Coefficient

7.2.46 Regression Coefficient Type

Description: The types of Regression Coefficients derived from the analyses (see Regression Coefficients). The initial set are:

Time of Sunset (Time of Sunset)² Noon Effective Temperature Day of Week 1 Day of Week 2 Day of Week 3 Day of Week 4 Constant

Contains Attributes p Regression Coefficient Type

7.2.47 Season

Description: A contiguous block of days having similar weather characteristics occurring at different times of the year.

Seasons do not vary between GSP groups.

Contains Attributes

p Season Id

7.2.48 Settlement

Description: A calculation of the funds to be cleared between Suppliers and Generators in respect of electricity traded through the Pool. This includes settlement and reconciliation.

For each Settlement Day the Pool publishes a schedule of settlements. It may include target dates for completing the major business functions and running the various component 1998 systems (Data Processing, Data Aggregation, DPP, Existing Settlements and SSR).

Contains Attributes

p Settlement Code

p * Settlement Date

Payment Date

Planned SSR Run Date

7.2.49 Settlement Class

Description: The combination which defines the level at which non-Half Hourly Data Aggregators must supply aggregated EAC and AA values - that is for a Measurement Requirement, Profile and Line Loss Factor Class within a GSP Group.

Contains Attributes

p * GSP Group Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

* Effective From Settlement Date {LLFC}

7.2.50 Settlement Day

Description: A day in local time (not GMT), of a certain day type, within a season, on which electricity is traded and settled.

Contains Attributes

p Settlement Date

* Day Type Id

* Season Id

7.2.51 Settlement Period

Description: A half hour period within a Settlement Day.

Contains Attributes

p * Settlement Date

p Settlement Period Id

Settlement Period Label

7.2.52 Settlement Period Line Loss Factor

Description: The Line Loss Factor to be applied for a Line Loss Factor Class during a Settlement Period. A Line Loss Factor is the factor by which consumption is multiplied to derive an estimate of consumption at GSP level. They have a value >1. Line Loss Factor values are determined by the distribution area and will be specified as varying from half hour to half hour, by day type, season and over time. For the purposes of Initial Settlement and Reconciliation they are expressed here as a value by Settlement Period and Line Loss Factor Class.

Contains Attributes

p * Settlement Date

p * Settlement Period Id

p * Distributor Id

p * Line Loss Factor Class Id

Line Loss Factor

* Effective From Settlement Date {LLFC}

7.2.53 SSA Settlement Run

Description: Records for the Preliminary, Provisional and Final SSA Runs. Used by the SSR Run to reference GSP Group Takes for the set of Settlement Periods in a Settlement Day.

Contains Attributes

p SSA Settlement Run Number

p * Settlement Date

SSA Settlement Run Type Id

SSA Settlement Date

CDCS Extract Number

7.2.54 SSA Settlement GSP Group

Description: Daily totals supplied by the SSA by GSP Group to enable ISRA to balance GSP group Purchases

Contains Attributes

p * SSA Settlement Run Number p * Settlement Date p * GSP Group Id Daily GSP Group Purchases

7.2.55 SSR Run in GSP Group

Description: An occurrence of a run of the SSR Initial Settlement or Reconciliation process for a GSP Group. Audit data will be held against each run.

Contains Attributes

p * GSP Group Id

p * Settlement Code

p * Settlement Date

p SSR Run Number

SSR Run Date

* SSR Run Type Id

p Data Aggregation Run Number

p * Data Aggregation Type

p * GSP Group Id

p * Settlement Code

p * Settlement Date

* Effective From Settlement Date {DAIGG}

Date and Time Sent {Aggregation Run}

7.2.60 Supplier Data Aggregation Used In SSR Run

Description: A link entity between the Supplier Data Aggregation and SSR Run entities to reflect that more than one SSR Run may be associated with each occurrence of Supplier Data Aggregation and vice versa.

Contains Attributes

p * GSP Group Id

p * Settlement Date

p * Settlement Code

p * SSR Run Number

p * Supplier Id

p * Data Aggregator Id

p * Data Aggregation Run Number

p * Data Aggregation Type

* GSP Group Id1

* Settlement Date1

* Settlement Code1

7.2.61 Supplier In GSP Group

Description: The link entity between Suppliers and GSP Groups, reflecting that a Supplier can supply to one or more GSP Groups and that a GSP Group may have one or more Suppliers.

Contains Attributes

p * Supplier Id

p * GSP Group Id

p Effective From Settlement Date {SIGG}

o Effective To Settlement Date {SIGG}

7.2.62 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 Class (collectively known as Settlement Class).

Contains Attributes

p * GSP Group Id

p * Data Aggregator Id

p * Data Aggregation Run Number

p * Settlement Date

p * Settlement Code

p * Supplier Id

p * Profile Class Id

p * Distributor Id

p * Line Loss Factor Class Id

p * Time Pattern Regime Id

p * Standard Settlement Configuration Id

SPM Total EAC

SPM Total Annualised Advance

SPM Total Unmetered Consumption

SPM Total EAC MSID Count

SPM Total AA MSID Count

SPM Total Unmetered MSID Count

p Start Time {Tele-switch Interval}

End Time {Tele-switch Interval}

7.2.68 Teleswitch Register Rule

Description: A rule defining when a Teleswitch Time Pattern Regime is on. Most Teleswitch Time Pattern Regimes will have a single Teleswitch Register Rule, with a number of Teleswitch Contact Rule details, allowing the coding of rules such as “register 1 is on when contact A is on and contact B is off”.

Defining more than one Teleswitch Register Rule means that the Teleswitch Time Pattern Regime is on when any of the rules is satisfied. This allows the definition of more complex rules such as "register 1 is on when contact D is on, or contact A is on and contact B is off”. A Tele-switch Register Rule Id is a number which distinguishes between the different rules associated with a Teleswitch Time Pattern Regime.

Contains Attributes

p* Tele-switch Time Pattern Regime Id

p Tele-switch Register Rule Id

7.2.69 Teleswitch Time Pattern Regime

Description: A Time Pattern Regime associated with a teleswitched Standard Settlement Configuration. A Teleswitch Time Pattern Regime can only belong to one Teleswitch Group.

Contains Attributes

p Time Pattern Regime Id

* Tele-switch User Id

* Tele-switch Group Id

7.2.70 Time Block

Description: A block of time wholly within one GMT Day.

Contains Attributes

p Start Time

p End Time

7.2.71 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 teleswitching.

Contains Attributes

p Time Pattern Regime Id

GMT Indicator

Tele-switch/Clock Indicator

7.2.72 Valid Measurement Requirement Profile Class

Description: A Measurement Requirement within a valid Standard Settlement Configuration and Profile Class set. One or more Measurement Requirement in the set may measure switched load i.e. have the Switched Load Indicator set.

Contains Attributes

p * Profile Class Id

p * Standard Settlement Configuration Id

p * Time Pattern Regime Id

p * Effective From Settlement Date {VSCPC}

Switched Load Indicator

* Standard Settlement Configuration Id1

7.2.73 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

p Effective From Settlement Date {VSCPC}

o Effective To Settlement Date {VSCPC}

8. Entity/Datastore Cross Reference

The table below gives cross - references from each entity in the Logical Data Model to the data stores and data

The naming conventions for the datastores are:

Dn is for data shared between SSR and DPP
D1/n is for data used only by SSR
D2/n is for data used only by DPP

ID	Data Store	Description	Entities
D1	Time Regimes	Standing data defining the Standard Settlement Configurations supported by ISRA.	Average Fraction Of Yearly Consumption, Average Fraction Of Yearly Consumption Set, Clock Interval, Clock Time Pattern Regime, Date Block, Day Of The Week, Measurement Requirement, Season, Standard Settlement Configuration, Teleswitch Contact, Teleswitch Contact Interval, Teleswitch Contact Rule, Teleswitch Group, Teleswitch Interval, Teleswitch Register Rule, Teleswitch Time Pattern Regime, Time Block, Time Pattern Regime, Teleswitch Time Pattern Regime, Valid Measurement Requirement Profile Class, Valid Settlement Configuration Profile Class
D1/1	Trading Day Data	SSR data for each Settlement Day and/or GSP Group.	GSP Group Correction Factor, GSP Group Take, , Settlement, Settlement Period Line Loss Factor, Settlement Period, SSA Settlement GSP Group, Supplier Purchase Matrix
D1/2	SSR Standing Data	Standing data required for SSR processing.	Consumption Component Class, Data Aggregator, Data Aggregator In GSP Group, Distributor, GSP Group Correction Scaling Factor, GSP Group, BM for Supplier in GSP Group, Distributor, Line Loss Factor Class, Measurement Quantity, NHH BM Unit Allocation, Settlement Class, Supplier, Supplier In GSP Group
D1/3	Supplier HH Demand	Supplier demand broken down by consumption component.	Aggregated Supplier DA Period Consumption, Aggregated Supplier Period Consumption, Profiled SPM, Aggregated BM Unit Period Consumption
D1/4	Supplier Purchases	Total Supplier Purchases for each Settlement Period.	Period Supplier Purchase
D2	Daily Profiles	Consumption profiles calculated daily for each GSP Group from regression equations.	Basic Period Profile Coefficient, Combined Period Profile Coefficient, Daily Profile Coefficient, Period Profile Class Coefficient, Period Time Pattern State, Profile Production Run In GSP Group
D2/1	Daily Parameters	Noon effective temperature, time of sunset, and other daily parameters used for evaluating regression equations in each GSP Group.	Daily Profile Parameters, Day Type, Settlement Day
D2/3	Profiles	Profile classes and the associated regression equations.	GSP Group Average EAC, Period Regression Equation, Profile, Profile Class, Profile Regression Equation Set, Profile Set, Regression Coefficient, Regression Coefficient Type
D3	Shared Standing Data	Standing data relating to GSP Groups and Clock Changes, which are relevant both to SSR and to Daily Profile Production.	Clock Time Change, Data Collector, Data Collector in GSP Group, GSP Group, ISR Agent Appointment
D4	SSR Runs	Data related to controlling runs of the SSR system.	SSA Settlement Run, SSR Run In GSP Group, SSR Run Type, Supplier Data Aggregation, Supplier Data Aggregation Used In SSR Run

9. Function Descriptions and Events

Implemented By Process

Enter Calendar Details

9.1.6 Define Data Collectors

Description: This function allows details of Data Collectors and the GSP Groups for which they require daily Profile Coefficient totals to be defined and maintained.

Triggered by Event

Data Collector Appointed to GSP Group

Data Collector in GSP Group Deleted

Data Collector Deleted

Data Collector Details Entered

Data Collector Details Updated

Implemented By Process

Enter Data Collector Details

9.1.7 Define GSP Correction Scaling Factors

Description: This function allows the GSP Group Correction scaling factor for each consumption component to be maintained.

Triggered by Event

GSP Correction Scaling Factors Deleted

GSP Correction Scaling Factors Entered

GSP Correction Scaling Factors Updated

Implemented By Process

Maintain GSP correction scaling factors

9.1.8 Define GSP Group

Description: This function allows the list of valid GSP Group codes to be maintained and the periods of validity during which they are the responsibility of the ISR Agent.

Triggered by Event

GSP Group Deleted

GSP Group Entered

Implemented By Process

Enter GSP Group Details

9.1.9 Define Line Loss Codes

Description: This function allows the list of valid line loss factor codes to be maintained.

Triggered by Event

Line Loss Factor Codes Deleted

Line Loss Factor Codes Entered

Line Loss Factor Codes Updated

Implemented By Process

Maintain line loss factor codes

9.1.10 Define Profiles

Description: This function allows the details of Profile Classes and their corresponding profiles to be maintained.

Triggered by Event

Profile Class Deleted

Profile Class Entered

Profile Class Updated

Profile Deleted

Profile Entered

Profile Updated

Implemented By Process

Enter Profile Details

9.1.11 Define Settlement Timetable

Description: This function allows details of planned Settlements to be defined.

Triggered by Event

Settlement Deleted

Settlement Entered

Settlement Updated

Implemented By Process

Maintain Settlement Timetable

9.1.12 Define Standard Settlement Configurations

Description: This function allows details of Standard Settlement Configurations and their corresponding Measurement Requirements to be defined.

Triggered by Event

Standard Settlement Configuration Deleted

Standard Settlement Configuration Entered

Standard Settlement Configuration Updated

Time Pattern Assigned to Standard Sett Config

Time Pattern Deassigned From Standard Sett Config

Implemented By Process

Enter Settlement Configurations

Assign Time Patterns to Configurations

9.1.13 Define Supplier

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

Triggered by Event

Supplier Details Deleted

Supplier Details Entered

Supplier Details Updated

Implemented By Process

Maintain supplier details

9.1.14 Define Time Patterns

Description: This function allows time patterns and their associated standing data to be defined.

Triggered by Event

Teleswitch Register and Contact Rules Deleted

Teleswitch Register and Contact Rules Entered

Teleswitch Register and Contact Rules Updated

Time Pattern Regime Deleted

Time Pattern Regime Entered

Time Pattern Regime Updated

Clock Interval Deleted

Description: This function allows regression equations to be entered for each profile.

Triggered by Event

9.1.32 Specify Distributor for GSP Group

Description: This function allows distributors, and their assignments to GSP Groups, to be maintained. This data is used to validate the incoming line loss data

Triggered by Event

Distributor Assigned to GSP Group

Distributor Assignment Deleted

Distributor Deleted

Distributor Entered

Distributor Updated

Implemented By Process

Specify Distributor for GSP Group

9.1.33 Specify Non-Half Hourly BM Unit Allocation

Description: This function is invoked by an ISRA user to allow details of Non-Half Hourly BM Unit Allocations to be maintained.

Triggered by Event

Non-Half Hourly BM Unit Allocation Entered

Non-Half Hourly BM Unit Allocation Updated

Non-Half Hourly BM Unit Allocation Deleted

Implemented By Process

Assign NHH BM Units

9.1.34 Specify Profile Class and SSC Combinations

Description: This function allows the valid combinations of Profile Class and Standard Settlement Configuration to be defined. It also allows the average split of annual consumption over each measurement requirement to be defined.

Triggered by Event

Standard Sett Config Assigned To Profile Class

Standard Sett Config Deassigned From Profile Class

Assignment to Profile Class Updated

Implemented By Process

Assign Configurations to Profile Classes

9.1.35 Specify Suppliers Trading in GSP Group

Description: This function allows the list of Suppliers trading in each GSP Group to be maintained. This data is used to validate that data for all Suppliers have been received from the data aggregators prior to performing Settlement calculations.

Triggered by Event

Supplier Finishes Trading in GSP Group

Supplier Starts Trading in GSP Group

Implemented By Process

Assign Suppliers to GSP Groups

9.1.36 Run SSR

Description: Performs a full Settlements or Reconciliation run. Validates all the required data is available, profiles the non-half hourly meters and produces a deemed take for each half hour for each Supplier

Triggered by Event

SSR Run Event

Implemented By Process

Profile SPM data

Aggregate Profiled Data

Adjust for Line Losses

Calc & Apply GSP Group Correction

Calculate Deemed Supplier Take

Adjust for Non Pool Generation Spill

Produce TUoS Report

Produce DUoS Report

Apply PSP, TLM and LRM to Deemed Take

Invoke Run

9.1.37 Load Disconnection Purchase Matrix Data

Description: This function validates the Disconnection Purchase Matrix from the Non-Half Hourly Data Aggregator and loads it into the SSR system.

Triggered by Event

DPM Data Available

Implemented By Process

Validate SPM Data

9.1.38 Load Mapping Data for HH Aggregated Metering Systems

Description: This function validates and loads mapping details between Line Loss Factor Class Id and SSC received from the Distributor relating to HH consumption.

Triggered by Event

Mapping Data for HH Aggregated Metering Systems Available

Implemented By Process

Validate Mapping Data for HH Aggregated Metering Systems

9.1.39 Load Aggregated Half Hour Disconnection Data

Description: This function validates the aggregated half hourly disconnection data from the HH Data Aggregator and loads it into the ISR system.

Triggered by Event

Aggregated Half Hour Disconnection Data Available

Implemented By Process

Validate HH Data

9.1.40 Maintain Final Dispute Expected Aggregation

Description: This function allows the ISR Agent to maintain a list of Data Aggregators from whom data is expected to be received in the event of a Dispute. The information is used to validate that the relevant Data Aggregators have provided data and to validate that a Data Aggregator is sending the correct type of aggregated data (Half Hourly or Non-Half Hourly) for the correct Supplier.

Triggered by Event

Specify Final Dispute Expected Aggregation

Implemented by Process

Maintain Final Dispute Expected Aggregation

9.2 Enquiry Descriptions

9.2.1 BM Unit Supplier Take Energy Volume Data Report Requested

Description: A BM Unit Supplier Take Energy Volume Data Report is requested by either a user or automatically following the completion of a Settlement Run.

9.2.2 EAC Data Extract

Description: The operator requests an extract of daily Profile Coefficient totals for a particular settlement day, for use in calculating annualised advances and EACs.

9.2.3 SSR Report Run

Description: The operator of the SSR system requests the production of Supplier reports for a settlement day.

9.2.4 Supplier Profile Reports

Description: The ISR Agent requests production of profiling reports for a Settlement Day.

9.2.5 Standing Data Update Report

Description: The ISR Agent requests a Standing Data Update Report with reference to either an individual Supplier or for all Suppliers, over a specified timeframe of user defined change dates.

9.3 Entity Event Matrix - Supplier Settlement & Reconciliation

Note that the following entities are operational masters which are shown on the data model for purposes of logical completeness, but have no actual processing associated with them, and hence no events: Data Aggregator, Distributor, and Settlement Class.

Note that the following entities are read-only, because no requirement to update them has been identified: Consumption Component Class and SSR Run Type. The matrix shows them as being created by a dummy System Installation event.

9.4 Entity Event Matrix - Daily Profile Production

Note that the entity Teleswitch Contact 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.

9.5 System Events

Actual Noon Temperature Entered

The actual noon temperature is entered for a Settlement Day and GSP Group.

Aggregated Half Hour Data Available

The half hourly data aggregator makes a file of data available for a particular GSP Group, supplier and settlement day.

Aggregator Assigned to GSP Group

An aggregator (either half hourly or non-half hourly) is specified for a particular GSP Group and supplier. This event will occur, for example, at the start of trading in April 1998; or when a supplier changes the aggregator appointed for a GSP Group.

Aggregator Assignment Deleted

The link between an aggregator and a GSP Group is removed from the system. This event will occur, for example, when an assignment is entered in error; or when an assignment is subject to the Archive Criteria.

Archive Daily Profiles

The decision is taken to archive all the profile production data relating to a settlement day which is subject to the Archive Criteria.

Archive SSR Daily Data

The decision is taken to archive all the Supplier Settlement and Reconciliation data relating to a settlement day which is subject to the Archive Criteria.

Assignment to Profile Class Updated

The data for an existing combination of profile class and standard settlement configuration is updated.

BM Unit for Supplier and GSP Group Deleted

The user selects a Supplier and a GSP Group, and then selects an existing association to a BM Unit to be removed. The instance of BM Unit for Supplier in GSP Group is physically deleted along with any dependent occurrences of Non-Half Hourly BM Unit Allocation. Any GSP Group and Supplier combination can be chosen, not just those Suppliers trading in a GSP Group.

BM Unit for Supplier and GSP Group Entered

A BM Unit is entered for a Supplier in a GSP Group.

BM Unit for Supplier and GSP Group Updated

The user selects a Supplier and a GSP Group, and then selects an existing association to a BM Unit to be updated.

BM Unit Registration Data Loaded

A file containing BM Unit Registration Data is loaded.

Clock Change Deleted

A clock change is deleted from the system. This may be because it was originally entered in error; or it is subject to the Archive Criteria.

Clock Change Entered

A new clock change is entered onto the system.

Clock Change Updated

The details of a clock change already defined to the system are updated.

Clock Interval Deleted

One of the clock intervals defined for a time pattern regime is deleted. Typically this event would occur only if a clock interval was wrongly entered by the operator. The normal method of deleting a clock interval would be to delete the entire time pattern regime when it was no longer required.

Clock Interval Entered

One of the clock intervals for a time pattern regime is entered onto the system.

Data Collector Appointed to GSP Group

A Data Collector becomes active in a GSP Group, and therefore requires daily profile coefficient totals for that GSP Group.

Data Collector in GSP Group Deleted

A Data Collector ceases to be active in a GSP Group, and therefore no longer requires daily profile coefficient totals for that GSP Group.

Data Collector 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 is no longer active and therefore no longer requires daily profile coefficient totals.

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.

Day Type Specified for Settlement Day

The operator specifies the Day Type and Season Id for a Settlement Day.

Distributor Deleted

A distributor is removed from the system.

Distributor Entered

A new distributor is entered into the system.

Distributor Updated

Details of an existing distributor are updated.

Distributor Assigned to a GSP Group

A distributor is assigned to a GSP Group. This event will occur, for example, at the start of trading in April 1998 and when they begin to operate in a new GSP Group.

Distributor Assignment Deleted

The link between a distributor and a GSP Group is removed from the system. This event will occur, for example, when an assignment is entered in error.

DPM Data Available

A file of aggregated disconnected annual consumption data becomes available from a non-half hourly aggregator system.

GSP Correction Scaling Factors Deleted

The GSP Correction Scaling factor for a particular component and period of time is removed from the system. This event will occur, for example, when a scaling factor is entered in error; or when the period of time to which the scaling factor applies is subject to the Archive Criteria.

GSP Correction Scaling Factors Entered

A new GSP Correction Scaling Factor is entered on the system. This event will occur when the scaling factor for a consumption component changes.

GSP Correction Scaling Factors Updated

The value of a GSP Correction scaling factor is amended (without the period it covers changing). This event is only likely to occur if the value was originally entered in error.

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 may occur both at the start of trading, and subsequently if GSP Groups are reorganised.

GSP Group Take Available

A file of GSP Group Take data becomes available from the existing settlement system.

Line Loss Factor Codes Deleted

A line loss factor class code is removed from the system. This event will occur, for example, when the class was entered in error; or when it is subject to the Archive Criteria.

Line Loss Factor Codes Entered

A new line loss factor class is defined to the system.

Line Loss Factor Codes Updated

Details of an existing line loss factor class are amended.

Line Loss Factors Available

The file of line loss factor values for a Distributor becomes available from the relevant Host PES Distribution Business.

Mapping Data for HH Aggregated Metering Systems Available

The mapping information between LLFC and SSC for a Distributor relating to HH consumption becomes available from the relevant Host PES Distribution Business. Market Domain Data Complete Set Loaded

Settlement Day and Line Loss Factor Class details read from the file of published Market Domain Data prepared by the Market Domain Data Agent is loaded into the ISR system.

Non Half Hourly BM Unit Allocation Entered

A Non-Half Hourly BM Unit Allocation is entered.

Non Half Hourly BM Unit Allocation Updated

A Non-Half Hourly BM Unit Allocation is updated.

Non Half Hourly BM Unit Allocation Deleted

A Non-Half Hourly BM Unit Allocation is deleted.

Pool Market Domain Data Loaded

A file of Standard Settlement Configurations and associated data prepared by the Market Domain Data Agent is loaded into the ISR system.

Profile Class 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 is subject to the Archive Criteria.

Profile Class Entered

A new profile class is entered onto the system.

Profile Class Updated

Details of an existing profile class are updated.

Profile Deleted

A profile is removed from the system. This event will occur, for example, when a profile is entered in error; or when the profile is subject to the Archive Criteria.

Profile Entered

A new profile is entered onto the system.

Profile Updated

Details of an existing profile are updated.

Profiling Run

The ISR Agent requests that profiles are calculated for a given Settlement Day.

Regression Equation Deleted

A regression equation is removed from the system. This event will occur, for example, when the regression equation is subject to the Archive Criteria.

Regression Equation Entered

A file of regression equation data is loaded onto the system.

Regression Equation Updated

A file of regression equation data is reloaded, overwriting the original data.

Set of Average Consumption Fractions 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 is subject to the Archive Criteria.

Set of Average Consumption Fractions Entered

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

Set of Average Consumption Fractions Updated

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

Settlement Deleted

Details of a planned Settlement are removed from the system.

Settlement Entered

A planned Settlement is defined on the system.

Settlement Timetable Loaded

Details of the overall Settlement Timetable and the Settlement Codes, Planned SSR Run Dates and Payment Dates for each Settlement Date prepared by the Market Domain Data Agent is loaded into the ISR system.

Settlement Updated

Details of a planned Settlement are updated.

SPM Data Available

A file of aggregated annual consumption data becomes available from a non-half hourly aggregator system.

SSR Run Event

The operator of the SSR system requests that an SSR Run be carried out for a particular settlement day and selected GSP Groups.

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 is subject to the Archive Criteria.

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 is subject to the Archive Criteria.

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.

Sunset Data Loaded

A file of sunset times for a GSP Group are loaded into the system.

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 is subject to the Archive Criteria.

Supplier Details Entered

Details of a new supplier are entered onto the system.

Supplier Details Updated

Details of an existing supplier are updated.

Supplier Finishes Trading in GSP Group

A supplier indicates that it is no longer trading in a particular GSP Group (and will therefore not be submitting aggregated data).

Supplier Starts Trading in GSP Group

A supplier indicates that it has started trading in a particular GSP Group (and will therefore be submitting aggregated data).

System Installation

Dummy event, representing the setting up of each instance of the system to include fixed data such as SSR Run Types.

Teleswitch Contact Interval Deleted

A Teleswitch contact interval is removed from the system.

Teleswitch Contact Interval Entered

Details of a new Teleswitch contact interval are entered onto the system.

Teleswitch Contact Interval Updated

Details of an existing Teleswitch contact interval are updated.

Teleswitch Switching Times Available

A file of Teleswitch contact intervals (Teleswitch switching times) prepared by the Teleswitch Agent is loaded into the ISR system.

Teleswitch Register and Contact Rules Deleted

A Teleswitch register rule and its associated Teleswitch contact rule(s) are removed from the system.

Teleswitch Register and Contact Rules Entered

Details of a new Teleswitch register rule and its associated Teleswitch contact rule(s) are entered onto the system.

Teleswitch Register and Contact Rules Updated

Details of an existing Teleswitch register rule and its associated Teleswitch contact rule(s) 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.

Time Pattern Regime Deleted

A time pattern regime is removed from the system. This event will occur, for example, when a time pattern regime is entered in error; or when the time pattern regime is subject to the Archive Criteria.

Time Pattern Regime Entered

A new time pattern regime is entered onto the system.

Time Pattern Regime Updated

Details of an existing time pattern regime are updated.

10. USER Roles

10.1 User Catalogue

1. The User Catalogue defines all on-line Users of the required system and the tasks associated with them.

Job Title

Job Activities Description

ISR Agent

Administrator of ISRA system for specified GSP Groups. The activities of this job cover all aspects of the operation of these GSP Groups. This includes the following:

maintaining standing data for the system
monitoring and support of the operation of the system
monitoring the support of the operation of the interfaces
system monitoring for performance and capacity
checking the collection of data for a run
checking the electronic collection of daily data
entering manually collected data
initiating Settlement runs
initiating Reconciliation runs
initiating reporting runs
managing audit, security and control

managing backup, recovery and archive

10.2 User Roles

1. The User Roles define, at the highest level, the different roles performed, the jobs performed and the job descriptions.

User Role	Job Title	Activities
ISRA Operator	ISR Agent	checking the collection of data for a run checking the electronic collection of daily data entering manually collected data initiating Settlement runs initiating Reconciliation runs initiating reporting runs
ISRA System Manager	ISR Agent	system monitoring for performance and capacity managing audit, security and control managing backup, recovery and archive
ISRA Operations Supervisor	ISR Agent	maintaining standing data for the system monitoring and support of the operation of the system monitoring the support of the operation of the interfaces

The User Role Function Matrix will be available after the Logical Design stage.

10.3 Organisational Roles

1. The New Electricity Trading Arrangements identify a number of ‘roles’ which may be undertaken by different organisations. These are not users of the ISRA system, but they are related to ISRA in that they are external entities and as such sources or recipients of data from ISRA.

1998 Role	Organisation	NETA Functions
ISR Agent	ISR Agent(s)	Daily Profile Production Initial Settlement Calculation Reconciliation Calculation
Non-HH Data Collector	Host PES (to 31/3/2000) Data Collectors	Data Collection Data Processing EAC Calculation Meter Advance Derivation
Non-HH Data Aggregator	Host PES (to 31/3/2000) Data Aggregators	Supplier Data Aggregation
HH Data aggregator	Data Aggregators	HH Data Aggregation
Settlement Administration Agent (SAA)	IMServ	Determination of energy information, imbalance and balancing and total mechanism charges and payments.
Central Data Collection Agent	IMServ	Administration of the Central Data Collection System
Profile Administrator	Electricity Association Services Ltd (EASL)	Load research and provision of Regression Equations
PRS Agent	PRS Agent(s)	Administration and operation of PRS
Supplier	Host REC Energy Supplier Non-Host Energy Supplier	Energy Supplier
Transmission Use of System Administrator (TUoS)	NETSO	Calculation of Transmission Use of System charges
ISRA Auditor	Pool Auditor	Examining database data Examining exception and log runs Examining audit trails
Market Domain Data Agent	ISR Agent	Maintenance and distribution of Market Domain Data
Electricity Pool Administrator (Pool)	Chief Executive’s Office	Provision of Pool statistics
Teleswitch Agent	Electricity Association Services Ltd (EASL)	Provision of Teleswitch Data Service
Central Registration Agent	IMserv	Administration and operation of the Central Registration System.
Distributor	Distribution Business	Distributes electricity

APPENDIX A: Definition of Terms

This section is now in the 1998 Programme Glossary of Terms, reference 10.

APPENDIX B: Data Catalogue

This section contains a brief description of each data item or attribute used within the Data Flow Model and the Logical Data Model. The full definition of each data item will be available after the Logical Design stage.

AA/EAC Indicator

Bi-state indicator defining, for a non-half hourly metered Consumption Component Class, whether the profiled consumption is based on an Annualised Advance or an Estimated Annual Consumption.

Actual Noon Temperature

The arithmetic average of noon temperature as measured at representative weather stations within the GSP Group area.

Actual/Estimated Indicator

Bi-state indicator showing whether a Consumption Component Class pertains to actual or estimated half hourly meter data.

Aggregated Supplier Consumption

The sum of the Supplier Consumption for a GSP Group prior to GSP Group Correction. Values are unsigned.

Aggregated BM Unit Energy

The total consumption for a BM Unit for Supplier in GSP Group within a Consumption Component Class within a Settlement Period before GSP Group Correction is applied.

Aggregated BM Unit Line Losses

The total line and transformer loss incurred transferring energy between the GSPs and customers for a BM Unit for Supplier in GSP Group within a Consumption Component Class within a Settlement Period before GSP Group Correction is applied

Aggregated Supplier Line Loss

The total line and transformer loss incurred transferring energy between the GSPs and customers for a Supplier within a GSP Group. Values are unsigned.

Average Fraction of Yearly Consumption

The estimated fraction of consumption for metering systems in the Profile Class and Standard Settlement Configuration which belongs to the particular Measurement Requirement.

Blanket NHH Aggregation Indicator

An indicator showing whether all active NHH Data Aggregators should be included in a Final Dispute Expected Aggregation.

BM Unit Id

The basic unit of trade for Balancing Mechanism action. A BM Unit is the smallest number of Meter Points for which metered data is available to the Settlement Administration Agent.

CDCA Set Number

The unique set number generated for a CDCA settlement run within a Settlement Day. This data item replaces data item ‘SSA Settlement Run Number’ for Settlement Days from the start of the NETA. For backwards compatibility, the attributes and logical format of the SSA Settlement Run Number are retained for this data item.

CDCA Settlement Date

The Settlement Date for which a CDCA settlement run is performed. This data item replaces data item ‘SSA Settlement Date’ for Settlement Days from the start of the NETA. For backwards compatibility, the attributes and logical format of the SSA Settlement Date are retained for this data item.

CDCA Extract Number

The CDCA Extract Number used as a basis of the Settlement Run. This data item replaces data item ‘CDCS Extract Number’ for Settlement Days from the start of the NETA. For backwards compatibility, the attributes and logical format of the CDCS Extract Number are retained for this data item.

Change Date

The date on which clocks go forward or back to cater for daylight saving time.

Consumption Component Class Id

The unique identifier for a Consumption Component Class.

Consumption Component Indicator

A tri-state data item which shows whether a Consumption Component Class can be categorised by:

a) Metering System Specific Line Loss,

b) Class Specific Line Loss,

c) Consumption.

Corrected BM Unit Energy

For a half hour period, the amount of energy attributed to a BM Unit for Supplier In GSP Group within a Consumption Component Class after GSP Group Correction has been applied.

Corrected Supplier Consumption

For a half hour period, the amount of energy attributed to a Supplier, within a Consumption Component Class, after GSP Group Correction has been applied.

Corrected BM Unit Line Losses

For a half hour period, the deemed line loss which has been attributed a BM Unit for Supplier in GSP Group within a Consumption Component Class.

Corrected Supplier Line Loss

For a half hour period, the deemed line loss which has been attributed to a Supplier, within a Consumption Component Class.

Daily Corrected BM Unit Energy

A derived item for the daily Corrected BM Unit Energy for a BM Unit for Supplier in GSP Group within a Consumption Component Class for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a day) Corrected BM Unit Energy.

Daily Corrected BM Unit Line Losses

A derived item for the daily Corrected BM Unit Line Losses for BM Unit for Supplier in GSP Group within a Consumption Component Class for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a day) Corrected BM Unit Line Losses.

Daily Corrected Supplier Deemed Take

A derived item for the daily corrected supplier Deemed Take for a Supplier in a GSP Group, for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a Settlement Day) Period Corrected Supplier Deemed Take.

Daily Uncorrected Period BM Unit Total Allocated Volume

A derived item for the daily uncorrected BM Unit total allocated volume for a BM Unit for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a day) Uncorrected Period BM Unit Total Allocated Volume.

Daily Non-Corrected Supplier Deemed Take

A derived item for the daily non-corrected supplier Deemed Take for a Supplier in a GSP Group, for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a Settlement Day) Period Non-Corrected Supplier Deemed Take.

Daily Profile Coefficient

The daily totalled coefficient after the following adjustment has been made: Daily adjustment (different for each GSP Group) according to daily profile variables from the Authorised Temperature Provider i.e. Noon Effective Temperature, Time of Sunset and Type of Day (Sunday, Bank Holiday, etc.)

Daily Profiled SPM Total Annualised Advance

A derived data item created by summing the “Profiled SPM Total Annualised Advance” for a Settlement Class over all Settlement Periods.

Daily Profiled SPM Total EAC

A derived data item created by summing all “Profiled SPM Total EAC” and “Profiled SPM Total Unmetered Consumption” for a Settlement Class over all Settlement Periods.

Daily Supplier Deemed Take

A derived item for the daily supplier Deemed Take for a Supplier in a GSP Group, for a Settlement Day. It is derived from:

Sum (over all Settlement Periods in a Settlement Day) Period Supplier Deemed Take.

Daily Supplier Purchase Total

A derived item for the daily total purchases by a Supplier in a GSP Group, for a Settlement Day, derived from:

Sum (over all Settlement Periods in a Day) Period Supplier Purchase Total.

Data Aggregation Run Number

The unique number allocated to a data aggregation run by a Data Aggregator.

Data Aggregation Type

An indicator of what type of aggregation a particular Data Aggregator is performing - half hourly or non-half hourly.

Data Aggregator HH MSID Count

The count of half hourly metering systems by Consumption Component Class and Supplier. The count is supplied by the Data Aggregator with which those Metering Systems are registered.

Data Aggregator Id

The unique national identifier for a Data Aggregator company.

Data Collector Id

The unique national identifier for a Data Collection company.

Data Collector Name

The name of a Data Collection company.

Date and Time Sent {Aggregation Run}

The date and time at which a Data Aggregator company sends Data Aggregation Run data to the ISRA system.

Date (Midnight to Midnight UTC)

A calendar date, covering 24 hours from midnight to midnight in UTC.

Day of the Week Id

The identifier for a day of the week.

Day Type Id

System identifier for the type of settlement day, e. g.:

Saturday

Sunday

Weekday

Direction Of Energy Flow

A bi-state data item indicating whether the energy flow is import or export. Energy consumption is (Active) Import or Non-Pooled Generation is (Active) Export.

Distributor Id

The unique national identifier of a Distributor.

Distributor Name

Name to expand data item Distributor Id

Effective From Date {DCIGG}

The inclusive calendar date from which a Data Collector begins operating in a GSP Group.

Effective From Settlement Date {FDEDA}

The inclusive Settlement Date from which a Data Aggregator is expected to submit data in relation to a Dispute Final Run.

Effective From Date {IAA}

The inclusive calendar date from which ISR Agent Appointment begins for a GSP Group.

Effective From Settlement Date {AFOYCS}

The inclusive Settlement Date from which an Average Fraction of Yearly Consumption Set becomes effective.

Effective From Settlement Date {BMUIGG}

The inclusive Settlement Date from which a BM Unit for a Supplier and GSP Group combination becomes effective.

Effective From Settlement Date {DAIGG}

The inclusive Settlement Date from which a Data Aggregator begins operating in a GSP Group.

Effective From Settlement Date {GGD}

The inclusive Settlement Date from which a Distributor begins operating for a GSP Group.

Effective From Settlement Date {LLFC}

The inclusive Settlement Date from which a Line Loss Factor Class becomes effective.

Effective From Settlement Date {NHHBMUA}

The inclusive Settlement Date from which a Valid Settlement Configuration Profile Class is allocated to a BM Unit for Supplier in GSP Group.

Effective From Settlement Date {PSET}

The inclusive Settlement Date from which a Profile Regression Equation Set becomes effective.

Effective From Settlement Date {PROF}

The inclusive Settlement Date from which a Profile becomes effective.

Effective From Settlement Date {SIGG}

The inclusive Settlement Date from which a Supplier begins trading in a GSP Group.

Effective From Settlement Date {VSCPC}

The inclusive Settlement Date from which a Valid Settlement Configuration and Profile Class combination becomes effective.

Effective Time (UTC)

The time at which a particular Teleswitch contact is instructed to change state, within all teleswitched metering systems in a particular Teleswitch Group

Effective To Date {DCIGG}

The inclusive calendar date after which a Data Collector ceases to operate in a GSP Group.

Effective To Settlement Date {FDEDA}

The inclusive Settlement Date from which a Data Aggregator is no longer expected to submit data in relation to a Dispute Final Run.

Effective To Date {IAA}

The inclusive calendar date at which ISR Agent Appointment begins for a GSP Group.

Effective To Settlement Date {AFOYCS}

The inclusive Settlement Date after which an Average Fraction of Yearly Consumption Set ceases to be valid.

Effective To Settlement Date {BMUIGG}

The inclusive Settlement Date after which a BM Unit ceases to operate for a Supplier and GSP Group combination.

Effective To Settlement Date {DAIGG}

The inclusive Settlement Date after which a Data Aggregator ceases to operate in a GSP Group.

Effective To Settlement Date {GGD}

The inclusive Settlement Date after which a Distributor ceases to operate for a GSP Group.

Effective To Settlement Date {LLFC}

The inclusive Settlement Date after which a Line Loss Factor Class ceases to be valid.

Effective To Settlement Date {NHHBMUA}

The inclusive Settlement Date after which a Valid Settlement Configuration Profile Class is no longer allocated to a BM Unit for Supplier in GSP Group.

Effective To Settlement Date {PROF}

The inclusive Settlement Date after which a Profile ceases to be valid.

Effective To Settlement Date {SIGG}

The inclusive Settlement Date after which a Supplier ceases to operate in a GSP Group.

Effective To Settlement Date {VSCPC}

The inclusive Settlement Date after which a valid combination of Settlement Configuration and Profile Class ceases to be used.

End Date and Time {Tele-switch Contact Interval}

The date and time of day on which a Tele-switch Contact Interval ends.

End Day

The day of the month, expressed numerically, on which the end of an ‘on’ clock interval (by ISR definition) falls.

End Month

The month in which an ‘on’ clock interval (defined by ISR) ends.

End Time

A time at which time-switched metering system registers associated with a Time Pattern Regime are instructed to switch OFF.

End Time {Tele-switch Interval}

A time at which teleswitched metering system registers associated with a Time Pattern Regime are instructed to switch OFF.

GMT Indicator

An indicator showing whether a Time Pattern Regime records switching times in GMT or clock (local) time. Values are: Y - times recorded in GMT; N- times recorded in local time.

GMT Time

The time according to Greenwich Mean Time.

Group Average Annual Consumption

The estimated average annual consumption for metering systems in a Profile Class for a GSP Group.

GSP Group Correction Factor

The factored weighting that is applied to selected Consumption Component Classes to ensure that GSP Group Deemed Take is the same as the Group Take measured at GSP level.

GSP Group Correction Scaling Factor

A factor (S) which can be applied to the GSP Group Correction Factor to define to what degree the GSP Group Correction Factor will be applied to a particular Consumption Component Class:

S=0 - GSP Group Correction Factor not applied;

S=1 - GSP Group Correction Factor applied;

0<=S<=1 - GSP Group Correction Factor partially applied;

S>1 - GSP Group Correction Factor over-applied.

GSP Group Id

The unique national identifier for a particular GSP Group.

GSP Group Name

Name to expand data item GSP Group Id.

GSP Group Take

The energy consumption for the GSP Group measured at the Grid Point level by meter.

Line Loss Factor

The multiplicative factor applied to a customer's consumption to convert it into its estimated original consumption at the GSP level i.e. before transformer and line losses.

Line Loss Factor Class Id

The identifier for a class of Line Loss which applies to a group of metering systems.

Low Register Profile Coefficient

A profile coefficient which, when multiplied by an estimate of annual consumption, produces an estimate of consumption for the low register of a metering system.

Market Participant Role Code

The code which identifies the role which a Market Participant performs in the market.

Measurement Quantity Id

The unique identifier for a quantity which may be measured (e.g. consumption or generation).

Metered/Unmetered Indicator

Bi-state indicator showing whether the Consumption Component is for a metered supply or unmetered supply.

Metering System Specific Line Loss Factor Class Id

An indicator to show whether a Line Loss Factor Class is a general class or metering system specific.

MRPC Supplier Profiled AA

A derived item created by summing over all Settlement Periods in a day, over all Suppliers in a GSP Group, the Profiled SPM Total Annualised Advance for all Suppliers for a Valid Measurement Requirement Profile Class.

MRPC Supplier Profiled EAC

A derived item created by summing over all Settlement Periods in a day, over all Suppliers in a GSP Group, the Profiled SPM Total EAC for all Suppliers for a Valid Measurement Requirement Profile Class.

MRPC Supplier Profiled Unmetered Consumption

A derived item created by summing over all Settlement Periods in a day, over all Suppliers in a GSP Group, the Profiled SPM Total Unmetered Consumption for all Suppliers for a Valid Measurement Requirement Profile Class.

MSID Count

The count of metering systems for each Consumption Component Class (CCC) for each Supplier in a GSP Group by Settlement Period. This count aggregates the other MSID counts.

Noon Effective Temperature

This is the weighted average of the actual noon (clock time) temperatures for the settlement day and the previous two settlement days.

Normal Register Profile Coefficient

A profile coefficient which, when multiplied by an estimate of annual consumption, produces an estimate of consumption for the normal register of a metering system.

Payment Date

The date on which payment must be made for Suppliers’ energy purchases.

Period BM Unit Total Allocated Volume

A derived item detailing total energy allocated to a BM Unit for a half hour period of a Settlement Day. Derived by:

Summing Corrected BM Unit Energy and Line Losses across Consumption Component Classes for a BM Unit.

Period Corrected Supplier Deemed Take

A derived item for the deemed take, attributable to supplies which are subject to group correction, by a Supplier in a GSP Group, for a half hour period of a Settlement Day. The figure is derived by subtracting the Period Non-Corrected Supplier Deemed Take from the Period Supplier Deemed Take. For this subtraction, external data formats are used to ensure that the relation Period Corrected Supplier Deemed Take + Period Non-Corrected Supplier Deemed Take = Period Supplier Deemed Take holds exactly.

Period Non-Corrected Supplier Deemed Take

A derived item for the deemed take, attributable to supplies which are not subject to group correction, by a Supplier in a GSP Group, for a half hour period of a Settlement Day. Derived by:

Sum Aggregated Supplier Consumption and Line Loss across Consumption Component Classes which are not subject to Group Correction.

Period Profile Coefficient Value

A profile coefficient which, when multiplied by an estimate of annual consumption, produces an estimate of consumption for a metering system register.

Period Register On State Indicator

An indicator showing whether metering system registers associated with a Time Pattern Regime are to be treated as ON or OFF in a Settlement Period.

Period Supplier Deemed Take

The deemed take at GSP level for a Supplier during a half hour period.

Period Supplier Purchase Total

The financial liability (money owed) by a Supplier for energy used within a half hour period.

Planned SSR Run Date

The date on which an SSR system run is scheduled for a particular Settlement Day and GSP Group.

Pool Member Id

An identifier which uniquely references a member of the Electricity Pool of England and Wales.

Post Change Local Time

The local clock time after a clock change.

Profile Class Description

A description of the Profile Class for a given Profile Class Id.

Profile Class Id

The unique identifier for the Profile Class which holds the profile to be applied to a non-half hourly metered set of supplies belonging to that class.

Profile Description

A description of the profile in use.

Profile Id

A unique identifier for a profile within a Profile Class.

Profile Production Run Number

A unique identifier for a particular Profile Production Run.

Profile Settlement Periods

The number of Settlement Periods that a profile covers.

Profiled SPM Consumption

A derived data item created by summing “Profiled SPM Total Annualised Advance”, “Profiled SPM Total EAC” and “Profiled SPM Total Unmetered Consumption” for a Settlement Class and Settlement Period.

Profiled SPM Total Annualised Advance

The profiled Annualised Advance in a Settlement Period for a Supplier in a GSP Group by Settlement Class and Settlement.

Profiled SPM Total EAC

The profiled Estimated Annual Consumption in a Settlement Period for a Supplier in a GSP Group by Settlement Class and Settlement.

Profiled SPM Total Unmetered Consumption

The profiled unmetered consumption in a Settlement Period for a Supplier in a GSP Group by Settlement Class and Settlement.

Regression Coefficient

A coefficient or variable which specifies how consumption for a Profile varies, and is substituted into a Regression Equation.

Regression Coefficient Type

The valid types of Regression Coefficient. The initial set are:

Time of Sunset (Time of Sunset)² Noon Effective Temperature Day of Week 1 Day of Week 2 Day of Week 3 Day of Week 4 Constant

Scottish Day Type Id

System identifier for the type of Settlement Day applicable to Scotland only.

Season Id

The unique identifier given to a specified Season.

Settlement Code

A code which, together with the Settlement Date, identifies a Settlement published in the Pool's Settlement Timetable. It identifies the type of Settlement. Initial values may be Final Initial Settlement, First Reconciliation, Second Reconciliation, Third Reconciliation, Final Reconciliation, Dispute, Final Dispute.

Settlement Code Description

The description of a Settlement Code, for example “Final Initial Settlement”.

Settlement Date

The date on which energy is deemed to be used and must be later settled for. Also known as the Trading Day.

Settlement Period Id

The identifier - unique for a particular day - for a half hour trading period. A number between 1 and 50.

Settlement Period Label

The end time of a Settlement Period e.g. 00:30, 14:00. Where there is a backward Clock Change, the same Settlement Period will occur twice in one Settlement Day. The second occurrence of the Settlement Period end time is denoted with the suffix ‘a’ e.g. 01:30a.

SPM Default EAC MSID Count

The number of default EACs that had to be used in the calculation of a Supplier Purchase Matrix's SPM 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 SPM Total Unmetered Consumption.

SPM Total AA MSID Count

The count of non-half hourly metering systems whose consumption is based on an Annualised Advance and which are not de-energised with zero Annualised Advance for all Settlement Registers. It is for a given Supplier and Settlement Class within a GSP Group for a Settlement Run. The count is supplied by the Data Aggregator with which those Metering Systems are registered.

SPM Total Annualised Advance

The sum of Annualised Advances for a cell of the Supplier Purchase Matrix.

SPM Total Annualised Advance Report Value

The sum of Annualised Advances for a cell of the Supplier Purchase Matrix.

SPM Total All EACs

A derived data item created by summing the “SPM Total EAC” and “SPM Total Unmetered Consumption” for a Settlement Class.

SPM Total EAC

The sum of Estimated Annual Consumptions for a cell of the Supplier Purchase Matrix.

SPM Total EAC MSID Count

The count of non-half hourly metering systems whose consumption is based on an Estimated Annual Consumption. It is for a given Supplier and Settlement Class within a GSP Group for a Settlement Run. The count is supplied by the Data Aggregator with which those Metering Systems are registered.

SPM Total Unmetered Consumption

The sum of the estimated annual unmetered consumption for a cell of the Supplier Purchase Matrix.

SPM Total Unmetered MSID Count

The count of non-half hourly Unmetered Systems. It is for a given Supplier and Settlement Class within a GSP Group for a Settlement Run. The count is supplied by the Data Aggregator with which those systems are registered.

SSR Run Date

The date on which an SSR system run is done for a particular Settlement Day and GSP Group.

SSR Run Number

The unique identifier which the system creates for a SSR run.

SSR Run Type Id

The type of run to which an SSR run belongs. Proposed types will be the same as for Settlement Code.

Standard Settlement Configuration Desc

Description of a logical non-half hourly metering configuration supported by the settlement process.

Standard Settlement Configuration Id

A unique identifier for a logical non-half hourly metering configuration supported by the settlement process.

Standard Settlement Configuration Type

Identifies whether the Standard Settlement Configuration should be used for Import or Export Metering Systems.

Start Date and Time {Tele-switch Contact Interval}

The date and time of day on which a Tele-switch Contact Interval starts.

Start Day

The inclusive day of the month, expressed numerically, on which an ‘on’ clock interval (by ISR definition) commences.

Start Month

The month in which an ‘on’ clock interval (defined by ISR) commences.

Start of Day Tele-switch On Indicator

Identifies whether a particular Teleswitch contact is closed (on) or open (off) at 00:00 UTC on a particular day, within all teleswitched metering systems in a particular Teleswitch Group. Valid values are as for data item Tele-switch Contact State.

Start Time

A time at which time-switched metering system registers associated with a Time Pattern Regime are instructed to switch ON.

Start Time {Tele-switch Interval}

A time at which teleswitched metering system registers associated with a Time Pattern Regime are instructed to switch ON.

Sunset Variable

The number of minutes that the sun sets after 1800 hours GMT (negative if before). This data item is derived from “Time of Sunset”.

Supplier Id

The unique national identifier for a Supplier of electricity.

Supplier Name

The name of an electricity supplier.

Switched Load Indicator

A bi-state indicator which indicates whether metering system registers associated with the Measurement Requirement are used for switching loads.

Switched Load Profile Class Ind

Indicates whether or not the Profile Class can be used for metering systems with switched load.

Tele-switch Contact Code

One of the logical contacts within each tele-switched meter, as supported by the existing tele-switch telecommunications infrastructure. Existing values are A,B,C or D.

Tele-switch Contact Rule

Indicates whether a particular rule, identified by a Tele-switch Register Rule Id, is satisfied depending on the state of a particular tele-switch contact. Valid values are:

i) ‘0’ meaning the Tele-switch Register Rule Id is satisfied if the contact is off;

ii) ‘1’ meaning the Tele-switch Register Rule Id is satisfied if the contact is on.

Tele-switch Group Id

An identifier for one of the groups of Teleswitches controlled by a Teleswitch user.

Tele-switch On Indicator

Identifies whether a particular Teleswitch contact is closed (on) or open (off) immediately after switching state, within all teleswitched metering systems in a particular Tele-switch Group. Valid values are as for data item Tele-switch Contact State.

Tele-switch Register Rule Id

A number which distinguishes between the different rules associated with a Tele-switch Time Pattern Regime. The rules identify the switching relationships between tele-switch contacts and Settlement registers. The numbering of the rules defining the behaviour of each Time Pattern Regime is arbitrary, and decided at the time when the Market Domain Data is approved.

Tele-switch Switch Id

A dummy value to be used in the Standard Settlement Configuration Report. This is required for consistency with an earlier version of the report where there was an extra field defined. This takes a constant value of ‘A’.

Tele-switch Time Pattern Regime Id

The identifier for the teleswitched time pattern regime being used to calculate money owed for energy used by each customer.

Tele-switch User Id

The identifier for a user (an electricity supplier) of the Teleswitch control unit.

Tele-switch/Clock Indicator

An indicator showing whether a Time Pattern Regime is controlled by a Teleswitch or a timeswitch (clock).

Time of Sunset

The time of sunset for a GSP Group.

Time Pattern Regime Id

The identifier for the time pattern regime being used to calculate money owed for energy used by each customer.

Timestamp

The date and time associated with a GSP Group.

Transmission Loss Multiplier

The multiplication factor which converts MWh into energy actually supplied by the generating company(ies).

Transmission Losses Reconciliation Multiplier

For a Settlement Period in a Transmission Service Day, the scaling factor used in the determination of Transmission Services Reconciliation Demand.

Unadjusted Supplier Deemed Take

The deemed take at GSP level for a Supplier during a half hour period before any adjustments have been made during Non Pooled Generation spill processing.

Uncorrected Period BM Unit Total Allocated Volume

A derived item detailing total energy allocated to a BM Unit before group correction is applied for a half hour period of a Settlement Day. Derived by:

for a BM Unit, summing Aggregated BM Unit Energy and Line Losses across Consumption Component Classes

APPENDIX C: Logical Data Structure Notation

APPENDIX D: Data Flow Diagram Notation

APPENDIX E: Example of Profiling

The following example is intended to show how the processes of chunking and algorithmic profiling, as specified in the Elementary Process Descriptions in section 6, would work for a hypothetical tariff.

E.1 Hypothetical Tariff

Consider a hypothetical domestic tariff, of the Economy 7 type, as follows:

low register is time-switched on between 00:30-06:30 and 14:30-16:30 in every Settlement Day. A single normal register is on for the remainder of the day;
on average, 60% of consumption is Switched Load and 40% is Base Load.

E.2 Data Entered in ISR

In order to support this tariff, data would be set up in ISR as follows:

a Standard Settlement Configuration would be created for the tariff, and would be specified as being valid only for the Domestic Economy 7 Profile Class. Two Time Pattern Regimes would be created: one for the low register, with two Clock Intervals, and one for the normal register, with three Clock Intervals.
Load Research would provide regression equations for the Base and Switched Load components. (They could provide Switched Load equations for a variety of durations, but only the 16 Settlement Period one is relevant to this tariff).
The Average Fraction of Yearly Consumption for the low and normal registers would be specified, based on historical consumption data. In order to simplify the calculations, we will suppose (unrealistically) that Base Load consumption for this Profile Class is the same in all Settlement Periods. This implies that:

AFYC_low = .6 + .4 * (16/48) = .733

AFYC_normal = .4 * (32/48) = .267

E.3 Daily Calculation of Profiles

The Daily Profile Production process would calculate Profile Coefficients each Settlement Day as follows:

Process 2.3.1 would convert the Clock Intervals, specified as standing data, into Period Register On State Indicators for the low and normal registers for each Settlement Period.

Settlement Periods	Period Register On State Indicator for Low Register	Period Register On State Indicator for Normal Register
1 00:00 - 00:30	0	1
2-13 00:30 - 06:30	1	0
14-29 06:30 - 14:30	0	1
30-33 14:30 - 16:30	1	0
34-48 16:30 - 00:00	0	1

Process 2.3.2 would evaluate the regression equations:

Process 2.3.3 would calculate a combined profile as follows:
- Step (i) - Label the 16 low register on periods in sequence;
- Step (iii) - Move the 16 Switched Load Profile Coefficients into the on periods;
- Step (v) - Calculate H_pt as the sum of the on period Base Load Profile Coefficients over the sum of the off period Base Load Profile Coefficients. Given our assumption that the Base Load profile is flat, H_pt would be 16/32 = 0.5.
- Step (vi) - Calculate the fractions of consumption corresponding to Base and Switched Load:

Base Fraction = 1.5 * 0.267 = 0.4

Switched Fraction = .733 - 0.5 * 0.267 = 0.6

Of course, in our made-up example we already knew the fractions of Base and Switched Load. However, the calculation illustrates the use of Hpt to convert from low and normal registers to Base and Switched Load.

Low and Normal Register profile coefficients are then produced by combining the Base and Switched Load profiles.

• Process 2.3.4 would split the low and normal register profiles into low and normal register chunks, renormalising the area of each chunk by dividing by AFYC.

APPENDIX F: Basis for Capacity Requirement Estimates

This appendix contains the detailed assumptions upon which the mandatory and desirable capacity requirements specified in section 5 were based.

The following table shows, for each entity in the Logical Data model:

the number of occurrences expected initially
the maximum expected volume of occurrences
the event, time unit, or entity on which the occurrences are based
the source of the estimate
the basis for the estimate.

It is not proposed to update this table beyond Issue 1.1 of the URS.

Entity	Initial Volumes		Maximum Volumes	Per	Source	Basis / Reason	Actual/ Est
Aggregated Supplier DA Period Consumption	18,096		960 million	SSR Run	URS Team	1 per Supplier/DA combination, per Settlement Period, per Consumption Component Class, for HH CCCs (Initially 13 & max 25)	E
Aggregated Supplier Period Consumption	8,352		240,000	SSR Run	URS Team	1 per Supplier, per Settlement Period, per Consumption Component Class, for non HH CCCs (min 6 max 25)	E
Basic Period Profile Coefficients	432		19,200	Profile Production Run	URS Team	1 per Period per Profile	E
Clock Intervals	2,140		8,000	at any one time	URS Team	no of Measurement requirements * 2 (average no of Clock Intervals per Time Pattern Regime)	E
Clock Time Change	2		2	annum		current summer time changes	A
Combined Period Profile Coefficients	16,896		96,000	Profile Production Run	URS Team	Initial = 1 per Period per Valid Settlement Config Profile Class, for Switched load (economy 7 Profile Classes only) Max = 1 per period for 50% Valid SCPC	E
Consumption Component Class	19		50	at any one time	URS team	initial set up 19 CCCs	A
Daily Profile Coefficients		2,142	16,000	Profile Production Run	URS team	= No of Period PC Coefficients/ no of periods in a day	E
Daily Profile Parameters		1	1	Profile Production Run	URS team		E
Data Aggregators (HH)		29	2,000	GSP Group	Expert Group	Assume all DAs operate in all GSP Groups Initial = 1 per Supplier Max = 10 per Supplier	E
Data Aggregators (Non HH)		1	2,000	GSP Group	Expert Group	Assume all DAs operate in all GSP Groups Initial = Current PESs Max = 10 Per Supplier	E
Data Aggregator Registration		58	4,000	GSP Group	Expert Group	Initial = 2 for each Supplier Max = 20 for each Supplier	E
Data Collectors (Non HH)		1	2,000	GSP Group	URS Team	Assume all DAs operate in all GSP Groups Initial = Current PESs Max = 10 per Supplier	E
Day Types (Clock Intervals)		7	20	at any one time	URS Team	Initial = days of the week Max may include special days (e.g. Xmas)	E
Day Types (Regression equations)		7	20	at any one time	URS Team	Initial = days of the week Max may include special days (e.g. Xmas)	E
Distributor		1	5	GSP Group	OF		A
GSP Group		12	20	Nationally	URS Team	Initially will be up to 12	E
GSP Group Correction Factor		48	48	SSR Run	URS Team	1 per period	E
GSP Group Corr Scaling Factor		29	75	at any one time	URS Team	1.5 per Consumption Component Class	E
GSP Group Distributor		12	40	nationally	URS Team	Initial 1 per GSP Group, max 2 per GSP Group	E
GSP Group Take		48	48	SSA Settlement Run	URS Team	1 per period	A
Line Loss Factor Class		2	50	Distributor	Expert Group URS Team	Initial = 2 currently identified (HV & LV)	E
Line Loss Factors		96	2,400	Settlement Day	URS team	1 per Line Loss Class per Settlement Period	E
Measurement Quantity		4	10	at any time	URS Team	Active Import, Active Export Reactive Import Reactive Export	A
Measurement Requirement		1,070	4,000	at any one time	URS Team	Initial = see attached sheet Max = 4* Initial	E
Measurement Requirement per Standard Settlement Configuration		avge: 2.2 max: 7	21	at any one time	URS Team	Initial Average = Standard Settlement Configuration/ Measurement Requirements; Initial Max = current max Max capacity= Initial max * 3	E
Period Profile Class Coefficients		102,816	768,000	Profile Production Run	URS Team	1 per period per Valid Measurement Requirement Profile Class	E
Period Regression Equation		15,120	3.9 million	at any one time	URS Team	1 per period (48) per Regression equation set	E
Period Supplier Purchase		1,392	9,600	SSR Run	URS Team	1 per Supplier per Settlement Period	E
Period Time Pattern State		51,360	192,000	Settlement Day	URS Team	1 per Settlement Period per Time Pattern Regime	E
Profile		9	20	Initial: nationally Max: by Profile Class	URS Team	Initial = 1 Profile Class has 2 Profiles, others have 1; Max = Each Profile Class has 20 Profiles	E
Profile Classes		8	20	Initial: Nationally Max: by GSP Group	Expert Group	Initial = 8 used nationally Max = Different Profile Classes in different GSP Groups	E
Profile Production Run		2	10	Settlement day	URS Team
Profile Regression Equation Set		315	80,000	at any one time	Load Research	1 per Profile per Day Type per Season	E
		48	48	SSR reconciliation run	URS Team	1 per period per SSR reconciliation run
Seasons (Clock Intervals)		5	100	at any one time	URS Team	Max could vary by PES	E
Seasons (Regression Equations)		5	10	at any one time	URS Team	Max could introduce high/low seasons	E
Settlement Class		4,284	800,000	at any one time	URS team	Valid Meas Reqt Profile Class * LLF Class	E
Settlement Day		Avge: 365 Max: 366	Avge: 365 Max: 366	annum	URS team		A
Settlement Period		48	48	settlement day	URS team	1 per half hour; 46 on a short day; 50 on a long day; 48 otherwise (ave)	A
Settlement Period Line Loss Factor Class		96	2,400	settlement day	URS team	1 per Line Loss Factor Class per Settlement Period	E
Settlement		6	10	Settlement day	Expert Group		E
SSA Settlement Runs		2	10	Settlement day	Pool		E
SSR Run Type		6	10	at any time	Expert Group	Initial Settlement, Final Settlement, reconciliations 1 to 3 Final reconciliation	A
SSR Run		6	10	Settlement day	Expert Group	See Requirements Catalogue entry	E
Standard Settlement Configuration		482	2,500	at any one time	URS Team	Initial = data supplied by RECs to the BRG Max = 5* Initial	E
Supplier		29	200	at any one time	Expert Group		E
Supplier Data Aggregation		58	4,000	SSR Run	URS Team	Initial: 2 per Supplier (1 HH and 1 Non-HH) Max: 20 per Supplier	E
Supplier In GSP Group		29	400	GSP Group	Expert Group	Assuming all Suppliers trade in all GSP Groups Initial = 1 per Supplier (per GSP Group) Max = 2 per Supplier (per GSP Group)	E
Supplier Purchase Matrix		6,426	1.2 million	SSR Run	URS team	In theory: 1 per Supplier non HH Data Agg run and Settlement Class. However, in practice each Supplier will probably have his own set of tariffs (Valid MRPC) so 1.5 Suppliers per Settlement Class is more reasonable.	E
Teleswitch Contact		4	4	at any one time	EASL		A
Teleswitch Contact Interval		3840	131,072	UTC day	URS team EASL	Initial = 320 Teleswitch Groups * 4 Contacts * 3 Contact States Max = 4096 Teleswitch Groups * 4 Contacts * 8 Contact States	E
Teleswitch Contact Rule		1140	163,840	at any one time	URS Team	Initial = Data supplied by PESs to the Pool Max = 40,960 Teleswitch Register Rules * 4 Contacts	E
Teleswitch Group		320	4096	at any one time	URS Team EASL	Initial = 20 Groups * 16 Users Max = 256 Groups * 16 Users	E
Teleswitch Interval		960	32,768	Settlement day	URS Team	Derived from Teleswitch Time Pattern Regime, i.e. Initial = 1.5 * 640 Max = 4 * 8192	E
Teleswitch Register Rule		640	40,960	at any one time	URS Team	Initial = Data supplied by PESs to the Pool Max = 8192 Teleswitch Time Pattern Regimes * 5	E
Teleswitch Time Pattern Regime		640	8,192	at any one time	EASL	Initial = 20 Groups * 16 Users * 2 switches Max = 256 Groups * 16 Users * 2 switches	E
Time Pattern Regime		1,070	4,000	at any one time	URS Team	Worst case is all Measurement Requirements are based on different Time Pattern Regimes	E
Valid Measurement Requirement Profile Class		2,142	16,000	at any one time	URS Team	Initial = data supplied by RECs to the BRG Max = 8* Initial	E
Valid Standard Settlement Configuration Profile Class		820	4,000	at any one time	URS Team	Initial = data supplied by RECs to the BRG Max = 5* Initial	E

APPENDIX G: SVA METERING SYSTEM AND ASSET METERING SYSTEM REGISTER

Supplier Volume Allocation Agent (SVAA) User Requirements Specification SVA Metering System and Asset Metering System Register

Synopsis: The SVAA is responsible for the creation and maintenance of the SVA Metering System and Asset Metering System Register (MSAMSR). The MSAMSR is a register of SVA Metering System Numbers and Asset Metering System Numbers and the Secondary and / or Additional BM Unit to which they have been allocated for purposes of providing BM Services and the SVA Metering System Numbers provided by the NETSO in relation to the provision of Applicable Balancing Services to the NETSO outside of the BM (i.e. where there is no related BM Unit).

1 Management Summary

The MSAMSR is a SVAA administered reference data register that supports the operation of the Balancing and Settlement Code (BSC). The MSAMSR is critical to the successful operation of the BSC, as it records and maintains a register of SVA Metering System Numbers and Asset Metering System Numbers and, where applicable², the related Secondary or Additional BM Unit. This register is used as reference data when aggregating metered volumes for Secondary BM Units and calculating Supplier adjustments for actions taken by Secondary BM Units. The principal business processes involved may be summarised as:

The capture of data regarding new MSID Pair Allocations and AMSID Pair Allocations;
The capture of data regarding amendments to existing MSID Pair Allocations and AMSID Pair Allocations;
The procurement and capture of MSID Standing Data and AMSID Standing Data:
Whether MSID Pairs and / or AMSID Pairs in a Secondary BM Unit and MSID Pairs in an Additional BM Unit are classified as Baselined and, if so the period when such MSID Pairs and / or AMSID Pairs should be treated as Inactive and the Baselining Methodology;
In relation to Disputed MSID Pair Allocations and Disputed AMSID Pair Allocations by provide functionality to facilitate resolution between Parties ;and
Whether MSIDs have been declared in EMR MSID Declarations and MSID Pairs and AMSID Pairs have been declared in EMR AMSID Declarations for the purposes of calculating Supplier BM Unit Non-Chargeable Demand.

The purpose of this document is to provide a complete specification of the set of business requirements which the MSAMSR must satisfy for all of its various user types. These range from the BSCCo to the BSC Parties themselves. Similar documents will be produced to define the requirements for the other services. A convention has therefore been used for uniquely identifying the requirements in each document, so as to ensure that the fulfilment of each requirement can be unambiguously traced through the subsequent functional specification, design and implementation. This document does not, however, attempt to describe the integration of those services, which would be inappropriate for this MSAMSR User Requirement Specification (URS).

The requirements which have been identified have been divided into four categories:

Functional requirements - those requirements relating to a specific business activity, usually requiring some degree of automated support;
Interface requirements - the detailed requirements for the exchange of data between the SVA MSR, the other BSC services shown above, and the external participants (and covered in more detail in the Interface Definition and Design (IDD) documents);
Non-functional requirements - those requirements relating to such activities as security (both physical and user access related), audit, and system housekeeping (systems backups and archiving etc.). It is anticipated that the majority of these will be common with all of the BSCCo services to be provided;
Service requirements - the underlying service delivery requirements of the MSAMSR service, including such as issues as performance, volumetrics and number of Reconciliations to be carried out.

These requirements are catalogued in sections 5 to 8 respectively.

2 Introduction

This document is the User Requirements Specification (URS) for the MSAMSR within the Balancing and Settlement Code Services. It complements the set of documents detailing the requirements of the seven BSC central system services. The aforementioned document set comprises:

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS;

The objective of this document is to provide a complete specification of the requirements that the MSAMSR must meet, from the users’ point of view. For this purpose, the “users” include BSCCo Ltd, BSC Trading Party participants, the NETSO, other BSC Parties and the MSAMSR Service Provider’s own operators.

This User Requirements Specification forms the input to the System Specification for the MSAMSR. The System Specification constitutes the definition of the computer system requirements to be built in support of the MSAMSR Services.

3 Scope of Specification

This document provides a specification of the requirements for the MSAMSR that supports the operation of the Balancing and Settlement Code (BSC). The requirements are described from the point of view of the MSAMSR system users.

The document is divided into the following sections.

Section 4, Business and System Overview – describes the business context of the Service;

Section 5, Functional Requirements – describes the functional requirements of the Service from the point of view of the Service users;

Section 6, Interface Requirements – describes the interfaces with the external users of the Service;

Section 7, Non-Functional Requirements – describes the non-functional requirements of the Service, such as auditing, security and resilience;

Section 8, Service Requirements – describes the service delivery requirements of the Service, such as performance and volumetrics;

Section 9, User Roles and Activities – describes the roles supporting day to day operation of the Service and external users of the Service, such as BSC Parties and BSCCo Ltd.

4 Business and System Overview

This section provides an overview of the MSAMSR business requirements and is for indicative purposes only. The definitive statement of requirements is given in the following chapters.

4.1 Summary of Business Requirements

The MSAMSR will receive inbound MSID, MSID Pair and AMSID Pair data, provided by Virtual Lead Parties (VLP), Asset Metering VLPs (AMVLP), Suppliers and the NETSO, and will perform validation of such prior to processing. This operation will be performed in accordance BSC Section S, BSCP508 and BSCP602. The MSAMSR will also share the recorded reference data to allow for:

i) the aggregation of metered volumes for Secondary BM Units and calculating Supplier adjustments for actions taken by Secondary BM Units ;and

ii) The calculation of Supplier BM Unit Non BM ABSVD

for each Settlement Day and for each Settlement Run

The information the MSAMSR system will record and maintain will include:

MSID Pair Allocation data and AMSID Pair Allocation data;
MSID Standing Data and AMSID Standing Data;
Baselined MSID Pairs and / or AMSID Pairs, Baselining Methodology and related Event Days; and
Disputed MSID Pair Allocation and Disputed AMSID Pair Allocation data.

The processes that will allow the MSAMSR to record and maintain the requisite data will include:

MSID Pair Validation and AMSID Pair Validation;
Loss of MSID Pair Notification and Loss of AMSID Pair Notification; and
Disputed MSID Pair Allocation and Disputed AMSID Pair Allocation.

Settlement Run Provisions

Share recorded reference data with the relevant Settlement systems.

4.2 Service Context

The following diagram illustrates the context of the SVA MSR within the wider market of the Balancing and Settlement Code. This is a simplified view for clarity; section 6 describes the interfaces from the SVA MSR to other parties in detail.

BSCCo	The Balancing and Settlement Code Company
CRA	Central Registration Agent
EES	Electricity Enquiry System (previously ECOES ‘Electricity Central Online Enquiry System’)
SVAA	Supplier Volume Allocation Agent
NETSO	National Electricity Transmission System Operator

4.3 Requirements Summary

Requirement ID.	User Requirement
Functional
SVA_BSR-F001	Provision of MSID Pair Allocation data
SVA_BSR-F001a	Provision of AMSID Pair Allocation data
SVA_BSR-F002	Processing of MSID Pair Allocation data
SVA_BSR-F002a

SVA_BSR-F003	Loss of MSID Pair Notification
SVA_BSR-F003a	Loss of ASMID pair Notification
SVA_BSR-F004	Retrospective MSID Pair or AMSID Pair Allocation
SVA_BSR-F005	Procurement of MSID Standing Data
SVA_BSR-F005a	Procurement of AMSID Standing Data
SVA_BSR-F006	Validation of MSID Pair Allocation data (2)
SVA_BSR-F007	Disputed MSID Pair Allocation
SVA_BSR-F007a	Disputed AMSID Pair Allocation
SVA_BSR-F008	Three Stage process for the Registration of an Asset Metering System
SVA_BSR-F009	Allocation of an AMSID Pair to a Secondary BM Unit by the Registrant AMVLP
SVA_BSR-F010	Allocation of an AMSID Pair to a Secondary BM Unit by a non-Registrant AMVLP
SVA_BSR-F011	Settlement Run Activity
SVA_BSR-F012	Performance Assurance Reporting
SVA_BSR-F013	EMR MSID Declaration and EMR AMSID Declaration
Non Functional
SVA_BSR-N001	Input Interface Requirements

4.4 Numbering Schedule for Requirements Definitions

As described in section 2, the set of baseline requirement documents includes a User Requirements Specification for each of the services of the central BSC systems. Within these documents each requirement across the set of services is uniquely identified to provide traceability of each individual requirement from URS to System Specification (functional specification) and then to Design Specification (technical specification).

In keeping with industry good practise, this URS adopts a requirements numbering system that works as follows:

1. Each requirement is associated with either an individual service, or as common to all services supported by the central systems. (TAA is typically excluded from the latter.) If a requirement applies to more than one service, but not all (e.g. two out of six), then the requirement is restated for each, i.e. there would be two separately numbered requirements (which happen to be the same) in this example.

Each requirement is prefaced by one of the following codes, as a clear indicator as to which service generates the business need:

CRA (Central Registration Agent);
SAA (Settlement Administration Agent);
CDCA (Central Data Collection Agent);
ECVAA (Energy Contract Volume Aggregation Agent)
BMRA (Balancing Mechanism Reporting Agent);
MSAMSR (Metering System and Asset Metering System Register)
TAA (Technical Assurance Agent);
FAA (Funds Administration Agent);
GEN (General)

2. Requirements are categorised into the following headings:

Functional (F), a specific business requirement of the service.
Interface (I), a requirement for data exchange between services or to external parties.
Non-functional (N), which includes auditing, security, resilience etc. The majority of these will probably be associated with the General (GEN) service.
Service (S),

3. Within a service, each requirement has unique number in the range 001 to 999. Numbers are not unique across services. Leading zeroes are always included.

Combining 1, 2 and 3 thus gives the following format for numbering each requirement (including a separator character):

[Service]-[Category][Number]

For example:

CRA-F001
BMRA-S022
GEN-N112
SAA-I033

4.5 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: a unique identifier for the requirement, as described above.

Status: while the majority of MSAMSR requirements will be mandatory for the Go Live date, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: a short descriptive title for the requirement.

BSC reference: a cross reference to the BSC documentation which is the original source of the business need. In most cases this will include a reference to the relevant Service Description and where appropriate, any Modifications that have affected a particular requirement.

Man/auto: this field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism.

Frequency: an indication of how often a business event will take place. Minimum, maximum and average frequencies, and any timing or scheduling requirements, are also identified here, as appropriate.

Volumes: data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

The requirement is then described in detail, with any associated specific non-functional and interface requirements separately identified. Any outstanding issues relating to the requirement definition are also identified.

5 Functional Requirements

This section describes the detailed set of business requirements for the MSAMSR. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is uniquely numbered, based on the convention described in section 4.

5.1 Provision of MSID Pair Allocation Data

Requirement ID:

SVA_BSR-F001

Status:

Title:

Provision of MSID Pair Allocation data

BSC reference:

Section S 10.2

BSCP602 2.1

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The following data will be provided to the MSAMSR by Suppliers, VLPs and AMVLPs in order to enable SVAA aggregation of metered volumes for Secondary BM Units and for calculation of Supplier adjustments for actions taken by Secondary BM Units for each Settlement Run:

Each Supplier / VLP / AMVLP will provide for each MSID Pair:

the identification number of the relevant BM Unit;

in relation to a MSID Pair, the GSP Group in which the Import Metering System and (where applicable) Export Metering System are located;
Import Metering System MSID;
Export Metering System MSID (where applicable);
Effective From Settlement Date
Effective To Settlement Date
Import Metering System MSID Customer Consent Flag and associated:
- Effective From Settlement Date
- Effective To Settlement Date
Export Metering System MSID Customer Consent Flag and associated:
- Effective From Settlement Date
- Effective To Settlement Date

These data, with the exception of the relevant BM Unit, will also be provided to the MSAMSR by the NETSO, for calculation of Supplier adjustments for non BM Applicable Balancing Services provided to the NETSO.

Under P375, all Secondary BM Units will include a “MSID Pair Indicator” which may have the values:

‘T’ – no AMSID Pairs in Secondary BM Unit;
‘D’ – MSID Pair is associated with AMSID Pair(s) for Differencing;
‘A’ – MSID Pair is associated with AMSID Pair(s) for Asset Metering.

The default setting for a Secondary BM Unit is “T”. If an AMVLP wishes to add an AMSID Pair(s) to a Secondary BM Unit, they must change the “MSID Pair Indicator” to ‘D’ or ‘A’ as set out in SVA_BSR-F001a.

Non-Functional Requirements:

Interfaces:

P0278 – MSID Pair Allocation

Issues:

5.2 Provision of AMSID Pair Allocation Data

Requirement ID:

SVA_BSR-F001a

Status:

Title:

Provision of AMSID Pair Allocation data

BSC reference:

Section S 10.2

BSCP602 2.1

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The data P0306 ‘AMSID Pair Allocation to a Secondary BM Unit will be provided to the MSAMSR in addition to the MSID Pair Allocation Data by AMVLPs in order to enable SVAA aggregation of metered volumes for Secondary BM Units for actions taken by Secondary BM Units which include AMSID Pair(s) for each Settlement Run:

Each AMVLP will provide for each AMSID Pair allocated to a Secondary BM unit:

the identification number of the relevant BM Unit;
Import Asset Metering System AMSID
Export Asset Metering System AMSID (where applicable);
AMSID Pair Differencing Indicator (‘T’ for Differencing; ‘F’ for Asset Metering)
MSID Pair Indicator (‘D’ for Differencing; ‘A’ for Asset Metering)*
AMSID Pair in Secondary BM Unit EFD
AMSID Pair in Secondary BM Unit ETD (optional)
Import MSID
Export MSID (where applicable);

*The MSID Pair Indicator may not be ‘T’ if an AMSID Pair(s) is allocated to the Secondary BM Unit

Non-Functional Requirements:

Interfaces:

P0306 – AMSID Pair Allocation to a Secondary BM Unit

Issues:

5.3 Validation of MSID Pair Allocation data (1)

Requirement ID:

SVA_BSR-F002

Status:

Title:

VALIDATION OF MSID PAIR ALLOCATION DATA (1)

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Within 1 Working Day of receiving a MSID Pair Allocation the MSAMSR shall undertake, as a minimum, the following validation:

Validate Stage 1 – Schema Validation

The SVAA will validate the MSID Pair Allocation data from Suppliers / VLPs / AMVLPs / the NETSO. The incoming data will be validated to ensure:

Physical integrity; and

That the data file contains all mandatory data items in the required formats in accordance with the SVA Data Catalogue and data from Suppliers / VLPs / AMVLPs includes the relevant BM Unit.

Validate Stage 2 – Business Logic Validation

The MSAMSR will validate the MSID Pair Allocation in accordance with the requirements in Section S. The MSID Pair Allocation will be validated to ensure that:

it is from a valid Party (i.e. a qualified Supplier, VLP or AMVLP) or the NETSO

the BM Unit to be allocated is a valid BM Unit³

the Lead Party sending the notification is the Lead Party of the specified BM Unit to have a MSID Pair allocated²

a MSID may not be allocated to more than one MSID Pair at any given time

each MSID within the MSID Pair is located within the same GSP group associated with the BM Unit to which they are to be allocated to²; and

the EFSD of the MSID Pair Allocation is at least 5 working Days ahead of the date of receipt of the MSID Pair

Note that the SVAA must also complete ‘Validation of MSID Pair Allocation data (2)

(SVA_BSR-F006) before notifying the Lead Party of the outcome of the validation.

Non-Functional Requirements:

Interfaces:

Issues:

5.4 Validation of AMSID Pair Allocation data

Requirement ID:

SVA_BSR-F002a

Status:

Title:

Validation of AMSID Pair Allocation Data

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Within 1 Working Day of receiving an AMSID Pair Allocation in a P0306 the MSAMSR shall undertake, as a minimum, the following validation:

Validate Stage 1 – Schema Validation

The SVAA will validate the AMSID Pair Allocation data from AMVLPs.

The incoming data will be validated to ensure:

Physical integrity; and
That the data file contains all mandatory data items in the required formats in accordance with the SVA Data Catalogue and data from AMVLPs includes the relevant Secondary BM Unit.

Validate Stage 2 – Business Logic Validation

The MSAMSR will validate the AMSID Pair Allocation in accordance with the requirements in BSCP602.

The AMSID Pair Allocation will be validated to ensure that:

it is from a qualified AMVLP
the BM Unit to be allocated is a valid Secondary BM Unit⁴
the AMVLP sending the notification is the Lead Party of the specified BM Unit to have an AMSID Pair allocated²
an AMSID may not be allocated to more than one AMSID Pair at any given time
each AMSID within the AMSID Pair is located within the same GSP group associated with the BM Unit to which they are to be allocated to²; and
the Effective From Settlement Date (EFSD) of the AMSID Pair Allocation is at least 5 working Days ahead of the date of receipt of the AMSID Pair

Non-Functional Requirements:

Interfaces:

P0307 – Confirmation of AMSID Pair Allocation

P0308 – Confirmation of AMSID Pair Allocation

Issues:

5.5 Loss of MSID Pair Notification

Requirement ID:

SVA_BSR-F003

Status:

Title:

LOSS OF MSID PAIR NOTIFICATION

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where a MSID Pair is already allocated to a BM Unit that offers Balancing Services⁵, the MSAMSR shall, subject to validation, confirm the most recent allocation and notify the previous registrant of:

the SVA Metering System Number of each SVA Metering System that is no longer allocated to a BM Unit;

the GSP Group in which such SVA Metering System is located;

the date from when such SVA Metering System will no longer be allocated to their BM Unit for the purposes of providing Balancing Services in Settlement.

Non-Functional Requirements:

Interfaces:

P0281 – Loss of MSID Pair Allocation

Issues:

5.6 Loss of AMSID Pair Notification

Requirement ID:

SVA_BSR-F003a

Status:

Title:

Loss of AMSID Pair Notification

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where an AMSID Pair is already allocated to a Secondary BM Unit for the purposes of Asset Metering and a Second AMVLP wishes to include the same AMSID Pair is in one of its Secondary BM Units for the purposes of Asset Metering, the MSAMSR shall, subject to validation, remove the AMSID Pair from the Secondary BM Unit belonging to the first AMVLP (the Losing AMVLP) and reallocate it to the Secondary BM Unit belonging to the second AMVLP (the Gaining AMVLP). SVAA shall send a P0320 notify the previous AMVLP of:

Secondary BM Unit Id
Import AMSID
Export AMSID
AMSID Pair Differencing Indicator
AMSID Pair in Secondary BM Unit EFD
AMSID Pair in Secondary BM Unit ETD

Non-Functional Requirements

Interfaces:

P0320 – Loss of AMSID Pair Allocation

Issues:

5.7 Retrospective MSID Pair Allocation or AMSID Pair Allocation

Requirement ID:

SVA_BSR-F004

Status:

Title:

RETROSPECTIVE MSID PAIR OR AMSID PAIR ALLOCATION

BSC reference:

Section S 10.2

BSCP602 2.1

Man/auto:

Frequency:

As Necessary

Volumes:

Functional Requirements:

The MSAMSR shall provide functionality to allow a Supplier, VLP or AMVLP to retrospectively correct a MSID Pair Allocation error or an AMSID Pair Allocation error, and that where correction of the identified error ensures that the future accuracy of Settlement. The MSAMSR shall facilitate such amendments for Settlement Days prior to having undergone the R1 Settlement Run.

The exception to this rule is the MSID Pair Effective To Settlement Date (ETSD), or AMSID Pair ETSD, which can be amended to an earlier Settlement Date at any time.

To clarify only existing MSID Pair Allocations and AMSID Pair Allocations qualify for a Retrospective MSID Pair Allocation Error. The MSAMSR shall allow, where the Settlement Date has yet to have undergone the R1 Settlement Run, Lead Parties to:

Amend an existing MSID Pair Allocation or AMSID Pair Allocation; and

Delete an existing MSID Pair Allocation or AMSID Pair Allocation

The MSAMSR shall have robust controls to ensure that all retrospective MSID Pair Allocations and AMSID Pair Allocations are validated to ensure that the accuracy of Settlement is maintained.

Non-Functional Requirements:

Interfaces:

P0278 - MSID Pair Allocation

P0306 - AMSID Pair Allocation

Issues:

5.8 Procurement of MSID Standing Data

Requirement ID:

SVA_BSR-F005

Status:

Title:

PROCUREMENT OF MSID STANDING DATA

BSC reference:

Section S 11.2

BSCP507

Annex S-2

Man/auto:

Manual

Frequency:

Once per WD

Volumes:

Functional Requirements:

When the MSAMSR validates and confirms a MSID Pair Allocation it shall:

procure the MSID Standing Data; and

store such MSID Standing Data

"MSID Standing Data" means, in relation to a SVA Metering System:

the GSP Group in which the SVA Metering System is located;

the Supplier ID of the Supplier that has in accordance with section K2.4 registered the Metering System;

the Half Hourly Data Aggregator appointed in relation to that Metering System; and

any other data item defined in BSCP507 as being included in MSID Standing Data.

The MSAMSR shall procure the MSID Standing Data by either making a manual enquiry on the EES system, using an EES Automated Programmable Interface (API) or other source agreed by the Panel for both the Import SVA Metering System and, where applicable, the Export SVA Metering System.

Non-Functional Requirements:

Interfaces:

Issues:

5.9 Procurement of AMSID Standing Data

Requirement ID:

SVA_BSR-F005a

Status:

Title:

Procurement of MSID Standing Data

BSC reference:

Section S 11.2

BSCP507

Annex S-2

Man/auto:

Manual

Frequency:

Once per WD

Volumes:

Functional Requirements:

When the MSAMSR validates and confirms the data submitted in any of the three Asset Metering System Registration Stages (see SVA_BSR-8), it shall store such as AMSID Standing Data.

Non-Functional Requirements:

Interfaces:

Issues:

5.10 Validation of MSID Pair Allocation Data (2)

Requirement ID:

SVA_BSR-F006

Status:

Title:

VALIDATION OF MSID PAIR ALLOCATION DATA (2)

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Validate Stage 3 – SMRS Data Validation

The MSAMSR will further validate the individual MSIDs in MSID Pair Notifications to be allocated to Secondary BM Units² against MSID Standing Data procured from the relevant SMRS via the Electricity Enquiry Service (EES) through:

a Manual access to the EES portal; or

An EES Automated Programmable Interface (API)

MSID data will be validated to ensure that:

a MSID allocated to a Secondary BM Unit must be a SVA HH Metering System;

a MSID allocated to a Secondary BM Unit must not be disconnected; and

the MSID GSP Group has been recorded correctly.

Non-Functional Requirements:

Interfaces:

P0279 – Confirmation of MSID Pair Allocation

P0280 – Rejection of MSID Pair Allocation

Issues:

5.11 Disputed MSID Pair Allocation

Requirement ID:

SVA_BSR-F007

Status:

Title:

5.7 DISPUTED MSID PAIR ALLOCATION

BSC reference:

BSCP 602 2.3

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where a Lead Party has received a Loss of MSID Pair Allocation notification or a Rejection of MSID Pair Delivered Volume notification, and after discussion with the customer they believe it to be an erroneous notification, they may initiate the Disputed Allocation Procedure via the SVA MSR.

A Lead Party may initiate the Disputed MSID Pair Allocation Resolution Process by sending the dispute to the Current Lead Party.

The Current Lead Party shall use reasonable endeavours to respond to the Initial Request within 5 Working Days of receipt of the dispute.

Once the initial request has been made one of the following options shall be taken:

Both Parties agree how the MSID is to be allocated

After appropriate investigation e.g. checking a valid contract is in place, the Current Lead Party disagrees with the initiating Lead Party

Where Lead Parties are in agreement:

Current Party shall delete the disputed MSID Pair Allocation and / or send a revised MSID Pair Allocation with agreed EFSD

The initiating Lead Party shall send a revised MSID Pair Allocation populated as agreed.

Where Lead Parties are not in agreement:

Current Lead Party shall respond to the initiating Lead Party indicating the Current Lead Party disagrees with the initiating Lead Party

The initiating Lead Party can restart process should they remain in the belief that the rejection is erroneous

Non-Functional Requirements:

Interfaces:

P0286– Disputed MSID Pair Allocation

Issues:

5.12 Disputed AMSID Pair Allocation

Requirement ID:

SVA_BSR-F007a

Status:

Title:

Disputed AMSID Pair Allocation

BSC reference:

BSCP 602 2.3

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where an AMVLP has received a Loss of AMSID Pair Allocation notification (a ‘Losing AMVLP’) and, after discussion with the customer, they believe it to be an erroneous notification, they may initiate the Disputed Allocation Procedure.

A Losing AMVLP may initiate the Disputed AMSID Pair Allocation Resolution process by sending a P0312 ‘Disputed AMSID Pair Allocation’ to the Gaining AMVLP.
The Gaining AMVLP shall use reasonable endeavours to respond to the Losing AMVLP within 5 Working Days of receipt of the P0312.

Once the initial request has been made one of the following options shall be taken:

The Gaining AMVLP agrees that the AMSID Pair is to be allocated to the Losing AMVLP.
After appropriate investigation e.g. checking a valid contract is in place, the Gaining AMVLP disagrees with the Losing AMVLP.

Where the Gaining AMVLP agrees with the Losing AMVLP:

The Gaining AMVLP shall update the MSAMSR with a revised AMSID Pair Allocation populated appropriately.
The Losing AMVLP shall send a new AMSID Pair Allocation populated appropriately.
Where AMVLPs are not in agreement:
The Gaining AMVLP shall send the Losing AMVLP the P0312 indicating the Gaining AMVLP disagrees with the Losing AMVLP
The Losing AMVLP can restart process should they remain in the belief that the rejection is erroneous (please return to step 1)

Where the Gaining AMVLP has received three transfer requests for the same AMSID Pair from the same Losing AMVLP and all requests are believed to be validly rejected, and prior to sending the third rejection:

They shall telephone the Customer to discuss the transfer and the reason for rejection,.
They shall come to a conclusion with the Customer as to whether the transfer request is valid or invalid.
If valid, they shall amend the EFSD as requested and continue as per current process.
If invalid, they will follow the current process in sending the rejection flow along with comments ‘validly rejected 3 times as agreed’.
If a further transfer request is received, the request will be escalated to a Gaining AMVLP team manager who will endeavour to reach a resolution with the Customer.

Non-Functional Requirements:

Interfaces:

P0286 – Disputed MSID Pair Allocation

P0312 – Disputed AMSID Pair Allocation

Issues:

5.13 Three Stage process for the Registration of an Asset Metering System

Requirement ID:

SVA_BSR-F008

Status:

Title:

Three Stage process for the Registration of an Asset Metering System

BSC reference:

BSCP 602 2.3

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Before an AMVLP may allocate an AMSID Pair to a Secondary BM Unit, or a Supplier may include an AMSID Pair in an EMR AMSID Declaration, the AMVLP or Supplier must register the related Asset Metering System. There are three stages to this process:

SVA_BSR-F008a: Stage 1 - Asset Registration:

AMVLP or Supplier submits a P0297 ‘Asset Registration’ to the MSAMSR
MSAMSR validates details.

If Asset Registration fails validation:

MSAMSR sends Rejection of Asset Registration (P0298) to AMVLP or Supplier.

If Asset Registration passes validation, the MSAMSR will:

Store the Asset details
Generate an AMSID Pair
Send the AMSID numbers comprising the AMSID Pair to the AMVLP or Supplier in the ‘Confirmation of Asset Registration’ (P0299)
Allow the registrant AMVLP or Supplier to submit Registration Stage 2 details

Note that the MSAMSR will not allow the AMVL or Supplier P allocate the AMSID Pair to a Secondary BM Unit until all three Registration Stages have completed successfully.

SVA_BSR-F008b: Stage 2 - Asset Metering Party Agent Registration:

AMVLP or Supplier submits a P0300 ‘ Registration of Asset Metering Agents’ to the MSAMSR
MSAMSR validates details.

If Asset Metering Party Agent Registration fails validation:

MSAMSR sends P0301’Rejection of Asset Metering Agent Registration’ to AMVLP or Supplier.

If Asset Metering Party Agent Registration passes validation, the MSAMSR will:

Store Asset Metering Party Agent details
Send Confirmation of Asset Metering Agent Registration (P0302) to AMVLP or Supplier
Allow the registrant AMVLP or Supplier to submit Registration Stage 3 details

Stage 3 - Asset Meter Registration:

AMVLP or Supplier submits a P0303 ‘Asset Meter Registration’ to the MSAMSR
MSAMSR validates details.

If Asset Meter Registration fails validation:

MSAMSR sends Rejection of Asset Meter Registration (P0304) to AMVLP or Supplier.

If Asset Meter Registration passes validation, the MSAMSR will:

Send Confirmation of Asset Meter Registration (P0305) to AMVLP or Supplier.
Allow the AMVLP: to allocate the AMSID Pair to a Secondary BM Unit
Allow the Supplier to include the AMSID Pair in an EMR AMSID Declaration
Allow a second AMVLP to allocate the same AMSID Pair to a Secondary BM Unit under specific conditions (SVA_BSR-F007a)

Non-Functional Requirements:

There are 3 mechanisms for data entry. One via manual entry in communities, file upload via communities or via email sent to Service Desk.

Interfaces:

P0297, P0298, P0299, P0300, P0301, P0302, P0303, P0304, P0305.

Issues:

5.14 Allocation of an AMSID Pair to a Secondary BM Unit by the Registrant AMVLP

Requirement ID:

SVA_BSR-F009

Status:

Title:

Allocation of an AMSID Pair to a Secondary BM Unit by the Registrant AMVLP

BSC reference:

BSCP 602 2.3

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

When an Asset Metering System has successfully completed all three Registration stages, the Registrant AMVLP may allocate the related AMSID Pair to a Secondary BM Unit, by submitting the details specified in the a P0306 ‘AMSID Pair Allocation’ to the MSAMSR:

An AMVLP may allocate an AMSID Pair to Secondary BM Unit(s) for either of two purposes:

Asset Metering, where

AMSID Pair Differencing Indicator = ‘F’; and
MSID Pair Indicator = ‘A’

Asset Differencing, where

AMSID Pair Differencing Indicator = ‘T’; and
MSID Pair Indicator = ‘D’

An AMVLP must submit to SVAA for each Settlement Date on which a Secondary BM Unit was used to provide Balancing Mechanism services:

MSID Pair Delivered Volumes for where an AMSID Pair is registered for Asset Differencing; or
AMSID Pair Delivered Volumes where an AMSID Pair is registered AMSID Pairs for Asset Metering

Second use of an AMSID Pair by the Registrant AMVLP

Where a Registrant AMVLP has allocated an AMSID Pair to one of its Secondary BM Units, the same AMVLP may also allocate the that AMSID Pair to another Secondary BM Unit in the same GSP Group, provided the AMSID Pair is used for Asset Metering in one Secondary BM Unit and for Differencing in the other Secondary BM Unit

Non-Functional Requirements:

Interfaces:

P0306

Issues:

5.15 Allocation of an AMSID Pair to a Secondary BM Unit by a non-Registrant AMVLP

Requirement ID:

SVA_BSR-F010

Status:

Title:

Allocation of an AMSID Pair to a Secondary BM Unit by a non-Registrant AMVLP

BSC reference:

BSCP 602 2.3

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

When an Asset Metering System has been Registered successfully, an AMVLP that is not the Registrant may also allocate the related AMSID Pair one of its Secondary BM Units, by submitting the details specified in the P0306 ‘AMSID Pair Allocation’ to the MSAMSR, under specific circumstances:

Where the first AMVLP is using the AMSID Pair for Asset Metering, the Second AMVLP may allocate that AMSID Pair to a Secondary BM Unit for Differencing – both AMVLPs may use the AMSID Pair.
Where the first AMVLP is using the AMSID Pair for Differencing, the Second AMVLP may allocate that AMSID Pair to a Secondary BM Unit for Asset Metering – both AMVLPs may use the AMSID Pair
Where the first AMVLP is using the AMSID Pair for Asset Metering, and the Second AMVLP allocates that AMSID Pair to another Secondary BM Unit for Asset Metering – both AMVLPs may not use the AMSID Pair – the AMSID Pair is allocated to the Second AMVLP’s Secondary BM Unit and the AMSID Pair is removed from the first AMVLP’s Secondary BM Unit.

The MSAMSR shall not process other scenarios.

Non-Functional Requirements:

Interfaces:

P0306 ‘AMSID Pair Allocation to a Secondary BM Unit’

P0307 ‘Confirmation of AMSID Pair Allocation to a Secondary BM Unit’

P0308 ‘Rejection of AMSID Pair Allocation to a Secondary BM Unit’

Issues:

5.16 Settlement Run Activity

Requirement ID: SVA_BSR-F011	Status: M	Title: 5.8 SETTLEMENT RUN ACTIVITY	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVA MSR shall make the allocation data contained with the register available to the SVAA for each Settlement Run for each Settlement day.
Non-Functional Requirements:

Interfaces:

Issues:

5.17 Performance Assurance Reporting

Requirement ID: SVA_BSR-F012	Status: M	Title: 5.9 PERFORMANCE ASSURANCE REPORTING	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVA MSR shall be able to provide upon request detailed Performance Assurance Reporting which as a minimum shall include: Routine Performance Monitoring Report: is a configurable report in respect of performance against the obligations specified within BSCP602 which shall include a date stamped record of each defined SVA MSR SVA Data Catalogue interface. Drill Down Data: is the data items held within each defined SVA MSR SVA Data Catalogue interface that is used to populate, the output of which is included within the Routine Performance Monitoring Report.
Non-Functional Requirements:

Interfaces:

Issues:

5.18 EMR MSID Declarations and EMR AMSID Declarations

Requirement ID: SVA_BSR-F013	Status: M	Title: EMR MSID Declaration and EMR AMSID Declaration	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
Where a Metering System registered in the SMRS (a “SVA Metering System”) only supplies generation (including storage facilities) operated by a Generation Licensee and does not supply any Final Demand, the relevant Supplier may exclude the Import associated with that Metering System from the calculation by the EMRS of the Registrant’s Final Consumption Levies, by registering such Metering System in the SVA Metering System and Asset Metering System through an “EMR MSID Declaration” in accordance with BSCP602. Where a SVA Metering System supplies both generation (including storage facilities) operated by a Generation Licensee and Final Demand, the relevant Supplier may exclude the amount of Import associated with that Metering System consumed by licensed generation from the calculation by the EMRS of the Registrant’s Final Consumption Levies, the Registrant should: register each generation asset supplied by that metering system in the AMRS; and register the MSID Pair relating to such Metering System and the AMSID Pair(s) relating to the generation asset(s) in the SVA Metering System and Asset Metering System through an “EMR AMSID Declaration” in accordance with BSCP602. Where a Supplier has more than one SVA Metering System supplying generation (including storage facilities) operated by a Generation Licensee and Final Demand, they should include all relevant MSID Pairs in the “EMR AMSID Declaration”.
Non-Functional Requirements:

Interfaces:

Issues:

6 Interface Requirements

The SVA MSR shall provide an interface to the following external parties.

Other Service Providers:

Central Registration Agent (CRA)
Supplier Volume Allocation Agent (SVAA)

Other external parties:

BSCCo Ltd

Suppliers
Virtual Lead Parties
Asset Metering Virtual Lead Parties

7 Non-Functional Requirements

This section specifies the specific non-functional requirements of the SVA BSR. Common non-functional requirements are described in CRA URS - Appendix D

Requirement ID:

SVA_BSR-N001

Status:

Title:

7.1 INPUT INTERFACE REQUIREMENTS

BSC reference:

Man/auto:

Automatic

Frequency:

All business transactions

Volumes:

Non-Functional Requirements:

The SVA BSR system shall provide manual input mechanisms for the insertion of data into the system from external parties where stated.

The SVA BSR service shall provide a mechanism for the decoding of electronically transferred data so that an operator may enter the details contained in the files.

The SVA BSR service shall provide functionality for a user to select an electronic data notification from a list of outstanding input messages and display the contents in a human readable form. Data items shall be listed alongside a label describing individual fields in the input data flow.

The SVA BSR system shall allow an Operator to ‘cut and paste’ the information in these messages.

The SVA BSR service shall carry out validation of all data input so as to ensure that the data is, as far as is practicable, complete and consistent.

Where data is to be input manually, the service shall use reasonable endeavours to ensure that the quality of the data is not compromised in any way. The exact mechanism to ensure this is conducted will be developed in detail within the System and Detailed Design Specification.

Should data, once entered, pass input validation but require further confirmation, the Operator shall then be presented with the ability to save the valid parts of the allocation (subject to database constraints) in a “Pending” state rather than having to abort the entire update. While in this state, the data will be “invisible” to other parts of the BSC Central Systems. For instance it will not be issued to other Services (SAA). At a later time, the Operator shall be able to retrieve the partial update and complete when the original failure has been corrected.

When overriding validation and / or business logic, it may be necessary that the level of authority for the override operation be increased from an Operator. A Supervisor may, in some cases, be required to action a specific Warning type. These roles shall be described in more detail in the SVA BSR System Specification.

All registration entries / amendments will be tagged with the date and time of the operation as well as the identifier (username) of the Operator who entered the details. In addition, where a validation Warning is expressly overridden, the Operator / Supervisor’s identification will also be logged.

Each allocation operation may require a specific level of authorisation within the requesting Party. The SVA BSR stores these levels of authorisation and shall validate that the requesting person has the authorisation to conduct the requested operation. Where this check fails the SVA BSR shall reject the entire request.

The SVA BSR system shall only accept allocation amendments from the Party that sent in the original registration request.

The SVA BSR Service shall undertake Interface Tests for all Parties wishing access to allocations within the SVA BSR. The interface tests will cover the following services (as appropriate to the applicant):

CRA;
SAA;
Lead Parties.

Where Validation errors occur within the system as either a result of individual data entry or through subsequent validation checks the system shall allow the failures to be viewed and searched for by an Operator in accordance with the following:

The system shall present each validation warning / failure to the Operator through an online screen on demand for subsequent rectification through View / Maintain functionality.
The SVA BSR system shall allow an Operator to search through the highlighted information by failure type, BSC Party and effective to / from dates to limit the amount of information presented at any one time.

8 Service Requirements

There are no specific service requirements for the SVA BSR. All common service requirements including indicative volumetrics and performance criteria are described in CRA URS - Appendix.

9 User Roles and Activities

The following table describes the user roles which will support the day to day operation of the SVA BSR.

Role	Activities
System Administrator	Database management Specific aspects of system configuration User account and security management
Supervisor	Management of operators Management of standing data updates Management of planned operational activities to meet service level requirements Creation of management information reports Support for communication with external parties
Operator	Performance of procedures to monitor receipt and processing of information from external parties. Performance of procedures to initiate and monitor operational processes and reports. Second level support for ad hoc queries raised by external parties
Help Desk Operator	First level support for ad hoc queries raised by external parties. Note that the Help Desk facility shall be shared by more than one service provision.
Auditor	There shall be a specific user security configuration which allows an external auditor to review data within the system, but prevents the initiation of batch processes or logical edits to business data

These roles and activities will be refined and developed in more detail during detailed business process definition.

APPENDIX H: SVA AGGREGATION SERVICE

SVAA User Requirements Specification for the SVA Aggregation Service

Synopsis: The SVAA is responsible for the creation and maintenance of the SVA Aggregation Service (SVA AS). The SVA AS will receive:

Half-Hourly Metering System Metered Data from Half Hourly Data Aggregators (HHDAs) for each SVA Metering System Number registered in the MSASMR;
Half Hourly Asset Metering System Metered Data from Half Hourly Data Collectors (HHDCs) for each Asset Metering System Number registered in the MSASMR;
MSID Pair Delivered Volume Notifications from Virtual Lead Parties (VLPs) for SVA Metering System Numbers associated with Secondary BM Units;
MSID Pair Delivered Volume Notifications or AMSID Pair Delivered Volume Notifications from Asset Metering VLPs (AMVLPs) for Asset Metering System Numbers associated with Secondary BM Units;
Details of Baselined BM Units, Baselining Methodologies and Event Days from AMVLPs, VLPs and Suppliers; and
MSID Pair Delivered Volume Notifications from the NETSO for SVA Metering System Numbers associated with the provision of Applicable Balancing Services to the NETSO.

The SVA AS will then use this data and the MSAMSR reference data to calculate:

aggregated volumes for each Secondary BM Unit⁶, in order to facilitate settlement of BM Acceptances and RR Activations:
Settlement Expected Volumes for inclusion in Settlement Calculations and in the Baselining Expected Volume Report; and

Supplier BM Unit Non BM ABSVD to adjust the imbalance positions for Supplier BM Units impacted by the provision of Applicable Balancing Services to the NETSO.

1 Management Summary:

The SVA AS is a SVAA-administered aggregation service that supports the operation of the BSC. The SVA AS is critical to the successful operation of the BSC, as it processes Half-Hourly Metered Data received from HHDAs and HHDCs and Delivered Volume notifications received from VLPs and AMVLPs for Secondary BM Units in accordance with the daily Activations Reports received from the SAA, in order to facilitate settlement of BM Acceptances and RR Activations. The principal business processes may be summarised as follows;

The capture of Metering System Half-Hourly Metered Data;
The capture of Asset Metering System Half-Hourly Metered Data;
The capture of MSID Pair Delivered Volume Notifications;
The capture of the Daily Activations Report;
The calculation of Half-Hourly Metering System Delivered Volumes and MSID ABSVD;
The adjustment of Metering System Half-Hourly Metered Data and Asset Metering System Half-Hourly Metered Data to account for Line Losses and GSP Group Correction Factor;
The aggregation of Line Loss and GSP Group Correction Factor adjusted SVA Metering System Half-Hourly Metered Data and Asset Metering System Half-Hourly Metered Data to create Secondary BM Unit Demand Volumes;
The aggregation of Line Losses and GSP Group Correction Factor adjusted Half-Hourly Metering System and Half-Hourly Asset Metering System Delivered Volumes data to create Secondary BM Unit Consumption Volumes;
The aggregation of Line Losses and GSP Group Correction Factor adjusted MSID ABSVD to create Supplier BM Unit Non BM ABSVD;
The calculation of MSID and AMSID Baseline Values for all MSID Pairs and AMSID Pairs that are in a Baselined BM Unit and registered for a baseline methodology;
The reporting of Secondary BM Unit Demand Volumes Secondary BM Unit Delivered Volumes and Supplier BM Unit Non BM ABSVD to SAA;
The reporting of Secondary Half-Hourly Delivered Volumes to Suppliers; and
The reporting of Secondary Half-Hourly Consumption Volumes to VLPs and AMVLPs.
The reporting of Supplier BM Unit Non-Chargeable Demand to SAA to be used for EMR Settlement Purposes.

The purpose of this document is to provide a complete specification of the set of business requirements that the SVA AS must satisfy for all of its various user types. These range from the BSCCo to the BSC Parties themselves. These requirements have been divided into four categories:

Functional requirements - those requirements relating to a specific business activity, usually requiring some degree of automated support;
Interface requirements - the detailed requirements for the exchange of data between the SVA AS, the other BSC services shown above, and the external participants (and covered in more detail in the Interface Definition and Design (IDD) documents);
Non-functional requirements - those requirements relating to such activities as security (both physical and user access related), audit, and system housekeeping (systems backups and archiving etc.). It is anticipated that the majority of these will be common with all of the BSCCo services to be provided;
Service requirements - the underlying service delivery requirements of the SVA AS service, including such as issues as performance, volumetric and number of Reconciliations to be carried out.

These requirements are catalogued in sections 5 to 8 respectively.

2 Introduction

This Appendix H to the SVAA URS sets out the User Requirement for the SVA AS, as provided by the SVAA BSC Agent. The SVAA URS is one of a set of documents forming the baseline for requirements of the seven BSC central system services. The aforementioned document set comprises:

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS;

The objective of this Appendix H is to provide a complete specification of the requirements that the SVA AS must meet, from the users’ point of view. For this purpose, the “users” include BSCCo Ltd, BSC Trading Parties, other BSC Parties and the SVA AS Provider’s own operators.

This User Requirement Specification forms the input to the System Specification for the SVA AS. The System Specification constitutes the definition of the computer system requirements to be built in support of the SVA AS.

3 Scope of Specification

This Appendix H provides a specification of the requirements for the SVA AS that supports the implementation of the Balancing and Settlement Code. The requirements are described from the point of view of the SVA AS users.

The document is divided into the following sections.

Section 4, Business and System Overview – describes the business context of the Service;

Section 5, Functional Requirements – describes the functional requirements of the Service from the point of view of the Service users;

Section 6, Interface Requirements – describes the interfaces with the external users of the Service;

Section 7, Non-Functional Requirements – describes the non-functional requirements of the Service, such as auditing, security and resilience;

Section 8, Service Requirements – describes the service delivery requirements of the Service, such as performance and volumetric;

Section 9, User Roles and Activities – describes the roles supporting day to day operation of the Service and external users of the Service, such as BSC Parties and BSCCo Ltd.

4 Business and System Overview

This section provides an overview of the SVA AS user requirements and is for indicative purposes only. The definitive statement of user requirements is given in the subsequent sections

4.1 Summary of Business Requirements

The SVA AS shall receive the inbound data, provided by BSC Parties, Party Agents and other BSC Services, and perform calculations based on the most recent validated data. This operation shall be performed in accordance with the Settlement Timetable. The SVA AS will also produce reports for distribution to the Virtual Lead Parties, Suppliers and the SAA service.

4.2 SVA Aggregation Service Context Diagram

The following diagram illustrates the boundaries between the SVA AS and other BSC Parties and systems.

4.3 Calculations Overview of the SVA Aggregation Service

4.3.1 The following diagram illustrates a high-level overview of the SVA AS TERRE calculations.

4.3.2 The following diagram illustrates a high-level overview of the SVA AS ABSVD calculations.

4.4 High Level Business Processes

The high level business processes are illustrated below:

4.5 Requirements Summary

The following table summarises the functional requirements of the SVAA Aggregation Service (SVA AS). These are further described in detail in Section 5 – Functional Requirement, including the source reference for each requirement.

Requirement ID.	Type	User Requirement
SVA_AS_F001	Functional	Capture of Reference Data
SVA_AS_F002	Functional	Establish Metering System Reporting
SVA_AS_F002a	Functional	Establish Half Hourly Asset Metering System Reporting
SVA_AS_F003	Functional	Capture of SVA Metering System Half-Hourly Metered Data
SVA_AS_F003a	Functional	Capture of Asset Metering System Half-Hourly Metered Data
SVA_AS_F004	Functional	Capture Delivered Volume Data
SVA_AS_F005	Functional	Validation of SVA Metering System Half-Hourly Metered Data
SVA_AS_F005a	Functional	Validation of Asset Metering System Half-Hourly Metered Data
SVA_AS_F006	Functional	Validation of Delivered Volume Data
SVA_AS_F007	Functional	Capture or Defaulting of Missing Metering System Half-Hourly Metered Data
SVA_AS_F007a	Functional	Capture of Missing Asset Metering System Half-Hourly Metered Data
SVA_AS_F007b	Functional	Invalid Asset Metering System Half Hourly Metered Data or Invalid Asset Metering System Half Hourly Metered Data
SVA_AS_F008	Functional	Missing Delivered Volumes data or ABS MSID Pair Delivered Volumes data
SVA_AS_F009	Functional	Determination of Metering System Delivered Volume
SVA_AS_F009a	Functional	Determination of MSID Pair Delivered Volumes and AMSID Pair Delivered Volumes
SVA_AS_F009b	Functional	Determination of Asset Metering System Allocated Metered Consumption
SVA_AS_F010	Functional	Calculation of Half-Hourly Metered Line Losses
SVA_AS_F011	Functional	Calculation of Secondary BMU Demand Volumes
SVA_AS_F012	Functional	Exception Handling for MSID Pair Delivered Volume Apportionment
SVA_AS_F013	Functional	Calculation of Secondary BMU Supplier Delivered Line Losses
SVA_AS_F014	Functional	Calculation of Secondary BMU Delivered volumes
SVA_AS_F015	Functional	Report Secondary Half Hourly Consumption Volumes
SVA_AS_F016	Functional	Report Secondary BM Unit Demand Volume
SVA_AS_F017	Functional	Report Secondary Half Hourly Unit Delivered Volumes
SVA_AS_F018	Functional	Report Secondary Half Hourly Unit Supplier Delivered Volume
SVA_AS_F019	Functional	Calculation of Supplier BM Unit Non BM ABSVD
SVA_AS_F020	Functional	Determination of Settlement Expected Volumes
SVA_AS_F021	Functional	Report Supplier BM Unit Non BM ABSVD
SVA_AS_F022	Functional	Submission of EMR MSID Declarations and for EMR AMSID Declarations
SVA_AS_F023	Functional	Calculate Period BM Unit Non Chargeable Demand
SVA_AS_N001	Non-Functional	Reliability Non-Functional Requirement
SVA_AS_N002	Non-Functional	Availability Non-Functional Requirement
SVA_AS_N003	Non-Functional	Auditability Non-Functional Requirement
SVA_AS_N004	Non-Functional	Assurance Non-Functional Requirement
SVA_AS_N005	Non-Functional	Archiving Non-Functional Requirement

4.6 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: a unique identifier for the requirement, as described above.

Status: while the majority of SVA AS requirements will be mandatory, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: a short descriptive title for the requirement.

Man/auto: this field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism.

Volumes: data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

5 Functional Requirements

This section describes the detailed set of functional requirements for the SVA AS. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is uniquely numbered, based on the convention described in section 4.

5.1 Capture of Reference Data

Requirement ID:

SVA_AS_F001

Status:

Title:

Capture of Reference Data

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall be required to capture the following reference data:

D0269 “Market Domain Data” – this is an existing file type created by the MDD Agent and is received by SVAA on a monthly basis. The Data items required are as follows:

Clock Time Changes (CTC)
Line Loss Factor Classes (LLFC)
GSP Group Correction Factor
GSP Group Scaling Weight

D0268 “Data Aggregation and Settlement Timetable” – this is an existing file type created by the Legacy MDD Agent and extracted by SVAA on a yearly basis. The information required for each settlement period and settlement run are as follows:

SVA notification deadlines
Data Aggregation run dates
SSR Run dates
Payment dates

D0265 “Line Loss Factor Data”– this is an existing file type submitted by Distributors to BSCCo, which collates the annual data for each Distributor and publishes it on the ELEXON Portal; the SVAA operator obtains and manually loads the Line Loss Factor data on an annual basis (note that there may be occasional within-year updates to Line Loss Factor data for some Distributors).

L0054 “GSP Group Correction Factor Data”- this is an existing file type created by the SVAA for each settlement date and settlement run during the Volume Allocation Run (VAR) calculation and sent by SVAA on daily basis.

Non-Functional Requirements:

Interfaces:

D0269 - Market Domain Data

D0268 - Data Aggregation and Settlement Timetable

D0265 - Line Loss Factor Data

L0054 - GSP Group Correction Factor Data

Issues:

5.2 Establish Half Hourly SVA Metering System Reporting

Requirement ID:

SVA_AS_F002

Status:

Title:

Establish Half Hourly SVA Metering System Reporting

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The SVA AS shall identify the correct Half Hourly Data Aggregator (HHDA) for the provision of Metering System Half-Hourly Metered Volume data for each SVA Metering System Number as follows

Upon a SVA Metering System Number being associated as belonging to a MSID included in the MSAMSR, SVA AS shall notify the relevant HHDA as identified in the EES (Electricity Enquiry Service © RECCo) database by sending a D0354 “Metering System Reporting Notification”.

SVA AS shall receive from the HHDA either:

D0355 “Metering System Reporting Confirmation” if that HHDA will be responsible for that SVA Metering System on the Effective From Date specified in the D0354; otherwise

D0356 “Metering System Reporting Rejection” notification.

The SVA AS operator shall collate the response data flow received against each D0354 issues, and shall resolve instances when a Metering System reporting Rejection has been received from the appointed HHDA.

If there are any changes relating to the HHDA for a SVA Metering System Number in the MSAMSR, the SVA AS will issue a new D0354 to the relevant HHDA.

Non-Functional Requirements:

Interfaces:

D0354 - Metering System Reporting Notification

D0355 - Metering System Reporting Confirmation

D0356 - Metering System Reporting Rejection

Issues:

5.3 Establish Half Hourly Asset Metering System Reporting

Requirement ID: SVA_AS_F002a	Status: M	Title: Half Hourly Asset Metering System Reporting	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
Each Half Hourly Data Collector (HHDC) appointed to the AMSIDs in an AMSID Pair for an Asset Metering System shall provide Half Hourly Asset Metering System Metered Volumes to the SVAA as instructed by the Registrant AMVLP for the Asset Metering System. There is no equivalent process to SVA_AS_F002 for Asset Metering Systems.
Non-Functional Requirements:

Interfaces:

Issues:

5.4 Capture of SVA Metering System Half-Hourly Metered Volume data

Requirement ID: SVA_AS_F003	Status: M	Title: Capture of SVA Metering System Half-Hourly Metered Volume data	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVA AS shall receive SVA Metering System Half Hourly Metered Volumes from the HHDAs established in accordance with SVA_AS_F002 for SVA Metering System Numbers in Secondary BM Units to Settlement in accordance with BSCP503. As part of each SVA Run, SVA AS shall receive “on a daily basis” a data file containing the SVA Metering System Half Hourly Metred Data for each SVA Metering System Number from each HHDA. The Data items required for each relevant SVA Metering System Number are as follows: The 13-digit MSID (analogous to MPAN Core under the Retail Energy Code) Supplier Id Primary BM Unit Id GSP Group Id Consumption Component Class Id Period Metering System Metered Data (in kWh) Distributor Id Line Loss Factor Class Id Settlement Date Settlement Run
Non-Functional Requirements:

Interfaces:
D0385 – SVA Metering System Half Hourly Metered Data
Issues:

5.5 Capture of Asset Metering System Half-Hourly Metered Volume data

Requirement ID: SVA_AS_F003a	Status: M	Title: Capture of Half-Hourly Asset Metering System Metered Volume data	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVA AS shall receive Asset Metering System Half Hourly Metered Volumes from the HHDCs for Asset Metering System Numbers in Secondary BM Units to Settlement in accordance with BSCP502. As part of each SVA Run, SVA AS shall receive “on a daily basis” a data file containing the Metering System Half Hourly Metred Data for each SVA Metering System Number from each HHDA. The Data items required for each relevant SVA Metering System Number are as follows: 13-digit AMSID (in the MPAN Core Data Item under the Retail Energy Code) Measurement Quantity ID Period Asset Metering System Metered Data GSP Group ID Actual / Estimated Indicator Settlement Date Settlement Period Id
Non-Functional Requirements:

Interfaces:
D0390 – Asset Metering System Half Hourly Metered Data
Issues:

5.6 Capture of Delivered Volume Data

Requirement ID:

SVA_AS_F004

Status:

Title:

Capture of Delivered Volume data

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

For Secondary BM Units that contain only MSID Pairs, SVA AS shall receive from the Lead Party of a Secondary BM Unit to which a BM Acceptance or an RR Activation was issued (by no later than the day after the date of the BM Acceptance or RR Activation) the MSID Pair Delivered Volume (MPDV) identifying the delivered MWh volumes for each SVA MSID Pair associated with the Secondary BM Unit that was instructed to deliver the BM Acceptance or RR Activation.

For Secondary BM Units that contain AMSID Pairs and MSID Pairs, SVA AS shall receive from the Lead Party (AMVLP) of a Secondary BM Unit to which a BM Acceptance was issued (by no later than the day after the date of the BM Acceptance):

Where the AMSID Pair is included for the purposes of Asset Metering, the AMVLP shall submit the AMSID Pair Delivered volume; and
Where the AMSID Pair is included for the purposes of Differencing, the AMVLP shall submit the MSID Pair Delivered volume.

SVA AS shall receive from the NETSO (by no later than the forty-fifth calendar day after the date of the provision of a Non BM Applicable Balancing Service) the ABS MSID Pair Delivered Volume (MPDV) identifying the delivered MWh volumes for each SVA MSID Pair used to provide the Non BM Applicable Balancing Service. The SVAA shall process such ABS MSID Pair Delivered Volume data in the first Settlement Run following receipt, and shall not use default data if no data has been received.

SVA AS may receive from time to time from the Lead Party of a Secondary BM Unit to which a BM Acceptance or an RR Activation was issued, or from the NETSO an updated data file [prior to subsequent Settlement Run] identifying more accurate delivered MWh volumes for each MSID Pair or AMSID Pair that was instructed to deliver the BM Acceptance or RR Activation.

Where a VLP or AMVLP has only registered MSID Pair(s) to a Secondary BM Unit, or an AMVLP has allocated AMSID Pair(s), to a Secondary BM Unit for the Purposes of Differencing, The Data items required for each delivered volumes Notification are as follows:

BM Unit Id
The 13-digit MSID of the Import Metering System
The 13-digit MSID of the associated Export Metering System (where applicable)
MSID Pair Indicator
GSP Group
Settlement Date
Settlement Period
MSID Pair Delivered volume (in MWh, where a positive value represents an increase in output and a negative volume represents a decrease in output)

Note that the AMVLP must not include AMSID Pair Delivered Volumes in such Delivered Volume Notifications.

Where the AMVLP has allocated an AMSID Pair to a Secondary BM Unit for the purposes of Asset Metering, the AMVLP shall submit

BM Unit Id
The 13-digit AMSID of the Import Asset Metering System
The 13-digit AMSID of the associated Export Asset Metering System (where applicable)
MSID Pair Indicator
GSP Group
Settlement Date
Settlement Period
AMSID Pair Delivered volume (in MWh, where a positive value represents an increase in output and a negative volume represents a decrease in output)

Note that the AMVLP must not include MSID Pair Delivered Volumes in such Delivered Volume Notifications.

Non-Functional Requirements:

Interfaces:

P0282 – MSID Pair Delivered Volume Notification

P0292 – ABS MSID Pair Delivered Volume Notification

Issues:

5.7 Validation of Metering System Half-Hourly Metered Volume Data

Requirement ID:

SVA_AS_F005

Status:

Title:

Validation of Metering System Half-Hourly Metered Volume data (D0385)

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The SVA AS shall undertake validation on receipt of Metering System Half Hourly Metered data (D0385).

The SVA AS shall undertake, as a minimum, for each Volume Allocation Run (VAR):

Validation Stage 1 – Technical Validation:

The SVA AS will validate the input Metering System Half Hourly Metered data file from each HHDA to ensure:

Physical integrity; and
That the data file contains all mandatory data items in the required formats in accordance with the SVA Data Catalogue.

Validation Stage 2 – Business Logic Validation:

The SVA AS will validate the Half Hourly Metered data in accordance with the requirements in BSC Section S. The Half Hourly Metered Volume data will be validated to ensure that:

It is from a HHDA

One file is generated for each HHDA who is responsible for one or more MSIDs whose association with a secondary BM Unit has changed.

Non-Functional Requirements:

Interfaces:

D0385 – Metering System Half Hourly Metered Data

Issues:

5.8 Validation of Asset Metering System Half-Hourly Metered Volume Data

Requirement ID:

SVA_AS_F005a

Status:

Title:

Validation of Asset Metering System Half-Hourly Metered Volume data (D0390)

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The SVA AS shall undertake validation on receipt of Asset Metering System Half Hourly Metered data (D0390).

The SVA AS shall undertake, as a minimum:

Validation Stage 1 – Technical Validation:

The SVA AS will validate the input Asset Metering System Half Hourly Metered data file from each HHDC to ensure:

Physical integrity; and
That the data file contains all mandatory data items in the required formats in accordance with the SVA Data Catalogue.

Validation Stage 2 – Business Logic Validation:

The SVA AS will validate the Asset Metering System Half Hourly Metered data in accordance with the requirements in BSC Section S. The Asset Metering System Half Hourly Metered Volume data will be validated to ensure:

that it is from a HHDC; and
whether the data

One file is generated for each HHDC who is responsible for one or more AMSIDs whose association with a secondary BM Unit has changed.

Non-Functional Requirements:

Interfaces:

D0390 – Asset Metering System Half Hourly Metered Data

Issues:

5.9 Validation of Delivered Volume Data (P0282) and ABS MSID Pair Delivered Volume Data (P0292)

Requirement ID:

SVA_AS_F006

Status:

Title:

Validation of Delivered Volume data and ABS MSID Pair Delivered Volume data

BSC reference:

BSCP602 2.1

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

The SVA AS shall undertake validation on receipt of Delivered Volume Data (P0282) and ABS MSID Pair Delivered Volume Data (P0292).

The SVA AS shall undertake, as a minimum:

Validation Stage 1 – Schema Validation

The SVA AS will validate the input Delivered Volume Data file from each AMVLP or VLP and ABS MSID Pair Delivered Volume Data from the NETSO to ensure:

Physical integrity; and
That the data file contains all mandatory data items in the required formats in accordance with the SVA Data Catalogue.

Validation Stage 2 – Business Logic Validation

The SVA AS will validate the Delivered Volume Data in accordance with the requirements in Section S. The Half Hourly Delivered Volume data will be validated to ensure that:

Each P0282 is from a AMVLP or VLP and each P0292 is from the NETSO.
Each P0282 contains AMSID Pair Delivered Volume Data for each AMSID Pair allocated for the purposes of Asset Metering and otherwise contains MSID Pair Delivered Volume Data.

Non-Functional Requirements:

Interfaces:

P0282 – Delivered Volumes Notification

P0292 – ABS MSID Pair Delivered Volumes Notification

Issues:

5.10 Capture or Defaulting of Missing Metering System Half Hourly Metered Data

Requirement ID:

SVA_AS_F007

Status:

Title:

Capture or Defaulting of Missing Metering System Half Hourly Metered Data

BSC reference:

BSCP01

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVA AS should receive D0385 data from HHDAs for each VAR.

For each VAR after the II VAR, the SVA AS shall check whether D0385 data has been received for each MSID 3 WD before the SVAA Run date.

In the event of Missing Metering System Half Hourly Metered Data within the effective date range of the D0355, the SVAA Agent shall be required to carry out the following:

Notify the relevant HHDA of missing ‘Metering System Half Hourly Metered Data’ by issuing a P0310 ‘Missing Metering System Data’ to the relevant HHDA in respect of each MSID where no D0385 data has been received.
Make every attempt to procure the missing data from the relevant HHDA in accordance with BSCP01.

In the event where all attempts to acquire the missing data are unsuccessful then the SVAA Agent shall perform the following tasks:

Derive data from the previous VAR for that Settlement Day.
If no previous Settlement Run exists then no data is entered into that Settlement Run.

Non-Functional Requirements:

Interfaces:

D0355 - Metering System Reporting Confirmation

D0385 – Metering System Half Hourly Metered Data

Issues:

5.11 Capture of Missing Asset Metering System Half Hourly Metered Data

Requirement ID:

SVA_AS_F007a

Status:

Title:

Capture of Missing Asset Metering System Half Hourly Metered Data

BSC reference:

BSCP01

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVA AS should receive D0390 data– which should contain Actual Data where available, but must contain Estimated Data where no Actual Data is available - for each AMSID from HHDCs in time for the SF VAR.

For each VAR after the SF VAR, the SVA AS shall check whether Actual D0390 data has been received for each MSID 3 WD before the SVAA Run date, and shall issue a P0310 ‘Missing Metering System Data’ to the relevant HHDC and AMVLP in respect of each MSID where no Actual D0390 data has been received.

The SVA AS shall not use default data – i.e. shall not derive data from the previous Volume Allocation Run for that Settlement Day.

Non-Functional Requirements:

Interfaces:

D0390 – Metering System Half Hourly Metered Data

P0310 - Missing Metering System Data

Issues:

5.12 Invalid Asset Metering System Half Hourly Metered Data or Invalid Asset Metering System Half Hourly Metered Data

Requirement ID:

SVA_AS_F007b

Status:

Title:

Invalid Asset Metering System Half Hourly Metered Data or Invalid Asset Metering System Half Hourly Metered Data

BSC reference:

BSCP01

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where SVA AS has identified an invalid Metering System Half Hourly Metered Data (D0385) file or an invalid Asset Metering System Half Hourly Metered Data (D0390) file in accordance with SVA_AS_F006, SVA AS shall issue a P0311 ‘Invalid Metering System Metered Data’ to the HHDA (for an Invalid D0385) or to the HHDC and AMVLP (for an Invalid D0390).

Non-Functional Requirements:

Interfaces:

D0385 – Metering System Half Hourly Metered Data

D0390 – Asset Metering System Half Hourly Metered Data

P0311 - Invalid Metering System Metered Data

Issues:

5.13 Capture or Defaulting of Missing Delivered Volumes data or ABS MSID Pair Delivered Volumes data

Requirement ID:

SVA_AS_F008

Status:

Title:

Capture or Defaulting of Missing Delivered Volumes data or ABS MSID Pair Delivered Volumes data

BSC reference:

BSCP01

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

In the event of missing Delivered Volumes data (P0282) or missing ABS MSID Pair Delivered Volumes data (P0292) relating to the RR Activations received from SAA, the SVA AS Agent shall:

Notify the relevant Lead Party of missing Delivered Volumes data or missing ABS MSID Pair Delivered Volumes data; and.

Make every attempt to procure the missing data from the relevant Lead Party in accordance with BSCP01.

In the event where all attempts to acquire the missing data are unsuccessful then the SVA AS shall:

Deem a zero for the Settlement Run

Note that this process should not be applied to ABS MSID Pair Delivered Volumes.

Non-Functional Requirements:

P0282 – Delivered Volumes

P0292 - ABS MSID Pair Delivered Volumes

Issues:

5.14 Determination of Metering System Delivered Volumes

Requirements ID

SVA_AS_F009

Status:

Title

MSID Pair Delivered Volume Apportionment

BSC Reference

Man/auto

Automatic

Frequency

As required

Volumes

Functional Requirement

For each Settlement Period and Settlement Run, the SVA AS shall determine the Total Metering System Delivered Volumes for each Metering System Number in a MSID Pair, using the Metering System Half Hourly Metered Data and the MSID Pair Delivered Volume Notifications or ABS MSID Pair Delivered Volume Notifications received.

Note that where a MSID Pair does not include an Export MSID, the SVA AS will allocate all of the MSID Pair Delivered Volume to the Import MSID.

Steps:

Determine for each Settlement Period and for each relevant Metering System per Settlement Run the ‘Total Metering System Delivered Volume’ [TQVMD_Kj] from the Total MSID Pair Delivered Volume (TMPDV_j) relating to such MSID Pair and the Metering System Metered Consumption (VMMCHZaNLKji) for the relevant Metering Systems.

Case 1 – If the Total MSID Pair Delivered Volumes is greater than or equal to zero and there exists an Export MSID in the MSID Pair

Then the Export Metering System Delivered Volume shall be calculated as follows:

TQVMD_Kj = MIN(TMPDV_j, VMMC_HZaNLKji)

Case 2 - If MSID Pair Delivered Volumes is greater than or equal to zero for the Import MSID in the MSID Pair

This shall be calculated as follows:

TQVMD_Kj = TMPDV_j - QVMD_Export

Where QVMD_Export is the value of TQVMD_Kj allocated to the Export MSID in accordance with ,Case 1 or zero if there is no Export MSID in the MSID Pair.

Case 3 – If MSID Pair Delivered Volumes is less than zero for the Import MSID in the MSID Pair

This shall be calculated as follows:

TQVMD_Kj = – MIN(–TMPDV_j, VMMC_HZaNLKji)

Case 4 – If MSID Pair Delivered Volumes is less than zero for the Export MSID in the MSID Pair

This shall be calculated as follows:

TQVMD_Kj = TMPDV_j - QVMD_Import

where QVMD_Import is the value of TQVMD_Kj allocated to the Import MSID in accordance with Case 1

Case 5 – If MSID Pair Delivered Volumes is less than zero and if TMPDV < –VMMC_HZaNLKji and there is no Export MSID in the MSID Pair then for the Import MSID:

This shall be calculated as follows:

TQVMD_Kj = 0

In such a case SVA AS will log a rejection message against the MSID pair in “MSID Pair Delivered Volume Exception Report” to be reported in P0285 report to the VLP or AMVLP, or in the P0295 report to the NETSO, as appropriate.

Note that the above formulae have been defined in the BSC Annex S-2

For each Settlement Period and relevant Metering System, SVAA shall determine a value of Metering System Delivered Volume (QVMD_Kj) corresponding to each value of MPDV_j that was calculated by SVAA in accordance with paragraph 3.10.1A, 3.11.2 or 3.11.6 and/or provided by Virtual Lead Parties in accordance with Section S11 for that Settlement Period and MSID Pair:

QVMD_Kj = TQVMD_Kj * MPDV_j / ∑ MPDV_j

where ∑ is the summation of MSID Pair Delivered Volumes (MPDV_j) calculated by SVAA in accordance with paragraph 3.10.1A and/or provided by Virtual Lead Parties in accordance with Section S11 for that Settlement Period and MSID Pair.

In relation to values of ABS MSID Pair Delivered Volume (MPDV_j) provided by the NETSO in accordance with Section S11, the Metering System Delivered Volume (QVMD_Kj) shall be determined by SVAA as:

QVMD_Kj = TQVMD_Kj

Non-Functional Requirement

Interfaces

D0385 – Aggregated Half Hourly Metered Volumes

P0282 – Aggregated MSID Pair Delivered Volumes

P0292 – ABS MSID Pair Delivered Volume Notifications

P0291 – BM/RR Activation Reports

Issues

5.15 Determination of MSID Pair Delivered Volumes and AMSID Pair Delivered Volumes

Requirements ID

SVA_AS_F009a

Status:

Title

Determination of MSID Pair Delivered Volumes and AMSID Pair Delivered Volumes

BSC Reference

P376

Man/auto

Automatic

Frequency

As required

Volumes

Functional Requirement

1. For each Baselined MSID Pair that is allocated to the Secondary BM Unit or is an Associated MSID Pair of an AMSID Pair allocated to the BM Unit the SVAA shall determine the MSID Pair Delivered Volume in accordance with the following formula:

MPDV_j = (MBV_KiLj - VBMMC_i2aNLKji) – (MBV_K'iLj - VBMMC_i2aNLK'ji)

Where K is the Import MSID within the MSID Pair, and K' is the Export MSID within the MSID Pair (where applicable).

2. For each Baselined AMSID Pair that is allocated to the Secondary BM Unit (other than for purposes of Asset Differencing) and is not identified as Inactive, the SVAA shall determine the Total AMSID Pair Delivered Volume (TAPDVj) in accordance with the following formula:

TAPDVj = (AMBVKiLj - VBMMCHZNLKji) – (AMBVK'iLj - VBMMCHZNLK'ji)

Where K is the Import AMSID within the AMSID Pair, and K' is the Export AMSID within the AMSID Pair (where applicable).

Steps:

Determine a value of AMSID Pair Delivered Volume (AMPDVj) for each Associated MSID Pair of the AMSID Pair.

Case 1 – If the AMSID Pair has a single Associated MSID Pair

This shall be calculated as follows:

AMPDVj = TAPDVj

Case 2 - If the AMSID Pair has more than one Associated MSID Pair, and the values of MSID Pair Delivered Volume calculated for those Associated MSID Pairs in accordance with paragraph 1 are either all positive or all negative

This shall be calculated as follows:

AMPDVj = TAPDVj * MPDVj * / ∑ MPDVj

Where ∑ is the summation of MSID Pair Delivered Volumes (MPDVj) calculated by SVAA for each Associated MSID Pair in accordance with paragraph 1.

Case 3 – if the AMSID Pair has more than one Associated MSID Pair, and the values of MSID Pair Delivered Volume calculated for those Associated MSID Pairs in accordance with paragraph 2 include both positive and negative values:

i) for those Associated MSID Pairs for which the MSID Pair Delivered Volume and the Total AMSID Pair Delivered Volume either both have positive values or both have negative values

This shall be calculated as follows:

AMPDVj = TAPDVj * MPDVj * / ∑ MPDVj

where ∑ is the summation over those Associated MSID Pairs to which this paragraph applies.

ii)for those Associated MSID Pairs for which the MSID Pair Delivered Volume and the Total AMSID Pair Delivered Volume do not either both have positive values or both have negative values

This shall be calculated as follows:

AMPDVj = 0

The SVAA shall determine the Net Differencing Delivered Volume (NDDVj) for each set of SVA Metering Systems and Asset Metering Systems that are related to each other for purposes of differencing in accordance with paragraph 7.1.1CA in Section S-2, in accordance with the following formula:

NDDVj = NDBVij – VNDKj

For each value of Net Differencing Delivered Volume, the SVAA shall determine a value of MSID Pair Delivered Volume (MPDVj) for each MSID Pair containing SVA Metering System(s) to which the Net Differencing Delivered Volume relates

If there is one such MSID Pair this shall be calculated as follows:

MPDVj = NDDVj

If there is more than one such MSID Pair, and the values of MSID Pair Delivered Volume calculated for those MSID Pairs in accordance with paragraph 1 are either all positive or all negative

this shall be calculated as follows:

MPDVj = NDDVj * MPDVj * / ∑ MPDVj

Where ∑ is the summation of MSID Pair Delivered Volumes (MPDV_j) calculated by SVAA for each MSID Pair in accordance with paragraph 1.

If there is more than one such MSID Pair, and the values of MSID Pair Delivered Volume calculated for those MSID Pairs in accordance with paragraph 1 include both positive and negative values:

(i) for those MSID Pairs for which the MSID Pair Delivered Volume and the Net Differencing Delivered Volume either both have positive values or both have negative values

this shall be calculated as follows:

MPDV_j = NDDV_{j *} MPDV_j * / ∑ MPDV_j

where ∑ is the summation over those MSID Pairs to which this paragraph applies

(i) for those MSID Pairs for which the MSID Pair Delivered Volume and the Net Differencing Delivered Volume do not either both have positive values or both have negative values

this shall be calculated as follows:

MPDVj = 0

Non-Functional Requirement

Interfaces

Issues

5.16 Determination of Asset Metering System Allocated Metered Consumption

Requirements ID

SVA_AS_F009b

Status:

Title

MSID Pair Delivered Volume Apportionment

BSC Reference

Man/auto

Automatic

Frequency

As required

Volumes

Functional Requirement

For each Allocated Asset Metering System Metered Consumption (AAVMMC_HNLKj) value provided pursuant to paragraph 3.9.2A the SVAA shall determine the Asset Metering System Allocated Metered Consumption (VMMC_HNLKj) within Consumption Component Class "N" (which Consumption Component Class shall not be a Consumption Component Class for line losses) for a particular GSP Group "H", Metering System "K" according to the following formula:

VMMC_HNLKj = AAVMMC_HNLKj / 1000

Case 1 – Asset Differencing: if the Metering System or Asset Metering System K has been allocated to the Secondary BM Unit for purposes of Asset Differencing in accordance with paragraph 10.1.3(i)(iii) or 10.1A.2(e)(i) of Section S:

(i) if the Net Differencing Volume VNDK_j is greater than or equal to zero, Consumption Component Class N' shall be the Import Consumption Component Class associated with Consumption Component Class N; and

(ii) if the Net Differencing Volume VNDK_j is less than zero, Consumption Component Class N' shall be the Export Consumption Component Class associated with Consumption Component Class N;

where SVAA shall determine the Net Differencing Volume (VNDK_j) as:

VNDK_j = ∑_N ∑^Associated_K (VMMC_HaNLKji – VMMC_HNLKj)

and ∑^Associated_K means the summation over all Metering Systems and Asset Metering Systems that are related for purposes of differencing to Metering System or Asset Metering System K

Otherwise, Consumption Component Class N’ shall be the same as Consumption Component Class N.

The Metering Systems and Asset Metering Systems related for purposes of differencing to a Metering System or Asset Metering System K shall be determined as follows:

(a) In relation to an Asset Metering System K in an AMSID Pair:

(i) The Metering Systems in any Associated MSID Pairs allocated to a Secondary BM Unit for purposes of Asset Differencing; and

(ii) Any Asset Metering Systems that are related for purposes of differencing to the Metering Systems in paragraph (a)(i);

(b) In relation to a Metering System K in an MSID Pair:

(i) The Asset Metering Systems in any AMSID Pairs allocated to a Secondary BM Unit for purposes of Asset Differencing for which the MSID Pair is an Associated MSID Pair; and

(ii) Any Metering Systems that are related for purposes of differencing to the Asset Metering Systems in paragraph (b)(i).

Non-Functional Requirement

Interfaces

D0385 – Aggregated Metering System Half Hourly Metered Volumes

D0390 – Aggregated Asset Metering System Half Hourly Metered Volumes

P0278 – MSID Pair Allocation

P0306 – AMSID Pair Allocation to a Secondary BM Unit

P0282 – Aggregated Delivered Volumes

P0292 – ABS MSID Pair Delivered Volume Notifications

P0291 – BM/RR Activation Reports

Issues

5.17 Calculation of Line Losses for Metering System Half Hourly Metered Data

Requirements ID

SVA_AS_F010

Status:

Title:

Calculation of Half Hourly Metered Line Losses

BSC Reference

Man/auto:

Automatic

Frequency:

Once per Settlement Run

Volumes

TBD

Functional Requirement:

For all Settlement Runs dates, the SVA AS shall adjust Metering System Half Hourly Metered Data for Line Losses each Half-Hourly SVA metering system number using the Line Loss Factor Class (LLFC) provided by the HHDA.

This calculation shall be performed at MSID level and subsequently aggregated to Secondary BMU level when calculating the Secondary BMU Demand Volumes.

Calculation Steps:

Calculate the Half Hourly consumption metered Losses

This is done by calculating the Secondary Half Hourly consumption metered Losses (VLOSS_i2KNji) value for each Metering System and Secondary BM Unit and determine the CCC ID (Losses); this will be equivalent to the original delivered volume with a consumption component indicator for class specific Line Loss.

This shall be calculated as follows:

${V L O S S}_{i 2 N K j} = \sum_{a} (({L L F}_{L j} - 1) * {V B M M C}_{i 2 a N L K j i})$

Calculate the Half Hourly Metered Consumption

This is done by calculating the Secondary Half Hourly Consumption Non Losses $(V_{i 2 K N j})$ value for each Metering System and Secondary BM Unit

This shall be calculated as follows:

$V_{i 2 N K j} = \sum_{a} {V B M M C}_{i 2 a N L K j i}$

Note that the above formulae have been defined in the BSC, Annex S-2):

VLOSS_i2NKj -

$V_{i 2 K N j}$ -

“N” represents the Consumption Component Class (CCC)

“K” represents the SVA Metering System Number

“i2” represents the Secondary BM Unit

“j” represents the Settlement Period

“I” represents the BM Unit

“L” represents the Line Loss Factor Class

Non-Functional Requirement

Interfaces:

D0385 – Aggregated Half Hourly Metered Volumes

Issues

5.18 Calculation of Secondary BM Unit Half Hourly Demand Volumes

Requirements ID

SVA_AS_F011

Status:

Title:

Calculation of Secondary BM Unit Half Hourly Demand Volumes

BSC Reference

Man/auto:

Automatic

Frequency:

Once per Settlement Run

Volumes

TBD

Functional Requirement:

For all Settlement Runs post P344 Go Live, the SVAA shall adjust HH metered data for GSP Group Correction Factor (GSP GCF) and GSP Group Correction Scaling Weight for each SVA Metering Number.

This calculation shall be performed at Secondary BM Unit level by applying the GSP Corrections to the aggregated metered consumption Non-Losses and Losses.

Calculation Steps:

Aggregate Metered Data Consumption Non-Losses

The metered consumption (Non-Losses) shall be aggregated based on the Secondary BM Unit to derive a value per Secondary BM Unit and CCC ID.

This shall be calculated as follows:

$V_{i 2 N j} = \sum_{K}^{} V_{i 2 N K j}$

Aggregate Metered Consumption Losses

The metered consumption (Losses) shall be aggregated based on the Secondary BM Unit to derive a value per Secondary BM Unit and CCC ID.

This shall be calculated as follows:

${V L O S S}_{i 2 N j} = \sum_{K}^{} {V L O S S}_{i 2 N K j}$

Adjust the Half Hourly Metered Data for GSP Group Correction Factor and GSP Group Correction Scaling Weight.

This shall be calculated as follows:

${V C O R C}_{i 2 N j} = (V_{i 2 N j} + {V L O S S}_{i 2 N j}) * (1 + ({C F}_{H j} - 1) * {W T}_{N})$

Aggregate to Secondary BM Unit Level

The SVAA shall aggregate Line Loss and GSP Group Correction Factor adjusted metered data received from the HHDA to calculate Secondary BM Unit Demand Volume ( ${V B M U D V}_{i 2 j}$ ) in MWh for each Secondary BM Unit.

This shall be calculated as follows:

${V B M U D V}_{i 2 j} = \sum_{N} {V C O R C}_{i 2 N j}$

Note that the above formulae contain references to formulae that have been defined in the Legal Text (Annex S-2):

“ $V_{i 2 N j}$ ” represents the Secondary BM Unit Metered Consumption (Non-Losses)

“ ${V L O S S}_{i 2 N j} "$ represents Secondary BM Unit Metered Consumption (Losses)

“ ${C F}_{H j} ”$ represents the GSP Group Correction Factor

“ ${W T}_{N} ”$ represents the GSP Group Correction Scaling Factor

“ $C O R C ”$ represents the aggregation over Consumption Component Class

Where export CCC ID = Positive and import CCC ID = negative

“H” represents the GSP Group

“N” represents the Consumption Component Class (CCC)

“K” represents the SVA Metering System Number

“i2” represents the Secondary BM Unit

“j” represents the Settlement Period

“i” represents the BM Unit

Non-Functional Requirement

Interfaces

L0054 - GSP Group Correction Factor

D0385 – calculated Metered Consumptions and Losses

Issues

5.19 Exception Handling for MSID Pair Delivered Volume Apportionment

Requirement ID: SVA_AS_F012	Status: M	Title: Exception Handling for MSID Pair Delivered Volume Apportionment	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
In the event where the Delivered Volume or ABS MSID Pair Delivered Volume cannot be apportioned in full to between the SVA Metering Systems using the above mentioned Determination of Metering System Delivered Volumes process, the SVAA shall do the following: SVAA shall log an exception where the MSID Pair Delivered Volumes cannot be apportioned between the SVA Metering Systems MSIDs. Generate a Delivered Volume Exception Report (P0285) or a ABS MSID Pair Delivered Volume Exception Report (P0295). Send the Delivered Volume Exception Report to the relevant VLP or AMVLP or send the ABS MSID Pair Delivered Volume Exception Report to the NETSO, as appropriate. Inform BSCCo of any Delivered Volume Exception or any ABS MSID Pair Delivered Volume Exception.
Non-Functional Requirements:

Interfaces:
P0285 - Delivered Volume Exception Report P0295 - ABS MSID Pair Delivered Volume Exception Report
Issues:

5.20 Calculation of Secondary BM Unit Supplier Delivered Line Losses

Requirements ID

SVA_AS_F013

Status:

Title

Calculation of Secondary BM Unit Supplier Delivered Line Losses

BSC Reference

Man/auto:

Automatic

Frequency

Volumes

Functional Requirement:

The SVAA shall determine the Secondary Half Hourly Delivered Losses within Consumption Component Class; which Consumption Component Class shall be a Consumption Component Class for line losses for each Metering System for each Secondary BM Unit and Supplier BM Unit.

Calculate the delivered losses

This shall be calculated as follows:

${V D L O S S}_{i 2 N K j} = ({L L F}_{L j} - 1) * {Q V B M D}_{i 2 N L K j i}$

Calculate the delivered consumptions

This shall be calculated as follows:

${V D}_{i 2 N K j i} = {Q V B M D}_{i 2 N L K j i}$

Note that the above formulae contain references to formulae that have been defined in the Legal Text (Annex S-2):

“(VDLOSS)” represents the Secondary Half Hourly Delivered Losses

“ $Q V B M D$ ” represents Secondary Half Hourly Delivered Volumes

“ ${L L F}_{L j}$ ” represents the Line Loss Factor Class “L”

“N” represents the Consumption Component Class (CCC)

“K” represents the SVA Metering System Number

“i2” represents the Secondary BM Unit

“j” represents the Settlement Period

Non-Functional Requirement

Interfaces

Issues

5.21 Calculation of Secondary BM Unit Supplier Delivered Volumes

Requirements ID

SVA_AS_F014

Status:

Title

Calculation of Secondary BM Unit Supplier Delivered Volumes

BSC Reference

Man/auto:

Automatic

Frequency

Volumes

Functional Requirement:

The SVAA shall calculate the Adjusted Delivered Volume by applying the GSP Group Correction Factor and GSP Group Correction Scaling Weight to the above calculated Secondary BM Unit Supplier Delivered Losses.

Note that the SVAA shall retrieve the GSP Group Correction factor relevant to the Settlement Period for the GSP Groups.

Calculate the corrected component:

This shall be calculated as follows:

VCORDC_i2NKji = (VD_i2NKji + VDLOSS_i2NKji ) * (1 + (CF_Hj - 1) * WT_N)

Aggregate to Primary BMU level for each Secondary BMU:

This shall be calculated as follows:

${V B M U S D V}_{i 2 j i} = \sum_{i ϵ K} \sum_{N} {V C O R D C}_{i 2 N K j i}$

Note that the above formulae contain references to formulae that have been defined in the Legal Text (Annex S-2):

VCORDC_i2NKji - Secondary BM Unit Delivered Volumes

VD_{i2NKji -}Secondary BMU HH Delivered (non-losses)

VDLOSS_{i2NKj -}Secondary BMU HH Delivered Loss

CF_{Hj -}GSP Group Correction Factor for GSP Group

"H" - GSP Group

WT_{N -}GSP Group Correction Scaling Weight for Consumption Component Class (non-losses)

"N" - Consumption Component Class

${V B M U S D V}_{i 2 j i}$ - $\sum_{K}$ the summation over all CCC ids in a given metering system

$\sum_{i \in K}$ is the summation over all MSID allocated to Supplier BM Unit

"i" - represents the BM Unit

Non-Functional Requirement

Interfaces

Issues

5.22 Report Secondary Half Hourly Consumption Volumes

Requirements ID SVA_AS_F015	Status: M	Title Report Secondary Half Hourly Consumption Volumes	BSC Reference
Man/auto: Automatic	Frequency	Volumes
Functional Requirement: The SVA AS shall report Secondary Half Hour Consumption Volumes to each relevant Virtual Lead Party and Asset Metering Virtual Lead Party. The SVA AS shall produce the reports daily in accordance with SSR Run schedule, each file contains data for a settlement day / run.
Non-Functional Requirement
Interfaces:
P0288
Issues

5.23 Report Secondary BM Unit Demand Volumes

Requirements ID SVA_AS_F016	Status: M	Title Report Secondary BM Unit Demand Volumes	BSC Reference
Man/auto: Automatic	Frequency	Volumes
Functional Requirement: The SVA AS shall report the adjusted Secondary BM Unit Demand volumes to SAA. The SVA AS shall produce the reports daily in accordance with SSR Run schedule, each file contains data for a Settlement Day and Settlement Run.
Non-Functional Requirement
Interfaces:
P0289
Issues

5.24 Report Secondary Half Hourly Delivered Volumes

Requirements ID SVA_AS_F017	Status: Mandatory	Title Report Adjusted Secondary Half Hourly Delivered Volumes	BSC Reference
Man/auto: Automatic	Frequency	Volumes
Functional Requirement: The SVA AS shall report the Secondary Half Hourly Delivered (Non-Losses) volumes to the relevant Suppliers subject to Customer Consent Flag status (i.e. where the Customer Consent Flag has been marked as TRUE). The SVA AS shall report the Secondary Half Hourly Delivered (Losses) volumes to the relevant Suppliers subject to Customer Consent Flag status (i.e. where the Customer Consent Flag has been marked as TRUE). The SVA AS shall produce the reports daily in accordance with SSR Run schedule, each file contains data for a Settlement Day and Settlement Run.
Non-Functional Requirement
Interfaces:
P0287
Issues

5.25 Report Secondary BM Unit Supplier Delivered Volumes

Requirements ID SVA_AS_F018	Status: Mandatory	Title Report Secondary BM Unit Supplier Delivered Volumes	BSC Reference
Method: Automatic	Frequency	Volumes
Functional Requirement: The SVA AS shall report the adjusted the Secondary BM Unit Supplier Delivered volumes to SAA. The SVA AS shall produce the reports daily in accordance with SSR Run schedule, each file contains data for a Settlement Day and Settlement Run.
Non-Functional Requirement
Interfaces:
P0290
Issues

5.26 Calculation of Supplier BM Unit Non BM ABSVD

Requirements ID

SVA_AS_F019

Status:

Title

Calculation of Supplier BM Unit Non BM ABSVD

BSC Reference

P354

Man/auto:

Automatic

Frequency

Volumes

Functional Requirement:

The SVAA shall calculate the Supplier BM Unit Non BM ABSVD

For each Metering System Delivered Volume (QVMD_Kj) value for a Metering System associated with the NETSO in the SVA Metering System Register, the SVAA shall determine the ABSVD BM Unit Delivered Volume (AQVMD_iNLKj) by assigning the Metering System Delivered Volume value to the relevant Supplier BM Unit "i" as recorded in the SVA Metering System Register, Line Loss Factor Class "L" and Consumption Component Class "N".

The SVAA shall determine the MSID ABSVD (Non Losses) (MSABSVD_iNKj) within Consumption Component Class "N" (which Consumption Component Class shall not be a Consumption Component Class for line losses) for each Metering System "K" for each Supplier BM unit "i" according to the following formula:

MSABSVD_iNKj = AQVMD_iNLKj

The SVAA shall determine the MSID ABSVD (Losses) (MSABSVDLiNKj) within Consumption Component Class "N" (which Consumption Component Class shall be a Consumption Component Class for line losses) for each Metering System "K" for each Supplier BM Unit "i" according to the following formula:

MSABSVDLiNKj = (∑^(vv)_L ((LLFLj - 1) * ∑ ^(vv)_PR AQVMD_iNLKj))

The SVAA shall send MSID ABSVD (Losses) (MSABSVDL_iNKj) and MSID ABSVD (Non Losses) (MSABSVD_iNKj) for those MSIDs which have Customer consent (supplied in the ABS MSID Pair data notified to the SVAA) to the relevant Supplier.

The SVAA shall determine the Corrected MSID ABSVD Component (CORABSVDC_iNKj) for each Consumption Component Class "N" within Supplier BM Unit "i" according to the following formula:

CORABSVDC_iNKj = (MSABSVD_iNKj+ MSABSVDL_iNKj) * (1 + (CFH_j - 1) * WTN)

where WTN is the associated GSP Group Correction Scaling Weight and CFH_j is the value of GSP Group Correction Factor for the GSP Group "H" associated with the Supplier BM Unit "i".

In respect of each Supplier BM Unit "i", the SVAA shall determine the Supplier BM Unit Non BM ABSVD (SNBABSVD_ij) for each Settlement Period "j" according the following formula:

SNBABSVD_ij= ∑N CORABSVDC_iNKj

Non-Functional Requirement

Interfaces

P0287 Metering System Half Hourly Volume Adjustments

Issues

5.27 Determination of Settlement Expected Volumes

Requirements ID

SVA_AS_F020

Status:

Title

Determination of Settlement Expected Volumes

BSC Reference

P376

Man/auto:

Automatic

Frequency

Volumes

Functional Requirement:

1. The SVAA shall determine the MSID Baseline Value (MBV_KiLj) for each SVA Metering System “K” in a Baselined MSID Pair.

2. The SVAA shall determine the AMSID Baseline Value (AMBV_KiLj) for each Asset Metering System “K” in a Baselined AMSID Pair.

3. The SVAA shall determine the Net Differencing Baseline Value (NDBV_ij) for each set of SVA Metering Systems and Asset Metering Systems that are related to each other for purposes of differencing in accordance with paragraph 7.1.1CA in Section S-2.

i. For each MSID Baseline Value (MBVKiLj), the SVAA shall determine the MSID Baseline Losses (MBLKiLj) in accordance with the following formula:

MBLKiLj = (LLFLj - 1) * MBVKiLj

ii. For each AMSID Baseline Value (AMBVKiLj), the SVAA shall determine the AMSID Baseline Losses (AMBLKiLj) in accordance with the following formula:

AMBLKiLj = (LLFLj - 1) * AMBVKiLj

iii. For each Baselined BM Unit “i” and Settlement Period “j”, the SVAA shall exclude any Metering System “K” that is within an MSID Pair identified as Inactive and determine the Baselined Expected Volume (BEVij) in accordance with the following formula:

BEVij = ∑K (MBVKiLj + MBLKiLj) + ∑K^NonDiff (AMBV_KiLj+ AMBL_KiLj) – ∑_K^Diff(AMBV_KiLj + AMBL_KiLj)

iv. For each Baselined BM Unit “i” and Settlement Period “j”, the SVAA shall determine the Party Submitted Expected Volume (PSEV_ij) as the Submitted Expected Volume submitted by the Lead Party and validated by the SVAA in accordance with Section S13. Where no such value was submitted and validated:

(a) If all the MSID Pairs and/or AMSID Pairs within the Baselined BM Unit are Baselined MSID Pairs and/or AMSID Pairs, SVAA shall determine the Party Submitted Expected Volume (PSEV_ij) to be zero; and

(b) Otherwise, SVAA shall not determine a value of Party Submitted Expected Volume (PSEV_ij).

v. For each Party Submitted Expected Volume (PSEV_ij) value determined in accordance with paragraph iv., the SVAA shall determine the Settlement Expected Volume (SEV_ij) in accordance with the following formula:

SEV_ij = BEV_ij+ PSEV_ij

vi. The SVAA shall provide the SAA with the Settlement Expected Volume (SEVij) for each Baselined BM Unit “i” for each Settlement Period "j" for each Volume Allocation Run. Where no such value was determined in accordance with paragraph v., the SVAA shall not provide a value to SAA.

Non-Functional Requirement

Interfaces

Issues

5.28 Report Supplier BM Unit Non BM ABSVD

Requirements ID SVA_AS_F021	Status: Mandatory	Title Report Supplier BM Unit Non BM ABSVD	BSC Reference
Method: Automatic	Frequency	Volumes
Functional Requirement: 1. The SVA AS shall report the Supplier BM Unit Non BM ABSVD ((SNBABSVD_ij) to SAA. 2. The SVA AS shall produce the reports daily, and each file shall contain data for a Settlement Day and Settlement Run.
Non-Functional Requirement
Interfaces:
P0296 Supplier BM Unit Non BM ABSVD
Issues

5.29 Submission of EMR MSID Declarations and for EMR AMSID Declarations

Requirement ID:

SVA_AS-F022

Status:

Title:

Submission of EMR MSID Declarations and for EMR AMSID Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where a Supplier intends to register Metering Systems and, where applicable, Asset Metering Systems, on the SVA Metering System and Asset Metering System Register for the purposes of calculating Period BM Unit Non Chargeable Demand, it shall submit a EMR Declaration, which may be either:

(a) an EMR MSID Declaration containing one Metering System Number; or

(b) an EMR AMSID Declaration containing one or more MSID Pairs and one or more AMSID Pairs,

to the SVAA in accordance with BSCP602, and shall keep the SVAA informed of any amendments or updates to that EMR Declaration.

Each Supplier shall ensure that Metered Data for each Settlement Period of each Settlement Day are made available to the SVAA, in respect of all of such Supplier’s Metering System Numbers and Asset Metering System Numbers which are listed on the SVA Metering System and Asset Metering System Register and subject to half hourly metering.

If a Generator or Storage Facility consumes Import Active Energy through a SVA Metering System and such Import Active Energy is allocated between two or more Suppliers, each such Supplier shall ensure that Metered Data for each Settlement Period of each Settlement Day shall be made available to the SVAA in respect of all of such Supplier’s Metering System Numbers associated with Metering Systems which are listed on the SVA Storage Facilities Register and subject to half hourly metering.

Each Supplier shall ensure that each of its Half Hourly Data Aggregators shall in respect of that Supplier’s Metering Systems listed on the SVA Metering System and Asset Metering System Register as part of an EMR Declaration for which that Half Hourly Data Aggregator is responsible and in respect of a particular Settlement Day:

(a) receive half hourly Supplier's Metering System Metered Consumption from the relevant Half Hourly Data Collectors;

(b) undertake checks and provide reports in accordance with BSCP503; and

Each Supplier shall ensure that each of its Half Hourly Data Collectors shall in respect of that Supplier’s Asset Metering Systems listed on the SVA Metering System and Asset Metering System Register as part of an EMR Declaration for which that Half Hourly Data Collector is responsible and in respect of a particular Settlement Day:

a) Collect or, where such has been appointed by the Supplier, receive from the relevant Asset Metering Half Hourly Data Collector half hourly Asset Metering System Metered Consumption;

b)undertake checks and provide reports in accordance with BSCP603;

c) provide to the SVAA the Actual half hourly Asset Metering System Metered Consumption data for the Initial Settlement Volume Allocation Run where available, otherwise Estimated half hourly Asset Metering System Metered Consumption data;

d) where Estimated half hourly Asset Metering System Metered Consumption data has been provided for an Asset Metering System Number to the SVAA pursuant to (c), the Half Hourly Data Collector shall be required to provide, where available, Actual data for that Asset Metering System Number for the next Volume Allocation Run; and

(e) where Actual half hourly Asset Metering System Metered Consumption data has been provided for an Asset Metering System Number to the SVAA pursuant to (c) or (d), the Half Hourly Data Collector shall not be required to provide such data for any subsequent Volume Allocation Run;

The SVAA shall determine the Period BM Unit Non Chargeable Demand in respect of an EMR Declaration. In respect of an EMR Declaration, and in each case in accordance with BSCP508, the SVAA shall:

(a) validate each EMR Declaration submitted by a Supplier pursuant to paragraph;

(b) register all details submitted in a valid EMR Declaration in the SVA Metering System and Asset Metering System Register;

(d) provide reports and information to BSCCo including submissions and validations made pursuant to this paragraph 14 and associated calculations and data; and

(e) maintain and publish a record of all Generation and SVA Storage Facilities that have been included in a valid EMR Declaration.

Non-Functional Requirements:

Interfaces:

Issues:

5.30 Calculate Period BM Unit Non Chargeable Demand

Requirements ID

SVA_AS_F0023

Status:

Title

Calculate Period BM Unit Non Chargeable Demand

BSC Reference

Man/auto

Automatic

Frequency

As required

Volumes

Functional Requirement

The SVAA shall determine the Period BM Unit Non Chargeable Demand for EMR MSID Declarations containing one or more Metering System Numbers and EMR AMSID Declarations containing one or more MSID Pairs and one or more AMSID Pairs.

Case 1 – For each Allocated Metering System Metered Consumption (AVMMC_HZaNLKji) value for an Import Metering System “K” in an EMR MSID Declaration “D”, SVAA shall determine the Metering System Non-Chargeable Consumption (NCMC_iNLKj) and Metering System Non-Chargeable Losses (NCML_iNLKj) for each Import Metering System K included in the Declaration and each Settlement Period j.

This shall be calculated as follows:

NCMCiNLKj = AVMMCHZaNLKji / 1000

NCMLiNKj = NCMCi(vv)LKj * (LLFLj – 1)

where "(vv)" is the Consumption Component Class (not for line losses) associated with the Consumption Component Class "N" for which the value of NCML_iNKj is to be determined.

Case 2 - For each EMR AMSID Declaration “D”, SVAA shall determine the “Metering System Non-Chargeable Consumption” (NCMCiNLKj) and “Metering System Non-Chargeable Losses” (NCMLiNLKj) for each Import Metering System K included in the Declaration and each Settlement Period j.

a) Determine the AMSID Declaration Boundary Point Import (ADBPIDi) as follows:

ADBPIDi = ∑K (AVMMCHZaNLKji * LLFLj / 1000)

where ∑K denotes the summation over all Import Metering Systems “K” associated with the EMR AMSID Declaration “D”;

b) Determine the AMSID Declaration Boundary Point Export (ADBPE_Di) as follows:

ADBPE_Di = ∑_K (AVMMC_HZaNLKji * LLF_Lj / 1000)

where ∑_K denotes the summation over all Export Metering Systems “K” associated with the EMR AMSID Declaration “D”;

c) Determine the AMSID Declaration Storage Import (ADSI_Di) as follows:

ADSI_Di = ∑_K (AAVMMC_HNLKj * LLF_Lj / 1000)

where ∑_K denotes the summation over all Import Asset Metering Systems “K” associated with Storage in the EMR AMSID Declaration “D”;

d) Determine the AMSID Declaration Storage Export (ADSE_Di) as follows:

ADSE_Di = ∑_K (AAVMMC_HNLKj * LLF_Lj / 1000)

where ∑_K denotes the summation over all Export Asset Metering Systems “K” associated with Storage in the EMR AMSID Declaration “D”;

e) Determine the AMSID Declaration Generation Import (ADGI_Di) as follows:

ADGI_Di = ∑_K (AAVMMC_HNLKj * LLF_Lj / 1000)

where ∑_K denotes the summation over all Import Asset Metering Systems “K” associated with Licensed Generation in the EMR AMSID Declaration “D”;

g) Determine the AMSID Declaration Generation Export (ADGEDi) as follows:

ADGE_Di = ∑_K (AAVMMC_HNLKj * LLF_Lj / 1000)

where ∑_K denotes the summation over all Export Asset Metering Systems “K” associated with Licensed Generation in the EMR AMSID Declaration “D”;

g) In accordance with the On-Site Energy Allocation Methodology, determine the AMSID Declaration Non‑Chargeable Proportion (ADNCPDj), which is a number between 0.0 and 1.0 inclusive representing the proportion of Boundary Point Imports to the Import Metering Systems included in the EMR AMSID Declaration “D” that are deemed Non-Chargeable in that Settlement Period;

h) For each Import MSID K included in the EMR AMSID Declaration, determine the Metering System Non-Chargeable Consumption (NCMC_iNLKj) as follows:

NCMC_iNLKj = ADNCP_Dj * AVMMC_HZaNLKji / 1000

i) For each Import MSID K included in the Declaration, calculate the Metering System Non-Chargeable Losses (NCML_iNLKj) in accordance with the following formula:

NCML_iNLKj = NCMC_i(vv)LKj * (LLF_Lj – 1)

where "(vv)" is the Consumption Component Class (not for line losses) associated with the Consumption Component Class "N" for which the value of NCML_iNKj is to be determined.

Case 3 - The SVAA shall determine the Non-Chargeable Consumption (Non Losses) (NCC_iNj) within Consumption Component Class "N" (which Consumption Component Class shall not be a Consumption Component Class for line losses) for each Supplier BM Unit "i" according to the following formula:

NCC_iNj = ∑_LK NCMC_iNLKj

where Metering System Non-Chargeable Consumption (NCMC_iNLKj) are determined pursuant to paragraphs 3.11.1 and 3.11.2(h).

Case 4 - The SVAA shall determine the Non-Chargeable Consumption (Losses) (NCCLOSS_iNj) within Consumption Component Class "N" (which Consumption Component Class shall be a Consumption Component Class for line losses) for each Supplier BM Unit "i" according to the following formula:

NCCLOSS_iNj = ∑_LK NCML_iNLKj

where Metering System Non-Chargeable Losses (NCML_iNLKj) are determined pursuant to paragraphs 3.11.1 and 3.11.2(i).

Case 5 - The SVAA shall determine the Non-Chargeable Corrected Component (NCCORC_iNj) for each Consumption Component Class "N" within Supplier BM Unit "i" according to the following formula:

NCCORC_iNj = (NCC_iNj + NCCLOSS_iNj) * (1 + (CF_Hj - 1) * WT_N)

where WT_N is the associated GSP Group Correction Scaling Weight and CF_Hj is the value of GSP Group Correction Factor determined pursuant to paragraph 9.2 for the GSP Group "H" associated with the Supplier BM Unit "i".

Case 6 - The Period BM Unit Non Chargeable Demand (NCBMUD_ij) shall be determined by the SVAA by aggregating the Non-Chargeable Corrected Components (NCCORC_iNj) for each Supplier BM Unit "i" and Settlement Period "j":

NCBMUD_ij = ∑_N NCCORC_iNj

The SVAA shall send the Period BM Unit Non Chargeable Demand to the SAA in the SAA-I057 ‘Supplier BM Unit Non Chargeable Demand’, which is also called the P0338.

Non-Functional Requirement

Interfaces

SAA-I057 – Supplier BM Unit Period Non-Chargeable Demand

Issues

6 Interface Requirements

The SVA AS shall provide an interface to the following BSC Parties, Party Agents and Systems. Please refer to the System Context Diagram for data flows.

External Parties:

Virtual Lead Parties and Asset Metering Virtual Lead Parties
Half Hourly Data Aggregators
Half Hourly Data Collectors
Suppliers
The NETSO

BSC Systems

SAA
SVAA
MSAMSR

7 Non-functional Requirements

This section specifies the Non-Functional Requirements for the SVA AS

Req. No.	Requirement Name	Requirement
SVA_AS_N001	Reliability	The SVA AS must be always on 100% and reliably performing its main business functions with the exceptions: Where there is a planned BSC Systems downtime
SVA_AS_N002	Availability	BSC operations relating to the SVAA Aggregation Service must be completed with 100% success rate for E2E settlement process in accordance with the Settlement Calendar and BSC Obligations.
SVA_AS_N003	Auditing	The SVAA Aggregation Service (SVA AS) will need to record an audit log of all business transactions. Such business transactions shall include; Receipt of Data, Technical/Business Validation, Use of Substitute data, Calculations, manual interventions, reporting and error logs.
SVA_AS_N004	Assurance	The SVAA Aggregation Service must be able to: 1. Demonstrate which data set was used in settlement of BM Acceptances and RR Activations or the calculation of Supplier BM Unit Non BM ABSVD, as appropriate. 2. Demonstrate how the results of any individual settlement of BM Acceptances and RR Activations, or how Supplier BM Unit Non BM ABSVD was derived. 3. Track and/or re-run any individual settlement of BM Acceptances and RR Activations process or calculation of Supplier BM Unit Non BM ABSVD to recreate the results exactly as originally generated, as a historic report. 4. Track and/or re-run settlement of BM Acceptances and RR Activations or calculation of Supplier BM Unit Non BM ABSVD rules over time in order to apply calculation rule, which was in force at the date on which the trading day was first settled, or alternatively to apply retrospectively an amended calculation rule. 5. Track and review warning and/or error logs generated by a settlement Run. 6. Track, review, and investigate Settlement of BM Acceptances and RR Activations or calculation of Supplier BM Unit Non BM ABSVD issues and disputes.
SVA_AS_N005	Archiving	Active Data – 40 months. Historic Data - must be archived.

8 Service Requirements

There are no specific service requirements for the SVA AS.

9 User Roles and Activities

The following table describes the user roles which will support the day to day operation of the SVA AS.

Role	Activities
System Administrator	Database management Specific aspects of system configuration User account and security management
Supervisor	Management of operators Management of standing data updates Co-ordination of creation of the Settlement Calendar Management of planned operational activities to meet Settlement Calendar timescales and service level requirements Creation of management information reports Support for communication with external parties
Operator	Performance of procedures to monitor receipt and processing of information from external parties. Performance of procedures to initiate and monitor settlement runs and reports. Second level support for ad hoc queries raised by external parties
Help Desk Operator	First level support for ad hoc queries raised by external parties. Note that the Help Desk facility shall be shared by more than one service Capture.
Auditor	There shall be a specific user security configuration which allows an external auditor to review data within the system, but prevents the initiation of batch processes or logical edits to business data.

APPENDIX I: SVA REQUIREMENTS FOR REPORTING DEMAND DATA TO THE NETSO FOR THE CALCULATION OF NETWORK CHARGES FOR NON-FINAL DEMAND FACILITIES

SVAA User Requirements Specification for reporting demand data to the NETSO for the calculation of network charges for storage facilities

Synopsis: The SVAA is responsible for the receipt, validation, processing, storage and communication to NETSO of demand data from Half Hourly Data Aggregators (HHDAs) for SVA Metering Systems (MSIDs) notified as belonging to SVA Non-Final Demand Facilities. SVAA will use the data collected from HHDAs to calculate:

Aggregated demand from storage facilities in each SVA BMU for each HH ‘Period BMU Gross Storage Demand’ and each Settlement Day ‘Daily BMU Gross HH Storage Demand’; and
Corrected demand for SVA BMUs for each Settlement Period ‘Corrected Period BMU Gross HH Demand’ and each Settlement Day ‘Corrected Daily BMU Gross HH Demand’.

These data items will form part of the P0210 TUoS report, submitted to the NETSO to inform network charging.

1 Introduction

This Appendix I sets out the User Requirements for SVAA to process demand data related to Storage Facilities for the purpose of correcting network charging, a service provided by the SVAA BSC Agent. It is one of a set of documents forming the baseline for requirements of the seven BSC central system services. The aforementioned document set comprises:

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS;

The objective of this Appendix I is to provide a specification of the requirements that the SVAA must meet in respect of the function of corrected demand sent to NETSO in relation to Storage Facilities for network charging purposes (‘the relevant SVAA function’ for this purpose of this Appendix I), from the users’ point of view. For this purpose, the “users” include BSCCo Ltd, Suppliers and their Agents and the SVAA Service Provider’s own operators.

The SVAA will implement these requirements in a way consistent with the delivery of all other SVAA functional requirements. The requirements include new Data Items and specify new Data Flows, which the SVAA will implement in addition to the items in Sections 6 and 7 of this document.

2 Scope of Specification

This Appendix I provides a specification of the requirements for the relevant SVAA function that supports the implementation of the Balancing and Settlement Code. The requirements are described from the point of view of the relevant SVAA function users.

The document is divided into the following sections.

Section 3, Business and System Overview – describes the business context of the Service;

Section 4, Functional Requirements – describes the functional requirements of the Service from the point of view of the Service users;

Section 5, Interface Requirements – describes the interfaces with the external users of the Service;

Section 6, Non-Functional Requirements – describes the non-functional requirements of the Service, such as auditing, security and resilience;

3 Business and System Overview

This section provides an overview of the SVAA user requirements and is for indicative purposes only. The definitive statement of user requirements is given in the subsequent sections.

3.1 Summary of Business Requirements

SVAA shall receive, validate and store the inbound data, provided by BSC Parties, Party Agents and other BSC Services, and perform calculations based on the most recent validated data. This operation shall be performed in accordance with the requirements. SVAA will also produce reports for distribution to the NETSO.

The following table summarises the functional requirements of the relevant SVAA function These are further described in detail in Section 4 – Functional Requirements, including the source reference for each requirement.

Requirement ID.	Type	User Requirement
SVAA RF F001	Functional	Receive Declaration from Supplier
SVAA RF F002	Functional	Process Declarations and assign status
SVAA RF F003	Functional	Track changes to MSID details
SVAA RF F004	Functional	Validation of New Declarations
SVAA RF F005	Functional	Validation of Change of Supplier Declarations
SVAA RF F006	Functional	Validation of Change of MSID Declarations
SVAA RF F007	Functional	Validation of Change of Agent Declarations
SVAA RF F008	Functional	Validation of Withdrawal Declarations
SVAA RF F009	Functional	End Storage Facility as Central Action
SVAA RF F010	Functional	Notifications to Supplier
SVAA RF F011	Functional	Send D0354
SVAA RF F012	Functional	Investigate missing/incorrect metered data
SVAA RF F013	Functional	Liaise with HHDA on rejection of D0354
SVAA RF F014	Functional	Receive and store valid metered data
SVAA RF F015	Functional	Calculate Storage Demand Volumes
SVAA RF F016	Functional	Update instruction flows
SVAA RF F017	Functional	Revoke HHDA instruction to provide metered data
SVAA RF F018	Functional	Report demand volumes to NETSO
SVAA RF F019	Functional	Make data subject to Declaration available to BSCCo
SVAA RF F020	Functional	Maintain validity of Declarations
SVAA_RF_N001	Non-Functional	Archiving

3.2 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: a unique identifier for the requirement, as described above.

Status: while the majority of relevant SVAA function requirements will be mandatory for the Go Live date, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: a short descriptive title for the requirement.

Man/auto: this field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism.

Volumes: data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

4 Functional Requirements

This section describes the detailed set of functional requirements for the relevant SVAA function.

4.1 Receive Declaration from Supplier

Requirement ID: SVAA RF_F001	Status: M	Title: Receive Declaration from Supplier	BSC reference:
Man/auto: Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVAA shall receive Declarations from Suppliers. Declarations will contain the following information: Source (x1) Supplier Contact Email Address Supplier MPID Declaration (x1) Declaration Type Declaration Set ID Declaration Declaration Effective Date Storage Facility Operator (SFO) (x1) SFO Participant ID SFO Company Number SFO Company Name SFO Company Address SFO Company Director SFO Contact Name SFO Contact Phone SFO Contact Email Storage Facility (SF) (x1) SF ID SF Name SF Address/Location SF Description SF Effective From Date SF Effective To Date SF Total MSIDs Count Metering System (xN) MSID MS Import Export Indicator MS GSP Group MS SF Effective From Date MS SF Effective To Date MS Supplier Effective From Date MS HHDA MPID MS HHDA Effective From Date SVAA shall create Data Items and Relationships to store Declaration items, including mapping the following relationships: Map storage facility to Operator Name. Map storage facility to MSID(s). Map Operator(s) to Supplier(s). Map MSID(s) to HHDA appointment (same process as the existing MSID Pair model). Map MSID(s) to Supplier (same process as the existing MSID Pair model). SVAA shall map effective from date and effective to date of the above relationships. HHDA Appointments Effective Dates must overlap with the MSID Pair Effective Dates range,
Non-Functional Requirements:

Interfaces:

Issues:

4.2 Process Declarations and assign status

Requirement ID: SVAA_RF_F002	Status: M	Title: Process Declarations and assign status	BSC reference:
Man/auto: Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVAA shall process Declarations and updates to Declarations according to the following processes; For new declarations, Change of Supplier Declarations and Change of MSID declarations: SVAA shall create a Declaration associated with a Supplier, enter the declaration type and store details of the Declaration. SVAA shall manually validate the declaration according to SVAA RF F004, SVAA RF F005 or SVAA RF F006 as applicable. SVAA shall create the Supplier registration and HHDA appointment, and submit the Declaration to automatic validation according to SVAA RF F004, SVAA RF F005 or SVAA RF F006 as applicable. For a Change of Agent Declaration: SVAA shall validate the submission according to SVAA RF F007, create a Declaration associated with a Supplier, match the Storage Facility Role, Storage Facility and MSID(s) and validate with existing Declaration. Following successful validation, SVAA shall submit the declaration to automatic validation according to SVAA RF F007. For Withdrawal Declaration: SVAA shall create a Declaration and match the details with existing Declaration. SVAA shall validate the submission according to SVAA RF F008 and following successful validation submit the declaration to automatic validation according to SVAA RF F008. SVAA shall assign a status to each Declaration and MSIDs within a Declaration. Status will be one of: Draft (in process of validation) Submit Incomplete (where the set of MSIDs in related declarations does not include all the MSIDs of the Storage Facility) Reject Valid Obsolete
Non-Functional Requirements:

Interfaces:

Issues:

4.3 Track changes to MSID Details

Requirement ID: SVAA_RF_F003	Status: M	Title: Track changes to MSID details	BSC reference:
Man/auto: Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVAA shall ensure that MSID records created or amended according to BSC processes including this relevant SVAA function are consistent for the period of time that the MSID records overlap. SVAA shall use the most updated MSIDs, and maintain a process for marking MSIDs as Pending where MSID information does not match. On registering new MSIDs with the same Import or Export MSID and concurrent effective dates as another MSID, SVAA shall verify existing data for that MSID and apply any existing data to the new MSID. SVAA shall manually validate MSIDs created in this way and update accordingly. SVAA shall ensure Supplier and HHDA records match for the new and existing MSID submissions. If records do not match, SVAA shall reject the new MSID.
Non-Functional Requirements:

Interfaces:

Issues:

4.4 Validation of New Declarations

Requirement ID:

SVAA_RF_F004

Status:

Title:

Validation of New Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall process Declaration type ‘New’ where there are is no existing valid Declaration for the Storage Facility identified in the Declaration.

SVAA shall validate New Declarations as follows;

For each step if validation passes proceed to next step

Step	Validation	Condition	Manual/ Automatic	Result
1	Declaration ID	The Declaration ID must not be present for a New declaration.	Automatic (A)	If declaration ID is present for a New declaration, the Declaration is rejected and the supplier is notified
2	Check if operator details already recorded		Manual (M)	If yes check operator details match
3	Check operator details match	If operator details already recorded then Declaration must match	M	If details do not match reject Declaration and inform Supplier
3a	Check Declaration set ID is new for SFO	Check Declaration for same SFO and that Declaration Set ID is not already Valid/Obsolete	A	If Declaration Set ID has been used by SFO then reject Declaration and inform Supplier
4	Check operator details	Check SFO registered on Companies House. Check SFO Company Number matches Electricity Generation license	M	If details not present reject Declaration and inform Supplier
5	Check Storage Facility details match live Storage Facility	Check Storage Facility is not already live with overlapping dates in other Declaration	M	If Storage Facility already live reject Declaration and inform Supplier
	For each MSID in the declaration
6	Check MSID in ECOES	Check MSID is energised, registered to correct Supplier, MSID EFD/ETD overlap with Storage Facility Period, Import/Export match, GSP Group match, HHDA match, MSIDs are SVAA HH MSIDs	M	If MSID details are not valid reject Declaration and inform Supplier. If MSIDs are not SVA HH MSIDs reject Declaration and inform Supplier
7	Check MSIDs in other declaration in same set	MSID cannot be in same Storage Facility with more than one Supplier at same time	A	If MSID in another overlapping declaration in same set reject Declaration and inform Supplier
7a	Check MSIDs in other live storage facilities	MSID cannot be in more than one Storage Facility at one time	A	If MSID in overlapping live Storage Facilities reject Declaration and inform Supplier
8	Check MSID registered for other purposes	If MSID registered for other purpose check HHDA and Supplier	A	If HHDA/Supplier do not match for overlapping periods suspend Declaration. Records can be corrected and validation continued.
9	Check related declarations	Declarations of same type with same Declaration Set ID	A	If no, set timer for 5 days. After 5 days for Declarations marked incomplete reject Declaration and inform Supplier
10	For all related Declarations	Declarations of same type with same Declaration Set ID	A	If no, set timer for 5 days. After 5 days for Declarations marked incomplete reject Declaration and inform Supplier
11	Check MSID count	MSID count equal MSIDs in related Declarations. Check completeness of related Declarations	A	If no, mark as incomplete and inform Supplier.
12	Check Import/Export	Set includes Import/Export MSIDs	A	If no reject Declaration and inform Supplier
12a	Check MSID count	Related Declarations complete. MSID count matches MSIDs in related Declarations	A	If no, mark as incomplete and inform Supplier
13	Check related details match	Storage Facility and Operator details match	A	If no, reject Declaration and inform Supplier. If yes, Declaration marked as valid, generate Declaration ID, notify Supplier.
14	Incomplete after 5 days		A	Once Declaration incomplete for 5 days reject Declaration and related Declarations and inform Supplier

Non-Functional Requirements:

Interfaces:

Issues:

4.5 Validation of Change of Supplier Declarations

Requirement ID:

SVAA_RF_F005

Status:

Title:

Validation of Change of Supplier Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall process Declaration type ‘Change of Supplier’ (CoS) where there is a current valid set of Declarations for a Storage Facility and there is a change of Supplier.

SVAA shall validate CoS Declarations as follows;

For each step if validation passes proceed to next step unless result indicates otherwise

Step	Validation	Condition	Manual/ Automatic	Result
1	Declaration ID	The Declaration ID must be present for a CoS declaration and relate to a live Declaration.	Automatic (A)	If Declaration does not contain Declaration ID relating to existing live Storage Facility reject Declaration and inform Supplier
2	Check operator details match	If operator details already recorded then Declaration must match	Manual (M)	If details do not match reject Declaration and inform Supplier
2a	Check Declaration set ID is new for SFO	Check Declaration for same SFO and that Declaration Set ID is not already Valid/Obsolete	A	If Declaration Set ID has been used by SFO then reject Declaration and inform Supplier
3	Storage Facility matches included Operator Contact Details		M	If details do not match reject Declaration and inform Supplier
4	MSID exists in existing Declaration and details match		M	If details do not match reject Declaration and inform Supplier
5	MSID not registered to new Supplier	Is Supplier in CoS Declaration different to Supplier for MSID	M	If yes, go to 6, if no, go to 9
6	MSID ECOES details match	New Supplier and HHDA EFD/ETD match	M	If details do not match reject Declaration and inform Supplier
7	MSID live in other Declaration with overlapping EFD/ETD		A	If MSID is live in other Declaration with overlapping EFD/ETD reject Declaration and inform Supplier
8	Check related declarations	Declarations of same type with same Declaration Set ID	A	If no, set timer for 5 days. After 5 days for Declarations marked incomplete reject Declaration and inform Supplier
	For all related Declarations
9	Check MSID count	MSID count equal MSIDs in related Declarations. Check completeness of related Declarations	A	If no, mark as incomplete and inform Supplier.
10	Check Import/Export	Set includes Import/Export MSIDs	A	If no reject Declaration and inform Supplier
11	At least one CoS	A CoS Declaration set must include one CoS	A	If CoS declaration with no CoS reject Declaration and inform Supplier
12	Check related details match	Storage Facility and Operator details match	A	If no, reject Declaration and inform Supplier. If yes, Declaration marked as valid, generate Declaration ID, notify Supplier.
13	Incomplete after 5 days		A	Once Declaration incomplete for 5 days reject Declaration and related Declarations and inform Supplier

Non-Functional Requirements:

Interfaces:

Issues:

4.6 Validation of Change of MSID Declarations

Requirement ID:

SVAA_RF_F006

Status:

Title:

Validation of Change of MSID Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall process Declaration type ‘Change of MSID’ (CoM) where there is a current valid set of Declarations for a Storage Facility and there is a change of MSIDs included in the Storage Facility.

SVAA shall validate CoM Declarations as follows;

For each step if validation passes proceed to next step unless result indicates otherwise

Step	Validation	Condition	Manual/ Automatic	Result
1	Data Complete, MSID formatted		Manual (M)	If Declaration incomplete reject Declaration and inform Supplier
2	Declaration ID	The Declaration ID must be present for a CoM declaration and relate to a live Declaration.	Automatic (A)	If Declaration does not contain Declaration ID relating to existing live Storage Facility reject Declaration and inform Supplier
3	Check operator details match	If operator details already recorded then Declaration must match	M	If details do not match reject Declaration and inform Supplier
3a	Check Declaration set ID is new for SFO	Check Declaration for same SFO and that Declaration Set ID is not already Valid/Obsolete	A	If Declaration Set ID has been used by SFO then reject Declaration and inform Supplier
4	Storage Facility matches included Operator Contact Details	Details other than MSID count must match	M	If details do not match reject Declaration and inform Supplier
5	Check Supplier already recorded for Storage Facility	Supplier must be registered for MSID that is retained	M	If Supplier not current Supplier at the Storage Facility reject Declaration and inform Supplier
6	Check MSID end date		M	If yes go to 7, if no go to 8
7	Check ETD after start date and before ETD of Storage Facility		M	If no reject Declaration and inform Supplier If yes MSID can be removed
8	Check MSID new in declaration		M	If no go to 9 If yes go to 10
9	Check MSID details match existing record	Details of Supplier, HHDA, GSP Group mMust match with current record	M	If no reject Declaration and inform Supplier
10	MSID ECOES details match	New Supplier and HHDA EFF match	M	If details do not match reject Declaration and inform Supplier
11	Check MSID in other declarations	Is MSID live in other Declaration with overlapping EFD/ETD	A	If yes, reject Declaration and inform Supplier
12	Check MSIDs registered for other purposes/HHDA mismatch	Check MSID registered for other purposes. If yes, do Supplier and HHDA match?	A	If HHDA/Supplier association records for Storage Facility MSID and existing MSID records do not match suspect Declaration. Records can be corrected and validation continued.
13	Check related declarations	Declarations of same type with same Declaration Set ID	A	If no, set timer for 5 days. After 5 days for Declarations marked incomplete reject Declaration and inform Supplier
	For set of Declarations
14	Check MSID count	MSID count equal MSIDs in related Declarations. Check completeness of related Declarations	A	If no, mark as incomplete and inform Supplier.
15	Check Import/Export	Set includes Import/Export MSIDs	A	If no reject Declaration and inform Supplier
16	At least one CoM	A CoM Declaration set must include one CoM	A	If CoM declaration with no CoM reject Declaration and inform Supplier
17	Details from related Declarations match	Storage Facility and Operator details match	A	If no match reject Declaration and inform Supplier. If yes, Declaration marked as valid, generate new Declaration ID, notify Supplier. Where required, obsolete MSID is end dated.
18	Incomplete after 5 days		A	Once Declaration incomplete for 5 days reject Declaration and related Declarations and inform Supplier

Non-Functional Requirements:

Interfaces:

Issues:

4.7 Validation of Change of Agent Declarations

Requirement ID:

SVAA_RF_F007

Status:

Title:

Validation of Change of Agent Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall process Declaration type ‘Change of Agent’ (CoA) where there is a current valid set of Declarations for a Storage Facility and a Supplier is recording a change of HHDA for one or more MSIDs.

SVAA shall validate CoA Declarations as follows;

For each step if validation passes proceed to next step unless result indicates otherwise

Step	Validation	Condition	Manual/ Automatic	Result
1	Data Complete, MSID formatted		Manual (M)	If Declaration incomplete reject Declaration and inform Supplier
2	Declaration ID	The Declaration ID must be present for a CoA declaration and relate to a live Declaration.	Automatic (A)	If Declaration does not contain Declaration ID relating to existing live Storage Facility reject Declaration and inform Supplier
3	Check operator details match	If operator details already recorded then Declaration must match	M	If details do not match reject Declaration and inform Supplier
3a	Check Declaration set ID is new for SFO	Check Declaration for same SFO and that Declaration Set ID is not already Valid/Obsolete	A	If Declaration Set ID has been used by SFO then reject Declaration and inform Supplier
4	Storage Facility matches included Operator Contact Details	Details other than MSID count must match	M	If details do not match reject Declaration and inform Supplier
5	ECOES validation	Supplier, HHDA, EFD/ETD match	M	If details do not match reject Declaration and inform Supplier
6	Check MSIDs registered for other purposes/HHDA mismatch	Check MSID registered for other purposes. If yes, do Supplier and HHDA match?	A	If HHDA/Supplier association records for Storage Facility MSID and existing MSID records do not match suspect Declaration. Records can be corrected and validation continued.
7	All validation successful		A	New HHDA appointment dates set, Declaration set to approved, inform Supplier

Non-Functional Requirements:

Interfaces:

Issues:

4.8 Validation of Withdrawal Declarations

Requirement ID:

SVAA_RF_F008

Status:

Title:

Validation of Withdrawal Declarations

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall process Declaration type ‘Withdrawal’ (WD) where there is a current valid set of Declarations for a Storage Facility and a Supplier is recording a that the Storage Facility is to cease operating as a Storage Facility.

SVAA shall validate WD Declarations as follows;

For each step if validation passes proceed to next step unless result indicates otherwise

Step	Validation	Condition	Manual/ Automatic	Result
1	Data Complete, MSID formatted		Manual (M)	If Declaration incomplete reject Declaration and inform Supplier
2	Declaration ID refers to live Storage Facility	The Declaration ID must be present for a WD declaration and relate to a live Storage Facility.	M	If Declaration does not contain Declaration ID relating to existing live Storage Facility reject Declaration and inform Supplier
3	Check operator details match	If operator details already recorded then Declaration must match	M	If details do not match reject Declaration and inform Supplier
3a	Check Declaration set ID is new for SFO	Check Declaration for same SFO and that Declaration Set ID is not already Valid/Obsolete	Automatic (A)	If Declaration Set ID has been used by SFO then reject Declaration and inform Supplier
4	Storage Facility matches included Operator Contact Details	Details other than MSID count must match	M	If details do not match reject Declaration and inform Supplier
5	MSID exists and registered to Supplier making Declaration		M	If no, reject Declaration and inform Supplier
6	All validation successful		A	New HHDA appointment dates set, Declaration set to approved, inform Supplier

Non-Functional Requirements:

Interfaces:

Issues:

4.9 End Storage Facility as Central Action

Requirement ID: SVAA_RF_F009	Status: M	Title: End Storage Facility as Central Action	BSC reference:
Man/auto: Manual & Automatic	Frequency: As Necessary	Volumes:
Functional Requirements:
SVAA shall record as invalid any Storage Facility discovered to no longer comply with the requirements for a Storage Facility following any SVAA investigation which may be triggered by any SVAA process.
Non-Functional Requirements:

Interfaces:

Issues:

4.10 Notifications to Suppliers

Requirement ID:

SVAA_RF_F010

Status:

Title:

Notifications to Supplier

BSC reference:

Man/auto:

Automatic

Frequency:

As required

Volumes:

Functional Requirements:

When a Declaration is rejected, SVAA shall send a notification with the reason or reasons for the rejection to the Supplier making that Declaration.

When a Declaration is determined to be incomplete, SVAA shall send a notification to the Supplier making that Declaration. Notifications of incomplete Declarations apply to Declarations within a set that do not complete the set of related Declarations

When a Declaration is determined to be valid, SVAA shall send a notification to the Supplier making that Declaration. Notifications of valid Declarations apply to the set of Declarations made.

When a Storage Facility reaches its ETD SVAA shall send a notification to all Suppliers involved. Notifications of Storage facilities reaching their ETD apply to the set of Declarations made.

Non-Functional Requirements:

Interfaces:

Issues:

4.11 Send D0354

Requirement ID:

SVAA_RF_F011

Status:

Title:

Send D0354

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall identify the correct Half Hourly Data Aggregator (HHDA) for the provision of Metering System Half-Hourly Metered Volume data for each MSID linked to a Declaration as follows;

SVAA shall identify all HHDAs where there is a valid set of Declaration, MSID and HHDA EFD and ETD values creating an active HHDA to MSID to Declaration relationship.

For each HHDA linked to an MSID with a current, valid Declaration SVAA shall create a D0354 file and send to the HHDAs.

SVAA shall maintain a target participate file sequence number, incrementing it for each new file created where that file requires a sequence number for that participant.

Non-Functional Requirements:

Interfaces:

D0354: Metering System Reporting Notification

Issues:

4.12 Investigate missing/incorrect metered data

Requirement ID:

SVAA_RF_F012

Status:

Title:

Investigate missing/incorrect metered data

BSC reference:

Man/auto:

Manual & Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Upon receipt of metered data from HHDA via D0385, the SVAA shall investigate instances where:

it receives metered data for a declared MSID, but Supplier ID in D0385 is different to Supplier ID in SVAA registration record; or
it receives metered data from a HHDA for a declared MSID that is different to HHDA in SVAA registration record for a given Volume Allocation Run.

The SVAA should investigate instances where it does not receive metered data for an MSID when it is expecting data.

If upon investigation the SVAA confirms a change of either Supplier or HHDA, then:

Where a Supplier changed, the SVAA should end date the Declaration(s) on the last day of the previous Supplier’s registration. New Supplier should not be notified in such instance. If SVAA requires D0385 data for a given MSID for a different purpose (e.g. reporting for Secondary BM Units), then SVAA will not issue D0354 to terminate instruction and therefore HHDA will be expected to continue submitting Metered Data.
Where a HHDA has changed in an event not related to Change of Supplier, the SVAA should appoint the new HHDA. Once the new HHDA accepted the appointment, the SVAA should update the Declaration record by end dating the old HHDA, and adding the new HHDA.

Non-Functional Requirements:

Interfaces:

D0385: Metering System Half Hourly Metered Data

Issues:

4.13 Liaise with HHDA on rejection of D0354

Requirement ID:

SVAA_RF_F013

Status:

Title:

Liaise with HHDA on rejection of D0354

BSC reference:

Man/auto:

Manual

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where a HHDA rejects an appointment, the SVAA should liaise with the HHDA and Supplier to understand the reason for rejection so it can resolve and subsequently confirm the/an appointment (by resending a D0354).

Non-Functional Requirements:

Interfaces:

Issues:

4.14 Receive and store valid metered data

Requirement ID:

SVAA_RF_F014

Status:

Title:

Receive and store valid metered data

BSC reference:

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

In respect of the relevant SVAA function and notwithstanding requirements from any other BSC process, SVAA shall process, validate and store all metered data received via D0385 in respect of MSIDs subject to a valid and current Declaration.

SVAA shall receive the D0385 via the Data Transfer Network (DTN) or as agreed with the relevant HHDA in accordance with Party Service Line 100.

SVAA shall process D0385 receipts according to the following steps;

1. The D0385 HHDA files are received for each GSP group and the combination of HHDA and GSP group shall be determined using SVAA reference data for “Storage MSID Details”. The combinations will be identified by finding entries where the settlement date is between the “HHDA Supplier Effective From Date” and “HHDA Supplier Effective To Date”. The combination of HHDA and associated GSP Group shall define the list of files expected for MSIDs associated with Storage Facilities.

2. File Receipt:

When a file is received SVAA shall record its receipt. Using the expected D0385 go through the list of HHDA and GSP group combinations to determine if all expected files have been received for that settlement day and code.

If before the SSR run date (i.e. a time trigger has not been received) and all expected files have been received, then aggregate (or re-aggregate if aggregation has already occurred), creating a new aggregated file and raising an event to notify that new data is available.

The service will select only data from MSIDS associated with a Storage Facility and then combine all of the data from all of the received HHDA files for the settlement day and create one file per settlement period that contains all of the data related to that settlement period. The newly created files are stored and transferred to enable the execution of calculation services.

When creating the output files, the input Allocated Metering System Metered Consumption will be converted into the Storage Metering System Metered Consumption using:

SVMMC_HZaNLKji = AVMMC_HZaNLKji / 1000

If after the SSR run date then do not create a new aggregated file.

3. Time Based Trigger:

When a time based trigger is received, then check if an aggregation has already occurred for the Settlement Period and code identified in the trigger. If it has then do nothing.

If an aggregation has not already occurred, i.e. because there is missing data, then aggregation occurs.

For each missing file for the settlement date/settlement code and HHDA and GSP group, then attempt to find a valid file for the same combination with an earlier settlement code; refer to domain data for the settlement code sequence. If a substitute file can be found then add the data to the aggregated file and raise a warning to record that the file for the HHDA and GSP group combination was substituted with the file for a different settlement code; the data needs to be available for BSCCo to retrieve.

When a substitute file cannot be found then raise a warning to record that no data was available for the HHDA and GSP group; the data needs to be available for BSCCo to retrieve. In this situation the aggregated file will have no entries for that HHDA and GSP group combination.

When aggregating data, create output files in the same manner as for step 2.

4. Manual Trigger:

When a manual trigger is received, then aggregation occurs, irrespective of whether it has previously occurred or whether we are after the SSR Run date.

When aggregating data, create output files in the same manner as for step 2.

5. Store the following set of data (extracted D0385 data):

MSID

Settlement Day

Settlement Period

Run Type (latest only)

GSP Group

BMU ID

CCC ID

LLFC ID

Metered Data

Storage Facility ID

Non-Functional Requirements:

Interfaces:

D0385: Metering System Half Hourly Metered Data

Issues:

4.15 Calculate Storage Demand Volumes

Requirement ID:

SVAA_RF_F015

Status:

Title:

Calculate Storage Demand Volumes

BSC reference:

Man/auto:

Automatic

Frequency:

For each Volume Allocation Run

Volumes:

Functional Requirements:

SVAA shall calculate for each settlement period for each Supplier BMU the Period BMU Gross Storage Demand (SDBMU_iHZmj). SVAA shall utilise Storage Facility Aggregated HH Metered Data obtained via D0385 and GSP Group Corrections obtained via L0054.

To calculate (SDBMU_iHZmj) SVAA shall run the following steps;

1. Calculate HH Storage Consumption (Non Losses) for import quantities only:

The SVAA shall determine the Half Hourly Storage Consumption (Non Losses) (SC_iHZNj) within Consumption Component Class "𝑁" (which Consumption Component Class shall not be a Consumption Component Class for line losses) for each Supplier BM Unit "𝑖" according to the following formula:

${S C}_{i H Z N j} = \sum_{a L K}^{N} ({S V M M C}_{H Z a N L K j i})$

Where SC_iHZNj is calculated for Consumption Component Class "𝑁" for each Import Metering System “𝐾” associated with a SVA Storage Facility, Supplier “Z”, BM Unit "𝑖" and Settlement Period “𝑗”.

Note the aggregation by HHDA, suffix 𝑎 has been included to indicate a transformation of the data rather than requiring a summation of the data.

2. Retrieve Line Loss Factor:

Retrieve the LLF data using the distributor id and LLFC id for the MSID, and to ensure the same data sets are used for all the calculations the latest valid file from the distributor containing the settlement date will be used where it was received on or before the calculation run began:

If LLF data is not present in reference for the LLFC Id and settlement period, then log a warning and default the LLF value to 1.

3. Calculate HH Storage Consumption (Losses) for import quantities only:

The SVAA shall determine the Half Hourly Storage Consumption (Losses) (SCLOSS_iHZNj) within Consumption Component Class "𝑁" (which Consumption Component Class shall be a Consumption Component Class for line losses) for each Supplier “Z”, BM Unit "𝑖" according to the following formula:

${S C L O S S}_{i H Z N j} = \sum_{a L K}^{v v} (({L L F}_{L j} - 1) * {S V M M C}_{H Z a N L K j i})$

Where Storage Metering System Metered Consumption (𝑆𝑉𝑀𝑀𝐶_{𝐻𝑍𝑎𝑁𝐿𝐾𝑗𝑖}) for each Import Metering System “𝐾” associated with a SVA Storage Facility and "(𝑣𝑣)" is the Consumption Component Class (for line losses) associated with the Consumption Component Class "𝑁" for which the value of SCLOSS_iHZNj is

to be determined.

Note the aggregation by HHDA, suffix 𝑎 has been included to indicate a transformation of the data rather than requiring a summation of the data.

4. Calculate Storage Corrected Component:

The Storage Corrected Component (SCORC_iHZNj) for each Consumption Component Class "𝑁" within Supplier BM Unit "𝑖" shall be determined by the SVAA according to the following formula:

${S C O R C}_{i H Z N j} = ({S C}_{i H Z N j} + {S C L O S S}_{i H Z N j}) \times (1 + ({C F}_{H j} - 1) \times {W T}_{N})$

Where 𝑊𝑇𝑛 is the associated GSP Group Correction Scaling Weight and 𝐶𝐹𝐻𝑗is the value of GSP Group Correction Factor determined pursuant to paragraph 9.2 for the GSP Group "𝐻" associated with the Supplier BM Unit "𝑖".

The HH Storage Consumption (Non Losses) (SC_iHZNj) and corresponding HH Storage Consumption (Losses) (SCLOSS_iHZNj) shall be retrieved and processed together (although, in normal operation, only one of the two values should be defined for any given BM Unit and CCC Id):

For a BM Unit and CCC Id combination, then if the values of SC_iHZNj and SCLOSS_iHZNj are both non-zero, then log a warning reporting that a CCC Id has both losses and non-losses. The output will continue to be included for that combination;

If the GSP GCF value is not available for the BM Unit and CCC Id combination, then log a warning reporting that the secondary corrected component could not be calculated and omit the output for that combination;

Based on the GSP Group Correction Scaling Weight based on the CCC Id from the reference data; if the value is not available then log a warning reporting that the corrected component could not be calculated and omit the output for the BM Unit and CCC Id combination;

When all values have been retrieved, calculate the secondary corrected component value. If a calculation could not be performed processing should continue to the next consumption.

5. Calculate Period BMU Gross Storage Demand:

The Period BM Unit Gross Storage Demand (SDBMU_iHZmj) shall be determined by the SVAA by aggregating the Storage Corrected Components (SCORC_iHZNj) for each Supplier BM Unit “𝑖", Measurement Class "𝑚" and Settlement Period "𝑗":

${S D B M U}_{i H Z m j} = \sum_{N \in M} {S C O R C}_{i H Z N j}$

SVAA shall derive the Period BM Unit Gross Storage Demand by summing the CORC for the relevant CCC IDs.

Non-Functional Requirements:

Interfaces:

Issues:

4.16 Update instruction flows

Requirement ID:

SVAA_RF_F016

Status:

Title:

Update instruction flows

BSC reference:

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where changes are made to MSIDs subject to a Declaration SVAA shall send updated D0354 instruction flow(s) to the relevant HHDA(s).

Non-Functional Requirements:

Interfaces:

D0385: Metering System Half Hourly Metered Data

Issues:

4.17 Revoke HHDA instruction to provide metered data

Requirement ID:

SVAA_RF_F017

Status:

Title:

Revoke HHDA instruction to provide metered data

BSC reference:

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

Where SVAA discovers that:

A given HHDA is not the SMRS registered HHDA for a facility’s MSID(s); or
A given MSID is no longer eligible to be a part of Declaration (e.g. disconnected MSID)

and that MSID is not a part of any other instructions made by SVAA (e.g. TERRE process), SVAA shall revoke the instruction to provide metered data sent to HHDA by sending D0354 with the ‘Effective to Settlement Date {MSCM}’ set to reflect the date on which the HHDA should cease reporting metered data.

Non-Functional Requirements:

Interfaces:

D0354: Metering System Reporting Notification

Issues:

4.18 Report demand volumes to NETSO

Requirement ID:

SVAA_RF_F018

Status:

Title:

Report demand volumes to NETSO

BSC reference:

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall report ‘Corrected Period BMU Gross HH Demand’, ‘Period BMU Gross Storage Demand’, ‘Daily BMU Gross Storage Demand’ and ‘Daily BMU Gross HH Storage Demand’ to the NETSO by adding these items to the P0210 (TUoS Report) Data Flow. SVAA shall use Period BMU Gross Storage Demand (SDBMU_iHZmj) and the Internal TUoS Report (HH/NHH) from the L0055 report to calculate the Corrected Period BMU Gross HH Demand, Daily BMU Gross Storage Demand and Daily BMU Gross HH Storage Demand.

The P0210 shall be sent according to existing timescales.

SVAA shall perform the following steps to calculate and add these items to the P0210 Data Flow:

1. SVAA shall reconstruct the TUoS Report (HH/NHH Split) from the Internal TUoS Report (HH/NHH Split)

2. SVAA shall insert Period BMU Gross Storage Demand field into the report. SVAA shall derive Corrected Period BMU Gross HH Demand and insert into the report.

Corrected Period BMU Gross HH Demand shall be derived as follows:

${C o r r e c t e d P e r i o d B M U G r o s s H H D e m a n d}_{i H Z m j} = {P e r i o d B M U G r o s s H H D e m a n d}_{i H Z m j} - {P e r i o d B M U G r o s s S t o r a g e D e m a n d}_{i H Z m j}$

Where Period BMU Gross HH Demand_{𝑖𝐻𝑍𝑚𝑗} is an existing item in the Internal TUoS Report (HH/NHH Split) input, under the HHB data record type group and Period BMU Gross Storage Demand_{𝑖𝐻𝑍𝑚𝑗} is received as input (on its own) by the service.

3. SVAA shall replace the TO3 record type group with the new version, containing Daily BMU Gross HH Storage Demand and Corrected Daily BMU Gross HH Demand.

Daily BMU Gross HH Storage Demand shall be derived as follows:

${D a i l y B M U G r o s s H H S t o r a g e D e m a n d}_{i H Z m D} = \sum_{j \in D} {P e r i o d B M U G r o s s S t o r a g e D e m a n d}_{i H Z m j}$

Where Period BMU Gross Storage Demand_{𝑖𝐻𝑍𝑚𝑗} is summed across every settlement period 𝑗 in a settlement day 𝐷

Corrected Daily BMU Gross HH Demand shall be derived as follows:

${C o r r e c t e d D a i l y B M U G r o s s H H D e m a n d}_{i H Z m D} = {D a i l y B M U G r o s s H H D e m a n d}_{i H Z m D} - {D a i l y B M U G r o s s S t o r a g e D e m a n d}_{i H Z m D}$

Where Daily BMU Gross HH Demand_{𝑖𝐻𝑍𝑚𝐷} is an existing item in the Internal TUoS Report (HH/NHH Split) input.

Non-Functional Requirements:

Interfaces:

P0210: TUoS Report (HH/NHH Split)

Issues:

4.19 Make data subject to Declaration available to BSCCo

Requirement ID:

SVAA_RF_F019

Status:

Title:

Make data subject to Declaration available to BSCCo

BSC reference:

Man/auto:

Automatic

Frequency:

As Necessary

Volumes:

Functional Requirements:

SVAA shall make the following data for every MSID that is subject to a Declaration (current and past) available to BSCCo:

Storage Facility details:

Storage Facility Name

Storage Facility Operator Name

Storage Facility Declaration start date

Storage Facility Declaration end date

Declaration ID

Declaration Status

Declaration Rejection Reason

Non-Functional Requirements:

Interfaces:

Issues:

4.20 Maintain validity of Declarations

Requirement ID: SVAA_RF_F020	Status: M	Title: Maintain validity of Declarations	BSC reference:
Man/auto: Automatic	Frequency: Monthly	Volumes:
Functional Requirements:
Every month after a Declaration is successfully validated SVAA shall repeat the validation originally made for the Declaration.
Non-Functional Requirements:

Interfaces:

Issues:

5 Interface Requirements

The SVAA shall interface with the following BSC Parties and Systems when performing the relevant SVAA function.

External Parties:

Suppliers
HHDAs
The NETSO

BSC Systems

SVAA
SVA BSR

6 Non-functional Requirements

This section specifies the Non-Functional Requirements for the relevant SVAA function, where not covered by existing SVAA non-functional requirements.

Req. No.	Requirement Name	Requirement
SVAA_RF_N001	Archiving	Details related to Declarations shall be kept in the system for at least 24 months following the latest EFD.

1 This is the start date of the British Electricity Trading and Transmission Arrangements, where the England and Wales Trading Arrangements are extended to Scotland.

2 SVA Metering System Numbers submitted by the NETSO will not have an associated BM Unit.

3 Not required if the MSID Pair is submitted by the NETSO

4 Not required if the MSID Pair is submitted by the NETSO

5 This process in not applicable where the NETSO and a Supplier / VLP / AMVLP notifies the SVA MSR of the same MSID Pair, although the SVAA shall inform the NETSO whenever this happens.

6 Not required for MSID Pairs notified by the NETSO

CONTENTS

Supplier Volume Allocation Agency V24.0

1. Introduction

1.1 Purpose and Scope

1.2 Summary of the Document

2. Principles and Objectives

2.1 Principles

2.2 Business Objectives

2.3 System Objectives

2.4 Project 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.2.5 Profile Production

3.2.6 Supplier Settlement and Reconciliation

3.2.6.1 Non-Pooled Generation Processing

3.2.6.2 GSP Group Correction

4. Business Description

4.1 Introduction

4.2 ISRA Scope

4.3 System Overview

4.3.1 Supplier Settlement and Reconciliation

4.3.1.1 GSP Group Aggregation

4.3.1.2 Deemed Take Calculation

4.3.1.3 BM Unit SVA Gross Demand Calculation (for purposes of the CFD Arrangements)

4.3.1.4 Determine Supplier Energy Volumes

4.3.1.5 Determine Quarterly Volumes

4.3.2 Daily Profile Production

4.4 ISRA Context

4.5 Business Events

4.5.1 Profile Production for Settlement Day

4.5.2 Initial Settlement for Settlement Day

4.5.3 Reconciliation for Settlement Day

4.5.4 Dispute Resolution for Settlement Day

4.5.5 Profile Changes

4.5.6 Profile Class Changes

4.5.7 Changes to Published Pool Market Domain Data

4.5.8 Settlement Timetable Published

4.5.9 Changes to Scaling Factors

4.5.10 Supplier starts/stops trading in GSP Group

4.5.11 Data Aggregator starts/stops operating in GSP Group

4.5.12 Data Collector starts/stops operating in GSP Group

4.5.13 Changes to Line Loss Factor Classes

4.5.14 Start of Trading on 1 April 1998

4.5.15 Changes to GSP Groups

4.5.16 Archiving Events

4.5.17 Changes to NHH BM Unit Allocation

4.5.18 Specify Final Dispute Expected Aggregation

5. Requirements Catalogue

5.1 Introduction

5.2 Key to the Requirements Catalogue

5.3 Functional Requirements

5.3.1 Functional Requirements - Supplier Settlement and Reconciliation Runs

5.3.2 Functional Requirements - Daily Profile Production System

5.3.3 Reporting Requirements

5.3.4 Interface Functionality Requirements

5.4 Non-Functional Requirements

5.4.1 Audit Requirements

5.4.2 Security and Control Requirements

5.5 Operational Requirements

5.5.1 Operational Requirements

5.6 Design Constraints

5.6.1 Design Constraints - Interfaces and Effect on Related Systems

5.7 Annex To Requirements Catalogue

5.7.1 Capacity requirements

5.7.1.1 Total Capacity Requirements

5.7.1.2 Estimates of Input Flows

5.7.1.3 Estimates of Output Flows

5.7.1.4 BM Unit Capacity Requirements

6. DATA FLOW MODEL

6.1 Purpose and Scope

6.2 Data Flow Diagrams and Elementary Process Descriptions

6.2.1 Initial Settlement and Reconciliation Agency

6.2.2 Process 1 - Supplier Settlement and Reconciliation

6.2.3 Process 1.1 - Marshal Incoming Data

6.2.3.1 Process 1.1.1 - Validate Settlements Data