1 Introduction

1.1 Introduction

• Monitoring and reporting;

• Calculation of Supplier Charges (also known as Liquidated Damages);

• Peer Comparison;

• Error and Failure Resolution; and

• Removal of Qualification¹.

1.2 Purpose and Scope

1.3 Summary of the Document

• 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 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).

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

2 Principles and Objectives

2.1 Purpose and Scope

1. PARMS will receive data from participants relating to the Serials and Standards established by the Code and Code Subsidiary Documents;

2. PARMS will determine Supplier Charges in accordance with the provisions of the Code;

3. PARMS will generate reports for the Elexon User showing the performance of market participants against the Serials and Standards;

4. PARMS will support interfaces with relevant participants and systems in order to facilitate timely data provision and receipt; and

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

2.3 System Objectives

3 Business Description

3.1 Introduction

• 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

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

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

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

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

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

1. Load Data from SVAA

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

2. Load Funding Shares

3. Load BM Unit Registration Data

4. Enter Additional Parameters

• 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

1. GSP Groups;

2. Distributors in GSP Groups;

3. Market Participant IDs;

4. Market Participant roles (Supplier, MOA, NHHDC, HHDC, NHHDA, HHDA, SMRS);

5. SSR Run Types; and

6. Settlement Calendar.

5.2.1.4 Non-Working Day Calendar

5.2.1.5 Maintain Output Data Schedule

1. The Suppliers from whom Output Data is expected for each GSP Group;

2. The Supplier Agents from whom Output Data is expected for each GSP Group;

3. The Suppliers and Supplier Agents expected to be identified as the subject of Output Data; and

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

5.2.1.5.2 Load Data Provider Information Data

5.2.1.5.3 Retrieve Settlement Calendar Data

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

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

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

4. 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).

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

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

5.2.1.7 Maintain Report Distribution Information

5.2.2 Produce PAA Output Data

5.2.2.1 Produce SP01 Output Data

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

• 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

• Reporting Period

• Supplier ID:

• GSP Group ID;

• month end date; and

• number of Working Days performance logs are late.

5.2.3 Manage Performance Data

• 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

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

5.2.3.7.3 Data Query

5.2.3.8 Provide Consolidated Performance Data

5.2.3.8.1 Generate Consolidated Third Party Output Data Report

5.2.3.8.2 Issue Consolidated Third Part Output Data Report

5.2.4 Generate Routine Reports

5.2.4.1 Produce Monitoring Reports

5.2.4.2 Produce Peer Comparison Reports

5.2.4.3 Ad-Hoc Reports

5.2.5 Supplier Charges

5.2.5.1 Calculate Supplier Charges

5.2.5.2 Apportion SCs to Trading Party

5.2.5.3 Produce Supplier Charges Reports

• Breakdown of charges by Supplier

• Summary of Supplier Charges by GSP Group

• Total Supplier Charges Across All GSP Groups

• Summary of Supplier Charges for all GSP Groups

5.2.6 Issue Routine Reports

5.2.6.1 Issue Peer Comparison and Supplier Charges Reports

5.2.6.2 Issue Routine Monitoring Reports

5.2.6.3 Issue Approved Peer Comparison Reports

5.2.6.4 Issue Approved Supplier Charge Reports

5.3 I/O Descriptions

6 Logical Data Model

6.1 Purpose and Scope

6.2 Reporting Periods and Adjustment Periods

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

6.3 Logical Data Structure

6.4 Entity Definitions

• 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).

Appendix A – Data File Formats

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

Appendix B – Data Processing Reports

1. Data Complete

2. Data Missing