Multiple BM Unit Instruction Processing Specification

v 2.0
Effective From Date:
Status:SUPERSEDED
Other versions
Download

Balancing and Settlement Code

Multiple BM Unit

Instruction Processing Specification

Version 2.0

Effective Date: 8 August 2008

Intellectual Property Rights, Copyright and Disclaimer

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

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

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

1 INTRODUCTION

This document describes the requirements for validation and processing of Notification of BM Unit Allocation (D0297) data flows sent from Suppliers to HHDA, and is structured as follows:

    • Section 2 describes the requirements for validation by HHDA of the D0297 data flows and the instructions they contain.

    • Section 3 describes the requirements for processing by HHDA of validated instructions.

    • Section 4 identifies the implications of the rules described in sections 2 and 3 for Suppliers collating instructions, and provides a hypothetical example of a complex instruction processing scenario.

    • Appendix A describes the formats of the data flows required as a result of this document.

2 INSTRUCTION VALIDATION

The HHDA will validate HH BM Unit Allocation (D0297) data flows in accordance with the following rules:

    • If the File Sequence Number is as expected (i.e. one greater than that of the last HH BM Unit Allocation file received from that Supplier, excluding any that themselves had invalid File Sequence Numbers), then the individual instructions in the file will be processed as described below.

    • If the File Sequence is higher than expected, indicating one or more missing files, the HHDA will notify the Supplier, and retain the file for processing once the missing file(s) have arrived.

    • If the File Sequence Number is lower than expected, the file is invalid, and the instructions it contains are not processed. The HHDA will send a Rejection of BM Unit Allocation (D0295) data flow to the Supplier, with a BM Unit Allocation Rejection Reason Code of 01, and null values for the Incoming Instruction Number, MPAN Core, BM Unit Id and Effective From Settlement Date.

Assuming the File Sequence Number is correct, each instruction the file contains will be validated in accordance with the following rules. If any validation check fails, the instruction is invalid, and will not be processed any further. In this case the HHDA will send a Rejection of BM Unit Allocation (D0295) data flow to the Supplier, with the Incoming Instruction Number, MPAN Core, BM Unit Id and Effective From Settlement Date set to the values on the incoming instruction:

    • If the Instruction Number is not one greater than that of the last instruction received from that Supplier (excluding any that themselves had invalid Instruction Numbers, but including any invalid for any other reason), the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 02.

    • If the MPAN core is not valid (i.e. not a thirteen‑digit number with a valid checksum digit, or MPAN missing), the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 04.

    • If the Supplier sending the file is not registered to the MPAN on the Effective From Settlement Date {MSBMU} (according to the D0209 instructions received by the HHDA from PRS), the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 03.

    • If the HHDA is not appointed to the MPAN on the Effective From Settlement Date {MSBMU} (according to the D0209 instructions received by the HHDA from PRS), the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 05.

    • If the file reached the HHDA’s gateway after Gate Closure for the Effective From Settlement Date {MSBMU}, the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 06.

    • If the combination of Supplier, GSP Group and BM Unit is not valid (according to the currently effective MDD), the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 07. See section 2.1 below for further details of this validation.

    • If the HHDA database indicates that the metering system is already allocated to the BM Unit specified in the instruction on the Effective From Settlement Date {MSBMU}, the instruction will be rejected with a BM Unit Allocation Rejection Reason Code of 08.

Suppliers should be aware that there are two possible interpretations of the last of these validation checks, each of which has been implemented by at least one HHDA. This ambiguity relates to the processing of an instruction that is explicitly allocating the metering system to the Base BM Unit, but where the metering system is already implicitly allocated to the Base BM Unit (because no BM Unit allocation is defined on the database). The two possible interpretations are as follows:

    • Because the metering system is not already explicitly allocated to the same BM Unit, the instruction should be accepted.

    • Because the metering system is already allocated to the same BM Unit (albeit implicitly), the instruction should be rejected with a BM Unit Allocation Rejection Reason Code of 08.

Either interpretation is acceptable. Suppliers will need to be aware when constructing instructions of which interpretation their Half Hourly Data Aggregator(s) have implemented.

Summary of Error Codes

Error Code

Meaning

1

File Sequence Number error

2

Instruction Sequence Number Error

3

Supplier Not Registered to MPAN on the Effective Settlement Date

4

Invalid MPAN Core

5

HHDA is Not Appointed to MPAN on the Effective Settlement Date

6

Instruction Received After Gate Closure

7

Invalid Supplier, GSP Group and BM Unit Combination

8

Metering System is Already Assigned Specified BM Unit

2.1 Validation of Instructions Against MDD

The rule for validating the Supplier / GSP Group / BM Unit combination is that the currently effective MDD must contain an instance of the BM Unit for Supplier in GSP Group entity that is valid on the Effective From Settlement Date {MSBMU}, and has the following attributes:

    • GSP Group Id equal to the GSP Group to which the metering system is assigned on the Effective From Settlement Date {MSBMU} (according to the D0209 data received from PRS).

    • Supplier Id equal to the Supplier to which the metering system is registered on the Effective From Settlement Date {MSBMU} (according to the D0209 data received from PRS).

    • BM Unit Id as specified in the incoming instruction.

This validation ensures that the first Settlement Day of the BM Unit allocation is consistent with MDD, but will not detect cases where a subsequent part of the allocation period is inconsistent with MDD. This situation could arise if the BM Unit for Supplier in GSP Group occurrence in MDD ends while the allocation is still effective, or if the metering system changes GSP Group within the period of the BM Unit allocation. In this case, SVAA will allocate the metering system to the Base BM Unit on the affected Settlement Dates.

The relevant MDD information is contained in the Stage 2 BM Unit Registration Data File (D0299) data flow. This is published and distributed by the MDDA.

3 INSTRUCTION PROCESSING

Once an instruction has been successfully validated, the HHDA will take the following steps:

    • Delete all BM Unit allocations for that metering system with an Effective From Settlement Date {MSBMU} equal to or after that specified in the instruction.

    • Create a new BM Unit allocation for the metering system with an Effective From Settlement Date {MSBMU} as specified in the instruction.

    • Send a Confirmation of BM Unit Allocation (D0294) data flow to the Supplier of the Metering System concerned.

4 IMPLICATIONS FOR SUPPLIERS (INCLUDING EXAMPLES)

It is not proposed to include rules for the collation of BM Unit allocation instructions by Suppliers because different Suppliers may have different requirements. For example, some Suppliers may decide to build systems that can schedule a number of planned changes to the BM Unit allocation for a metering system, while others may not need this level of flexibility. However, this section identifies a number of constraints that all Suppliers need to take into account when collating instructions, and provides a hypothetical example of a complex instruction processing scenario.

Clearly Suppliers need to take into account the HHDA processes described in section 2 and 3 above when collating HH BM Unit allocation data into instructions for HHDA. In particular, the following constraints need to be taken into account:

    • As HHDA are obliged to reject any instruction received after Gate Closure for the Effective From Settlement Date of the allocation, there is no point in a Supplier sending an instruction after Gate Closure.

    • HHDA will also reject any instruction that does not change the BM Unit allocation i.e. an instruction that allocates a metering system to a BM Unit ‘X’ will be rejected if the metering system is already allocated to BM Unit ‘X’ on the Effective From Settlement Date of the allocation. However, as described in section 2 of this document, HHDA are not obliged to reject an instruction which explicitly allocates to the Base BM Unit a metering system for which no allocation has previously been received (and which is therefore implicitly allocated to the Base BM Unit already).

    • Each instruction processed by the HHDA will overwrite any allocations for subsequent days for the same metering system.

The following example illustrates the effect of these constraints.

Step 1 – Initial Allocation

On 20-Dec-2000, the Supplier decides to transfer metering system 7654321234567 out of the Base BM Unit into BM017 with an Effective From Settlement Date of 1‑Jan‑2001. He also decides that the metering system should be transferred to BM Unit BM006 on 15‑Apr‑2001. In order to do this he sends the following instructions:

45C|2387|765432123456|BM017|20010101

45C|2388|765432123456|BM006|20010415

The HHDA processes both instructions, and sends confirmations to the Supplier. The HHDA database now holds the following allocations:

EFSD {MSBMU}

BM Unit

1-Jan-2001

BM017

15-Apr-2001

BM006

Step 2 – Erroneous Attempt to Move Date Back

On 28-Dec-2000, the Supplier realises he won’t be ready to trade BM017 on 1‑Jan‑2001, and decides to change the Effective From Settlement Date to 1‑Feb‑2001. This requires one instruction to allocate the metering system to the Base BM Unit BM001 on 1‑Jan‑2001; a second to transfer it to BM Unit BM017 on 1‑Feb‑2001; and a third to renotify the HHDA of the change to BM006 on 15-Apr-2001. Unfortunately, the Supplier makes an error, and types the wrong BM Unit Id into his system, allocating the metering system to BM018 instead of BM017:

45C|2718|765432123456|BM001|20010101

45C|2719|765432123456|BM018|20010201

45C|2720|765432123456|BM006|20010415

The HHDA processes all three instructions, and sends confirmations to the Supplier. The HHDA database now holds the following allocations:

EFSD {MSBMU}

BM Unit

1-Jan-2001

BM001

1-Feb-2001

BM018

15-Apr-2001

BM006

Step 3 – Erroneous Attempt to Correct Error

The Supplier doesn’t spot his error until 13-Mar-2001, when he investigates an unexpected non-delivery charge for BM017. He immediately sends an instruction to correct the error. Again the change to BM006 on 15-Apr-2001 has to be repeated:

45C|3011|765432123456|BM017|20010201

45C|3012|765432123456|BM006|20010415

The first of these instructions violates the Gate Closure rule, and is therefore rejected. This also causes the second to fail, because the BM017 instruction wasn’t processed, and the BM006 allocation on the HHDA database wasn’t therefore deleted as expected. The HHDA sends the following rejections to the Supplier:

24C|3011|765432123456|BM017|20010201|06

24C|3012|765432123456|BM006|20010415|08

Step 4 – Successful Attempt to Correct Error

On 14-Mar-2001, the Supplier realises that he still hasn’t solved the problem. Because of the Gate Closure rule his error cannot be corrected for Settlement Dates from 1-Feb-2001 to 14-Mar-2001 inclusive. He sends an instruction correcting the problem on 15-Mar-2001:

45C|3014|765432123456|BM017|20010315

45C|3015|765432123456|BM006|20010415

The HHDA processes both instructions, and sends confirmations to the Supplier. The HHDA database now holds the following allocations:

EFSD {MSBMU}

BM Unit

1-Jan-2001

BM001

1-Feb-2001

BM018

15-Mar-2001

BM017

15-Apr-2001

BM006

Step 5 – Date Moved Forward

On 20-Mar-2001, the Supplier decides to bring forward the change to BM006 from 15‑Apr‑2001 to 1-Apr-2001. This requires a single instruction:

45C|3163|765432123456|BM006|20010401

The HHDA processes the instruction, and sends a confirmations to the Supplier. The HHDA database now holds the following allocations:

EFSD {MSBMU}

BM Unit

1-Jan-2001

BM001

1-Feb-2001

BM018

15-Mar-2001

BM017

1-Apr-2001

BM006

APPENDIX A – DATA FLOW FORMATS

This Appendix describes the formats of the data flows required as a result of this document. These data flow formats are also defined in the SVA Data Catalogue. Note that all flows shown below should be sent to the network gateway in User File Format (UFF). This format also includes a Test Flag to allow test data to be routed to the appropriate test system.1

A.1 Confirmation of BM Unit Allocation

Flow Reference: D0294001

Flow Name: Confirmation of BM Unit Allocation

Description: Used to notify a Supplier that their BM Unit allocation has been accepted and include verification of the allocation.

Flow Ownership: MRA.

From

To

HHDA

Supplier

21C - File Sequence Number

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 21C

2

File Sequence Number

integer(12)

The file sequence on the incoming D0297 flow from the Supplier. Note that each D0294 flow can only contain confirmations for instructions received on a single D0297 flow.

22C - Confirmed Allocation

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 22C

2

Incoming Instruction Number

integer(12)

As on the incoming D0297 flow from the Supplier.

3

MPAN Core

integer(13)

As on the incoming D0297 flow from the Supplier.

4

BM Unit Id

text(11)

As on the incoming D0297 flow from the Supplier.

5

Effective from Settlement Date {MSBMU}

date

As on the incoming D0297 flow from the Supplier.

Repeating structure of file:

Confirmation of BM Unit Allocation ::= 21C {22C}

A.2 Notification of BM Unit Allocation

Flow Reference: D0297001

Flow Name: Notification of BM Unit Allocation

Description: Supplier notification to HHDA of the BM Unit for an MPAN. To be used for both initial allocation (where the Supplier doesn’t want to use the Base BM Unit) and for updates.

Flow Ownership: MRA.

From

To

Supplier

HHDA

44C - File Sequence Number

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 44C

2

File Sequence Number

integer(12)

45C - BM Unit Allocation

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 45C

2

Instruction Number

integer(12)

3

MPAN Core

integer(13)

4

BM Unit Id

text(11)

5

Effective from Settlement Date {MSBMU}

date

Repeating structure of file:

Notification of BM Unit Allocation ::= 44C {45C}

Additional requirements:

The File Sequence Number should be set to 1 for the first file sent from a given Supplier to a given HHDA, and incremented by 1 for each subsequent file sent from that Supplier to that HHDA.

A.3 Rejection of BM Unit Allocation

Flow Reference: D0295001

Flow Name: Rejection of BM Unit Allocation

Description: Notification to the Supplier that the BM Unit allocation has been rejected and giving the reason for rejection.

Flow Ownership: MRA.

From

To

HHDA

Supplier

23C - File Sequence Number

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 23C

2

File Sequence Number

integer(12)

The file sequence on the incoming D0297 flow from the Supplier. Note that each D0295 flow can only contain rejections for instructions received on a single D0297 flow.

24C - Rejected Allocation

Field

Field Name

Type

Comments

1

Record Type

text(3)

= 24C

2

Incoming Instruction Number

integer(12)

Optional (depending on the BM Unit Allocation Rejection Reason Code). If the rejection relates to a specific instruction, this should match the instruction number on the incoming D0297 flow from the Supplier

3

MPAN Core

integer(13)

Optional (depending on the BM Unit Allocation Rejection Reason Code). If provided, this field should match the value on the incoming D0297 flow from the Supplier.

4

BM Unit Id

text(11)

Optional (depending on the BM Unit Allocation Rejection Reason Code). If provided, this field should match the value on the incoming D0297 flow from the Supplier.

5

Effective from Settlement Date {MSBMU}

date

Optional (depending on the BM Unit Allocation Rejection Reason Code). If provided, this field should match the value on the incoming D0297 flow from the Supplier.

6

BM Unit Allocation Rejection Reason Code

text(2)

Repeating structure of file:

Rejection of BM Unit Allocation ::= 23C {24C}

1 Note that this Appendix does not show the format of the UFF header or footer records for these files. However, an appropriate UFF header and footer record will need to be included in the file whenever these flows are used.