SVA Data Catalogue Introduction Volume 1

v 60.0
Download

complex image of process

SVA Data Catalogue Volume 1

Abstract

This document defines the data interfaces required by Supplier Volume Allocation under the BSC.

All of the interfaces are cross-referenced to the relevant Programme documents (Technical Specifications, BSC Procedures, Service Lines and BSC Service Lines) where the data flow and its usage were originally defined.

Document Reference

Data Interfaces Used in the SVA Trading Arrangements

Version

60.0

Effective Date

02/11/2023

Reason for Issue

P395

Author

Elexon

0 DOCUMENT CONTROL

i Authorities

Name

Role & Review Responsibilities

Signed and Dated

Author(s)

Elexon Release Team

04/10/22

Reviewer(s)

Stephen Francis

Architecture

Authoriser(s)

SVG

ii Distribution List

Name

Organisation

BSC Parties

APPENDIX A: DATA INTERFACE INDEX

APPENDIX B: DATA INTERFACE DEFINITION

iv Change History

Issue 1.0 First formal issue for NETA. This document is the ELEXON Data Interfaces document v5.0 plus all changes delivered by the Implementation of NETA within Stage 2 Project and has been re-badged for NETA.

Issue 1.1 Incorporating changes required for NCR114 – Transfer of Metering Systems Between SMRS and CMRS.

Issue 2.0 For approval by the Panel on 22 February 2001 (Panel paper 13/016).

Issue 2.1 Changes as required for SIRs R1964, R2092, R2180, R2296, R2668, R2896, R2907, R2928, R3010 and R3011. Issued for combined peer and formal review.

Issue 3.0 Approved by the Panel (P/15/013).

Issue 3.2 Changes required for CP704, and internal database restructure.

Issue 3.3 Changes required for CP690, UMS (Unmetered Supplier) Clarifications and Improvements.

Issue 4.0 Changes required for Modification P30, availability of market information to BSC and non-BSC parties.

Issue 4.1 Changes required for Modification P68 and CP760.

Issue 5.0 Approved by SVG (SVG/21/259 and SVG/16/190).

Issue 5.1 Changes for CP518, CP696, CP698, CP774, CP792, CP799, CP805 and CP914.

Issue 6.0 Approved by SVG (SVG/22/275).

Issue 7.0 Changes required for Modification P91 ‘Extension to Data Provided to the Transmission Company in the TUoS Report’. Approved by SVG (SVG/24/319).

Issue 8.0 Changes required for Modification P88 ‘Introduction of obligations in relation to SVA Metering, Meter Operator Agents and Equipment Owners’, CP861 and CP899. Approved by SVG (SVG/27/364), (SVG/25/345) and (SVG/25/342).

Issue 9.0 Changes required for CP551 ‘Enduring Process to replace W006 – P0181 flow to SVAA’. Approved by SVG (SVG/29/387).

Issue 10.0 Changes required for Modification P62 ‘Changes to Facilitate Competitive Supply on the Networks of New Licensed Distributors’. Approved by SVG (SVG/29/390).

Issue 11.0 Changes required for the SVA August 03 Release. Approved by SVG (SVG/29/389, SVG/30/397).

Issue 12.0 Changes required for Modification P81 ‘Removal of the Requirement for Half Hourly Metering on Third Party Generators at Domestic Premises’. Approved by SVG (SVG/31/414).

Issue 13.0 Changes required for Modification P116 ‘Changes to Allow Line Loss Factor Data from BSC Website to be Used in Settlement’. Approved by SVG (SVG/33/447)

Issue 14.0 Changes required for CP904, CP941, CP969, CP1003 and CP1004. Approved SVG (SVG/36/487).

Issue 15.0 Changes required for Modification P99 ‘Changes to Accreditation, Entry Processes and the PARMS Serials and Standards resulting from the Performance Assurance Framework (PAF) Review (Phase 1)’. Approved by SVG (SVG/38/477).

Issue 16.0 Changes required for CP820 ‘Enhancements to a number of Unmetered Supplies Processes’. Approved by SVG (SVG/40/005).

Issue 17.0 Changes required for CP892 and CP947. Approved by SVG (SVG/43/003).

Issue 18.0 Changes required for CP844 and CP942 for the SVA Feb 05 Release. Approved by SVG (SVG/47/004)

Issue 19.0 Changes required for BETTA 6.3. Approved by SVG (SVG/48/004)

Issue 20.0 Changes required for CP1057, CP1079, CP1080, CP1082 for the SVA June 05 Release. Approved by SVG (SVG/51/004)

Issue 21.0 Changes required for CP1036, CP1098, and CP1105 for the SVA November 05 Release. Approved by SVG (SVG/56/004)

Issue 22.0 Changes required for CP1093, CP1102, and CP1127 for the Feb 06 Release.

Approved by SVG (SVG/60/004)

Issue 23.0 Changes required for CP1144 for the June 06 Release.

Approved by SVG (SVG/64/02)

Issue 24.0 Changes required for P196, CP1155, CP1159 for the February 07 Release

Approved by SVG (SVG/70/01)

Issue 25.0 Changes required for CP1173 and CP1181 for the June 2007 Release.

Approved by SVG (SVG/75/02)

Issue 26.0 Changes required for P197 for the Release on 23rd August 2007.

Approved by SVG (SVG/76/02)

Issue 27.0 Changes required for CP1200 and CP1210 for the November 2007 Release.

Approved by SVG (SVG/77/04 and SVG/79/02)

Issue 28.0 Changes required for CP1208, CP1209 and CP1223 for the June 2008 Release.

Approved by SVG (SVG82/03 and SVG84/02)

Issue 29.0 Changes required for CP1234 for the November 2008 Release.

Approved by SVG (SVG87/02)

Issue 30.0 Changes required for CP1249, CP1259 and P222 for the June 2009 Release.

Approved by SVG (SVG94/02, SVG93/02 and SVG97/05)

Issue 31.0 Changes required for CP1269 for the November 2009 Release

Approved by SVG (SVG97/01)

Issue 32.0 Changes required for CP1295 for the February 2010 Release

Approved by SVG (SVG102/01)

Issue 33.0 Changes required for CP1309 for the June 2010 Release

Approved by SVG (SVG105/02)

Issue 34.0 Changes required for CP1334 for the June 2011 Release

Approved by SVG (SVG114/02)

Issue 35.0 Changes required for CP1325, CP1334, CP1335 for the November 2011 Release

Approved by SVG (SVG127/13)

Issue 36.0 Changes required for CP1347 for the February 2012 Release

Approved by SVG (SVG130/01)

Issue 37.0 Changes required for ORD005: Electricity Market Reform (EMR), Effective from 1 August 2014 as Directed by the Secretary of State

Issue 38.0 Changes required for CP1405 for the November 2014 Release

Issue 39.0 Changes required for CP1395 for the February 2015 Release

Issue 40.0 Changes required for P300, P305 and CP1432 for the November 2015 Release

Issue 41.0 Changes required for CP1449 for the February 2016 Release

Issue 42.0 Changes required for P315 for the June 2016 Release

Issue 43.0 Additional changes required for P315 for the June 2016 Release

Issue 44.0 Changes required for P339 for the April 2017 Release and minor corrections for P300

Issue 45.0 Changes required for CP1469 for the June 2017 Release

Issue 46.0 Changes required for CP1484 for the November 2017 Release

Issue 47.0 Changes required for P348/349 for the February 2018 Release

Issue 48.0 Changes required for CP1495, CP1496 and CP1497 for November 2018 Release

Issue 49.0 Changes required for the P344 for February 2019 Release

Issue 50.0 Changes required for P369 for the March 2019 Release

Issue 51.0 Changes required for P367 for the June 2019 Release

Issue 52.0 Changes required for CP1517 for the 11 December 2019 Release

Issue 53.0 Changes required for P354 for the 1 April 2020 Release

Issue 54.0 Changes required for P383 for the 1 April 2021 Release

Issue 55.0 Changes required for P420 for the 1 September 2021 Non-Standard Release

Issue 56.0 Changes required for P402, P429 for the 24 February 2022 Standard Release

Issue 57.0 Changes required for P375, CP1561 for the 30 June 2022 Standard Release

Issue 58.0 Changes required for P436 for the 18 July Special 2022 Release

Issue 59.0 Changes required for P376, P419 for the February 2023 Standard Release

Issue 60.0 Changes required for P395 for the November 2023 Standard Release

v Changes Forecast

Future versions of this document will be issued in response to changes raised through the change control procedures.

vi Related Documents

Reference 1 SVA Data Catalogue Volume 2: Data Items

Reference 2 CVA Data Catalogue

Reference 3 BSC Reporting Catalogue

Reference 4 BSC Communication Requirements Document

Reference 5 Energy Market Data Specification

Reference 6 NHH Instruction Processing Specification

Reference 7 HH Instruction Processing Specification

Reference 8 Multiple BM Unit Instruction Processing Specification;

vii Intellectual Property Rights and Copyright

This document contains materials the copyright and other intellectual property rights in which are vested in Elexon Limited or which appear with the consent of the copyright owner. These materials are made available for you to review and to copy for the purposes of your establishment or operation of or participation in electricity trading arrangements under the Balancing and Settlement Code ("BSC"). All other commercial use is prohibited. Unless you are a person having such an interest in electricity trading under the BSC you are not permitted to view, download, modify, copy, distribute, transmit, store, reproduce or otherwise use, publish, licence, transfer, sell or create derivative works (in whatever format) from this document or any information obtained from this document otherwise than for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the original material must be retained on any copy that you make. All other rights of the copyright owner not expressly dealt with above are reserved.

Disclaimer - No representation, warranty or guarantee is made that the information provided is accurate, current or complete. Whilst care is taken in the collection and provision of this information, Elexon Limited will not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or any decision made or action taken in reliance on this information.

1 Introduction

Purpose

This document defines the interfaces required by the Elexon-delivered or certified applications and BSC Procedures, for communications between SVA data parties. It forms part of the "SVA Data Catalogue” as defined in Section O of the BSC.

All of the interfaces are cross-referenced to the relevant Programme documents (Technical Specifications, BSC Procedures and Service Lines) where the data flow and its usage were originally defined.

This is one of a set of five closely related Code Subsidiary Documents, the others being:

    • SVA Data Catalogue Volume 2 (reference 1). Defines the data items included within the Data Interfaces specified in this document;

    • CVA Data Catalogue (reference 2). Defines the data interfaces between BSC Agents and BSC Parties and Party Agents for all communications, other than SVA Communications, as set out in the BSC Section O;

    • The BSC Reporting Catalogue (reference 3). Catalogues and provides further information on the contents of reports issued by the BSC Agents as defined in Section X Annex X-1 of the BSC;

    • The BSC Communication Requirements Document (reference 4). Contains detailed requirements for sending and receiving communications between Parties and BSC Agents using one or more Communications Media.

This document is also closely related to the Energy Market Data Specification (reference 5), which details the definitions of all data flows and data items used over the Data Transfer Network.

      1. Objective

It is the objective of this Data Interface definition to achieve benefits of efficiency and quality for users and application systems within Supplier Volume Allocation under the BSC. This requires that:

    • data interface definitions are definitive, common, complete and consistent within the constraints of current scope;

    • the Data Interface definition is available electronically to all users and is centrally managed.

      1. Summary

Following this introductory section, section 2 of this document describes the conventions used in defining the physical files used to implement the SVA data interface requirements. Then section 3 provides a summary of instruction processing logic. The data interfaces within the scope of the document (see section 1.4) are then specified within the document appendices:

    • Appendix A provides an index of data interfaces in ascending sequence of flow reference, along with the flow name, ‘from’ and ‘to’ participant, and source document.

    • Appendix B provides a full definition of data interfaces identified in Appendix A in ascending alphabetic sequence of data flow name.

      1. Scope

The scope of the interfaces defined in this document are those enabling the flow of data required for Supplier Volume Allocation as defined in paragraph 1.4 of Section O of the Balancing and Settlement Code.

It does not cover those interfaces:

    • with external entities in the form of hard copy reports;

    • which are manual inputs to systems - these (user interfaces) are specified in the relevant system specifications; or

    • consisting of data items not required under the BSC.

Where a data interface is used by Settlement but defined within the Energy Market Data Specification (EMDS), this document will note the interface in Appendix A but will refer to the EMDS for the full details of the definition.

      1. Responsibilities

It is the responsibility of all SVA data parties to adopt the Data Interfaces. This will require the following:

    • incorporating the Data Interfaces within their own area of responsibility. For example, this may occur during initial compliance or following authorised updates to the Data Interfaces;

    • raising change requests to update the Data Interfaces. For example, changes to existing definitions or the addition of new data items as identified in their own area of responsibility.

It is the responsibility of the Data Interfaces owner to manage the Data Interfaces. This includes the following activities, which may be delegated:

    • provide SVA data parties with shared access;

    • make updates authorised by the change control procedure;

    • fulfil the role of a Data Manager with responsibility for monitoring the use of standards, arbitration, general housekeeping, etc.

The current owner of the Data Interfaces is the Elexon Design Authority.

2 Approach Used in Data Interface Definition

Introduction

Interface Definitions contained within this document are presented at Appendix B. This is preceded by general index of all interfaces required by Settlement, listed by Flow Number, Flow Name, From, To and Source Document, at Appendix A.

Each interface derives from a required flow of data specified in one or more of the BSC Procedures and/or one or more of the Technical Specifications for the Elexon-developed applications. Interfaces are physically implemented as structured files comprising a number of records, each of which comprise one or more fields. The non-physical definition of the interface is termed a data flow. Data flows are comprised of data groups that are, themselves, comprised of data items.

      1. Interface Definition

Each data flow in the catalogue is given a unique data flow name and a unique data flow reference. Data flow references are of the form Paaaa or Dnnnn1.

Each data flow is further defined as having

    • a version number2,

    • details of the documents providing the source of the interface definition,

    • data flow initiators and recipients,

    • details of data requirements from BSCPs,

    • a physical file specification

The following sections explain how to use and interpret the definitions.

      1. Sources of Interface Definitions

The interface definitions are derived from BSC Procedures and the Technical Specifications for the Elexon-developed applications. Each definition lists the relevant source documents together with each source’s internal reference(s) for the interface and any variation in the name by which a data flow is known within that source document.

      1. Data Flow Initiators and Recipients

Each interface definition includes the party initiating (from) and receiving (to) the communication for each occurrence of that interface specified in the source documents.

      1. BSC Procedures Data Requirement

This section documents the required content of the data flow as defined in one or more of the BSC Procedures used in operating the Supplier Volume Allocation aspects of the BSC.

Where the BSC Procedures specify the structure of a data flow this is documented in terms of:

    • the data groups which it comprises;

    • the data item name - the data items contained in each data group;

    • comments relating to the data items.

Where no structure is specified this is noted and a simple list of the data items is given. The data items named are defined in Volume 2 - Data Items (reference 1).

Note that, although it may not always be documented in the BSC procedures, each data flow includes:

    • who initiated the data flow;

    • who was the intended recipient;

    • the time and date the data flow was produced, and/or, the period over which the data is applicable.

Participants are required to populate ALL data items and groups where the data is available and the business reason for sending the flow indicates that the data is relevant to the recipient if it is provided.

      1. Physical File Specification

This section is included when the data flow is included in a Technical Specification. It documents the actual content and structure of the data flow as defined in one or more of the Technical Specifications for the Elexon-developed applications. It consists of:

    • Record: The identifier and description of a data group where the Technical Specification specifies a data structure (this is generally the case);

    • Field Name: The name of a data item as specified within the Technical Specification;

    • Comment: Clarification of the use and/ or content of the Field Name;

    • Value: Included where the field content is restricted to a specific value or two or more specific alternative values;

    • Optionality Indicator: This column is denoted with a ‘Yes’ where the field is optional within the Group.

2.6.1 General File Principles

All interface files utilise a common structure. These files comprise a number of records, each starting with a three character identifier3 (identifying the record type) and terminating with a line feed character.

The first record of the file will be a header and the last record a footer (each having a specific record type).

The fields contained in each record will depend on the record type, but each record of the same type (in a given file type) will always contain the same set of fields. Each field (including record type) is separated from the next by a separator character.

If a field is optional and not present then no character will be included between the separators or, in the case of the last field, between the last separator and line feed character.

Refer to sections 2.6.2 and 2.6.3 below for a description of the Field Types and File Structures used, and 0 for a definition of the additional data contained within Instruction Files.

2.6.2 Field Types

All fields that make up the records are written as ASCII data (see 2.6.5 for the defined character set). To determine the format of each field, refer to the logical format attribute of the associated data item in the Data Catalogue Volume 2 (reference 1) and the table below.

Logical Format

Data Type

Format

Example

INT

Integer

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

-1234 12

NUM

Decimal

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

-12.34 1.20

CHAR

Text

Left aligned with trailing spaces stripped. Only includes printable characters excluding the separator

The quick fox

DATE

Date

ASCII format as: YYYYMMDD

19961216

TIME

Time

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

131501

DATETIME

Date/Time

ASCII format as: YYYYMMDDHHMMSS

19961216131501

BOOLEAN

Boolean

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

T F

TIMESTAMP

Timestamp

BITS

2.6.3 File Structure

All files sent or received by Elexon-developed systems are structured files. This structure is as follows:

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

    • Body - other file records

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

Furthermore, the first record of the file “Body” contains header information dependent on whether the file is a data file or an instruction file. The record types for these records are “ZPD” and “ZPI” respectively. Note that the ZPD record is present for all data flows to and from the EAC/AA system regardless of whether they contain data or not. For data flows to and from SVAA and NHHDA the ZPD record is only present when there is actual data present within the record. The market domain data files will always contain a ZPD record.

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

File Header Record: Standard Pool Format

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Type

text(8)

5 character flow reference plus 3 character version number

3

From Role Code

text(1)

4

From Participant Id

text(4)

5

To Role Code

text(1)

6

To Participant Id

text(4)

Null if broadcast

7

Creation Time

date/time

Time file processing was started. Specified in GMT.

File Header Record: Pool Transfer Format

ZHD - File Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZHD

2

File Identifier

Text(10)

File identifier - unique within Market Participant

3

File Type

text(8)

5 character type (ranges allocated for DTS, pool or internal use) plus 3 character version

4

From Role Code

text(1)

5

From Participant Id

text(4)

6

To Role Code

text(1)

7

To Participant Id

text(4)

Null if broadcast

8

Creation Time

date/time

Time file processing was started. Specified in GMT.

9

Sending Application Id

Text (5)

Application identifier. For possible future use

10

Receiving Application Id

Text (5)

Application identifier. For possible future use

11

Broadcast

Text (1)

For possible future use.

12

Test data flag

Text (4)

Indicates that this file contains test data.

The additional data in the “Pool Transfer Format” Header Record is as follows:-

Field 2: File Identifier. A 10 character identifier unique within each Gateway. This identifier will be incremented for each physical file presented to the Gateway and will continuously clock-up over time. It will be used by the sender for tracking purposes across the network.

Field 9: Sending Application Id. Used to indicate the sending application system. This field is included for possible future use and (for market start-up) will initially be null.

Field 10: Receiving Application Id. Used to indicate the target application system. This field is included for possible future use and (for market start-up) will initially be null.

Field 11: Broadcast. Reserved for possible future use. Initially (for market start-up), will be null

Field 12: Test Data Flag. A text field containing the following valid set:

OPER indicates operational data

TR01 indicates Trialling scenario 1

TR02 indicates Trialling scenario 2

TR03 indicates Trialling scenario 3

TR04 indicates Trialling scenario 4

TR05 indicates Trialling scenario 5

TR06 indicates Trialling scenario 6

TE01 indicates Test 1 data

TE02 indicates Test 2 data

TE03 indicates Test 3 data

A null entry prior to live operations should be treated as TR01 (null entry means that there is no data in a field between 2 delimiters);

After the start of live operations then a null or incorrect entry will cause the message to be rejected.

For incoming flows, the flag will be used to assist in the correct routing of information to particular systems.

For outbound flows, the value should be set by the system administrator, which indicates the status of the file or message.

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.

ZPD - Data File Additional Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZPD

2

Settlement Date

date

Optional

3

Settlement Code

text(2)

Optional

4

Run Type Code

text(2)

Optional

5

Run Number

integer(7)

Optional

6

GSP Group

text(2)

Optional

ZPI - Instruction File Additional Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZPI

2

File Sequence Number

integer(6)

2.6.4 Instruction files

As well as the header and footer records described in the previous section, instruction files contain a number of records for each instruction. The first record for each instruction has a record type of ‘ZIN’. This record has the following components:

ZIN - Instruction Header

Field

Field Name

Type

Comments

1

Record Type

text(3)

= ZIN

2

Instruction Number

integer(12)

3

Type Code

text(4)

4

Metering System Id

integer(13)

Optional

5

Market Role

text(1)

Optional

6

Participant Id

text(4)

Optional

2.6.5 Character set

The character set used is based on the ISO Level B character set and includes 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 _

Separator: The vertical bar character ‘|’ is used as the separator.

Delimiter: The Carriage Return is used as the delimiter.

2.6.6 Backus-Naur Form (BNF)

This documents the physical structure of the records within the data flow. This section is included when the data flow is included in a Technical Specification or when its physical structure has otherwise been defined. The record structure is expressed in Backus-Naur form (BNF).

The BNF used is a modified form of the standard BNF. A flow structure is defined as follows:

Data Flow Name::= Flow Structure

The flow structure is further defined using a notation to show single occurrences, iteration, optionality and selection of data groups within the structure:

    • An obligatory, single occurrence of a data group is shown by naming the group. This implies that there is always just one occurrence of the data group

    • Iteration is shown by enclosing the iterated structure in braces {}, which implies that the data group can occur 0, 1 or many times.

    • Optionality is shown by enclosing the optional structure in square brackets []. This implies that a occurrence of the data group may or may not occur.

    • Selection is shown by enclosing the set of alternative structures in parenthesis () and separating each alternative with a vertical line |. This implies that one, and only one, of the alternatives will occur.

In order to improve the readability of the BNF definitions the Flow Structure is occasionally further broken out into substructures. These substructures follow the same notation as described above. As a rule of thumb, substructures are used where the level of iterative nesting exceeds two layers, for example:

Data Flow Name::= { ABC { DEF { GHJ } } }

may be shown as:

Data Flow Name::= { ABC { DEF_set } }

DEF_set ::= DEF { GHJ }

NaN INSTRUCTION PROCESSING SPECIFICATION

NHH Instruction Processing

The full details of the specification of non half hourly instruction processing is found at reference 6.The following text and associated diagram give an overview of non half hourly instruction processing.

0.1 Instruction File Processing

Figure 1 NHH Instruction Processing shows the interactions between the NHHDA and SMRS or the NHHDC for the sequence that is followed when the NHHDA processes instruction files, and the instructions contained in them, received from either source.

The NHHDA shall determine the cause of file failures in conjunction with the source. Failures due to the NHHDA shall be resolved by the NHHDA. Where the instruction file validation failure is due to transmission, the NHHDA shall request a resend. Where it is due to the source, the NHHDA shall request a refresh file.

0.2 Reporting of Failed Instructions

Where one or more instructions have failed, the NHHDA shall compile and send a file of the failed instructions with reasons for failure to the source and request a refresh.

0.3 Problem Log

The NHHDA shall set up, utilise and maintain a problem log for the management of failed and discarded instructions. The log shall hold the information about the latest instructions that are in a failed or discarded state.

The NHHDA shall record in the problem log the reasons for failure of failed instructions, the date and time of the latest processing attempt, mark the instructions to be resolved by the NHHDA and those that have been resolved by the NHHDA. The NHHDA shall, for each resolved instruction failure, record the corrective action taken in the problem log.

Figure 1 NHH Instruction Processing

      1. HH Instruction Processing

The full details of the specification of half hourly instruction processing is found at reference 7.

      1. Multiple BM Unit Instruction Processing

The full details of the specification of Multiple BM Unit instruction processing is found at reference 8.

1Where aaaa represents any four printable characters but is generally of the form nnnn, and where nnnn represents any four integers. The code is prefixed by a “D” when the data flow is included in the Energy Market Data Specification (EDMS, reference 5) or “P” when it is a Pool owned flow not in the DTC and so defined in the SVA Data Catalogue.

2 Flow version numbers are of the form 001, 002, 003 etc.

3 the general case is three characters, although there is at least one case where the record type is only two characters.