My BSC Dashboard Subscriptions Kinnect Customer Solution

V 11 0

This version of the document has been superseded.

See the current version.

Previous version

Next version

1 Introduction

2 Principles and Objectives

3 Business Description

4 Requirements Catalogue

5 Data Process Model

6 Logical Data Model

Appendix A – Data File Formats

Appendix B – Data Processing Reports

PARMS User Requirements Specification

v 11.0

Effective From Date:01/09/2021

Status:SUPERSEDED

Other versions

Download

PARMS User Requirements Specification

This document defines the User Requirements for the system that will be used to provide the Performance Assurance Reporting and Monitoring System (PARMS) following implementation of Approved Modification P99

Version Number	Version 11.0
Effective Date	1 September 2021
Author	Elexon

AMENDMENT RECORD

Version	Date	Changes Included
1.0	27/05/03	Issued for System Development
2.0	04/09/03	Simplification of Supplier Charges
3.0	01/04/04	For P99 Implementation
4.0	12/04/05	Version baselined for Release 3 and Release 2A
5.0	12/04/05	Version baselined for Release 4 (CR15, 16, 18, 24, 25, 26 & 35); CP1057, 1084, 1087 & 1088)
6.0	20/04/06	Version for Revised Scope of Release 4 (CRs 15, 19, 24 25, 34, 35 36 37, 38, 42, 43, 44 and 45; CPs 1087 & 1088) and Design Review
7.0	06/09/06	Version baselined following formal review
8.0	23/08/07	P197
9.0	01/07/11	June 2011 Release CP1334, CP1348
10.0	29/03/19	29 March 2019 Standalone Release P369
11.0	01/09/21	1 September 2021 Non Standard Release P420

Related Documents

Reference	Document
Reference 1	Balancing and Settlement Code, Section S, Annex 1 ‘Performance Levels and Supplier Charges’
Reference 2	BSCP533 PARMS Data Provision, Reporting and Publication of Peer Comparison Data including: BSCP533 Appendix A PARMS Data Provider File Formats BSCP533 Appendix B PARMS Calculation Guidelines
Reference 3	Interface Definition and Design Part 1

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

1 Introduction

1.1 Introduction

The Performance Assurance Reporting and Monitoring System (PARMS) provides a range of data to support the Performance Assurance Framework in carrying out a selection of Assurance Techniques. These techniques are designed to mitigate against risks that have been identified within the Settlement processes defined by the Balancing and Settlement Code and the Code Subsidiary Documents.

The Assurance Techniques supported by PARMS are:

Monitoring and reporting;
Calculation of Supplier Charges (also known as Liquidated Damages);
Peer Comparison;
Error and Failure Resolution; and
Removal of Qualification¹.

Furthermore, PARMS is used to support the general monitoring activities carried out by Elexon. PARMS requires the implementation of an IT system that allows the monitoring of performance of participants against standards defined within the BSC Procedures and Party Agent Service Lines, and has the ability to apply the techniques outlined above.

1.2 Purpose and Scope

The purpose of this document is to define and agree the business system that will be implemented to deliver PARMS. PARMS will be utilised (or managed by the Elexon User) by the Performance Assurance Administrator (PAA) and will be dependent on the receipt of data from Suppliers, Supplier Agents², Supplier Meter Registration Agents (SMRAs), the SVA Agent (SVAA), the Central Registration Agent (CRA) and the Central Data Collection Agent (CDCA).

This document identifies the functionality of the IT system (‘the system’) that will be required in order to deliver the successful operation of PARMS.

1.3 Summary of the Document

This User Requirements Specification comprises:

a description of the principles and aims of PARMS;
a summary of the constraints and assumptions upon which the system is based;
a description of the scope and functions of the service; and
supporting information including the Data Flow Model, the Logical Data Model and Supplier Charges calculations.

1.4 Terminology

The term Supplier in this URS is analogous to Supplier ID, which represents a customer base owned by a BSC Trading Party with a Supply License. A Trading Party may hold more than one Supplier ID at any one time, and Supplier IDs may be transferred between Trading Parties as a result of a trade sale.

Output Data is the term used in the Code Subsidiary Documents to describe the performance-related data issued by participants to PARMS. It defines:

the level of monitoring that is included in the output (GSP Group, Supplier, MSID, etc); and
the statistic that is produced (number of failures, % success, etc).

The PAA receives Output Data from four sources:

Suppliers, who submit Output Data relating to their timeliness in installing metering appropriate to the Code requirements;
Supplier Agents, who submit Output Data relating to their own Supplier performance, other Supplier Agents or their associated Supplier;
the SVAA, which submits Output Data relating to Supplier performance; and
the CDCA, which provides Output Data relating to CVA Proving Tests.

In addition, the PAA generates Output Data for those Serials which are directly monitored by BSCCo.

The Elexon User is the individual within Elexon who interacts with the system, either updating the parameters used in the calculations or querying data stored within the system. The providers of Output Data are referred to as Data Providers and the performance-related reports they produce as Output Data Reports.

Once data is received, validated and checked for completeness by PARMS and stored within PARMS, it is referred to as Performance Data.

In order to support the determination of data validation and completeness, and the calculation of Supplier Charges, PARMS requires reference data relating to Supplier Agent appointments. This is specifically referred to as Data Provider Information.

All other information used to support data validation, completeness checking and Supplier Charges is referred to as Standing Data.

2 Principles and Objectives

2.1 Purpose and Scope

The requirements of PARMS relate to the general principles established by the Code in relation to market monitoring and reporting. The detailed requirements listed in the Requirements Catalogue serve to support each of these principles:

PARMS will receive data from participants relating to the Serials and Standards established by the Code and Code Subsidiary Documents;
PARMS will determine Supplier Charges in accordance with the provisions of the Code;
PARMS will generate reports for the Elexon User showing the performance of market participants against the Serials and Standards;
PARMS will support interfaces with relevant participants and systems in order to facilitate timely data provision and receipt; and
PARMS will be capable of storing data to enable such data to be reviewed and calculations re-run after the data was originally used.

2.2 Business Objectives

The major business objectives are:

1. To provide a facility to monitor market participant performance levels in order to identify market issues and areas of non-compliance;

2. To enable the accurate and timely calculation of Supplier Charges in order to give incentive to improved performance;

3. To provide the market with clear indication of participants’ relative performance levels via the use of Peer Comparison reporting;

4. To support the assurance techniques of Error and Failure Resolution and Removal of Qualification carried out by the PAB; and

5. To ensure that PARMS can operate effectively following the implementation of the British Electricity Trading and Transmission Arrangements (BETTA).

2.3 System Objectives

The major system objectives of PARMS are:

1. To enable the system and the data contained therein to be accessed by the Elexon User at any time;

2. To provide periodic performance reports to the PAA;

3. To calculate Supplier Charges at the Supplier ID level each month and store them within the system in order that the Supplier Charge Apportionment system can apportion the charges between Trading Parties (where necessary) and report net totals to Elexon Finance;

4. To provide Supplier Charges reports to the PAA, Suppliers and Trading Parties each month;

5. To provide Peer Comparison reports to the PAA and Suppliers as required;

6. To maintain appropriate standing data required in order to achieve the business objectives;

7. To provide interfaces with other systems as required;

8. To provide a robust system that can operate efficiently and effectively, subject to the necessary data being made available;

9. To provide a system with the flexibility to allow the addition, removal or modification of Serials and Standards; and

10. To provide audit, security and control measures and maintain sufficient audit information to satisfy the PAA and the Performance Assurance Board (PAB).

3 Business Description

3.1 Introduction

This section describes the business processes, the scope and the context of the PARMS. The section contains:

the scope of PARMS and other monitoring and reporting operations;
a representation of the context of PARMS in terms of its interfaces with market participants and external systems; and
the business events that affect PARMS.

3.2 Service Scope

The scope of the service is as follows with respect to the assurance techniques contained within the Performance Assurance Framework:

Monitoring	PARMS will provide facilities for the analysis and reporting of all Output Data from Suppliers, Supplier Agents, the SVAA, the CDCA and the PAA.
Peer Comparison	PARMS will provide facilities for the generation, analysis, approval and distribution of Peer Comparison reports.
Supplier Charges	PARMS will provide facilities for the calculation, and invoicing of funds and analysis of queries relating to Supplier Charges.
Technical Assurance/Audit	PARMS will provide information to support the Technical Assurance process as required by the Technical Assurance Agent.
Removal of Qualification	PARMS will provide information relating to compliance with Performance Standards to the PAA and/or the PAB in relation to Serials that have been identified as subject to Removal of Qualification procedures.
Error and Failure Resolution	PARMS will provide information to support the Error and Failure resolution process.

3.3 System Scope

The scope of the central IT system is more focused than that of the overall PARMS service in that its role is primarily to provide or give access to data to the PAA for further action. Therefore, the role of the system in supporting the Performance Assurance Framework techniques is as follows:

Monitoring	The system will generate regular monitoring reports showing the performance of participants against the Serials and Standards used by PARMS.
Peer Comparison	The system will generate Peer Comparison reports consisting of selections and aggregations of data as directed by the Elexon User.
Supplier Charges	The system will perform Supplier Charges calculations and generate reports for the PAA, Suppliers and Trading Parties.
Technical Assurance/Audit	The system will provide for ad-hoc database queries performed by the Elexon User to support the Technical Assurance activities.
Removal of Qualification	The system will generate reports as required by the Elexon User showing the level of performance of participants for Serials against which the Removal of Qualification technique has been applied.
Error and Failure Resolution	The system will provide for ad-hoc queries report production to support the PAA’s efforts in Error and Failure Resolution.

3.4 Assumption

PARMS assumes that at any one time, only one Trading Party can take ownership of a Supplier ID in a GSP Group, i.e. it is not possible for two Parties to own different Supplier BM Units under a single Supplier ID on the same Settlement Date.

3.5 Interfaces

PARMS will be required to support interfaces (either manual or electronic) with the following participants in order to meet its business objectives:

3.5.1 Data Providers

Output Data will be sourced from Suppliers, Supplier Agents, SMRAs, the SVAA, the CDCA and the PAA. Data from Suppliers, Supplier Agents and SMRAs will be provided in a data format specified by the Code Subsidiary Documents. Output Data from the PAA may be fed into the PARMS IT system manually by the Elexon User.

3.5.2 Elexon Finance

Elexon Finance will provide bank interest rates, Funding Shares and associated Trading Party Ids for use in calculating Supplier Charges.

3.5.3 Suppliers

Suppliers will provide details of their Supplier Agent appointments for each reporting month, in a specific file known as ‘Data Provider Information’.

Supplier-related Performance Data received from the Data Providers will be issued to the relevant Suppliers for review and authorisation before the data is used in the assurance techniques.

3.5.4 Performance Assurance Board

The PAA will be responsible for providing reports to the Performance Assurance Board and obtaining authorisation for the release of reports to Suppliers.

3.5.5 SVAA

Interfaces will be maintained between PARMS and SVAA to enable information regarding Supplier-GSP Group relationships and relevant Market Domain Data to be retrieved. The Supplier-GSP Group relationship data enables the system to be aware of Suppliers entering or leaving the market.

3.5.6 CRA

The CRA will provide Supplier BM Unit registration information via a manual data flow to enable PARMS to identify the Trading Party associated with each Supplier ID.

3.5.7 Supplier Charge Apportionment System

A separate Supplier Charge Apportionment system will retrieve the Supplier Charges, registration data and calendar information stored within PARMS to correctly apportion Supplier Charges between Trading Parties where there has been a change of Supplier ownership during a Reporting Period. This system will issue reports to the Trading Parties affected and to Elexon Finance.

3.5.8 Pre-P99 PARMS

Any Supplier Charges calculated in pre-P99 PARMS as a result of adjustments to pre-P99 Serials will be retrieved from the old system and loaded into P99 PARMS for inclusion in Supplier Charge totals and subsequent reporting.

3.6 PARMS Context

3.7 Business Events

PARMS is affected by the following business events:

Data Providers added/deleted;
Suppliers added/deleted;
Contact details added/modified/deleted;
Change of Supplier Ownership within Reporting Period;
Data Providers sending Output Data;
SVAA sending Annual GSP Group Take Data;
SVAA sending Consumption Data;
Elexon sending Funding Share data;
Suppliers sending Data Provider Information;
CRA sending BM Unit registration data;
Changes to Standing Data such as Market Domain Data;
Queries/amendments raised by reviewers/approvers of reports generated by PARMS;
Approval of Reports;
Serial added/modified/deleted;
Standard added/modified/deleted;
Archiving; and
Application of Force Majeure and Error Correction.

A summary of these business events is given below.

3.7.1 Data Providers added/deleted

The identities of participants eligible to be Data Providers are added to or deleted from the system by the Elexon User to ensure the standing data against which Output Data is validated is kept up to date.

3.7.2 Suppliers added/deleted

The identities of Suppliers entering or leaving the market are added to or removed from the system by the Elexon User in order that Supplier Charges are assigned correctly.

3.7.3 Contact Details added/modified/deleted

The Elexon User provides updates to the set of contact details for those participants involved in PARMS.

3.7.4 Change of Supplier Ownership within Reporting Period

The ownership of a Supplier may change between Trading Parties within a reporting period. This necessitates the use of the Supplier Charge Apportionment system to apportion any Supplier Charges for that month between the Parties appropriately.

3.7.5 Data Providers sending Output Data

Output Data is submitted into PARMS by the Data Providers in accordance with the formats specified by BSCCo.

3.7.6 SVAA sending Annual GSP Group Take Data

Annual GSP Group Take data is provided by the SVAA for use in Supplier Charges calculations.

3.7.7 SVAA Sending Consumption Data

GSP Group Take and Supplier Cap Take data is provided by the SVAA for use in Supplier Charges calculations.

3.7.8 Elexon sending Funding Share data

Elexon Finance provides details of Trading Party Funding Shares four months after each Reporting Period for use in determining the apportionment of Supplier Charges to other Trading Parties.

3.7.9 Suppliers sending Data Provider Information

Suppliers provide PARMS with details of their Data Providers for each GSP Group valid for each Reporting Period to enable validation and completeness checks to be carried out.

3.7.10 CRA sending BM Unit registration data

The CRA provides details of Supplier BM Unit registration dates for use in determination of Party/Supplier ID relationships.

3.7.11 Changes to Market Domain Data

PARMS maintains a subset of MDD for use in validating Output Data. PARMS needs to receive notification of any changes to the appropriate aspects of MDD.

3.7.12 Queries/amendments raised by reviewers/approvers of reports generated by PARMS

Any PARMS reports against which queries have been raised are logged by the system, as are any amendments made following resolution of such queries.

3.7.13 Approval of Reports

The system maintains a log of Peer Comparison and Supplier Charges reports that have been approved for distribution by PAB.

3.7.14 Serial added/modified/deleted

Changes in the requirements of the PAA and PAB may result in the need to add, modify or delete Performance Serials used by PARMS.

3.7.15 Standard added/modified/deleted

In order to increase the effectiveness of any Performance Serial, the PAA and PAB may wish to add, modify or delete any of the associated Performance Standards.

3.7.16 Archiving

The PAA may require old data to be archived for audit purposes.

3.7.17 Application of Force Majeure and Error Correction

Where necessary, PAB may authorise other corrections or adjustments to Supplier Charges using the Force Majeure functionality. In such situations, Supplier Charges may be increased or decreased, and modified over a selection of Suppliers, Serials, GSP Groups and Reporting Periods as necessary.

4 Requirements Catalogue

The Requirements Catalogue represents a statement of the requirements of PARMS, categorised as follows:

Functional Requirements – what the system is expected to do;
Non-Functional Requirements – describing expected characteristics of the system; and
Operational Requirements – the way in which the system is expected to operate.

The centre column in each table indicates whether the requirement associated with the IT system is mandatory (M) or desirable (D). Processes that are not expected to be met by the IT system are not referenced in this document.

4.1 Functional Requirements

The Functional Requirements arise from the System Objectives listed in Section 2.3, which in turn are consequences of the overall Business Principles of PARMS. Cross-references are provided to the sections of the Data Flow Model that meet the requirements listed.

Requirement	M/D	Description	X-Ref
F1	M	Maintain Standing Data for use in validation, completeness checking and Supplier Charges calculations.	5.2.1
F2	M	Receive and store Output Data from Data Providers.	5.2.3.1,5.2.3.4
F3	M	Construct Output Data Schedules based upon Standing Data.	5.2.1.5
F4	M	Validate Output Data against list of authorised Data Providers and Market Domain Data for internal consistency.	5.2.3.2
F5	M	Reject any file in its entirety that fails validation.	5.2.3.3
F6	M	Log validation results.	5.2.3.3
F7	M	Report validation results to Data Providers, showing the files that were successfully processed and detailing the errors that caused others to fail validation.	5.2.3.3
F8	M	Check Output Data for completeness.	5.2.3.5
F9	M	Report completeness results and any change in completeness status to the relevant Suppliers.	5.2.3.6
F10	M	Provide Output Data to the associated Suppliers/Supplier Agents for review where they are not the Data Provider.	5.2.3.7
F11	M	Receive and log data queries from Suppliers.	5.2.3.7
F12	M	Calculate Output Data for Supplier Serial SP01.	5.2.2.1
F13	M	Generate monitoring reports showing performance of participants against each relevant Serial and Standard.	5.2.4.1
F14	M	Calculate Supplier Charges for Serials based on SVAA Settlement Runs.	5.2.5.1
F15	M	Update and maintain all records associated with application of Supplier Charges.	5.2.5
F16	M	Generate Supplier Charges reports for relevant participants.	5.2.5.3
F17	M	Generate Peer Comparison reports based upon approved Performance Data.	5.2.4.2
F18	M	Track PAB approval of Peer Comparison and Supplier Charges reports.	5.2.6.3
F19	D	Track Performance Data against which queries have been raised.	5.2.3.7
F20	M	Provide facilities to allow ad-hoc queries to be performed upon data stored in the system the Elexon User.	5.2.4.3
F21	M	Allow manual entry of SP02 data by the Elexon User.	5.2.2.2
F22	M	Allow modification of Supplier Charges for selected Reporting Periods and Serial/Supplier/GSP Group combinations.	5.2.5.1

4.2 Non-Functional Requirements

Requirement	M/D	Description
N1	M	For all Output Data files received the system must record the following information: the Market Participant ID of the originator of the file; the date and time at which the file was received.
N2	M	For all reports generated by PARMS for circulation the following data must be recorded: the identity of the recipient of the report; the date the report was sent.
N3	M	The system must be developed with appropriate security controls, including: facilities for controlling access to the application and the data, with separate administrator, maintenance and read-only user roles; facilities to enable the application and data to be backed up and restored.
N4	M	Facilities for archiving data (both source and report data) for a period appropriate to the importance of the data in question, such that it may be read but not uploaded back into the system.
N5	D	Provide facilities to provide an audit log of all Peer Comparison reports issued by the PAA.
N6	D	Provide facilities to provide an audit log of Supplier Charges reports issued by the PAA.
N7	M	Provide an audit trail of all manual amendments made to data.
N8	M	Provide facilities and procedures to enable Business Continuity in the case of disaster (including disaster recovery of the IT system) such that a recovery timescale of one day may be achieved.

4.3 Operational Requirements

Requirement	M/D	Description
O1	M	The system must have an ad hoc report writing facility that does not require knowledge of the underlying database or SQL from the user.
O2	M	The system must have the capability to integrate with standard MS applications (e.g. Word, Excel) to enable production of standard letters or further analysis.
O3	M	A PARMS internet email address must be supported to allow Data Providers to submit data into PARMS and communicate with the PARMS operator to resolve technical queries.
O4	M	The system must be capable of loading data from a CD-Rom provided it is in the correct format.
O5	M	The system must be capable of allowing simultaneous access by more than one user (a maximum of 10).
O6	M	If installed within Elexon the system must be compatible with the Elexon IT infrastructure (including the use of Windows XP).
O7	M	If installed within Elexon the system must not impact or degrade existing Elexon applications.
O8	M	The developed application, database and supporting IT tools should contain arrangements for compatibility with future releases of software and hardware.
O9	M	The system must be capable of generating graphical colour reports in an electronic format.
O10	M	Reports produced by the system must be provided in at least Word and pdf formats.
O11	M	The system must be able to group together reports (e.g. for Supplier Charges) into a single email where they are intended for a single recipient.
O12	M	The system must provide a flexible means of adapting the database, data processing rules and calculations as system requirements change due to revisions to Serials and Standards.
O13	M	The system must be resilient to handle user errors.
O14	M	The system must support automatic validation and acknowledgment of Output Data submitted by Data Providers.
O15	D	The system must be able to log email outages and feed such outages into the SP01 calculations.
O16	M	The system must BCC all outgoing emails to an Elexon email address.
O17	M	The system must enable the user to view the latest set of data received for each Serial.

In relation to the operational requirements above, the following table sets out indicative values for the PARMS volumetrics. The figures have been estimated based on current market activity and future projection.

GSP Groups	25
Supplier IDs	200
Trading Parties	300
Serials	100
NHH Data Collectors	30
NHH Data Aggregators	30
HH Data Collectors	20
HH Data Aggregator	20
Meter Operators	20
SMRAs	30
Number of Settlement Run Types	7

5 Data Process Model

5.1 Purpose and Scope

The Data Process Model describes the processes that comprise PARMS, and details the flows to and from organisations that lie outside of the system.

The model consists of descriptions of the Elementary Processes required of PARMS and a description of the system inputs and outputs.

The model does not give indications of how the flows and processing should be implemented, and represents a logical rather than physical model of PARMS. The model does however provide an overview of the basic procedures and storage facilities that are necessary in order for the system to meet the requirements established in Section 4.

5.2 Elementary Process Descriptions

5.2.1 Manage Standing Data

5.2.1.1 Performance Measurement Parameters

The measurement of market participants’ performance against Performance Standards requires the application and maintenance of parameters established by the Code. These parameters are subject to alteration through the BSC Modification procedures and therefore this process is concerned with the addition, amendment, deletion and archiving of Performance Measurement Parameters in a controlled and auditable manner.

5.2.1.1.1 Maintain Performance Serials, Standards and Charges

For each Serial, the required performance level for each Standard and, if relevant, the charge per unit of underachievement, is maintained as a system parameter. Each Serial may have a number of different Standards with different charges associated with each. All these parameters are subject to Serial effective from and to dates, allowing different sets of Serials and Standards to be applied across different ranges of Reporting Periods as required by the Code.

The set of serials required to be supported by PARMS, along with their related Standards and Supplier Charges (if relevant) are established in Annex S-1 of the Code (Reference 1) and in BSCP533 ‘PARMS Data Provision’ (Reference 2).

5.2.1.1.2 Maintain Serial Submission Window

For each Data Provider type, a submission window in which Output Data is expected to be submitted into PARMS following the end of the Reporting Period is defined in BSCP533 (Reference 2) and maintained by the system. This is compared to the actual receipt dates of Output Data and if necessary, a charge for late submission is calculated.

5.2.1.2 Supplier Charge Data

The calculation of Supplier Charges requires the loading and maintenance of market data and additional system parameters provided from various sources:

Load Data from SVAA

The following data is provided by the SVAA and is loaded into the system following business validation of the files received:

Annual GSP Group Take data consisting of the following:
1. for each GSP Group, the total GSP Group Take for the previous 12 months (GSP_A); and
2. the total GSP Group Take for the previous 12 months (GSP_AS).
The total Supplier Cap Take (SCT) for each Supplier in each GSP Group for each month. This data is used to calculate the Monthly Cap S_c for each Supplier;
The total GSP Group Take (GSP_DT) for each GSP Group and each month, also used in the calculation of S_c;
The Supplier NHH Energy (S_MNHH) for each Supplier in each GSP Group. This data is used to determine the each Supplier’s share SES_MNHH of the redistributed Supplier charges for each GSP Group; and
The Total NHH Energy (GSP_MNHH) for each GSP Group for each month, also used in the calculation of SES_MNHH.

The files containing this data are defined in the Supplier Charges Specification (Reference 3)

Load Funding Shares

Trading Party Funding Shares for each month are provided by Elexon Finance and validated against the specific file format described in Appendix A before being loaded into the system.

Load BM Unit Registration Data

BM Unit registration data is provided by the CRA via the CRA-I014 file defined in Part 1 of the IDD (Reference 4) and loaded into the system.

Enter Additional Parameters

The following parameters are determined by BSCCo and entered into the system through dedicated data entry screens by the Elexon User:

National Monthly Cap (N_MC) for each year, modified by annual inflation based upon the retail price index and provided by PAB;
The Supplier Payment Disbursement Factor (SPDF), initially set at 0.9; and
Interest Rates (including Base Rate and Late Penalty) for use in the event of any adjustments to Supplier Charges.

5.2.1.3 Market Domain Data

MDD is required in order to construct the Output Data Schedule and to validate incoming data. A subset of MDD is received from SVAA and once validated is stored, maintained and archived. The MDD categories to be maintained by PARMS are:

GSP Groups;
Distributors in GSP Groups;
Market Participant IDs;
Market Participant roles (Supplier, MOA, NHHDC, HHDC, NHHDA, HHDA, SMRS);
SSR Run Types; and
Settlement Calendar.

Note that the Settlement Calendar information provided to PARMS represents the actual Settlement Runs carried out by the SVAA to date, rather than the planned run types and dates published in the full set of MDD.

MDD is expected to be received from SVAA once per week. Each file will be a complete set of data, so much of the data content will remain the same from week to week (although each new file will include Settlement Calendar data, reflecting the runs of the SVAA system carried out in that week).

5.2.1.4 Non-Working Day Calendar

A Non-Working Day Calendar is maintained by the system for use in determination of Supplier Charges for SP01. The information is provided by the Elexon User, as are any updates such as amendments for extra Bank Holidays, for example.

5.2.1.5 Maintain Output Data Schedule

The Schedule will recognise the timetable of data submission requirements for all Output Data. The Schedule must identify:

The Suppliers from whom Output Data is expected for each GSP Group;
The Supplier Agents from whom Output Data is expected for each GSP Group;
The Suppliers and Supplier Agents expected to be identified as the subject of Output Data; and
Run Types for which Settlement Day-based Output Data should be expected for a given reporting month.³

5.2.1.5.1 Load Supplier-GSP Group Trading Data

A report is provided to PARMS by the SVAA identifying which Suppliers are trading in which GSP Groups, with associated effective start dates and (if they have ceased trading in the GSP Group) effective end dates. PARMS uses this Supplier-GSP Group information as the primary reference for the GSP Groups against which each Supplier is considered to be complete, and this forms the basis of the Output Data Schedule.

5.2.1.5.2 Load Data Provider Information Data

In addition to the data provided by the SVAA, Suppliers provide PARMS with Data Provider Information, which details the Data Providers (be they Data Aggregators, Data Collectors or SVA Meter Operator Agents) that are or have been acting for them in respect of each GSP Group specified above, and are expected to submit Output Data for the Serials valid for each Reporting Period, based upon information provided by the PAA.

Data Provider Information is required for each month from the Reporting Period containing the Supplier’s start date up to and including the Reporting Period containing the Final Reconciliation (RF) Settlement Run for their end date in that GSP Group.

Suppliers and Supplier Agents that are not operating in a GSP Group are not required to submit PARMS data for that Group (except when running off Serials for Settlement Days in which they were active in that GSP Group). Consequentially, where Data Provider Information contains data for GSP Groups additional to those reported by the SVAA in 5.2.1.5.1 above (such as data relating to the unknown GSP Group as defined in BSCP533 Appendix B section 2.1.1), this data is not used by PARMS in the construction of the Output Data Schedule.

5.2.1.5.3 Retrieve Settlement Calendar Data

The Settlement Calendar, received and loaded in 5.2.1.3 above, gives an indication of the data expected from Data Providers for those Serials directly related to Settlement Runs. For example, in the first reporting month after the P99 Implementation Date, PARMS should not expect to receive any Final Reconciliation Run data as these runs will take place many months after the Settlement Day to which they relate.

The Settlement Calendar is of particular relevance when a Supplier leaves the market or ceases trading in a GSP Group because (as noted in 5.2.1.5.2 above) DPI data is required until the completion of Final Reconciliation (RF). For this reason, the Output Data Schedule cannot be finalised until details have been received of all RF runs carried out in the Reporting Period.

Implementation Approach

In order to facilitate understanding of the approach taken in building the PARMS system, the following details of the implementation should be noted:

Although the URS describes separate requirements for maintaining the Output Data Schedule (as described in this section) and checking Output Data against that Schedule (as described in section 5.2.3.5), the PARMS system combines the two functions. In particular, each time the system updates the Output Data Schedule, it also reassesses the completeness of affected Suppliers.
Following the Completion Checking Design Review, it has been agreed that initial population of the Output Data Schedule will be triggered manually by Elexon. At that point, the Output Data Schedule will be populated with Supplier-GSP Group combinations based on the most recent Supplier-GSP Group Trading and Settlement Calendar data to have been received (and successfully loaded) from SVAA. It should be noted that the Supplier-GSP Group data will be that submitted to SVAA by Suppliers in accordance with BSCP507, modified by the ISRA software (for those Settlement Days which have undergone the SF SSR Run) to be consistent with files submitted to SVAA by Data Aggregators.
It has also been agreed that subsequent (retrospective) changes to Standing Data will not be taken into account for completion checking purposes for that Reporting Period. The onus therefore rests on Elexon not to trigger the initial population of the Output Data Schedule until the necessary Settlement Calendar and Supplier-GSP Group information is available.
The manual population of the Output Data Schedule must be triggered before the first monthly Completeness Reports are run (18 Working Days after the end of the Reporting Period). However, Elexon would not trigger the manual population process until after the following files have been successfully loaded:

The MDD file containing a Settlement Calendar entry for an RF Run Type with the SSR Run Date equal to the last Working Day of the previous month; and
The associated P0127 file (which will therefore be used to determine the set of Supplier-GSP Groups with which to populate the Completion Log).

In addition to the Settlement Calendar and Supplier-GSP Group data, the initial population of the Output Data Schedule will also take into account any DPI data and Output Data received at that point.
Each time DPI data and Output Data is received subsequently, the system will update the Output Data Schedule and the Supplier’s completeness level accordingly.

5.2.1.6 Maintain Data Provider Contact Details

Each Data Provider will provide details of authorised contacts for correspondence regarding the provision of Output Data and the receipt of reports. The PAA will maintain a list of contacts.

5.2.1.7 Maintain Report Distribution Information

The reports produced by PARMS are sent to specified recipients. Details include contact name, address, telephone and fax number, and e-mail address, and may involve using different contacts within the same company for different assurance techniques.

5.2.2 Produce PAA Output Data

5.2.2.1 Produce SP01 Output Data

This process constructs the Output Data for Serial SP01, which reports against Suppliers who fail to deliver Routine Performance Monitoring Reports within the required timescales.

The completeness checking process, described in section 5.2.3.5, monitors and logs the receipt of Output Data on an ongoing basis to determine whether any expected data is missing. Where data remains missing after the submission deadline of 20WD after the end of the Reporting Period, the SP01 calculation records the dates and the total number of Working Days for which the data is late for that month until the data is eventually received. For example, if a file has been missing since May and is received halfway through July, the July SP01 calculation will only reflect the number of Working Days that the file has been missing for that month, not the number of Working Days it has been missing in total.

Note that if a file relating to many different Suppliers is missing (from a Supplier Agent contracted to more than one Supplier in a GSP Group), then all those Suppliers will be regarded as failing the SP01 test.

Multiple periods of lateness can be accrued for a Reporting Period where the completeness status changes a number of times; in this case the SP01 calculation records each of the periods of lateness along with their associated start and end dates.

Outages to the Elexon email server may prevent submission deadlines being met through no fault of the Data Providers. Details of such outages are logged in PARMS and fed into the SP01 calculation so that any lateness for days affected by the outage is waived.

Any instances of lateness relating to the unknown GSP Group (as defined in BSCP533 Appendix B section 2.1.1) shall be disregarded from the SP01 calculations.

Furthermore, in accordance with Annex S-1, paragraph 3.9.2 of the BSC, any lateness relating to the Reporting Periods for May and June 2004 is also waived so as to ensure the correct timing of the commencement of any associated Supplier Charges.

Output Data

The results of this process are recorded as:

Reporting Period
Supplier ID;
GSP Group ID;
SP01 month end date;
SP01 start date;
SP01 end date; and
number of Working Days performance reports are late.

Implementation Approach

The SP01 calculation is manually initiated soon after the end of each Reporting Period, and calculates the number of SP01 Late Days for each previous period. For example, the SP01 calculation for June would be initiated on or shortly after 1 July, and would calculate the number of SP01 Late Days to be included in the June Supplier Charge run. However, the latest month to which these charges could relate would be May:

As the 20WD deadline for submission of May files will fall just a few days before the end of the June Reporting Period, the number of late days calculated for May by the June SP01 calculation (i.e. Reporting Period = June, SP01 Period = May) would be limited to no more than a few Working Days per Supplier;

For previous months (i.e. Reporting Period = June, SP01 Period < May), the number of late days for each Supplier may range from none to the full number of Working Days in June, depending on whether the Supplier was complete for that month in all of June, some of June or none of June.

5.2.2.2 Enter SP02 Data

Output Data for Serial SP02 is entered directly into the system by the Elexon User and consists of the following:

Reporting Period
Supplier ID:
GSP Group ID;
month end date; and

number of Working Days performance logs are late.

Where logs are received after the deadline, the values are updated by the Elexon User.

5.2.3 Manage Performance Data

The processes involved in managing Performance Data are as follows:

record receipt of original and resent data;
check validity and completeness of data;
log resulting exceptions;
report and resolve exceptions, including requesting resends;
store complete and valid data; and
acknowledge receipt.

5.2.3.1 Record and Acknowledge Data Receipt

This process occurs for both original receipts of data and the receipt of any subsequent resubmissions.

Implementation Approach

All data from Suppliers and their Agents will be submitted to the PARMS system via email. In addition, there is a facility for the Elexon User to submit data directly into the system (bypassing the email loader) by dropping files into the appropriate directory. This mechanism is used for certain interfaces (from CRA and Elexon Finance, for example) where there is no requirement to send an email acknowledging receipt. However, due to issues with receipt times (as described in 5.2.3.1.1 below), this manual mechanism should not be used where accurate recording of receipt time is important (e.g. for Serials subject to SP01).

5.2.3.1.1 Record Date and Time of Receipt

The date and time of receipt of all emails received by the Elexon email server are stored by PARMS in an email receipt log. This date and time is also treated as the date and time of receipt for the files attached to the email, for purposes of Completion Checking, and deciding which is the latest version of a file to use.

Implementation Approach

For files dropped manually into the system (as opposed to submitted via email), the system cannot record the date and time of email receipt, and instead records both the date and time at which the system processed the file, and the file’s last modified date. The system does not necessarily adopt a consistent approach in deciding which of these times should be regarded as the deemed receipt time, and as a result the manual method for submitting files should not be used where an accurate record of deemed receipt time is important.

If two files are submitted to the system via a single email, there is no clear definition of which is deemed to have been received first. As a result there is at least a theoretical possibility that different parts of the PARMS system could take a different view on the order in which the two files were received.

5.2.3.1.2 Validate Email Address

The email address of the sender is validated against the set of Data Provider Contact Details to ensure that the data is an authorised submission. All receipts of data are acknowledged by issuing an email receipt report to the Data Provider.

5.2.3.1.2 Acknowledge Receipt

Emails that pass the initial validation of address are acknowledged by issuing an email receipt report to the Data Provider.

5.2.3.2 Check Validity of Data

Following receipt, all data is validated against the data file format requirements established by BSCCo, and the information contained in the subset of MDD provided by the SVAA.

The Serials contained within Output Data and the Data Provider Information are checked against the Serial effective dates stored by the system to ensure that the data is a valid submission for the Reporting Period.

5.2.3.3 Process Validation Results

Validation exceptions are logged and reported to the Data Provider so that they may be resolved, usually by resubmission of the relevant Output Data. Any Output Data that is found to be invalid will not be passed for further processing (i.e. the completeness check).

Any exceptions outstanding after the 20 Working Day (20WD) timescale are highlighted to the PAB and the Data Provider’s identity notified.

5.2.3.4 Store Data

Once data has been successfully validated it is stored in the system as Performance Data and may be used in further possessing. The date and time of the storage is recorded.

5.2.3.5 Check Completeness of Data

The Output Data received after the end of each Reporting Period is continually checked against the Output Data Schedule in order to assess its level of completeness. Note that, while all Data Providers are recorded in the Data Provider Information by Supplier and GSP Group, some Serials only require Output Data to be provided on a national basis without reference to individual GSP Groups. The receipt of Output Data for these Serials is therefore deemed by PARMS to be a submission across all the Supplier-GSP Group entries listed in the Data Provider Information for a specific Serial, Data Provider and Reporting Period.

While all Data Providers are recorded in the Data Provider Information file by Supplier and GSP Group, the inclusion of Data Provider information for the unknown GSP Group (as defined in BSCP533 Appendix B section 2.1.1) is entirely optional. Any information received from Data Providers relating to the unknown GSP group shall be disregarded within the completeness checking process.

Data relating to serials that are no longer effective as a result of CP1344 ‘New PARMS Serials: Further Amendments to BSCP533 and BSCP533 Appendices’ shall be disregarded for the purposes of completeness checking.

Implementation Approach

Although the URS describes separate requirements for maintaining the Output Data Schedule (as described in section 5.2.1.5) and checking Output Data against that Schedule (as described in this section), the PARMS system combines the two functions. In particular, each time the system updates the Output Data Schedule, it also reassesses the completeness of affected Suppliers.

5.2.3.6 Report Completeness

The results of the routine completeness checks are logged and reported to the relevant Suppliers via monthly completeness reports, which highlight any missing data such that exceptions may be resolved. Resolution of completeness exceptions will be achieved through resubmission of Output Data by the relevant Data Providers or the receipt of correct appointment data from Suppliers if such data was in error. Any subsequent changes to a specific Supplier’s completeness status, for example if a Supplier Agent decides to withdraw data after the initial completeness check, will be notified to that Supplier via an individual completeness report.

5.2.3.7 Data Authorisation

5.2.3.7.1 Generate Third Party Output Data Report

Performance Data sourced from Supplier Agents and the SVAA that is to be used in any of the PARMS techniques is provided to the relevant Suppliers or associated Supplier Agents for review in the form of Third Party Output Data Reports.

5.2.3.7.2 Issue Third Party Output Data Report

These reports are produced and issued as soon as the relevant data has been received from Data Providers and has been validated and stored.

5.2.3.7.3 Data Query

Suppliers are required to raise any queries on the data (potentially on behalf of one of their Supplier Agents) within 5WD of receipt by quoting the data file ID, otherwise the system assumes the data is authorised for use. Data that is subject to query is removed from the system and not progressed for further processing. The removal of this data may affect the completeness of a Supplier’s submission for one or more GSP Groups, however this may be resolved via data resubmission by the original Data Provider.

5.2.3.8 Provide Consolidated Performance Data

5.2.3.8.1 Generate Consolidated Third Party Output Data Report

A report is generated for each Supplier and Supplier Agent containing all the Performance Data that has previously been provided on an individual Serial basis via the Data Authorisation process. This is used by recipients to provide an overview of their performance each month in the absence of any Peer Comparison reports.

The generation of the report is triggered manually by Elexon at least 25WD after the end of each Reporting Period; the system shall perform a check to confirm that this time has passed before generating the report.

5.2.3.8.2 Issue Consolidated Third Part Output Data Report

The report is issued to Suppliers and Supplier Agents by email immediately after it has been generated.

5.2.4 Generate Routine Reports

5.2.4.1 Produce Monitoring Reports

Reports are produced each month as per the prevailing requirements of the PAA in order to monitor participant performance across GSP Groups, Serials and Standards. All Performance Data stored in the system may be used for these reports, which may be presented in a tabular or graphical format.

5.2.4.2 Produce Peer Comparison Reports

Peer Comparison reports are constructed for each Agent type and Supplier and describe the level of performance aggregated over a range of Reporting Periods for those Serials identified as being suitable for Peer Comparison. The Serials subject to Peer Comparison, and the level of reporting required, are listed in the table below. Also listed are the recipients for each report.

Serial	Titled	Reporting Level (National or GSP)	Recipient
CM01	CVA MOA Proving Tests	National by CVA MOA	Each CVA MOA
CM02	CVA MOA Fault Resolution	National by CVA MOA	Each CVA MOA
SP01	Delivery of routine performance reports	National by Supplier	Each Supplier
SP02	Delivery of routine performance logs	National by Supplier	Each Supplier
SP04	Installation of HH metering	GSP Group by Supplier	Each Supplier
SP07	SMRA & SVAA MSID Count	GSP Group by Supplier	Each Supplier
SP08	Energy and MSID on Actuals	GSP Group by Supplier	Each Supplier
SP09	NHH Defaults	GSP Group by Supplier	Each Supplier
SP11	Timely Appointment of Agents	GSP Group by Supplier	Each Supplier
SP12	Timely Notification of Changes of the Data Aggregator via D00148	GSP Group by Supplier	Each Supplier
SP13	Timely Notification of Changes of the Meter Operator Agent via D00148	GSP Group by Supplier	Each Supplier
SP14	Timely Notification of Changes of the Data Collector via D00148	GSP Group by Supplier	Each Supplier
SP15	Missing Appointments of Agents	GSP Group by Supplier	Each Supplier
NC11	Missing NHH Meter Reads & History from Old NHHDC to New NHHDC	GSP Group by NHHDC	Each Supplier and DC
NM11	Timely Sending of NHH MTDs to NHHDCs	GSP Group by NHH SVA MOA	Each Supplier and SVA MOA
NM12	Missing NHH MTDs	GSP Group by NHH SVA MOA	Each Supplier and SVA MOA
HM11	Timely Sending of HH MTDs to HHDCs	GSP Group by HH SVA MOA	Each Supplier and SVA MOA
HM12	Missing HH MTDs	GSP Group by HH SVA MOA	Each Supplier and SVA MOA
HM13	Quality of HH MTDs	GSP Group by HH SVA MOA	Each Supplier and SVA MOA
HM14	Timely HH Meter Investigation Requests	GSP Group by HH SVA MOA	Each Supplier and SVA MOA

The specific contents of the Peer Comparison reports are agreed between Elexon and the Performance Assurance Board (PAB) and can change as required to use any standards from the above serials.

Peer Comparison reports are produced as required but usually as soon as possible after the end of each quarter, and may be re-run at a later date to take into account any data that has been re-sent.

5.2.4.3 Ad-Hoc Reports

Ad-hoc reports are produced from time to time as required by the Elexon User, based upon selections and aggregations of data stored in the system.

5.2.5 Supplier Charges

5.2.5.1 Calculate Supplier Charges

The Supplier Charges calculation process is performed on a monthly basis, based upon the information submitted for each Reporting Period by the various Data Providers and the performance parameters stored in the system. For any given month, data for a previous Reporting Period may be revised by way of resubmission of the relevant Output Data. This can result in an adjustment to the Supplier Charges originally calculated for that Reporting Period, and an amount of interest may be applied.

The calculation shall disregard any charges relating to Serials that are no longer effective as a result of CP1344 ‘New PARMS Serials: Further Amendments to BSCP533 and BSCP533 Appendices’.

Any data pertaining to the unknown GSP Group (as described in BSCP533 Appendix B section 2.1.1) shall be disregarded within the Supplier Charges calculations.

The full details of all activities relating to Supplier Charges are contained in the Supplier Charges Specification (Reference 3).

5.2.5.2 Apportion SCs to Trading Party

Although the calculations for Supplier Charges are focused on Supplier IDs, it is the owning Trading Parties that are responsible for any underperformance and therefore liable to be charged.

The Trading Party associated with each Supplier ID is derived from the BM Unit Registration Data provided by the CRA. Each Supplier is assigned a Default Supplier BM Unit for each GSP Group; the BM Unit is registered in CRA against the owning Trading Party but the Supplier is identified within the BM Unit ID. PARMS compares the Supplier IDs with the Default Supplier BM Unit IDs to identify the Trading Party associated with each Supplier.

So long as at least one Supplier BM Unit remains registered against the Supplier in CRA, any de-registration of additional Supplier BM Units has no impact on the ability of PARMS to determine the association between Trading Party and Supplier. However, if a Trading Party de-registers all of its Supplier BM Units, PARMS deems that the Supplier has ceased trading. Where Supplier Charges continue to be accrued due to Settlement run-off, the charges are apportioned to the last registered Trading Party associated with that Supplier.

In the event that there is a change of Trading Party during a Reporting Period, the Supplier Charges for the Supplier ID in question are initially assigned to the Trading Party that was using that Supplier ID on the last day of the Reporting Period. Elexon will use a separate application (the Supplier Charge Apportionment System) to suitably apportion the Supplier Charges for that Reporting Period between the Trading Parties, and a set of resulting Supplier Charge reports will be generated outside of PARMS.

5.2.5.3 Produce Supplier Charges Reports

The results of the Supplier Charge calculations are used to produce reports for the PAA, Suppliers, Trading Parties and Elexon Finance that set out the charges payable by each Trading Party in relation to the performance of each Supplier ID in each GSP Group against the Serials and Standards during the relevant Reporting Period.

Where an adjustment has occurred, the total charges and receipts contained within the reports (with the exception of ‘year to date’ values) represent only the additional amounts, including interest, owed or credited since the latest set of Supplier Charges were calculated for the affected Reporting Period.

Note that, in the event that a Supplier ID is transferred between Trading Parties during a Reporting Period, the Trading Party totals in these reports will not be correct.

The set of reports produced is as follows:

Supplier Trading Report

This report provides a detailed breakdown of a Supplier’s performance against each Serial and the associated Supplier Charges, along with the derived values defined in Sections 5.2.5.2-5.2.5.6 above. This report is produced for each GSP Group and for each Reporting Period or Adjustment Period included in the Supplier Charge run.

Trading Party Trading Report

This report details the Supplier Charges and Trading Party receipts for each Reporting Period or Adjustment Period included in the Supplier Charge Run, and represents the total amounts owed or credited for each Trading Party (excluding Supplier Monthly Receipts SRM) across all associated Suppliers and GSP Groups.

Trading Party Summary Report

This report provides a summary of all the charges owed or credited for each Trading Party, including the charges payable as a Supplier, the receipts as an NHH Supplier, the receipts as a Trading Party and the net position, over all Suppliers, GSP Groups, Reporting Periods and Adjustment Periods contained in each Supplier Charge run.

PAA Summary Supplier Charges Report

This report summarises all the charges and receipts that are owed or credited for Suppliers and Trading Parties as a result of each Supplier Charge run. One report is produced for each Reporting Period or Adjustment Period, with each report containing the following sections:

Breakdown of charges by Supplier

This section is repeated for each GSP Group and details for each Supplier the Supplier Charges (i.e. S_CH – S_{CH_OLD}), Late Interest, Adjustment Interest and Final Amount Charged (S_RC). It also shows the totals of these values across Suppliers and the total amounts redistributed to NHH Suppliers and Trading Parties.

Summary of Supplier Charges by GSP Group

This section details for each GSP Group, the Final Amount Charged (including interest, i.e. S_RC) for the Reporting Period, and the year to date total amounts redistributed to NHH Suppliers and Trading Parties.

Total Supplier Charges Across All GSP Groups

This section details for each Supplier the Final Amount Charged (S_RC) summed across all GSP Groups, both for the Reporting Period and the year to date.

Summary of Supplier Charges for all GSP Groups

This section details the grand total of the Supplier Charges (S_CH-S_{CH_OLD}), Late Interest, Adjustment Interest and Final Amount Charged (S_RC) across all Suppliers and GSP Groups for the Reporting Period.

PARMS Payment Instructions

This report details the total charges owed or credited for each Trading Party for all Reporting Periods and Adjustment Periods included in the Supplier Charge run.

Although the system has the functionality to produce this report, it is not currently used as operationally the PARMS Payment Instructions are generated by the separate Supplier Charge Apportionment system.

Further details on the structure of the Supplier Charge reports are contained in the Supplier Charges Specification (Reference 3).

5.2.6 Issue Routine Reports

5.2.6.1 Issue Peer Comparison and Supplier Charges Reports

Peer Comparison and Supplier Charges reports are issued to the PAA to take to PAB for approval before they are distributed to industry.

5.2.6.2 Issue Routine Monitoring Reports

Routine monitoring reports generated as per the prevailing requirements of the PAA and/or PAB are issued to the PAA.

5.2.6.3 Issue Approved Peer Comparison Reports

Following approval of the PC Reports by PAB, the PAA instructs PARMS to issue the reports to Suppliers and Supplier Agents according to the contact details stored as Standing Data.

5.2.6.4 Issue Approved Supplier Charge Reports

Following approval of the SC Reports by PAB, the PAA instructs PARMS to issue the reports to the relevant Suppliers.

5.3 I/O Descriptions

Data Flow Name	From	To	Comments
Approved Peer Comparison Reports	PARMS Issue Routine Reports	Suppliers Supplier Agents	Peer Comparison Reports, once approved by PAB, are issued to Suppliers and Supplier Agents
Approved Supplier Charges Reports	PARMS Issue Routine Reports	Suppliers Trading Parties	Supplier Charge Reports, once approved by PAB, are issued to the relevant participants
Data Completeness Report	PARMS Manage Performance Data	Suppliers	The results of the completeness check are reported to the relevant Suppliers
Data Provider Contact Details	Elexon User	PARMS Manage Standing Data	The Elexon User provides contact details of all Data Providers for use when issuing reports
BM Unit Registration Data	CRA	PARMS Manage Standing Data	The CRA provides a list of Supplier BM Units and their owning Trading Parties for use in apportioning Supplier Charges
GSP Group Take Data	SVAA	PARMS Manage Standing Data	GSP Group Take data used in the calculation of Supplier Charges
Market Domain Data	SVAA	PARMS Manage Standing Data	The following information is provided by SVAA: GSP Groups; Market Participants; Market Participant Roles; Settlement Run Types; Distributors in GSP Groups; Settlement Calendar
NHH Energy Apportionment Data	SVAA	PARMS Manage Standing Data	For each Supplier in a GSP Group, the amount of NHH Energy for each month, and the amount of NHH energy for that GSP Group for all Suppliers
Output Data	Data Providers	PARMS Manage Performance Data	Output Data is submitted into PARMS by Data Providers
Performance Measurement Parameters	Elexon User	PARMS Manage Standing Data	The Elexon User provides details of the Serials, Standards and associated Charges to be supported by PARMS
Routine Performance Assurance Reports	PARMS Issue Routine Reports	PAA	Routine reports such as those for Peer Comparison, Supplier Charges and Market Monitoring are provided to the PAA for analysis and PAB approval
Data Provider Information	Suppliers	PARMS Manage Standing Data	Each month Suppliers provide details of their appointed agents acting as Data Providers, the Serials they expect them to submit, and the GSP Groups they expect them to submit them for.
Finance Data	Elexon Finance	PARMS Manage Standing Data	Bank interest details and Funding Shares
Supplier Charges Parameters	Elexon User	PARMS Manage Standing Data	The Elexon User inputs a set of additional parameters for use in Supplier Charges, including: SPDF; N_MC; interest rates
Data Authorisation Report	PARMS Manage Performance Data	Suppliers Supplier Agents	Output Data received from SVAA and Supplier Agents is issued to the subject of that data (if not the Data Provider) for review and query
Data Query	Suppliers	PARMS Manage Performance Data	Suppliers review and if necessary query the validity of Output Data provided by SVAA or Supplier Agents
Consolidated Performance Report	Suppliers Supplier Agents	PARMS Manage Performance Data	PARMS provides Suppliers and Supplier Agents with consolidated performance data following the submission deadline
Supplier-GSP Group Report	SVAA	PARMS Manage Standing Data	The SVAA provides a report listing the Suppliers operational in GSP Groups.
Validation Report	PARMS Manage Performance Data	Data Providers	A report is issued to the relevant Data Provider following the receipt and validation of each Output Data file received by PARMS
Non-Working Day Calendar	Elexon User	PARMS Manage Standing Data	A Non-Working Day Calendar is provided by the Elexon User for general use by PARMS

6 Logical Data Model

6.1 Purpose and Scope

This Logical Data Model contains descriptions of the data that must be processed by the system in order to meet its requirements. It is not intended to be a complete model of all the data required for PARMS processing, but to illustrate the structure of the data where that may facilitate understanding of the requirements. The model does not give any indication of the way in which the data should be stored, nor does it include data entities solely related to processing, such as those that may be necessary to monitor the sending and receipt of files.

6.2 Reporting Periods and Adjustment Periods

As noted in section 5.2.5, Supplier Charges can be adjusted in subsequent runs. For example, the Supplier Charges for June ‘07 would be first calculated in the Supplier Charge Run for June ’07, but could then be adjusted in any subsequent Supplier Charge Run. The entity definitions for those entities relating to Supplier Charges therefore include two distinct data items:

The Reporting Period identifies the Supplier Charge Run in which the value was calculated; and
The Adjustment Period identifies the period to which the Supplier Charge Run relates.

For example, an adjustment to the June ’07 Supplier Charges calculated in the September ’07 Supplier Charge run would have a Reporting Period of September ’07 and an Adjustment Period of June ’07. The Adjustment Period entity represents this concept in the Logical Data Model.

6.3 Logical Data Structure

6.4 Entity Definitions

This section defines the entities in the Logical Data Model. Note that in the attribute definitions, ‘p’ indicates a Primary Key field, and ‘o’ indicates an optional field.

Adjustment Period

A calculation of Supplier Charges that:

Relates to a given Reporting Period (identified by the Adjustment Period attribute); and
Is carried out in the Supplier Charge Run for a given Reporting Period (identified by the Reporting Period attribute).

Contains attributes

p Reporting Period

p Adjustment Period

Annual GSP Group Take

The Annual GSP Group Take provided by the SVAA.

Contains attributes

p Year End Date

p GSP Group Id

Annual Take

BM Unit Allocation

Details of the Parties to which Supplier BM Units are allocated. This data is received from the Central Registration Agent (CRA), and is used to derive the link between Supplier Ids and BSC Party Ids (as the Supplier Id is embedded within the BM Unit Id for Supplier BM Units).

Contains attributes

p BM Unit Id

p Effective From Date

Trading Party Id

o Effective To Date

Completion Check Log

Tracks the completion status of a Supplier submission over time, and is used to calculate serial SP01.

Contains attributes

p Reporting Period

p Supplier Id

p GSP Group Id

p Updated

Status

Contact

The Contacts for each Market Participant. Note that there can be one contact per Assurance Technique

Contains attributes

p Participant Id

p Contact Id

p Effective From Data

o Effective To Date

Contact Name

Contact email

Contact Address

Data Provider

A role in which a specific Market Participant provides Output Data relating to one or more Suppliers. Note that Data Provider Id is a synonym of Market Participant Id.

Contains attributes

p Data Provider Id

p Data Provider Role Code

Effective From Date

Effective To Date

Funding Share

The monthly funding share for each Trading Party.

Contains attributes

p Reporting Period

p Trading Party Id

Funding Share

GSP Group

The GSP Groups that the system covers.

Contains Attributes

p GSP Group Id

p Effective From Date

o Effective To Date

Description

GSP Group Reporting Period

Data for a GSP Group in a Reporting Period e.g. the GSP Group Take, Half Hourly and Non Half Hourly energy totals (provided by the SVAA) and the GSP Group Monthly Cap.

Contains attributes

p Reporting Period

p GSP Group Id

GSP Group Monthly Cap

GSP Group Take

Non-Half Hourly Energy

Market Participant

The participants in the Trading Arrangements e.g. Suppliers (for whom Supplier Charges are calculated) and Supplier Agents (who act as Data Providers)

Contains Attributes

p Market Participant Id

p Effective From Date

o Effective To Date

Name

Non Working Days

The non working days. This entity is manually updated and is required for the calculation of Serial SP01.

Contains attributes

p Date

Output Data Log

Logs the Output Data expected by the system, based on the lists of Agents, GSP Groups and Serials (‘Data Provider Information’) submitted by Suppliers.

The Data Received attribute can have the value “Yes” to indicate that the data was expected and has been received; or “No” to indicate that the data is expected but has not yet arrived.

Contains attributes

p Reporting Period

p Supplier Id

p GSP Group Id

p Data Provider Role Code

p Data Provider Id

p Serial Id

Data Received

Party SC Totals

The Party level totals values calculated as part of the Supplier Charge Calculation. For the Run Period during the calculation, both the Reporting Period and Run Period should be set to the Run Period value.

Contains attributes

p Reporting Period

p Adjustment Period

p Trading Party Id

Total Supplier Charge

Performance Targets

Performance Targets for Techniques

Contains attributes

p Technique

p Serial Id

p Standard Id

p Effective From Date

p Performance Standard Id

o Effective To Date

Performance Standard

Reporting Period

The Output Data Reporting Period (i.e. a month). This entity is used to track the Supplier Charge status.

Contains attributes

p Reporting Period

SC Status

Base Rate

o PAB Approval Date

Serial

The Serials for which data is required to be submitted. The SP01 Applicable flag identifies the Serials to which SP01 applies.

Contains attributes

p Serial Id

p Effective From Date

o Effective To Date

Description

SP01 Applicable

SP01 Late Details

The low level data derived in the SP01 calculation. Note that Reporting Period identifies the Reporting Period during which the data was late (and in which the SP01 charge will be levied), while SP01 Reporting Period identifies the Reporting Period to which the files relate. For example, if files relating to June ’07 were still missing in September ’07, this would be recorded with a Reporting Period of September ’07 and an SP01 Reporting Period of June ’07.

Start Date is the first date of the incomplete period, and End Date is the last. Note that an accurate record of which Working Days data was missing on must be maintained (to allow the Supplier Charge Apportionment system to apportion SP01 charges correctly), and therefore more than one record may be required for a given Reporting Period, SP01 Reporting Period, Supplier Id and GSP Group Id.

Contains attributes

p Reporting Period

p SP01 Reporting Period

p Supplier Id

p GSP Group Id

p Start Date

End Date

Days Late

SP01 Period

An occurrence of SP01 Period indicates that one or more Suppliers have missing data (for the previous Reporting Period identified by the SP01 Reporting Period attribute) in a given Reporting Period.

Contains attributes

p Reporting Period

p SP01 Reporting Period

Standards

The Standards, as described in the Modification.

Contains attributes

p Serial Id

p Standard Id

p Effective From Date

o Effective To Date

Description

Supplier

A licensed supply business (as identified by a Supplier Id published in Market Domain data). Note that a Supplier Id is a type of Market Participant Id.

Contains attributes

p Supplier Id

Supplier Charge Standards

The Standards against which Supplier Charges are calculated.

Contains attributes

p Technique Id

p Serial Id

p Standard Id

p Effective From Date

p Performance Standard Id

o Effective To Date

Performance Standard

Cost Per Unit of Failure

Supplier GSP Group in Reporting Period

The GSP Group Take, Half Hourly and Non Half Hourly energy totals provided by the SVAA. Note that Supplier Cap is optional, as it is calculated as part of the Supplier Charges process.

Contains attributes

p Reporting Period

p GSP Group Id

p Supplier Id

Supplier Deemed Take

Supplier Cap Take

Supplier Non-Half Hourly Energy

o Supplier Cap

Serial Total

The GSP Group and Supplier and Serial level totals for the Supplier Charges Calculation.

Contains attributes:

p Reporting Period

p Adjustment Period

p GSP Group Id

p Supplier Id

p Serial Id

p Standard Id

p Settlement Date

p Settlement Run Type

Performance Level

Serial Charge

Supplier Charge

The GSP Group and Supplier level totals for the Supplier Charges Calculation.

Contains attributes

p Reporting Period

p Adjustment Period

p GSP Group Id

p Supplier Id

Supplier Charge (S_CH)

Final Amount Charged (S_RC)

Previous Charge (S_{CH_OLD})

Supplier Serial Charge

The component of the Supplier Charge (for a given GSP Group, Supplier, Reporting Period and Adjustment Period) that relates to a specific Standard.

Contains attributes

p Reporting Period

p Adjustment Period

p GSP Group Id

p Supplier Id

p Serial Id

p Standard Id

Supplier Serial Charge

Trading Party

A Trading Party i.e. a legal entity (other than the National Electricity Transmission System Operator (NETSO)) that has acceded to the BSC and registered Trading Accounts.

Contains attributes

p Trading Party Id

Appendix A – Data File Formats

Output Data

Output Data is provided in a prescribed file format, with one file for each Serial. The majority of Output Data is provided in the Pool File Format, which contains a number of records separated by a Record Delimiter character. The records are as follows:

header – a standard ZHD file header record;
subject participant – a record denoting the participant that is the subject of the Serial (e.g. a Supplier, HHDC, MO, etc);
serial data – this is the data relating to the performance of the subject in relation to a specific Serial;
footer – a standard ZPT file footer record, including a record count and a checksum.

ZHD - File Header
Field	Field Name	Type	Comments
1	Record Type	text(3)	= ZHD
2	File Type	text(8)	5 character type (ranges allocated for DTS, pool or internal use) plus 3 character version
3	From Role Code	text(1)
4	From Participant ID	text(4)
5	To Role Code	text(1)	‘Z’ (representing PAA)
6	To Participant ID	text(4)	‘POOL’ (representing Elexon)
7	Creation Time	date/time	Time file processing was started. Specified in GMT.

SUB - Subject Participant Header
Field	Field Name	Type	Comments
1	Record Type	text(3)	= SUB
2	Market Sector	text(1)	= H (half hourly) = N (non-half hourly) = B (both)
3	Market Participant Role Code	text(1)	Role Code of the subject Market Participant
4	Market Participant ID	text(4)	Identifier of the subject Market Participant
5	Period End Date	date	Date of the last calendar day of the period to which the data applies.
6	Periodicity	text(1)	Indicates whether the Period End Date is ‘W’eekly, ‘M’onthly or ‘Q’uarterly.

ZPT - File Footer
Field	Field Name	Type	Comments
1	Record Type	text(3)	= ZPT
2	Record count	integer(10)	Includes header and footer
3	Checksum	integer(10)	Although type is shown as integer(10) the value is actually a 32-bit unsigned value and hence will fit in an “unsigned long” C variable.

The structure and content of the Serial data record differs for each Serial. Full details are contained in BSCP533 Appendix A ‘PARMS Data Provider File Formats’ (Reference 2).

Output Data for Serials SH01, SH02, and NC01

The information required by PARMS for these Serials is received from copies of DTN files from participants whenever such files are generated. The files in question are as follows:

SH01 and SH02: D0023 Failed Instructions

NC01: D0235 Half Hourly Aggregation Exception Report

These files are therefore provided in the User file format. This format uses a ZHV rather than a ZHD file header group and is structured as follows:

ZHV - File Header
Field	Field Name	Type	Comments
1	Record Type	text(3)	= ZHV
2	File Identifier	text(10)	File identifier unique within participant
3	Data flow and version number	text(8)
4	From Role Code	text(1)
5	From Participant Id	text(4)
6	To Role Code	text(1)
7	To Participant Id	text(4)
8	Creation Time	date/time	Time file processing was started. Specified in GMT.

Full details are contained in BSCP533 (Reference 2).

SVAA Standing Data

Standing Data is provided by SVAA in Pool File Format but in a different structure than that of the Output Data. Full Details are contained in BSCP533 (Reference 2).

Funding Shares

Trading Party Funding Shares are provided by Elexon Finance in a specific format which is structured as follows:

Field	Field Name	Type	Comments
Date Information
1	Date	date	Date of last day of month
Funding Share Data
2	Trading Party ID	text(8)
3	Main Funding Share	dec(13,6)
4	Trading Party Name	text(30)

Appendix B – Data Processing Reports

The following reports are those generated by PARMS and issued to participants to support data processing, validation and authorisation activities.

Email Receipt Report

P_A_R_M_S

Email received from:

Received on:

Subject:

The following attachments were processed from this email:

The following problems were encountered when processing this email:

Report created:

Data Receipt Report

P_A_R_M_S

Data file:

File type:

Attached to email received on: [DATETIME] from:

Creation date time:

Period End date:

Validation Results:

Report created:

Completeness Report

Data Complete

P_A_R_M_S

Data complete for reporting period [reportingperiod]

Report Created:

All expected data for this period has been received the date and time this report was created. Your subsequent actions (i.e. altered agent appointment advice to Elexon) may result in this report becoming inaccurate. It remains your responsibility to ensure all reporting is complete, accurate and Code compliant.

Data Missing

P_A_R_M_S

[data example]

Data Missing for reporting period SEP-2004, GSP Group : _K, Participant : ABCD, Role : M, Serial : NM03

Data Missing for reporting period SEP-2004, GSP Group : _K, Participant : ABCD, Role : M, Serial : NM04

Data Missing for reporting period SEP-2004, GSP Group : _K, Participant : ABCD, Role : M, Serial : SP05

Data Missing for reporting period SEP-2004, GSP Group : _K, Participant : ABCD, Role : M, Serial : SP06

Data Missing for reporting period SEP-2004, GSP Group : _L, Participant : EFGH, Role : M, Serial : NM03

Data Missing for reporting period SEP-2004, GSP Group : _L, Participant : EFGH, Role : M, Serial : NM04

Data Missing for reporting period SEP-2004, GSP Group : _L, Participant : EFGH, Role : M, Serial : SP05

Data Missing for reporting period SEP-2004, GSP Group : _L, Participant : EFGH, Role : M, Serial : SP06

Data Missing for reporting period SEP-2004, GSP Group : _M, Participant : IJKL, Role : M, Serial : NM03

Data Missing for reporting period SEP-2004, GSP Group : _M, Participant : IJKL, Role : M, Serial : NM04

Data Missing for reporting period SEP-2004, GSP Group : _M, Participant : IJKL, Role : M, Serial : SP05

Data Missing for reporting period SEP-2004, GSP Group : _M, Participant : IJKL, Role : M, Serial : SP06

Report Created: 28-OCT-2004 09:13:37

These are the reports known to be missing at the date and time this report was created. Your subsequent actions (i.e. altered agent appointment advice to Elexon) may result in this list becoming incomplete. It remains your responsibility to ensure all reporting is complete, accurate and Code compliant.

Third Party Output Data Report

P_A_R_M_S

The following data has been submitted to PARMS on your behalf by the Participant detailed below. No queries raised on this data by close of business [DD-MMM-YYYY] will be taken as acceptance.

PARMS Reference:

Serial:

From Participant Id:

From Role Code:

File Name:

Received:

Period End Date:

Contents:

[(spooled details)]

Report created: [Sys date/time]

Consolidated Third Party Output Data Report

P_A_R_M_S Consolidated Report

The following data has been submitted to PARMS on your behalf for the Serials below.

Period End Date: [PeriodEndDate]

Contents:

Serial Data Data [(spooled details)]

Id Provider Provider

Id Role Code

SP05 ABCD M ….

SP05 ABCD D ….

HM02 EFGH G ….

HM02 IJKL M ….

Report created: [Sys date/time]

1 Following the implementation of P197 on 23 August 2007, all new applicants are subject to the new Qualification process set out in BSCP537.

2 SVA MOAs will be subject to the requirements of this PARMS URS for the period of the “SVA MOA Performance Assurance Transition Period” detailed in Section Z 5.1.1A – 5.1.1C

3 Although forming part of the Output Data Schedule, Run Type information is not used by the Completeness Checking process.

CONTENTS

PARMS User Requirements Specification

1 Introduction

1.1 Introduction

1.2 Purpose and Scope

1.3 Summary of the Document

1.4 Terminology

2 Principles and Objectives

2.1 Purpose and Scope

2.2 Business Objectives

2.3 System Objectives

3 Business Description

3.1 Introduction

3.2 Service Scope

3.3 System Scope

3.4 Assumption

3.5 Interfaces

3.5.1 Data Providers

3.5.2 Elexon Finance

3.5.3 Suppliers

3.5.4 Performance Assurance Board

3.5.5 SVAA

3.5.6 CRA

3.5.7 Supplier Charge Apportionment System

3.5.8 Pre-P99 PARMS

3.6 PARMS Context

3.7 Business Events

3.7.1 Data Providers added/deleted

3.7.2 Suppliers added/deleted

3.7.3 Contact Details added/modified/deleted

3.7.4 Change of Supplier Ownership within Reporting Period

3.7.5 Data Providers sending Output Data

3.7.6 SVAA sending Annual GSP Group Take Data

3.7.7 SVAA Sending Consumption Data

3.7.8 Elexon sending Funding Share data

3.7.9 Suppliers sending Data Provider Information

3.7.10 CRA sending BM Unit registration data

3.7.11 Changes to Market Domain Data

3.7.12 Queries/amendments raised by reviewers/approvers of reports generated by PARMS

3.7.13 Approval of Reports

3.7.14 Serial added/modified/deleted

3.7.15 Standard added/modified/deleted

3.7.16 Archiving

3.7.17 Application of Force Majeure and Error Correction

4 Requirements Catalogue

4.1 Functional Requirements

4.2 Non-Functional Requirements

4.3 Operational Requirements

5 Data Process Model

5.1 Purpose and Scope

5.2 Elementary Process Descriptions

5.2.1 Manage Standing Data

5.2.1.1 Performance Measurement Parameters

5.2.1.1.1 Maintain Performance Serials, Standards and Charges

5.2.1.1.2 Maintain Serial Submission Window

5.2.1.2 Supplier Charge Data

5.2.1.3 Market Domain Data

5.2.1.4 Non-Working Day Calendar

5.2.1.5 Maintain Output Data Schedule

5.2.1.5.1 Load Supplier-GSP Group Trading Data

5.2.1.5.2 Load Data Provider Information Data

5.2.1.5.3 Retrieve Settlement Calendar Data

5.2.1.6 Maintain Data Provider Contact Details

5.2.1.7 Maintain Report Distribution Information

5.2.2 Produce PAA Output Data

5.2.2.1 Produce SP01 Output Data

5.2.2.2 Enter SP02 Data

5.2.3 Manage Performance Data

5.2.3.1 Record and Acknowledge Data Receipt

5.2.3.1.1 Record Date and Time of Receipt

5.2.3.1.2 Validate Email Address

5.2.3.1.2 Acknowledge Receipt

5.2.3.2 Check Validity of Data

5.2.3.3 Process Validation Results

5.2.3.4 Store Data

5.2.3.5 Check Completeness of Data

5.2.3.6 Report Completeness

5.2.3.7 Data Authorisation

5.2.3.7.1 Generate Third Party Output Data Report

5.2.3.7.2 Issue Third Party Output Data Report