Advanced Search

BSCP533: Appendix A PARMS Data Provider File Formats Appx A

v 19.0
Download

Balancing and Settlement Code

BSC PROCEDURE

BSCP533 – Appendix A:

PARMS Data Provider File Formats

Version 19.0

Date: 24 February 2022

BSCP533 Appendix A Relating to PARMS Data Provider File Formats

1. Reference is made to the Balancing and Settlement Code and in particular, to the definition of “BSC Procedure” In Section X, Annex X-1 thereof.

2. This is BSC Procedure 533 Appendix A Version 19.0 relating to PARMS Data Provider File Formats.

3. This BSC Procedure is effective from 24 February 2022.

4. This BSC Procedure has been approved by the Panel.

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

AMENDMENT RECORD

Version

Date

Description of Changes

Changes Included

Mods /Panel/ Committee Refs

0.1

Code Effective Date

Re-badged AP533 to form BSCP533

1.1

Code Effective Date

Submitted to the Panel for approval

NCR313

2.0

27/03/01

Approved by the Panel on 22nd February 2001

P13/008

3.0

01 November

Changes for Modification P68

P68

NPAB19/210

4.0

01/03/03

Updated to reflect the terminology used in the BSC

CP852

NPAB22/244

5.0

01/08/03

Updated for Modification P62

P62

6.0

06/01/04

Updated for Modification P99

P99

6.1

13/01/04

Updated with SVG and P99 workshop comments

P99

7.0

01/05/04

Approved by SVG

P99

8.0

01/07/04

Consistency Amendments and Working Day timings updates

P99

SVG41/002

9.0

04/11/04

Incremented to align with document suite amended for the SVA November 2004 Release

10.0

23/02/05

SVA February 05 Release and BETTA 6.3

BETTA 6.3, CP1090, CP1091

SVG47/004

11.0

30/06/05

SVA June 05 Release

CP1103

SVG52/005

12.0

03/11/05

SVA November 05 Release

CP1087

SVG56/004

13.0

28/06/07

June 07 Release

Updated terminology in preparation for P197 Release

CP1178

P197

SVG72/04

14.0

05/11/09

November 09 Release

CP1248 v2.0

SVG97/01

15.0

01/11/10

November 10 Release

CP1325

SVG111/01

16.0

01/07/11

June 11 Release

CP13341

SVG114/02

CP13441

SVG122/02

CP13481

SVG125/01

17.0

07/11/13

November 2013 Release

CP1387

PAB145/08

SVG145/04

CP1399

PAB152/04

SVG152/08

18.0

01/09/21

1 September 2021 Non-Standard Release

P420

P316/05

19.0

24/02/22

February 2022 Standard Release

P429

Ofgem

Related Documents

Reference 1

PARMS User Requirements Specification

Reference 2

BSC Procedure: PARMS Data Provision, Reporting and Publication of Peer Comparison Data (BSCP533)

Reference 3

BSC Procedure: PARMS Data Provision (BSCP533 – Appendix B: PARMS Calculation Guidelines)

1. INTRODUCTION

1.1 Purpose

The purpose of this document is to specify the file format specification associated with the information to be submitted to the Performance Assurance Reporting and Monitoring System (PARMS) which monitors Market Participants’ performance. This is intended to provide guidance for Data Providers to assist them in the development of their systems.

1.2 PARMS Data

1.2.1 PARMS Data: General Description

PARMS Data consists of data pertaining to the performance of specified market Participants and is provided via a pre-determined series of files by agreed Data Providers (SMRAs, the SVAA, the CDCA, Suppliers or Supplier Agents). This data is specified in BSCP533 PARMS Data Provision, Reporting and Publication of Peer Comparison Data. The data will be loaded automatically into the PARMS database using the corresponding PARMS validation process.

The data descriptions defined in the relevant Data sections of BSCP533 have been summarised in this paper into usable data identifiers.

The appropriate files are summarised below:

Output Data

Serial

Titled

FILETYPE

TA01

GSP Group Correction Factor

P0137001

TA02

Annual Demand Ratio

P0138001

CM01

CVA MOA Proving Tests

P0133001

CM02

CVA MOA Fault Resolution

P0134001

SP02

Delivery of Routine Performance Logs

P0140001

SP07

SMRA & SVAA MSID Count – SMRA File

P0045002 (SMRA)

SP07

SMRA & SVAA MSID Count – SVAA File

P0164001 (SVAA)

SP08

Energy and MSIDs on Actuals

P0145002

SP09

NHH Defaults

P0146001

Standing Data

FILETYPE

PARMS Market Domain Data

P0136001

Suppliers Trading / Ceased Trading in GSP Groups

P0127001

2. PHYSICAL FILE PRESENTATION

2.1 Media

Data files will be submitted into PARMS by the Data Provider (Supplier, Supplier Agent or BSC Agent) in the form of ASCII files. A separate data file is required for each Serial, although a number of files may be contained in one submission.

2.2 File Naming

An 8-character file naming convention will be used as follows:

    • The 1st to 4th characters will be the participant ID of the Data Provider;

    • The 5th to 7th will relate to the File Identifier that will be used in the SVA Data Catalogue; and

    • The 8th will be the last digit of the year number (e.g. ‘2’ for 2002, ‘3’ for 2003).

The file extension will indicate the month to which the data pertains (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC).

2.3 File Submission and Verification of Output Data

Data Providers should submit PARMS data +(x) WDs after the end of the reporting period as follows:

    • SMRAs: +10 WDs; and

    • SVAA: +7 WDs

All files will be submitted direct to PARMS by the Data Providers specified in the File Formats. Where there has been no occurrence of an event monitored by a Serial, Data Providers should reflect this by using zeros in place of the values for each Supplier and GSP Group. Where there has been no occurrence of an event, but appointments exist in for that Supplier and GSP Group combination, Data Providers should reflect this by submitting zero values against all the standards for these combinations. Failure to do so may result in missing data. If no data is provided at all then PARMS will regard the submission as incomplete and apply Supplier Charges if appropriate. The process and timescale for submission is detailed in BSCP533 ‘PARMS Data Provision Reporting and Publication of Peer Comparison Data’.

Once received, BSCCo will distribute any Supplier-related data to the relevant Suppliers in order to allow them to verify the data submitted by its appointed agents, particularly where poor performance against a Serial may lead to Supplier Charges. Any queries raised will be dealt with between the Supplier and its Agent, and any resubmission of data should be by the specified Data Provider. (Suppliers can, of course, request that their agents provide copies of any files submitted to PARMS for checking, but this will not be assumed by BSCCo).

2.4 File Resubmission and Correction

Once a Data Provider has submitted a file, it may be resubmitted in order to correct errors subsequently identified in the file. For each Serial, if a correction is required then a complete submission for the affected GSP Group must be provided, such that it is made clear that the data that was originally correct should remain in the system. If a file is submitted containing only the corrected data, PARMS will assume that the rest of the data already stored in the system has been since been identified by the Data Provider as incorrect and that the data should be deleted from the system.

3. PHYSICAL FILE FORMATS

3.1 Pool File Format

The majority of the Data Output files will use the Pool file format. In this format, a file contains a number of records, each starting with a three-character identifier and ending with a Record Delimiter character. The first record of each file will be a header; the last a footer. The last record of a physical block will not require a Record Delimiter.

Each record contains fields of various types such as text, integer, date and time. The full range is described below:

Type

Format

Example

int

(Integer)

ASCII representation, no leading zeros or spaces, leading “-“ if negative (no sign if positive)

-1234

12

dec

(Decimal)

ASCII representation. As for Integer, but with a decimal point and fixed number of decimal digits (including trailing zeros) dependent on precision

dec(4,2): -12.34

dec(3,2): 1.20

text

ASCII format, left aligned with trailing spaces stripped. Only includes printable characters excluding the separator

The quick fox

date

ASCII format as: YYYYMMDD

19961216

time

ASCII format as: HHMMSS (24 hour format). Note: both GMT and local time (e.g. British Summertime) will be used and will be indicated as necessary.

131501

date/time

ASCII format as: YYYYMMDDHHMMSS

19961216131501

bol

(Boolean)

One ASCII character: T for True, F for False (uppercase only)

T

F

A Field Separator character separates each field (with the exception of the last field of each record). All fields are mandatory, unless specifically indicated as optional in the ‘comments’ column. A null submission is achieved by omitting any characters between the Field Separators.

All files sent or received by PARMS are structured as follows:

    • Header - first record in file - record type = “ZHD”

    • Body - other file records

    • Footer - last record in file - record type = “ZPT”

For PARMS Output Data, the first record of the file “Body” is a subject participant header (record type “SUB”) containing information about the subject market participant.

Note that there may be many SUB records (e.g. where a Supplier has a number of agents, or an agent contracted to many Suppliers, and where the Supplier is operating in more than one GSP Group).

The components of these three standard record types are defined in the following tables:

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’ (Non-Core - PARMS)

6

To Participant Id

text(4)

‘POOL’

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)

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 (generally either a month or a quarter) 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

int(10)

Includes header and footer

3

Checksum

int(10)

Although type is shown as int(10) the value is actually a 32-bit unsigned value and hence will fit in an “unsigned long” C variable.

The remaining component of the File is a body record containing the required PARMS information. These will be specific for each Serial and, like the SUB record, will be repeated in situations where, for example, an SMRS or a Supplier Agent is operating in a number of different GSP Groups, or where data is required for a number of different Settlement Run types.

Some files involve the reporting of a data item against a list of Settlement dates, such as for Serial SP07. In these instances, the dates and the associated data items should be listed in ascending order.

The character set used is based on the ISO Level B character set and will include the following characters:

Letters, upper case

A to Z

Letters, lower case

a to z

Numerals

0 to 9

Space character

Full stop

.

Comma

,

Hyphen/minus

-

Opening parenthesis

(

Closing parenthesis

)

Slash

/

Apostrophe

'

Plus

+

Colon

:

Equals

=

Question mark

?

Exclamation mark

!

Quotation mark

"

Percentage sign

%

Ampersand

&

Asterisk

*

Semi-colon

;

Less than

<

Greater than

>

Underscore

_

Field Separator: The vertical bar character ‘|’ will be used as the separator.

Record Delimiter: The Line Feed character (hex “A”) or a Carriage Return is used as the delimiter.

4. STANDING DATA FILE FORMATS

4.1 Not Used

4.2 PARMS Market Domain Data

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0136001

3

From Role Code

text(1)

= G (SVA Agent)

4

From Participant Id

text(4)

CAPG

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

VER : MDD version

1

Record Type

text(3)

= VER

2

MDD Version Number

int(8)

GSG : GSP Group

1

Record Type

text(3)

= GSG

2

GSP Group Id

text(2)

3

GSP Group Name

text(30)

GGD : GSP Group Distributors

1

Record Type

text(3)

=GGD

2

Distributor Id

int(2)

3

Market Participant Role Code

text(1)

4

Effective from Date {MPR}

date

5

Effective from Settlement Date {GGD}

date

6

Effective to Settlement Date {GGD}

date

optional

MRC : Market Participant Role Codes

1

Record Type

text(3)

= MRC

2

Market Participant Role Code

text(1)

3

Role Code Description

text(30)

MAP : Market Participants

1

Record Type

text(3)

= MAP

2

Market Participant Id

text(4)

3

Market Participant Name

text(40)

4

Pool Member Id

text(4)

optional

MPR : Market Participant Roles

1

Record Type

text(3)

= MPR

2

Market Participant Role Code

text(1)

3

Effective from Settlement Date {MPR}

date

4

Effective to Settlement Date {MPR)

date

optional

SSR : SSR Run Type

1

Record Type

text(3)

= SSR

2

SSR Run Type

text(2)

3

SSR Run Type Name

text(40)

SSC : Settlement Calendar

1

Record Type

text(3)

= SSC

2

SSR Run number

int(7)

3

Settlement Date

date

4

SSR Run Type

text(2)

5

SSR Run Date

date

Note

1 there is a one to many relationship between Meter asset provider (MAP) and market participant role (MPR) record types

2 the VER record type denotes which version of MDD was used for the source of this file

Backus-Naur Form:

PARMS Market Domain Data ::= ZHD VER {GSG {GGD}} {MRC} {MAP {MPR}} {SSR} {SSC} ZPT

4.3 Suppliers Trading / Ceased Trading in GSP Groups

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0127001

3

From Role Code

text(1)

= G (SVA Agent)

4

From Participant Id

text(4)

CAPG

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SPT : Supplier Trading / Ceased Trading in GSP Group

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SPT

2

GSP Group Id

text(2)

3

Supplier Id

text(4)

4

Effective from Date Supplier Trading in GSP Group

date

Calendar date started trading in GSP Group

5

Effective to Date Supplier Trading in GSP Group

date

Optional. Calendar date ceased trading in GSP Group

Backus-Naur Form:

Suppliers Trading / Ceased Trading in GSP Groups ::= ZHD {SPT} ZPT

5. OUTPUT DATA FILE FORMATS

5.1 TA01 – GSP Group Correction Factor

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0137001

3

From Role Code

text(1)

= G (SVAA)

4

From Participant Id

text(4)

= CAPG

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= B (indicates HH and NHH data)

3

Market Participant Role Code

text(1)

= NULL

4

Market Participant Id

text(4)

= NULL

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

TA1 Trading Arrangements Serial 1 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= TA1

2

Number of GCF queries raised

int(5)

5.2 TA02 – Annual Demand Ratio

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0138001

3

From Role Code

text(1)

= G (SVAA)

4

From Participant Id

text(4)

=CAPG

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= B (indicates HH and NHH data)

3

Market Participant Role Code

text(1)

Not applicable

4

Market Participant Id

text(4)

Not applicable

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

TA2 Trading Arrangements Serial 2 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= TA2

2

Annual Demand Ratio

dec(5,4)

Backus-Naur Form:

Annual Demand Ratio ::= ZHD SUB TA2 ZPT

5.3 CM01 – CVA MOA Proving Tests

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0133001

3

From Role Code

text(1)

= Z

4

From Participant Id

text(4)

= CDCA

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SB1

2

Market Sector

text(1)

= H

3

Market Participant Role Code

text(1)

= M (MOA)

4

Market Participant Id

text(8)

ID of CVA MOA

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

CM01 CVA MOA Serial 1 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= CM1

2

GSP Group Id

text(2)

= ‘NULL’ if directly-connected site

3

Number of MSIDs affected in period

int(7)

4

Average number of working days Proving Test is outstanding after Effective From Date at time of report

dec(4,1)

5

Count of faults outstanding after Effective From Date

int(7)

Backus-Naur Form:

CVA MOA Proving Tests ::= ZHD {SB1 {CM1}} ZPT

5.4 CM02 – CVA MOA Fault Resolution

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0134001

3

From Role Code

text(1)

= Z

4

From Participant Id

text(4)

= CDCA

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SB2

2

Market Sector

text(1)

= H

3

Market Participant Role Code

text(1)

= M (MOA)

4

Market Participant Id

text(8)

ID of CVA MOA

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

CM02 CVA MOA Serial 2 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= CM2

2

GSP Group Id

text(2)

= ‘NULL’ if directly-connected site

3

Number of MSIDs affected in period

int(7)

4

Count of faults identified

int(7)

5

Average number of working days faults outstanding at time of report

dec(4,1)

5

Average number of working days taken to resolve faults

dec(4,1)

Backus-Naur Form:

CVA MOA Fault Resolution ::= ZHD {SB2 {CM2}} ZPT

5.5 Not Used

5.6 Not Used

5.7 Not Used

5.8 Not Used

5.9 Not Used

5.10 Not Used

5.11 Not Used

5.12 SP07 – SMRA & SVAA MSID Count – SMRA File

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0045002

3

From Role Code

text(1)

= P (SMRA)

4

From Participant Id

text(4)

ID of originating SMRA

5

To Role Code

text(1)

= Z (Non-Core -PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= B (indicates HH and NHH data)

3

Market Participant Role Code

text(1)

= X (Supplier)

4

Market Participant Id

text(4)

ID of Supplier

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

SP7 Supplier Serial 7 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SP7

2

GSP Group Id

text(2)

3

Market Participant ID

text(4)

ID of Data Aggregator

4

Market Participant Role Code

text(1)

A (Half Hourly Data Aggregator) or

B (non-Half Hourly Data Aggregator)

5

Date

date(8)

yyyymmdd

6

Energised MSID Count

int (10)

7

De-energised MSID Count

int(10)

Backus-Naur Form:

SMRA/SVAA MSID Count– SMRA File::= ZHD {SUB {SP7}} ZPT

5.13 SP07 – SMRA & SVAA MSID Count – SVAA File

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0164001

3

From Role Code

text(1)

= G (SVAA)

4

From Participant Id

text(4)

= CAPG

5

To Role Code

text(1)

= Z (Non-Core -PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= B (indicates HH and NHH data)

3

Market Participant Role Code

text(1)

= X (Supplier)

4

Market Participant Id

text(4)

ID of Supplier

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

SP7 Supplier Serial 7 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SP7

2

GSP Group Id

text(2)

3

Market Participant ID

text(4)

ID of Data Aggregator

4

Market Participant Role Code

text(1)

A (Half Hourly Data Aggregator) or

B (non-Half Hourly Data Aggregator)

5

Settlement Date

date(8)

yyyymmdd

6

Settlement Type

text(2)

7

MSID Count

int(10)

Backus-Naur Form:

SMRA/SVAA MSID Count– SVAA File::= ZHD {SUB {SP7}} ZPT

5.14 SP08 – Energy and MSIDs on Actuals

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0145002

3

From Role Code

text(1)

= G (SVAA)

4

From Participant Id

text(4)

= CAPG

5

To Role Code

text(1)

= Z (Non-Core - PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= B (indicates HH and NHH data)

3

Market Participant Role Code

text(1)

= X (Supplier)

4

Market Participant Id

text(4)

ID of Supplier

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

SP8 Supplier Serial 8 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SP8

2

Settlement Day

date

3

Settlement Type

text(2)

SF, R1, R2, R3 and RF run types

4

GSP Group Id

text(2)

5

% NHH Energy Aggregated on Actuals

dec(4,1)

The type ‘dec 4,1’ allows for percentage values up to, and including, 999.9% in this data field

6

% NHH MSIDs Aggregated on Actuals

dec(4,1)

7

Total Actual NHH Energy

dec(10,2)

8

Total NHH Energy

dec(10,2)

9

% non-100kW HH Energy Aggregated on Actuals

dec(4,1)

The type ‘dec 4,1’ allows for percentage values up to, and including, 999.9% in this data field

10

% non-100kW HH MSIDs Aggregated on Actuals

dec(4,1)

11

Total Actual non-100kW HH Energy

dec(10,2)

12

Total non-100kW HH Energy

dec(10,2)

13

% 100kW HH Energy Aggregated on Actuals

dec(4,1)

The type ‘dec 4,1’ allows for percentage values up to, and including, 999.9% in this data field

14

% 100kW HH MSIDs Aggregated on Actuals

dec(4,1)

15

Total Actual 100kW HH Energy

dec(10,2)

16

Total 100kW HH Energy

dec(10,2)

Backus-Naur Form:

Energy and MSIDs on Actuals::= ZHD {SUB {SP8}} ZPT

5.15 SP09 – NHH Defaults

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

= P0146001

3

From Role Code

text(1)

= G (SVAA)

4

From Participant Id

text(4)

= CAPG

5

To Role Code

text(1)

= Z (Non-Core -PARMS)

6

To Participant Id

text(4)

= POOL

7

Creation Time

date/time

Date & time of file generation

SUB - Subject Participant Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SUB

2

Market Sector

text(1)

= N (indicates NHH data)

3

Market Participant Role Code

text(1)

= X (Supplier)

4

Market Participant Id

text(4)

ID of Supplier

5

Period End Date

date

Date of last day of calendar month

6

Periodicity

text(1)

‘M’onthly

SP9 Supplier Serial 9 Data

Field

Field Name

Type

Comments

1

Record Type

text(3)

= SP9

2

Settlement Day

date

3

Settlement Type

text(2)

SF, R1, R2, R3 and RF run types

4

GSP Group Id

text(2)

5

% NHH MSIDs Settled using Default EACs

dec(4,1)

6

Number of NHH MSIDs Settled using Default EACs

int(7)

Backus-Naur Form:

NHH Defaults ::= ZHD {SUB {SP9}} ZPT

5.16 Not Used

5.17 Not Used

5.18 HM13 – Quality of HH MTDs

5.19 Not Used

5.20 Not Used

5.21 Not Used

5.22 Not Used

Appendix 1: Algorithm For Checksum Required For BSCCo Defined Software

Introduction

In order to meet the Auditor requirements for a method of ensuring file integrity, a checksum algorithm was agreed that provides a signature for files coming into, and out from, the three Business Process Operations (BPO) Service developed systems.

The purpose of the algorithm is to provide a reasonable degree of assurance that the binary nature of the file has not changed. It does not provide any assurance as to the accuracy of the data within the file.

Requirement

The checksum algorithm is defined as follows:

Wj,k is the kth 4-byte word of the Jth record.

Therefore the function can be defined as:

(((W1,1 XOR W1,2 ) XORW1,3.).. XORW1+n,m)

n = the total number of records (less the footer record)

m = the number of 4 byte words in the last record

Key points to note are that the algorithm:

    • excludes line terminators

    • excludes the last record

    • where the last word of a record is less than 4 bytes then it is padded with binary zeroes.

Pseudo-Code

The detail of the algorithm is as follows (note that this assumes that each record is submitted one by one):

This takes four byte sections (excluding the end of line character), padded with nulls if required, and exclusive OR (XOR) them into checksum. The algorithm for this is illustrated by the following ‘C-like’ pseudo code.

num_chars = strlen (context.record buffer)

FOR (i = 0; i < num_chars;)

value = 0

FOR (j = 0; j < 4; i++, j++)

IF i < num_chars

value = ((value << 8 ) + context.record_buffer[i])

ELSE

value = value << 8

END IF

ENDFOR

context.checksum = context.checksum XOR value

ENDFOR

Example Algorithm

This algorithm has been produced by the BSCCo in Visual Basic. This routine has been used in the generation of test data and the output of the routine has been checked against BPO Service data.

Public Function Calc(sFile As String) As Long

'Algorithm to Calculate Checksum from G. Swinton, 23/04/97.

On Error GoTo c1_Error

Dim i As Integer

Dim j As Integer

Dim chksum As Long

Dim bytes(4) As Integer

Dim sLine As String

' validate that the file exists

Open sFile For Input As #1

Do While Not EOF(1)

Line Input #1, sLine

i = 1

If Left$(sLine, 3) <> "ZPT" Then

For j = 1 To Len(sLine)

bytes(i) = bytes(i) Xor Asc(Mid$(sLine, j, 1))

i = i + 1

If i = 5 Then i = 1

Next

End If

Loop

For j = 1 To 4

chksum = chksum + (256 ^ (4 - j) * bytes(j))

Next

Calc = chksum

c1_Exit:

Close #1

Exit Function

c1_Error:

MsgBox Error$()

Calc = -1

Resume c1_Exit

End Function

1 Please note: CP1334, CP1344 and CP1348 were implemented as part of the June 2011 Release, effective from 01 July 2011