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 22.0
Effective date	30 June 2022

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

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.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 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.
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.
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 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.
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.
BM Unit SVA 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
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
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
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
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

6.5 Data Flow Descriptions

6.5.1 Actual GSP Group Take

From/To:

External entity f Central Data Collection Agent

to Process 1.1.1 Validate Settlements Data

Data Items:

CDCA Set Number

CDCA Extract Number

GSP Group Id

GSP Group Take

CDCA Settlement Date

Settlement Period Id

6.5.2 Actual HH GSP Group Take

From/To:

Data store D1/1 Trading Day Data

to Process 1.4.9.1 Calc & Apply GSP Group Correction

Data store D1/1 Trading Day Data

to Process 1.4.9 Calculate Deemed Take

Data Items:

GSP Group Id

GSP Group Take

SSA Settlement Date

SSA Settlement Run Number

SSA Settlement Run Type Id

Settlement Period Id

6.5.3 Actual Noon Temperature

From/To:

Data store D2/1 Daily Parameters

to Process 2.1 Enter Parameter Data

External entity k ISR Agent

to Process 2.1.3 Calculate Noon Effective Temperature

Process 2.1.3 Calculate Noon Effective Temperature

to Data store D2/1 Daily Parameters

Data Items:

Actual Noon Temperature

GSP Group Id

Settlement Date

6.5.4 Aggregated Profiled HH Values

From/To:

Process 1.4.8.2 Aggregate Profiled Data

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

Consumption Component Class Id

Distributor Id

GSP Group Id

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

Data store D2 Daily Profiles

to Process 2.4.2 Extract Data For EAC Calculator

Constituent Data Flows:

Base Load Class Profile

Combined Load Regime Profile

Non Switched Load Class Profile

Profiles by Timeslot

Switched Load Class Profile

6.5.32 Daily Standing Data

This data flow is no longer used.

6.5.33 Data Aggregator Assignments

From/To:

Data store D1/2 SSR Standing Data

to Process 1.4.1 Invoke Run

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.34 Data Collector Details

From/To:

External entity k ISR Agent

to Process 2.1.5 Enter Data Collector Details

Data Items:

Data Collector Id

Data Collector Name

Effective From Date {DCIGG}

Effective To Date {DCIGG}

6.5.35 Data Collector Registrations

From/To:

Data store D3 Shared Standing Data

to Process 2.4 Produce Profile Reports

Data store D3 Shared Standing Data

to Process 2.4.2 Extract Data For EAC Calculator

Data store D3 Shared Standing Data

to Process 2.4.1 Produce Supplier & DC Profile Reports

Data Items:

Data Collector Id

Data Collector Name

6.5.36 Dates of Clock Change

From/To:

Data store D3 Shared Standing Data

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

Data store D3 Shared Standing Data

to Process 1.2.5 Create GSP Group Consumption Totals Report

Data store D3 Shared Standing Data

to Process 1.2 Produce SSR Supplier Reports

Data Items:

GSP Group Name

6.5.55 GSP Group Purchases

This Data Flow is no longer used.

6.5.56 GSP Group Supplier Assignment

From/To:

External entity k ISR Agent

to Process 1.3.2 Assign Suppliers to GSP Groups

Data Items:

Effective From Settlement Date {SIGG}

Effective To Settlement Date {SIGG}

GSP Group Id

Supplier Id

6.5.57 GSP Group Takes

From/To:

Data store D1/1 Trading Day Data to Process 1.1 Marshal Incoming Data

Data Items:

GSP Group Take

GSP Group Id

Settlement Period Id

Settlement Date

Timestamp

6.5.58 GSP Groups

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

6.5.74 Noon Effective Temperature

From/To:

Process 2.1.3 Calculate Noon Effective Temperature

to Data store D2/1 Daily Parameters

Data Items:

GSP Group Id

Noon Effective Temperature

Settlement Date

6.5.75 Parameter Changes

From/To:

External entity k ISR Agent

to Process 2.1 Enter Parameter Data

Constituent Data Flows:

Actual Noon Temperature

Calendar Details

Data Collector Details

GSP Group Details

6.5.76 Period Profile Data

From/To:

Data store D2 Daily Profiles

to Process 2.3 Calculate Daily Profiles

Constituent Data Flows:

Base Load Profile

Low Register State

Measurement Requirement Period State

Switched Load Profile

6.5.77 Pool Market Domain Data

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

Constituent Data Flows:

Daily Profiles

Period Profile Data

6.5.94 Settlement classes

From/To:

Data store D1/2 SSR Standing Data

to Process 1.1 Marshal Incoming Data

6.5.95 Settlement Data

From/To:

External entity f Settlements Systems Administrator

to Process 1 Supplier Settlement and Reconciliation

External entity f Settlements Systems Administrator

to Process 1.1 Marshal Incoming Data

Constituent Data Flows:

Actual GSP Group Take

6.5.96 Settlement Data for Run

From/To:

Data store D1/1 Trading Day Data

to Process 1.4 Run SSR

Constituent Data Flows:

Actual HH GSP Group Take

Daily Price Data

SPM Totals for Trading Day

6.5.97 Settlement Period Labels

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

CONTENTS

Supplier Volume Allocation Agency

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