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:

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

Therefore the function can be defined as:

(((W_1,1 XOR W_1,2 ) XORW_1,3.).. XORW_1+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

End If

Loop

For j = 1 To 4

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

Calc = chksum

c1_Exit:

Close #1

Exit Function

c1_Error:

MsgBox Error$()

Calc = -1

Resume c1_Exit

End Function

AMENDMENT RECORD – BSCP533 APPENDIX A

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	CP1334¹	SVG114/02
			CP1344¹	SVG122/02
			CP1348¹	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

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 Please note: CP1334, CP1344 and CP1348 were implemented as part of the June 2011 Release, effective from 01 July 2011

CONTENTS

BSCP533 Appendix A PARMS Data Provider File Formats Appx A

1. INTRODUCTION

1.1 Purpose

1.2 PARMS Data

1.2.1 PARMS Data: General Description

2. PHYSICAL FILE PRESENTATION

2.1 Media

2.2 File Naming

2.3 File Submission and Verification of Output Data

2.4 File Resubmission and Correction

3. PHYSICAL FILE FORMATS

3.1 Pool File Format

4. STANDING DATA FILE FORMATS

4.1 Not Used

4.2 PARMS Market Domain Data

4.3 Suppliers Trading / Ceased Trading in GSP Groups

5. OUTPUT DATA FILE FORMATS

5.1 TA01 – GSP Group Correction Factor

5.2 TA02 – Annual Demand Ratio

5.3 CM01 – CVA MOA Proving Tests

5.4 CM02 – CVA MOA Fault Resolution

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

5.13 SP07 – SMRA & SVAA MSID Count – SVAA File

5.14 SP08 – Energy and MSIDs on Actuals

5.15 SP09 – NHH Defaults

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

AMENDMENT RECORD – BSCP533 APPENDIX A