Synopsis	This document describes the user requirements for the Energy Contract Volume Aggregation Agent (ECVAA) service of the NETA Central Systems Project.
Version	Version 25.0
Effective Date	27 February 2020

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 History

Date	Version	Changes Included	Mods/ Panel/ Committee Ref
27/01/2010	16.0	CP1313, February 2010 Release
28/02/2013	17.0	Document rebadged and amended for February 2013 Release (CP1373)	ISG136/02
25/06/2015	18.0	June 2015 Release (P307)	ISG169/05
		June 2015 Release (P310 Self-Governance)
05/11/2015	19.0	November 2015 Release (CP1430)	ISG168/01
		November 2015 Release (P309 Alternative)	ISG172/04
23/02/2017	20.0	February 2017 Release (P326 Self-Governance Alternative)	ISG188/05
02/11/2017	21.0	November 2017 Release (P342 Alternative)	P261/07
28/02/2019	22.0	February 2019 Release (P344)	Panel 284C/01
29/03/2019	23.0	March 2019 Standalone Release (P369)	Panel 285/12
11/12/2019	24.0	CP1517 – TERRE Final Date	ISG220/01 ISG222/03
27/02/2020	25.0	February 2020 Release (P394 Self Governance)	Panel 297/07

References

ECVAA SD	Service Description for Energy Contract Volume Aggregation
CRA URS	Central Registration Agent User Requirements Specification
IDD	Interface Definition and Design Parts 1 and 2

Abbreviations

See Glossary in CRA URS Appendix G.

1. Management Summary

The Energy Contract Volume Aggregation Agent (ECVAA) is one of the suite of seven services that support the operation of the Balancing and Settlement Code (BSC).

The role of the ECVAA is to collate and provide to the Settlement Administration Agent (SAA) all energy contract volume and metered volume reallocation data. The principal business processes involved may be summarised as:

The approval of Energy Contract Volume Notification Agent Authorisations between two BSC Parties and their appointed Energy Contract Volume Notification Agent(s);
The approval of Metered Volume Reallocation Notification Agent Authorisations between a Lead Party, Subsidiary Parties and their appointed Metered Volume Reallocation Notification Agent(s);
The receipt and validation of Energy Contract Volume Notifications and Metered Volume Reallocation Notifications from appropriate notification agents up until the Submission Deadline for each Settlement Period;
The credit checking of BSC Parties on a Settlement Period basis and the rejection of notifications should a Party breach their credit limit threshold;
The transmission of aggregated Energy Contract Volumes and valid Metered Volume Reallocation data to the SAA at the end of each Settlement Day.

1.1 Purpose

The purpose of this document is to provide a complete specification of the set of business requirements which the ECVAA service must satisfy for all of its various user types. These range from the BSC Parties to BSCCo Ltd and its various agents, including the operators of the ECVAA itself and the other BSC services. Similar documents define the requirements for the other services. A convention has therefore been used for uniquely identifying the requirements in each document, so as to ensure that the fulfilment of each requirement can be unambiguously traced through the subsequent functional specification, design and implementation.

The requirements which have been identified have been divided into four categories:

Functional requirements – those requirements relating to a specific business activity, usually requiring some degree of automated support;
Interface requirements – the detailed requirements for the exchange of data between the ECVAA, the other BSC services shown above, and the external participants;
Non-functional requirements – those requirements relating to such activities as security (both physical and user access related), audit, and system housekeeping (systems backups and archiving etc.). It is anticipated that the majority of these will be common to all of the services to be provided;
Service requirements – the underlying service delivery requirements of the ECVAA service, including such as issues as performance and volumetrics.

These requirements are catalogued in sections 5 to 8 respectively.

1.2 Scope

The document defines the requirements for the Energy Contract Volume Aggregation Agent service of the NETA Central Systems. The requirements are described from the point of view of the ECVAA Service Operators. The full document scope is listed within section 3 of this document.

2 Introduction

This document is the User Requirements Specification (URS) for the Energy Contract Volume Aggregation Agent role within the Balancing and Settlement Code Services. It is one of a set of documents forming the baseline for requirements of the seven NETA services. This document set comprises:

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS;
SVAA URS
Interface Definition and Design.

The objective of this document is to provide a complete specification of the user requirements that the ECVAA service must meet. For this purpose, the “users” include BSCCo Ltd, Ofgem, National Electricity Transmission System Operator (NETSO) as the balancing mechanism operator, other Service Providers, BSC Parties, and the ECVAA Service Provider’s own operators.

This User Requirements Specification forms the input to the lower level documents such as the System Specification and Design Specification for the ECVAA Service. These specifications constitute the definition of the computer systems built in support of the ECVAA Services.

This document refers to a “Supplier BM Unit”, which means a BM Unit with a BM Unit Type of ‘G’ or ‘S’, and to a “Secondary BM Unit”, which means a BM Unit registered by a Virtual Lead Party (VLP) with a BM Unit Type of ‘V’, as stated by the Lead Party on the ‘Registration of BM Unit’ form in BSCP15.

3 Scope of Specification

This document provides a specification of the requirements for the Energy Contract Volume Aggregation Agent (ECVAA) Service within the NETA programme. The requirements are described from the point of view of the ECVAA Service users.

The document is divided into the following chapters.

Chapter 4, Business and System Overview – describes the business context of the ECVAA Service;
Chapter 5, Functional Requirements – describes the functional requirements of the Service from the point of view of the Service users;
Chapter 6, Interfaces Requirements – describes the interfaces with the external users of the Service;
Chapter 7, Non-Functional Requirements – describes the non-functional requirements of the Service, such as auditing, security and resilience;
Chapter 8, Service Requirements – describes the service delivery requirements of the Service, such as performance and volumetrics;
Chapter 9, User Roles and Activities – describes the roles supporting day to day operation of the Service and external users of the Service, such as other Service Providers and BSCCo Ltd;
Chapter 10, Future Enhancements – describes potential functional enhancements;
Appendix A, Glossary - includes a glossary of terms and acronyms;
Appendix B, Requirements Compliance Matrix – shows the mapping of requirements defined by this document to requirements set out in the Customer’s Tender Invitation documents;
Appendix C, Not Used;
Appendix D, Business Process Model.

4 Business and System Overview

4.1 Summary of Business Requirements

The Energy Contract Volume Aggregation Agent is responsible for the following key roles:

the approval of Energy Contract Volume Notification Agent Authorisations (ECVNAAs) between two BSC Parties and their appointed Energy Contract Volume Notification Agent(s);
the approval of Metered Volume Reallocation Notification Agent Authorisations (MVRNAAs) between a Lead Party, Subsidiary Parties and their appointed Metered Volume Reallocation Notification Agent(s);
the receipt and validation of Energy Contract Volume Notifications and Metered Volume Reallocation Notifications from appropriate notification agents up until the Submission Deadline for each Settlement Period;
the credit checking of BSC Parties on a Settlement Period basis and the rejection of notifications should a Party breach their credit limit threshold;
the transmission of aggregated Energy Contract Volumes and valid Metered Volume Reallocation data to the SAA at the end of each Settlement Day.

4.1.1 ECVNAA Approval

The ECVAA will receive, validate, approve and record Energy Contract Volume Notification Agent Authorisation (ECVNAA), Authorisation Change and termination requests from BSC Parties appointing Energy Contract Volume Notification Agent(s) (ECVNA). In many cases these notification agents are likely either to be power exchanges or market participants themselves.

4.1.2 MRVNAA Approval

The ECVAA will also receive, validate, approve and record Metered Volume Reallocation Notification Agent Authorisation (MVRNAA) and termination requests from BSC Lead and Subsidiary Parties appointing Metered Volume Reallocation Notification Agent(s) (MVRNA).

4.1.3 Notification Collection

The ECVAA will receive Energy Contract Volume Notifications prior to the Submission Deadline from authorised ECVNAs which will be validated against its register of approved ECVNAAs.

The ECVAA will also receive Metered Volume Reallocation Notifications prior to the Submission Deadline from authorised MVRNAs which will be validated against its register of approved MVRNAAs.

The ECVAA Service must be available 24 hours a day, 365 days a year in order to ensure that ECVNS and MVRNs can be registered in near real-time up to the Submission Deadline for any particular half-hour.

4.1.4 Credit Checking

Immediately after the Submission Deadline for each Settlement Period the ECVAA will perform credit checking of all BSC Parties. Should a Party breach their credit limit threshold the ECVAA will reject notifications that increase the Indebtedness of that Party. In addition, the ECVAA will warn BSC Parties and BSCCo Ltd about Parties who are approaching their credit limit.

4.1.5 Aggregation and reporting to SAA

At the end of each Settlement Day the ECVAA will aggregate the notified Energy Contract Volumes to determine the Account Bilateral Contract Volume for each BSC Party. The ECVAA will then transmit the Account Bilateral Contract Volumes and validated MVRNs to the SAA in timely manner to allow SAA to comply with the requirements of the Settlement Calendar.

4.2 Service Context

The following diagram illustrates the context of the ECVAA service within the wider scope of the Balancing and Settlement Code. This is a simplified view for clarity; section 6 describes the interfaces from the ECVAA service to other parties in detail.

Item	Description
Bank	A bank which receives debit and credit instructions from the Funds Administration Agent.
BMRA	Balancing Mechanism Reporting Agent.
BSC Party	A party which is signatory to the Balancing and Settlement Code
BSCCo Ltd	The Balancing and Settlement Code Company.
CDCA	Central Data Collection Agent.
CRA	Central Registration Agent
Credit Agency	A credit agency which provides credit cover data on BSC Parties.
ECVAA	Energy Contract Volume Aggregation Agent.
ECVNA	Energy Contract Volume Notification Agent.
FAA	Funds Administration Agent.
IA	Interconnector Administrator.
IEA	Interconnector Error Administrator
Meter	A physical meter registered within the Balancing and Settlement Code arrangements.
MIDP	Market Index Data Provider
MOA	Meter Operation Agent.
MVRNA	Metered Volume Reallocation Notification Agent
NETSO	National Electricity Transmission System Operator as the holder of the Transmission Licence and any reference to "NETSO", "NGESO", "National Grid Company" or "NGC" in the Code or any Subsidiary Document shall have the same meaning
Public	A member of the general public.
SAA	Settlement Administration Agent.
SVAA	Supplier Volume Aggregation Agent, equivalent to the current Initial Settlement and Reconciliation Agent (ISRA).
TAA	Technical Assurance Agent.
TLFA	Transmission Loss Factor Agent
Transfer Coordinator	A role undertaken by BSCCo Ltd to coordinate transfers of metering between CVA (CRA & CDCA) and SVA in order to address the risk that Metering Systems are ‘double counted’ or ‘omitted’ from Settlements’.

4.3 User Requirements Source Documents

In addition to our tender, the reference documents listed in section 1.5 have been used. The code listed in the first column is used as a cross reference in the detailed requirement specifications listed in section 5.

4.4 Requirements Summary

The following table summarises the requirements of the ECVAA service. These are then described in detail in section 5, including the source reference for each requirement. Requirements common to all the NETA Central Services are described in the CRA URS.

Requirement ID.	User Requirement
Functional
ECVAA-F001	Process Registration Data
ECVAA-F002	Process Credit Limit Data
ECVAA-F003	Process Energy Contract Volume Notification Agent Authorisation
ECVAA-F004	Process Metered Volume Reallocation Notification Agent Authorisation
ECVAA-F005	Process Energy Contract Volume Notifications
ECVAA-F006	Process Metered Volume Reallocation Notifications
ECVAA-F007	Perform Credit Check
ECVAA-F008	Aggregate Energy Contract Volumes
ECVAA-F009	Process Exception Data
ECVAA-F010	Calculate Party Indebtedness
ECVAA-F011	Process Credit Cover Minimum Eligible Amount Request
ECVAA-F012	Process Volume Notification Nullification Requests
ECVAA-F013	Manage ECVAA System Failure / Withdrawal
ECVAA-F014	Matching of Submitted ECVNs
ECVAA-F015	Matching of Submitted MVRNs
ECVAA-F016	ECVAA Web service Common Functionality
ECVAA-F017	ECVAA Web service – BSC Party View ECVNs Functionality.
ECVAA-F018	ECVAA Web service – BSC Party View MVRNs Functionality.
ECVAA-F019	ECVAA Web service - ECVNA Functionality
ECVAA-F020	ECVAA Web service - ECVNA ECVN Submission Functionality.
ECVAA-F021	ECVAA Web service - MVRNA Functionality.
ECVAA-F022	ECVAA Web service - MVRNA MVRN Submission Functionality.
ECVAA-F023	Banning/Unbanning Individual User Access to the ECVAA Web service Functionality
ECVAA-F024	Process Withdrawing Party Authorisation and Notification Details
ECVAA-F025	Calculate Period Final Physical Notification Volumes
ECVAA-F026	Removal of ECVNs / MVRNs from ECVAA for a Party in section H Default
Interface
ECVAA-I001	Receive Registration Data
ECVAA-I002	Receive Energy Contract Volume Notification Agent Authorisation Data
ECVAA-I003	Receive Metered Volume Reallocation Notification Agent Authorisation Data
ECVAA-I004	Receive Energy Contract Volume Notifications
ECVAA-I005	Receive Metered Volume Reallocation Notifications
ECVAA-I006	Receive Credit Limit Data
ECVAA-I007	Issue Energy Contract Volume Notification Agent Authorisation Feedback
ECVAA-I008	Issue Metered Volume Reallocation Notification Agent Authorisation Feedback
ECVAA-I009	Issue Energy Contract Volume Notification Feedback (Rejection)
ECVAA-I010	Issue Metered Volume Reallocation Notification Feedback (Rejection)
ECVAA-I011	Issue Account Bilateral Contract Volume Report
ECVAA-I012	Issue Metered Volume Reallocation Notification Report
ECVAA-I013	Issue Authorisation Report
ECVAA-I014	Issue Notification Report
ECVAA-I015	Receive BM Unit Credit Cover Meter Volume Data
ECVAA-I016	Issue Exception Reports
ECVAA-I017	Issue ECVAA Performance Report
ECVAA-I018	Receive Acknowledgement
ECVAA-I019	Issue Acknowledgement
ECVAA-I020	Receive Exception Report
ECVAA-I021	Issue Credit Limit Warning
ECVAA-I022	Forward Contract Report
ECVAA-I023	ECVAA BSC Schedule D Charging Data
ECVAA-I024	Receive Credit Cover Minimum Eligible Amount Request
ECVAA-I025	Issue Credit Cover Minimum Eligible Amount Report
ECVAA-I026	Issue Minimum Eligible Amount Rule Request
ECVAA-I027	Notification of BSC Party in Section H Default
ECVAA-I028	Issue ECVN Acceptance Feedback
ECVAA-I029	Issue MVRN Acceptance Feedback
ECVAA-I030	Receive Notification Agent Termination Request
ECVAA-I031	Issue Notification Agent Termination Feedback
ECVAA-I032	Receive Credit Assessment Price
ECVAA-I033	Receive Credit/Debit Report
ECVAA-I034	Reserved for future use
ECVAA-I035	Receive Forward Contract Report Start Period Override
ECVAA-I036	Publish Credit Default Report
ECVAA-I037	Receive Volume Notification Nullification Request
ECVAA-I038	Issue Volume Notification Nullification Confirmation Report
ECVAA-I039	Issue Nullification Completion Report
ECVAA-I040	Issue Notification System Status Report
ECVAA-I041	Receive Party Credit Default Authorisation Details
ECVAA-I042	Banning/Unbanning Individual User Access to the ECVAA Web service
ECVAA-I043	ECVAA Web Service – BSC Party View ECVNs.
ECVAA-I044	ECVAA Web service – BSC Party View MVRNs.
ECVAA-I045	ECVAA Web service – ECVNA View ECVNs
ECVAA-I046	ECVAA Web service – MVRNA View MVRNs.
ECVAA-I047	Issue Withdrawing Party Authorisation and Notification Details
ECVAA-I048	Receive Physical Notification Data
ECVAA-I049	Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default
ECVAA-I050	Remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default Feedback
Service
ECVAA-S001	Service Availability
ECVAA-S002	Volumetric Requirements
ECVAA-S003	Resilience Requirements

4.5 Numbering Scheme for Requirements Definitions

As described in section 2, the set of baseline requirement documents will include a User Requirements Specification for each of the services of the central NETA systems (except FAA - see footnote 1). Within these documents each requirement across the set of services is uniquely identified to provide traceability of each individual requirement from URS to System Specification (functional specification) and then to Design Specification (technical specification).

In keeping with industry good practice, this URS adopts a requirements numbering system that works as follows:

1. Each requirement is be associated with either an individual service, or as common to all services supported by our systems. (TAA will typically be excluded from the latter.) If a requirement applies to more than one service, but not all (e.g. two out of six), then the requirement will be restated for each, i.e. there would be two separately numbered requirements (which happen to be the same) in this example.

Each requirement is prefaced by one of the following codes, as a clear indicator as to which service generates the business need:

CRA (Central Registration Agent);
SAA (Settlement Administration Agent);
CDCA (Central Data Collection Agent);
ECVAA (Energy Contract Volume Aggregation Agent);
BMRA (Balancing Mechanism Reporting Agent);
FAA (Funds Administration Agent);
SVAA (Supplier Volume Allocation Agent);
GEN (General). General requirements are described in the appendices of the CRA URS.

2. Requirements are categorised into the following headings:

Functional (F), a specific business requirement of the service.
Interface (I), a requirement for data exchange between services or to external parties.
Non-functional (N), which includes auditing, security, resilience etc. The majority of these will probably be associated with the General (GEN) service.
Service (S), which includes all time-related service delivery requirements, including performance and volumetrics.

3. Within a service, each requirement has a unique number in the range 001 to 999. Numbers are not unique across services. Leading zeroes are always included.

Combining 1, 2 and 3 thus gives the following format for numbering each requirement (including a separator character):

[Service]-[Category][Number]

For example:

CRA-F001
BMRA-S022
GEN-N112
SAA-I033

4.6 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: a unique identifier for the requirement, as described above.

Status: while the majority of ECVAA requirements will be mandatory for the Go Live date, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: a short descriptive title for the requirement.

BSC reference: a cross reference to the BSC section which is the original source of the business need. Note that there may be detailed requirements identified in the User Requirements Specification which are not individually described in the BSC; in this case this field is used to reference the alternative source of the requirement, for instance a specific workshop with the customer’s user community.

Man/auto: this field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism.

Frequency: an indication of how often a business event will take place. Minimum, maximum and average frequencies, and any timing or scheduling requirements, are also identified here, as appropriate.

Volumes: data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

The requirement is then described in detail, with any associated specific non-functional and interface requirements separately identified. Any outstanding issues relating to the requirement definition are also identified.

5 Functional Requirements

This section describes the detailed set of business requirements for the Energy Contract Volume Aggregation Agent Service. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is uniquely numbered, based on the convention described in section 4.

5.1 ECVAA-F001: Process Registration Data

Requirement ID: ECVAA-F001	Status: Mandatory	Title: Process Registration Data	BSC Reference: ECVAA SD: 4, B1 ECVAA BPM: 3.1, 3.2 CP503
Man/auto: Automatic	Frequency: Daily, each working day	Volumes: Low
Functional Requirement:
The ECVAA shall receive registration data from the CRA as described by requirement ECVAA-I001: Receive Registration Data. The registration data shall comprise: Party and Party Authentication Details Party Agent and Party Agent Authentication Details BM Unit & Energy Account Registration Data Note: the ECVAA shall expect a data file from the CRA on each working day even if that file indicates that there is no new or updated registration data.
1: The ECVAA shall validate the received registration data. The validation shall include the following: a. checks to ensure data accuracy and consistency - for instance, that data is of the correct type and format, forms a complete set of registration data and is consistent within that set, etc.; b. data is received at least one calendar day prior to the date that it comes into effect.
2: The ECVAA shall input valid registration data into its systems except that of Secondary BM Unit data received from the CRA.
3: Should the ECVAA be unable to input the registration data (e.g. because it is in the wrong format) it shall report the matter to the CRA and not input any part of the data. Rejected data shall be retained for audit purposes. The ECVAA shall report registration data validation failures to the CRA as described by requirement ECVAA-I016: Issue Exception Report.
4: Where valid registration data is received that terminates or amends the termination date for a BSC Party the ECVAA shall perform the following processing to ensure consistency of data. If the termination date of the BSC Party within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate ECVNAAs and MVRNAAs as follows. The ECVAA shall terminate ECVNAAs and MVRNAAs, with a Termination Effective Date equal to the received BSC Party’s termination date, where: the BSC Party is a party to the ECVNAA/MVRNAA; and the Effective From Date of the ECVNAA/MVRNAA is: on or prior to the Termination Effective Date and the ECVNAA/MVRNAA is evergreen or overlaps the Termination Effective Date; or after the Termination Effective Date, i.e. the ECVNAA/MVRNAA is not yet effective. (Note: Terminating an ECVNAA/MVRNAA in this way effectively deletes it.) The ECVAA shall notify the BSC Parties and the relevant ECVNA of each ECVNAA termination via the confirmed termination feedback described by requirement I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback. The ECVAA shall notify the Lead Party, Subsidiary Party and the relevant MVRNA of each MVRNAA termination via the confirmed termination feedback described by requirement I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback. Note: Termination of an ECVNAA/MVRNAA will prevent any further ECVNs/MVRNs being accepted from the ECVNA/MVRNA after the Termination Effective Date. Any ECVNs/MVRNs which exist after the Termination Effective Date will be considered void since the BSC Party is no longer effective, and therefore will not be reported to the SAA.
5: Where valid registration data is received that terminates or amends the termination date for a BSC Party Agent the ECVAA shall perform the following processing to ensure consistency of data. If the termination date of the BSC Party Agent within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate ECVNAAs and MVRNAAs as follows. The ECVAA shall terminate ECVNAAs and MVRNAAs, with a Termination Effective Date equal to the received BSC Party Agent’s termination date, where: the BSC Party Agent is the authorised ECVNA/MVRNA for the ECVNAA/MVRNAA; and the Effective From Date of the ECVNAA/MVRNAA is: on or prior to the Termination Effective Date and the ECVNAA/MVRNAA is evergreen or overlaps the Termination Effective Date; or after the Termination Effective Date, i.e. the ECVNAA/MVRNAA is not yet effective. (Note: Terminating an ECVNAA/MVRNAA in this way effectively deletes it.) The ECVAA shall notify the BSC Parties and the relevant ECVNA of each ECVNAA termination via the confirmed termination feedback described by requirement I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback. The ECVAA shall notify the Lead Party, Subsidiary Party and the relevant MVRNA of each MVRNAA termination via the confirmed termination feedback described by requirement I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback. Note: Termination of an ECVNAA/MVRNAA will prevent any further ECVNs/MVRNs being accepted from the ECVNA/MVRNA after the Termination Effective Date. However ECVNs/MVRNs may still be received from other authorised ECVNAs/MVRNAs. Any ECVNs/MVRNs which exist after the Termination Effective Date will still be valid and will be reported to the SAA. ECVAA shall receive details from CRA of attempted ECVNA or MVRNA de-registrations and verify that any related authorisations have been terminated. This communication is described by the requirements ECVAA-I030 and ECVAA-I031.
6: Where valid registration data is received that terminates or amends the termination date of a BSC Party as the Lead Party for a BM Unit the ECVAA shall perform the following processing to ensure consistency of data. If the termination date of the BSC Party as Lead Party to the BM Unit within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate MVRNAAs as follows. The ECVAA shall terminate MVRNAAs, with a Termination Effective Date equal to the received Lead Party termination date, where: the MVRNAA is for the relevant BM Unit; and the BSC Party is the Lead Party to the MVRNAA; and the Effective From Date of the MVRNAA is: on or prior to the Termination Effective Date and the MVRNAA is evergreen or overlaps the Termination Effective Date; or after the Termination Effective Date, i.e. the MVRNAA is not yet effective. (Note: Terminating a MVRNAA in this way effectively deletes it.) The ECVAA shall notify the Lead Party, Subsidiary Party and the relevant MVRNA of each MVRNAA termination via the confirmed termination feedback described by requirement I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback. Note: Termination of a MVRNAA will prevent any further MVRNs being accepted from the MVRNA after the Termination Effective Date. Any MVRNs which exist after the Termination Effective Date will be considered void since the BSC Party is no longer Lead Party to the BM Unit, and therefore will not be reported to the SAA.
7: Where valid registration data is received that amends a BM Unit’s type (production or consumption) the ECVAA shall perform the following processing to ensure consistency of data. The ECVAA shall terminate MVRNAAs whose Effective Dates encompass the Effective From dates for the amendment to the relevant BM Unit type. These MVRNAAs will be terminated by setting the MVRNAA Effective To date equal to the Termination Effective date for the original BM Unit type. In the case of MVRNAAs not yet effective (i.e. where the MVRNAA Effective From date is after the Effective From date of the amendment), setting the MVRNAA Effective To date as above will effectively delete these MVRNAAs. The ECVAA shall notify the Lead Party, Subsidiary Party and the relevant MVRNA of each MVRNAA termination via the confirmed termination feedback described by requirement I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback. Note: Termination of a MVRNAA will prevent any further MVRNs being accepted from the MVRNA after the Termination Effective Date. Any MVRNs which exist after the Termination Effective Date will be considered void since the Lead and Subsidiary Party Energy Accounts are not consistent with the BM Unit type, and therefore will not be reported to the SAA.
ECVAA will use the reporting requirements received as part of registration data to determine which reports (optional) need to be sent to the registered participant.
Non Functional Requirement:
The ECVAA Service shall process registration data within 1 day of receipt.
Interfaces:
Related interface requirements:
ECVAA-I001: Receive Registration Data ECVAA-I016: Issue Exception Report ECVAA-I030: Receive Notification Agent Termination Request ECVAA-I031: Issue Notification Agent Termination Feedback

Requirement ID:

ECVAA-F001

Status:

Mandatory

Title:

Process Registration Data

BSC Reference:

ECVAA SD: 4, B1

ECVAA BPM: 3.1, 3.2

CP503

Man/auto:

Automatic

Frequency:

Daily, each working day

Volumes:

Low

Functional Requirement:

The ECVAA shall receive registration data from the CRA as described by requirement ECVAA-I001: Receive Registration Data. The registration data shall comprise:

Party and Party Authentication Details

Party Agent and Party Agent Authentication Details

BM Unit & Energy Account Registration Data

Note: the ECVAA shall expect a data file from the CRA on each working day even if that file indicates that there is no new or updated registration data.

1: The ECVAA shall validate the received registration data. The validation shall include the following:

a. checks to ensure data accuracy and consistency - for instance, that data is of the correct type and format, forms a complete set of registration data and is consistent within that set, etc.;

b. data is received at least one calendar day prior to the date that it comes into effect.

2: The ECVAA shall input valid registration data into its systems except that of Secondary BM Unit data received from the CRA.

3: Should the ECVAA be unable to input the registration data (e.g. because it is in the wrong format) it shall report the matter to the CRA and not input any part of the data. Rejected data shall be retained for audit purposes.

The ECVAA shall report registration data validation failures to the CRA as described by requirement ECVAA-I016: Issue Exception Report.

4: Where valid registration data is received that terminates or amends the termination date for a BSC Party the ECVAA shall perform the following processing to ensure consistency of data.

If the termination date of the BSC Party within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate ECVNAAs and MVRNAAs as follows.

The ECVAA shall terminate ECVNAAs and MVRNAAs, with a Termination Effective Date equal to the received BSC Party’s termination date, where:

the BSC Party is a party to the ECVNAA/MVRNAA; and
the Effective From Date of the ECVNAA/MVRNAA is:

on or prior to the Termination Effective Date and the ECVNAA/MVRNAA is evergreen or overlaps the Termination Effective Date; or
after the Termination Effective Date, i.e. the ECVNAA/MVRNAA is not yet effective. (Note: Terminating an ECVNAA/MVRNAA in this way effectively deletes it.)

The ECVAA shall notify the BSC Parties and the relevant ECVNA of each ECVNAA termination via the confirmed termination feedback described by requirement I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

The ECVAA shall notify the Lead Party, Subsidiary Party and the relevant MVRNA of each MVRNAA termination via the confirmed termination feedback described by requirement I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

Note: Termination of an ECVNAA/MVRNAA will prevent any further ECVNs/MVRNs being accepted from the ECVNA/MVRNA after the Termination Effective Date. Any ECVNs/MVRNs which exist after the Termination Effective Date will be considered void since the BSC Party is no longer effective, and therefore will not be reported to the SAA.

5: Where valid registration data is received that terminates or amends the termination date for a BSC Party Agent the ECVAA shall perform the following processing to ensure consistency of data.

If the termination date of the BSC Party Agent within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate ECVNAAs and MVRNAAs as follows.

The ECVAA shall terminate ECVNAAs and MVRNAAs, with a Termination Effective Date equal to the received BSC Party Agent’s termination date, where:

the BSC Party Agent is the authorised ECVNA/MVRNA for the ECVNAA/MVRNAA; and
the Effective From Date of the ECVNAA/MVRNAA is:

on or prior to the Termination Effective Date and the ECVNAA/MVRNAA is evergreen or overlaps the Termination Effective Date; or
after the Termination Effective Date, i.e. the ECVNAA/MVRNAA is not yet effective. (Note: Terminating an ECVNAA/MVRNAA in this way effectively deletes it.)

Note: Termination of an ECVNAA/MVRNAA will prevent any further ECVNs/MVRNs being accepted from the ECVNA/MVRNA after the Termination Effective Date. However ECVNs/MVRNs may still be received from other authorised ECVNAs/MVRNAs. Any ECVNs/MVRNs which exist after the Termination Effective Date will still be valid and will be reported to the SAA.

ECVAA shall receive details from CRA of attempted ECVNA or MVRNA de-registrations and verify that any related authorisations have been terminated. This communication is described by the requirements ECVAA-I030 and ECVAA-I031.

6: Where valid registration data is received that terminates or amends the termination date of a BSC Party as the Lead Party for a BM Unit the ECVAA shall perform the following processing to ensure consistency of data.

If the termination date of the BSC Party as Lead Party to the BM Unit within the ECVAA systems is null (evergreen) or is after the received termination date then the ECVAA shall terminate MVRNAAs as follows.

The ECVAA shall terminate MVRNAAs, with a Termination Effective Date equal to the received Lead Party termination date, where:

the MVRNAA is for the relevant BM Unit; and
the BSC Party is the Lead Party to the MVRNAA; and
the Effective From Date of the MVRNAA is:

on or prior to the Termination Effective Date and the MVRNAA is evergreen or overlaps the Termination Effective Date; or
after the Termination Effective Date, i.e. the MVRNAA is not yet effective. (Note: Terminating a MVRNAA in this way effectively deletes it.)

Note: Termination of a MVRNAA will prevent any further MVRNs being accepted from the MVRNA after the Termination Effective Date. Any MVRNs which exist after the Termination Effective Date will be considered void since the BSC Party is no longer Lead Party to the BM Unit, and therefore will not be reported to the SAA.

7: Where valid registration data is received that amends a BM Unit’s type (production or consumption) the ECVAA shall perform the following processing to ensure consistency of data.

The ECVAA shall terminate MVRNAAs whose Effective Dates encompass the Effective From dates for the amendment to the relevant BM Unit type.

These MVRNAAs will be terminated by setting the MVRNAA Effective To date equal to the Termination Effective date for the original BM Unit type.

In the case of MVRNAAs not yet effective (i.e. where the MVRNAA Effective From date is after the Effective From date of the amendment), setting the MVRNAA Effective To date as above will effectively delete these MVRNAAs.

Note: Termination of a MVRNAA will prevent any further MVRNs being accepted from the MVRNA after the Termination Effective Date. Any MVRNs which exist after the Termination Effective Date will be considered void since the Lead and Subsidiary Party Energy Accounts are not consistent with the BM Unit type, and therefore will not be reported to the SAA.

ECVAA will use the reporting requirements received as part of registration data to determine which reports (optional) need to be sent to the registered participant.

Non Functional Requirement:

The ECVAA Service shall process registration data within 1 day of receipt.

Interfaces:

Related interface requirements:

ECVAA-I001: Receive Registration Data

ECVAA-I016: Issue Exception Report

ECVAA-I030: Receive Notification Agent Termination Request

ECVAA-I031: Issue Notification Agent Termination Feedback

5.2 ECVAA-F002: Process Credit Limit Data

Requirement ID: ECVAA-F002	Status: Mandatory	Title: Process Credit Limit Data	ITT reference: ECVAA SD: 5, B2 ECVAA BPM: 3.3 CR012
Man/auto: Automatic	Frequency: Continuous, when credit limit changes	Volumes: Medium
Functional Requirement:
The ECVAA shall receive credit limit data from the FAA as described by requirement ECVAA-I006: Receive Credit Limit Data. The credit limit data shall comprise: Party Credit Limit Details Note: the ECVAA shall only receive credit limit data from the FAA when data changes. Currently the FAA service only operates during normal working hours and therefore credit limit data will only be expected during these hours.
1: The ECVAA shall validate the received credit limit data. The validation shall include the following: a. checks to ensure data accuracy and consistency - for instance, that data is of the correct type and format, is consistent with registration data received from the CRA, etc.; b. the Effective From Date for the credit limit data is on or after the date of receipt.
2: The ECVAA shall input valid credit limit data into its systems. If the Effective From Date for the credit limit data is the date of receipt then the new credit limit will take immediate effect and the ECVAA shall record the time/Settlement Period at which the new credit limit was applied. Note: The FAA is not informed of the time/Settlement Period at which the new credit limit was applied by the ECVAA.
3: Should the ECVAA be unable to input the credit limit data (e.g. because the BSC Party’s identifier p does not exist), it shall report the matter to the FAA and not input any part of the data. Rejected data shall be retained for audit purposes. For the avoidance of doubt, if credit limit data is rejected any existing credit limit data for the BSC Party will continue to remain in force. If there is no existing credit limit data for the BSC Party a default value of zero will be used. The ECVAA shall report credit limit data validation failures to the FAA as described by requirement ECVAA-I016: Issue Exception Report.
Non Functional Requirement:
The ECVAA Service shall process credit limit data automatically on receipt and shall return an Exception Report, if required, within 15 minutes of receipt.
Interfaces:
Related interface requirements: ECVAA-I006: Receive Credit Limit Data
ECVAA-I016: Issue Exception Report

Requirement ID:

ECVAA-F002

Status:

Mandatory

Title:

Process Credit Limit Data

ITT reference:

ECVAA SD: 5, B2

ECVAA BPM: 3.3

CR012

Man/auto:

Automatic

Frequency:

Continuous, when credit limit changes

Volumes:

Medium

Functional Requirement:

The ECVAA shall receive credit limit data from the FAA as described by requirement ECVAA-I006: Receive Credit Limit Data. The credit limit data shall comprise:

Party Credit Limit Details

Note: the ECVAA shall only receive credit limit data from the FAA when data changes. Currently the FAA service only operates during normal working hours and therefore credit limit data will only be expected during these hours.

1: The ECVAA shall validate the received credit limit data. The validation shall include the following:

a. checks to ensure data accuracy and consistency - for instance, that data is of the correct type and format, is consistent with registration data received from the CRA, etc.;

b. the Effective From Date for the credit limit data is on or after the date of receipt.

2: The ECVAA shall input valid credit limit data into its systems.

If the Effective From Date for the credit limit data is the date of receipt then the new credit limit will take immediate effect and the ECVAA shall record the time/Settlement Period at which the new credit limit was applied. Note: The FAA is not informed of the time/Settlement Period at which the new credit limit was applied by the ECVAA.

3: Should the ECVAA be unable to input the credit limit data (e.g. because the BSC Party’s identifier p does not exist), it shall report the matter to the FAA and not input any part of the data. Rejected data shall be retained for audit purposes.

For the avoidance of doubt, if credit limit data is rejected any existing credit limit data for the BSC Party will continue to remain in force. If there is no existing credit limit data for the BSC Party a default value of zero will be used.

The ECVAA shall report credit limit data validation failures to the FAA as described by requirement ECVAA-I016: Issue Exception Report.

Non Functional Requirement:

The ECVAA Service shall process credit limit data automatically on receipt and shall return an Exception Report, if required, within 15 minutes of receipt.

Interfaces:

Related interface requirements:

ECVAA-I006: Receive Credit Limit Data

ECVAA-I016: Issue Exception Report

5.3 ECVAA-F003: Process ECVNAA

Requirement ID: ECVAA-F003	Status: Mandatory	Title: Process Energy Contract Volume Notification Agent Authorisation (ECVNAA)	BSC Reference: ECVAA SD: 6, B3-4, ECVAA BPM: 3.1, CR008, Clarification: ‘ECVAA Authorisation Keys’, CR028, CP547, CP571, Variation 49, CP888, P98, CP1009, P309
Man/auto: Manual	Frequency: Daily	Volumes: Low
Functional Requirement: The ECVAA shall receive Energy Contract Volume Notification Agent Authorisation data from the BSC Parties and ECVNAs as described by requirement ECVAA-I002: Receive Energy Contract Volume Notification Agent Authorisation Data. The Energy Contract Volume Notification Agent Authorisation data shall comprise: ECVNAA Requests ECVNAA Termination Requests ECVNAA Key Change Requests ECVNAA reporting option Change Requests ECVNAA Changes The ECVAA should process ECVNAA Request Data that include the NETSO as one of the counterparties in an identical manner as for any other party. This will require the ECVAA to treat the NETSO as if it has Energy Accounts. The ECVAA shall process ECVNAA data as follows.
ECVNAA Requests:
1: The ECVAA shall validate the received ECVNAA requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: Name and identifier of the ECVNA(s); Names and identifiers of the two BSC Parties; Production/consumption flags of the two BSC Parties’ Energy Account; Effective From Settlement Day; Effective To Settlement Day (An ECVNAA may be open-ended, i.e. the Effective To Settlement Day is optional. An ECVNAA relates to a complete Settlement Day, i.e. no time element to the effective date range); Reporting options for each BSC Party and ECVNA (for requests with Effective From Settlement Day after the P98 BSC Implementation Date); Notification Amendment Type set to ‘Additional’, ‘Replacement’ or ‘Both’; and Notification Amendment Type Effective From Date; b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with registration data received from the CRA, production/consumption flags are valid, etc.; c. the effective from Settlement Day must not be before the BSC start date; d. the effective from Settlement Day must not be more than thirty calendar days after the day of receipt of the application; e. the same ECVNAA request has been received from both parties and the ECVNA(s), each correctly authorised. An unmatched ECVNAA request will be rejected after five working days; f. the effective from Settlement Day must not be before the P98 BSC Implementation Date where two different ECVNAs are appointed; g. the Notification Amendment Type Effective From Date must be the same as the Effective From Settlement Day (for the overall Authorisation) for new or successor Authorisation requests only. There will be no restrictions on the number of ECVNAAs that can be accepted per counter-party/Energy Account pair, i.e. a given BSC Party can appoint multiple ECVNAs to notify for the same counter-party/Energy Account pair on a given day. An ECVNAA can be between any combination of the BSC Parties’ Energy Accounts, including the two accounts of a single party, i.e. an ECVNAA can be between: the production account of both party 1 and 2; the consumption account of both party 1 and 2; the production account of party 1 and the consumption account of party 2; the consumption account of party 1 and the production account of party 2; the production and consumption account of a single party. An ECVNAA authorises an ECVNA(s) to submit ECVNs on behalf of each of the two BSC Parties for the period of the authorisation. The ECVNs are not however ‘owned’ by the ECVNA(s) but by the BSC Parties. Therefore ECVNs submitted by one ECVNA may be subsequently amended by another authorised ECVNA. Since both BSC Parties appoint the same ECVNA, only one copy of the Authorisation Request will be received from that ECVNA. ECVAA shall allow BSC Parties to change an existing Authorisation by raising an Authorisation Change. This allows them to modify the terms of an existing Authorisation, e.g. the Notification Amendment Type, without terminating the existing Authorisation and requiring a new Authorisation. It also means that any existing ECVNs accepted under the earlier version of the Authorisation are unaffected by the change(s).
2: The ECVAA shall reject any ECVNAA request that fails the validation described in point 1 above and notify the relevant BSC Parties and the relevant ECVNA(s) of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected ECVNAAs as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
3: The ECVAA shall notify the relevant BSC Parties and the relevant ECVNA(s) of the acceptance of each valid ECVNAA request. The ECVAA shall issue a unique ECVNAA identifier and ECVNAA Key for each valid ECVNAA request. The ECVAA shall notify the identifier to both the BSC Parties and the ECVNA(s). The ECVAA shall notify the Key to the ECVNA only. Each ECVNA will be issued with their own ECVNAA Key. The ECVAA shall report confirmed ECVNAAs (including identifier and key as appropriate) as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
4: The ECVAA shall input each validated ECVNAA into its systems. The data to be recorded for each valid ECVNAA shall include the following: ECVNAA identifier; ECVNAA Key (or data allowing the ECVNAA Key to be checked); Name and identifier of the ECVNA(s); Names and identifiers of the two BSC Parties; Production/consumption flags of the two BSC Parties’ Energy Account; Notification Amendment Type Effective From Settlement Day; Effective To Settlement Day; Notification Amendment Type; Notification Amendment Type Effective From Date. Note that the Effective From Settlement Day and Notification Amendment Type Effective From Date shall be set by the ECVAA to be either the first calendar day after the day of receipt of the application, or the requested Effective From date, whichever is the later. Furthermore, it is this value of Effective From Settlement Day that shall be reported in ECVAA-I007 in point 3 above.
5: The ECVAA shall determine whether an ECVNAA request matches a previously recorded authorisation where the Effective From Settlement Day / Effective To Settlement Day range overlaps an existing ECVNAA and that it has the same values for: ECVNA identifier(s); BSC Parties; Production/consumption flags for each BSC Party A previously recorded ECVNAA is deemed to be effective on a given day if the Effective From Settlement Day / Effective To Settlement Day range includes that day. Any previously recorded ECVNAA’s which are matched and are not effective on the day of receipt will be deleted. An ECVAA-I007 report generated manually for each ECVNAA deleted in this way. If a recorded ECVNAA is matched and is effective on the day of receipt, then it will be terminated at (have its Effective To Date set to) the day before the Effective From Date of the received ECVNAA request. An ECVAA-I007 report generated automatically for each ECVNAA terminated in this way. In this case, the existing ECVNAA key will continue to be valid unless a new key is specifically requested. The received authorisation will be recorded by the ECVAA as described in point 4. The new ECVNAA details and new ECVNAA key(s) will be reported to the participants as described in point 3.
ECVNAA Termination Requests:
6: The ECVAA shall validate the received ECVNAA Termination requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: ECVNAA identifier; Identifiers of the two BSC Parties and ECVNA(s). b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.; c. the termination request is submitted by either of the two BSC Parties or an ECVNA for the relevant ECVNAA, as identified by the ECVNAA ID.
7: The ECVAA shall reject any request to terminate an ECVNAA that fails the validation described in point 6 above and notify the relevant BSC Party or ECVNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected termination of ECVNAAs as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
8: The ECVAA shall notify both BSC Parties and the relevant ECVNA(s) of any terminations of ECVNAA that pass validation. If the request is processed before the Effective From date of the recorded ECVNAA, then the termination will be reported manually (ECVAA-I007; deletion). In all other cases, the ECVAA shall report confirmed terminations of ECVNAA as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
9: The ECVAA shall update its records accordingly for each valid ECVNAA termination; the ECVNAA Effective To date shall be set to the current date, and the ECVNAA Key shall be deleted. The termination of an ECVNAA will not delete any Energy Contract Volume Notification already lodged under that ECVNAA, but will prevent any further Energy Contract Volume Notifications under that ECVNAA.
ECVNAA Key Change Requests:
10: The ECVAA shall validate the received ECVNAA Key change requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: ECVNAA identifier; Identifiers of the two BSC Parties and the ECVNA(s). b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.; c. the ECVNA requesting the ECVNAA Key change is an ECVNA to the relevant ECVNAA, as identified by the ECVNAA ID.
11: The ECVAA shall reject any ECVNAA Key change request that fails the validation described in point 9 above and notify the relevant ECVNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected ECVNAA Key change requests as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
12: The ECVAA shall issue a new unique ECVNAA Key for each valid ECVNAA Key change request. The ECVAA shall notify the relevant ECVNA of the new ECVNAA Key and the date/time that the new ECVNAA Key is effective. The ECVAA shall report new ECVNAA Keys as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback. Only the ECVNA requesting a key change will be issued with a new key. Where there is a second ECVNA, then the other ECVNA’s key will remain unchanged.
13: The ECVAA shall update its records accordingly for each valid ECVNAA Key change.
ECVNAA reporting option Change Requests:
14: The ECVAA shall validate the received ECVNAA reporting option change requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: ECVNAA identifier; Identifiers of the two BSC Parties and the ECVNA(s). b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.; c. the BSC Party or the ECVNA requesting the ECVNAA reporting option change is one of the BSC Parties or ECVNAs to the relevant ECVNAA, as identified by the ECVNAA ID. d. Reporting Option Change Requests will not be accepted before the P98 BSC Implementation Date.
15: The ECVAA shall update its records accordingly for each valid ECVNAA reporting option change request. Any new reporting options will have immediate effect. Note: The reporting option will indicate one of the following: No report; the requesting organisation does not wish to receive any ECVAA-I009 (RFRs) or ECVAA-I028 (AFRs) reports resulting from the specified ECVNAA. Feedback; the requesting organisation wishes to receive ECVAA-I009 and ECVAA-I028 reports for this ECVNAA, but that these reports should contain only feedback on ECVNs submitted by the requesting organisation. Matching; the requesting organisation wishes to receive ECVAA-I009 and full ECVAA-I028 reports for this ECVNAA. The ECVAA-I028 reports will contain feedback on submitted ECVNs and the current positions held on behalf of both ECVNAs (if applicable) and the matched position. Details of how the reporting options are use are given in ECVAA-I028. The ECVAA shall report new ECVNAA reporting options as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.
Non Functional Requirement:
The ECVAA Service shall process ECVNAA requests within 1 day of receipt. For the avoidance of doubt, the time of receipt of an ECVNAA request is the time of receipt of the last matching request to be received. The ECVAA shall process ECVNAA termination requests within 1 hour of receipt when received between 8:00am and 5:00pm on Working Days (Monday-Friday) and 8:00am to 11:00am on all other days. ECVNAA termination requests received outside these working hours will be processed immediately at the start of the next Working Day.
Interfaces:
Related interface requirements: ECVAA-I002: Receive Energy Contract Volume Notification Agent Authorisation Data ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback

Requirement ID:

ECVAA-F003

Status:

Mandatory

Title:

Process Energy Contract Volume Notification Agent Authorisation (ECVNAA)

BSC Reference:

ECVAA SD: 6, B3-4, ECVAA BPM: 3.1, CR008, Clarification: ‘ECVAA Authorisation Keys’, CR028, CP547, CP571, Variation 49, CP888, P98, CP1009, P309

Man/auto:

Manual

Frequency:

Daily

Volumes:

Low

Functional Requirement:

The ECVAA shall receive Energy Contract Volume Notification Agent Authorisation data from the BSC Parties and ECVNAs as described by requirement ECVAA-I002: Receive Energy Contract Volume Notification Agent Authorisation Data. The Energy Contract Volume Notification Agent Authorisation data shall comprise:

ECVNAA Requests

ECVNAA Termination Requests

ECVNAA Key Change Requests

ECVNAA reporting option Change Requests

ECVNAA Changes

The ECVAA should process ECVNAA Request Data that include the NETSO as one of the counterparties in an identical manner as for any other party. This will require the ECVAA to treat the NETSO as if it has Energy Accounts.

The ECVAA shall process ECVNAA data as follows.

ECVNAA Requests:

1: The ECVAA shall validate the received ECVNAA requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

Name and identifier of the ECVNA(s);
Names and identifiers of the two BSC Parties;
Production/consumption flags of the two BSC Parties’ Energy Account;
Effective From Settlement Day;
Effective To Settlement Day (An ECVNAA may be open-ended, i.e. the Effective To Settlement Day is optional. An ECVNAA relates to a complete Settlement Day, i.e. no time element to the effective date range);
Reporting options for each BSC Party and ECVNA (for requests with Effective From Settlement Day after the P98 BSC Implementation Date);
Notification Amendment Type set to ‘Additional’, ‘Replacement’ or ‘Both’; and Notification Amendment Type Effective From Date;

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with registration data received from the CRA, production/consumption flags are valid, etc.;

c. the effective from Settlement Day must not be before the BSC start date;

d. the effective from Settlement Day must not be more than thirty calendar days after the day of receipt of the application;

e. the same ECVNAA request has been received from both parties and the ECVNA(s), each correctly authorised. An unmatched ECVNAA request will be rejected after five working days;

f. the effective from Settlement Day must not be before the P98 BSC Implementation Date where two different ECVNAs are appointed;

g. the Notification Amendment Type Effective From Date must be the same as the Effective From Settlement Day (for the overall Authorisation) for new or successor Authorisation requests only.

There will be no restrictions on the number of ECVNAAs that can be accepted per counter-party/Energy Account pair, i.e. a given BSC Party can appoint multiple ECVNAs to notify for the same counter-party/Energy Account pair on a given day.

An ECVNAA can be between any combination of the BSC Parties’ Energy Accounts, including the two accounts of a single party, i.e. an ECVNAA can be between:

the production account of both party 1 and 2;
the consumption account of both party 1 and 2;
the production account of party 1 and the consumption account of party 2;
the consumption account of party 1 and the production account of party 2;
the production and consumption account of a single party.

An ECVNAA authorises an ECVNA(s) to submit ECVNs on behalf of each of the two BSC Parties for the period of the authorisation. The ECVNs are not however ‘owned’ by the ECVNA(s) but by the BSC Parties. Therefore ECVNs submitted by one ECVNA may be subsequently amended by another authorised ECVNA.

Since both BSC Parties appoint the same ECVNA, only one copy of the Authorisation Request will be received from that ECVNA.

ECVAA shall allow BSC Parties to change an existing Authorisation by raising an Authorisation Change. This allows them to modify the terms of an existing Authorisation, e.g. the Notification Amendment Type, without terminating the existing Authorisation and requiring a new Authorisation. It also means that any existing ECVNs accepted under the earlier version of the Authorisation are unaffected by the change(s).

2: The ECVAA shall reject any ECVNAA request that fails the validation described in point 1 above and notify the relevant BSC Parties and the relevant ECVNA(s) of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected ECVNAAs as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

3: The ECVAA shall notify the relevant BSC Parties and the relevant ECVNA(s) of the acceptance of each valid ECVNAA request. The ECVAA shall issue a unique ECVNAA identifier and ECVNAA Key for each valid ECVNAA request. The ECVAA shall notify the identifier to both the BSC Parties and the ECVNA(s). The ECVAA shall notify the Key to the ECVNA only. Each ECVNA will be issued with their own ECVNAA Key.

The ECVAA shall report confirmed ECVNAAs (including identifier and key as appropriate) as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

4: The ECVAA shall input each validated ECVNAA into its systems. The data to be recorded for each valid ECVNAA shall include the following:

ECVNAA identifier;
ECVNAA Key (or data allowing the ECVNAA Key to be checked);
Name and identifier of the ECVNA(s);
Names and identifiers of the two BSC Parties;
Production/consumption flags of the two BSC Parties’ Energy Account;
Notification Amendment Type
Effective From Settlement Day;
Effective To Settlement Day;
Notification Amendment Type;
Notification Amendment Type Effective From Date.

Note that the Effective From Settlement Day and Notification Amendment Type Effective From Date shall be set by the ECVAA to be either the first calendar day after the day of receipt of the application, or the requested Effective From date, whichever is the later. Furthermore, it is this value of Effective From Settlement Day that shall be reported in ECVAA-I007 in point 3 above.

5: The ECVAA shall determine whether an ECVNAA request matches a previously recorded authorisation where the Effective From Settlement Day / Effective To Settlement Day range overlaps an existing ECVNAA and that it has the same values for:

ECVNA identifier(s);
BSC Parties;
Production/consumption flags for each BSC Party

A previously recorded ECVNAA is deemed to be effective on a given day if the Effective From Settlement Day / Effective To Settlement Day range includes that day.

Any previously recorded ECVNAA’s which are matched and are not effective on the day of receipt will be deleted. An ECVAA-I007 report generated manually for each ECVNAA deleted in this way.

If a recorded ECVNAA is matched and is effective on the day of receipt, then it will be terminated at (have its Effective To Date set to) the day before the Effective From Date of the received ECVNAA request. An ECVAA-I007 report generated automatically for each ECVNAA terminated in this way. In this case, the existing ECVNAA key will continue to be valid unless a new key is specifically requested.

The received authorisation will be recorded by the ECVAA as described in point 4.

The new ECVNAA details and new ECVNAA key(s) will be reported to the participants as described in point 3.

ECVNAA Termination Requests:

6: The ECVAA shall validate the received ECVNAA Termination requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

ECVNAA identifier;
Identifiers of the two BSC Parties and ECVNA(s).

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.;

c. the termination request is submitted by either of the two BSC Parties or an ECVNA for the relevant ECVNAA, as identified by the ECVNAA ID.

7: The ECVAA shall reject any request to terminate an ECVNAA that fails the validation described in point 6 above and notify the relevant BSC Party or ECVNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected termination of ECVNAAs as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

8: The ECVAA shall notify both BSC Parties and the relevant ECVNA(s) of any terminations of ECVNAA that pass validation.

If the request is processed before the Effective From date of the recorded ECVNAA, then the termination will be reported manually (ECVAA-I007; deletion).

In all other cases, the ECVAA shall report confirmed terminations of ECVNAA as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

9: The ECVAA shall update its records accordingly for each valid ECVNAA termination; the ECVNAA Effective To date shall be set to the current date, and the ECVNAA Key shall be deleted. The termination of an ECVNAA will not delete any Energy Contract Volume Notification already lodged under that ECVNAA, but will prevent any further Energy Contract Volume Notifications under that ECVNAA.

ECVNAA Key Change Requests:

10: The ECVAA shall validate the received ECVNAA Key change requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

ECVNAA identifier;
Identifiers of the two BSC Parties and the ECVNA(s).

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.;

c. the ECVNA requesting the ECVNAA Key change is an ECVNA to the relevant ECVNAA, as identified by the ECVNAA ID.

11: The ECVAA shall reject any ECVNAA Key change request that fails the validation described in point 9 above and notify the relevant ECVNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected ECVNAA Key change requests as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

12: The ECVAA shall issue a new unique ECVNAA Key for each valid ECVNAA Key change request. The ECVAA shall notify the relevant ECVNA of the new ECVNAA Key and the date/time that the new ECVNAA Key is effective.

The ECVAA shall report new ECVNAA Keys as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

Only the ECVNA requesting a key change will be issued with a new key. Where there is a second ECVNA, then the other ECVNA’s key will remain unchanged.

13: The ECVAA shall update its records accordingly for each valid ECVNAA Key change.

ECVNAA reporting option Change Requests:

14: The ECVAA shall validate the received ECVNAA reporting option change requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

ECVNAA identifier;
Identifiers of the two BSC Parties and the ECVNA(s).

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the ECVNAA already approved by the ECVAA, etc.;

c. the BSC Party or the ECVNA requesting the ECVNAA reporting option change is one of the BSC Parties or ECVNAs to the relevant ECVNAA, as identified by the ECVNAA ID.

d. Reporting Option Change Requests will not be accepted before the P98 BSC Implementation Date.

15: The ECVAA shall update its records accordingly for each valid ECVNAA reporting option change request.

Any new reporting options will have immediate effect.

Note: The reporting option will indicate one of the following:

No report; the requesting organisation does not wish to receive any ECVAA-I009 (RFRs) or ECVAA-I028 (AFRs) reports resulting from the specified ECVNAA.
Feedback; the requesting organisation wishes to receive ECVAA-I009 and ECVAA-I028 reports for this ECVNAA, but that these reports should contain only feedback on ECVNs submitted by the requesting organisation.
Matching; the requesting organisation wishes to receive ECVAA-I009 and full ECVAA-I028 reports for this ECVNAA. The ECVAA-I028 reports will contain feedback on submitted ECVNs and the current positions held on behalf of both ECVNAs (if applicable) and the matched position.

Details of how the reporting options are use are given in ECVAA-I028.

The ECVAA shall report new ECVNAA reporting options as described by requirement ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback.

Non Functional Requirement:

The ECVAA Service shall process ECVNAA requests within 1 day of receipt. For the avoidance of doubt, the time of receipt of an ECVNAA request is the time of receipt of the last matching request to be received.

The ECVAA shall process ECVNAA termination requests within 1 hour of receipt when received between 8:00am and 5:00pm on Working Days (Monday-Friday) and 8:00am to 11:00am on all other days. ECVNAA termination requests received outside these working hours will be processed immediately at the start of the next Working Day.

Interfaces:

Related interface requirements:

ECVAA-I002: Receive Energy Contract Volume Notification Agent Authorisation Data

ECVAA-I007: Issue Energy Contract Volume Notification Agent Authorisation Feedback

5.4 ECVAA-F004: Process MVRNAA

Requirement ID: ECVAA-F004	Status: Mandatory	Title: Process Metered Volume Reallocation Notification Agent Authorisation (MVRNAA)	BSC Reference: ECVAA SD: 7, B5-7 ECVAA BPM: 3.2 CR005 Clarification: ‘ECVAA Authorisation Keys’, CR028, CP547, CP571, Variation 49, CP888, P98, CP1009
Man/auto: Manual	Frequency: Daily	Volumes: Low
Functional Requirement: The ECVAA shall receive Metered Volume Reallocation Notification Agent Authorisation (MVRNAA) data from the BSC Parties and MVRNAs as described by requirement ECVAA-I003: Receive Metered Volume Reallocation Notification Agent Authorisation Data. The Metered Volume Reallocation Notification Agent Authorisation shall comprise: MVRNAA Requests MVRNAA Termination Requests MVRNAA Key Change Requests MVRNAA reporting option change requests The ECVAA should process MVRNAA Request Data that include the NETSO as one of the counterparties in an identical manner as for any other party, the NETSO may be a subsidiary party to a MVRNAA. This will require the ECVAA to treat the NETSO as if it has Energy Accounts.
The ECVAA shall process MVRNAA data as follows.
MVRNAA Requests:
1: The ECVAA shall validate the received MVRNAA requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: Name and identifier of the MVRNA(s); BM Unit identifier; Names and identifiers of the BM Unit Lead and Subsidiary Party; Production/consumption flags of the BM Unit Lead and Subsidiary Party Energy Account; Effective From Settlement Day; Effective To Settlement Day. (A MVRNAA may be open-ended, i.e. the Effective To Settlement Day is optional. A MVRNAA relates to a complete Settlement Day, i.e. no time element to the effective date range.) Reporting options for each BSC Party and MVRNA. (for requests with Effective From Settlement Day after the P98 BSC Implementation Date) b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with registration data received from the CRA, production/consumption flags are valid, etc.; c. the Energy Account production/consumption flag must be consistent with the BM Unit type, i.e. if the BM Unit type is production the Energy Accounts of the Lead and Subsidiary Party must be production, if the BM Unit type is consumption the Energy Accounts of the Lead and Subsidiary Party must be consumption; d. the effective from Settlement Day must not be before the BSC start date; e. the effective from Settlement Day must not be more than thirty calendar days after the day of receipt of the application; f. the same MVRNAA request has been received from both parties and the MVRNA(s), each correctly authorised. An unmatched MVRNAA request will be rejected after five working days; g. the effective from Settlement Day must not be before the P98 BSC Implementation Date where two different MVRNAs are appointed. h. the BM Unit to which it relates is not a Secondary BM Unit. There will be no restrictions on the number of MVRNAAs that can be accepted per Lead-Subsidiary Party/Energy Account pair, i.e. a given BSC Party can appoint multiple MVRNAs to notify for the same Lead-Subsidiary Party/Energy Account pair on a given day. An MVRNAA authorises a MVRNA(s) to submit MVRNs on behalf of either the Lead or the Subsidiary Party (or both) for the period of the authorisation. The MVRNs are not however ‘owned’ by the MVRNA but by the Lead and Subsidiary Party. Therefore MVRNs submitted by one MVRNA may be subsequently amended by another authorised MVRNA. Only one copy of the Authorisation Request will be received from the MVRNA.
2: The ECVAA shall reject any MVRNAA request that fails the validation described in point 1 above and notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA(s) of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
3: The ECVAA shall notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA of the acceptance of each valid MVRNAA request. The ECVAA shall issue a unique MVRNAA identifier and MVRNAA Key for each valid MVRNAA request. The ECVAA shall notify the identifier to the Lead and Subsidiary Party and the MVRNA(s). The ECVAA shall notify the Key to the MVRNA only. Each MVRNA will be issued with their own MVRNAA Key. The ECVAA shall report confirmed MVRNAAs (including identifier and key) as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
4: The ECVAA shall input each validated MVRNAA into its systems. The data to be recorded for each valid MVRNAA shall include the following: MVRNAA identifier; MVRNAA Key (or data allowing the MVRNAA Key to be checked); Name and identifier of the MVRNA(s); BM Unit identifier; Names and identifiers of the BM Unit Lead and Subsidiary Party; Production/consumption flags of the BM Unit Lead and Subsidiary Party Energy Account; Effective From Settlement Day; Effective To Settlement Day. Note that the Effective From Settlement Day shall be set by the ECVAA to be either the first calendar day after the day of receipt of the application, or the requested Effective From date, whichever is the later. Furthermore, it is this value of Effective From Settlement Day that shall be reported in ECVAA-I008 in point 3 above.
5: The ECVAA shall determine whether an MVRNAA request matches a previously recorded authorisation where the Effective From Settlement Day / Effective To Settlement Day range overlaps an existing MVRNAA and that it that has the same values for: MVRNA identifier(s); BM Unit identifier; BM Unit Lead and Subsidiary Parties; Production/consumption flags for BM Unit Lead and Subsidiary Party A previously recorded MVRNAA is deemed to be effective on a given day if the Effective From Settlement Day / Effective To Settlement Day range includes that day. Any previously recorded MVRNAA’s which are matched and are not effective on the day of receipt will be deleted. An ECVAA-I008 report generated manually for each MVRNAA deleted in this way. If a recorded MVRNAA is matched and is effective on the day of receipt, then it will be terminated at (have its Effective To Date set to) the day before the Effective From Date of the received MVRNAA request. An ECVAA-I008 report generated automatically for each MVRNAA terminated in this way. In this case, the existing MVRNAA key will continue to be valid unless a new key is specifically requested. The received authorisation will be recorded by the ECVAA as described in point 4. The new MVRNAA details and new MVRNAA keys will be reported to the participants as described in point 3.
MVRNAA Termination Requests:
6: The ECVAA shall validate the received requests to terminate MVRNAAs. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: MVRNAA identifier; BM Unit identifier; Identifiers of the Lead Party, Subsidiary Party and MVRNA(s) whether there is a corresponding VNNR. b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.; c. the termination is submitted by either a BM Unit Lead Party, a BM Unit Subsidiary Party or a MVRNA for the relevant MVRNAA, as identified by the MVRNAA ID.
7: The ECVAA shall reject any request to terminate a MVRNAA that fails the validation described in point 6 above and notify the relevant BM Unit Lead Party, Subsidiary Party or MVRNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected termination of MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
8: The ECVAA shall notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA(s) of any terminations to MVRNAAs that pass validation. If the Termination Effective Date is before the Effective From date of the recorded MVRNAA, then the termination will be reported manually (ECVAA-I008; deletion). In all other cases, the ECVAA shall report confirmed termination of MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
9: The ECVAA shall update its records accordingly for each valid MVRNAA termination; the MVRNAA Effective To date shall be set to the current date, and the MVRNAA Key shall be deleted. The termination of a MVRNAA will not delete any Metered Volume Reallocation Notifications already lodged under that MVRNAA, but will prevent any further Metered Volume Reallocation Notifications under that MVRNAA.
MVRNAA Key Change Requests:
10: The ECVAA shall validate the received MVRNAA Key change requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: MVRNAA identifier; BM Unit identifier; Identifiers of the Lead Party, Subsidiary Party and the MVRNA(s). b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.; c. the MVRNA requesting the MVRNAA Key change is a MVRNA to the relevant MVRNAA, as identified by the MVRNAA ID.
11: The ECVAA shall reject any MVRNAA Key change request that fails the validation described in point 9 above and notify the relevant MVRNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected MVRNAA Key change requests as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
12: The ECVAA shall issue a new unique MVRNAA Key for each valid MVRNAA Key change request. The ECVAA shall notify the relevant MVRNA of the new MVRNAA Key and the date/time that the new MVRNAA Key is effective. The ECVAA shall report new MVRNAA Keys as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback. Only the MVRNA requesting a key change will be issued with a new key. Where there is a second MVRNA, then the other MVRNA's key will remain unchanged.
13: The ECVAA shall update its records accordingly for each valid MVRNAA Key change.
MVRNAA reporting option Change Requests:
14: The ECVAA shall validate the received MVRNAA reporting option change requests. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: MVRNAA identifier; BM Unit identifier; Identifiers of the Lead Party, Subsidiary Party and the MVRNA(s). b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.; c. the BSC Party or the MVRNA requesting the MVRNAA reporting option change is one of the BSC Parties or MVRNAs to the relevant MVRNAA, as identified by the MVRNAA ID. d. Reporting Option Change Requests will not be accepted before the P98 BSC Implementation Date.
15: The ECVAA shall update its records accordingly for each valid MVRNAA reporting option change request. Any new reporting options will have immediate effect. Note: The reporting option will indicate one of the following: No report; the requesting organisation does not wish to receive any ECVAA-I010 (RFRs) or ECVAA-I029 (AFRs) reports resulting from the specified MVRNAA. Feedback; the requesting organisation wishes to receive ECVAA-I010 and ECVAA-I029 reports for this MVRNAA, but that these reports should contain only feedback on MVRNs submitted by the requesting organisation. Matching; the requesting organisation wishes to receive ECVAA-I010 and full ECVAA-I029 reports for this MVRNAA. The ECVAA-I029 reports will contain feedback on submitted MVRNs and the current positions held on behalf of both MVRNAs (if applicable) and the matched position. The ECVAA shall report new MVRNAA reporting options as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.
Non Functional Requirement:
The ECVAA Service shall process MVRNAA requests within 1 day of receipt. For the avoidance of doubt, the time of receipt of an MVRNAA request is the time of receipt of the last matching request to be received. The ECVAA shall process MVRNAA termination requests within 1 hour of receipt when received between 8:00am and 5:00pm on Working Days (Monday-Friday) and 8:00am to 11:00am on all other days. MVRNAA termination requests received outside these working hours will be processed immediately at the start of the next Working Day.
Interfaces:
Related interface requirements: ECVAA-I003: Receive Metered Volume Reallocation Notification Agent Authorisation Data ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback

Requirement ID:

ECVAA-F004

Status:

Mandatory

Title:

Process Metered Volume Reallocation Notification Agent Authorisation (MVRNAA)

BSC Reference:

ECVAA SD: 7, B5-7

ECVAA BPM: 3.2

CR005

Clarification: ‘ECVAA Authorisation Keys’, CR028, CP547, CP571, Variation 49, CP888, P98, CP1009

Man/auto:

Manual

Frequency:

Daily

Volumes:

Low

Functional Requirement:

The ECVAA shall receive Metered Volume Reallocation Notification Agent Authorisation (MVRNAA) data from the BSC Parties and MVRNAs as described by requirement ECVAA-I003: Receive Metered Volume Reallocation Notification Agent Authorisation Data. The Metered Volume Reallocation Notification Agent Authorisation shall comprise:

MVRNAA Requests

MVRNAA Termination Requests

MVRNAA Key Change Requests

MVRNAA reporting option change requests

The ECVAA should process MVRNAA Request Data that include the NETSO as one of the counterparties in an identical manner as for any other party, the NETSO may be a subsidiary party to a MVRNAA. This will require the ECVAA to treat the NETSO as if it has Energy Accounts.

The ECVAA shall process MVRNAA data as follows.

MVRNAA Requests:

1: The ECVAA shall validate the received MVRNAA requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

Name and identifier of the MVRNA(s);
BM Unit identifier;
Names and identifiers of the BM Unit Lead and Subsidiary Party;
Production/consumption flags of the BM Unit Lead and Subsidiary Party Energy Account;
Effective From Settlement Day;
Effective To Settlement Day. (A MVRNAA may be open-ended, i.e. the Effective To Settlement Day is optional. A MVRNAA relates to a complete Settlement Day, i.e. no time element to the effective date range.)
Reporting options for each BSC Party and MVRNA. (for requests with Effective From Settlement Day after the P98 BSC Implementation Date)

c. the Energy Account production/consumption flag must be consistent with the BM Unit type, i.e. if the BM Unit type is production the Energy Accounts of the Lead and Subsidiary Party must be production, if the BM Unit type is consumption the Energy Accounts of the Lead and Subsidiary Party must be consumption;

d. the effective from Settlement Day must not be before the BSC start date;

e. the effective from Settlement Day must not be more than thirty calendar days after the day of receipt of the application;

f. the same MVRNAA request has been received from both parties and the MVRNA(s), each correctly authorised. An unmatched MVRNAA request will be rejected after five working days;

g. the effective from Settlement Day must not be before the P98 BSC Implementation Date where two different MVRNAs are appointed.

h. the BM Unit to which it relates is not a Secondary BM Unit.

There will be no restrictions on the number of MVRNAAs that can be accepted per Lead-Subsidiary Party/Energy Account pair, i.e. a given BSC Party can appoint multiple MVRNAs to notify for the same Lead-Subsidiary Party/Energy Account pair on a given day.

An MVRNAA authorises a MVRNA(s) to submit MVRNs on behalf of either the Lead or the Subsidiary Party (or both) for the period of the authorisation. The MVRNs are not however ‘owned’ by the MVRNA but by the Lead and Subsidiary Party. Therefore MVRNs submitted by one MVRNA may be subsequently amended by another authorised MVRNA.

Only one copy of the Authorisation Request will be received from the MVRNA.

2: The ECVAA shall reject any MVRNAA request that fails the validation described in point 1 above and notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA(s) of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

3: The ECVAA shall notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA of the acceptance of each valid MVRNAA request. The ECVAA shall issue a unique MVRNAA identifier and MVRNAA Key for each valid MVRNAA request. The ECVAA shall notify the identifier to the Lead and Subsidiary Party and the MVRNA(s). The ECVAA shall notify the Key to the MVRNA only. Each MVRNA will be issued with their own MVRNAA Key.

The ECVAA shall report confirmed MVRNAAs (including identifier and key) as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

4: The ECVAA shall input each validated MVRNAA into its systems. The data to be recorded for each valid MVRNAA shall include the following:

MVRNAA identifier;
MVRNAA Key (or data allowing the MVRNAA Key to be checked);
Name and identifier of the MVRNA(s);
BM Unit identifier;
Names and identifiers of the BM Unit Lead and Subsidiary Party;
Production/consumption flags of the BM Unit Lead and Subsidiary Party Energy Account;
Effective From Settlement Day;
Effective To Settlement Day.

Note that the Effective From Settlement Day shall be set by the ECVAA to be either the first calendar day after the day of receipt of the application, or the requested Effective From date, whichever is the later. Furthermore, it is this value of Effective From Settlement Day that shall be reported in ECVAA-I008 in point 3 above.

5: The ECVAA shall determine whether an MVRNAA request matches a previously recorded authorisation where the Effective From Settlement Day / Effective To Settlement Day range overlaps an existing MVRNAA and that it that has the same values for:

MVRNA identifier(s);
BM Unit identifier;
BM Unit Lead and Subsidiary Parties;
Production/consumption flags for BM Unit Lead and Subsidiary Party

A previously recorded MVRNAA is deemed to be effective on a given day if the Effective From Settlement Day / Effective To Settlement Day range includes that day.

Any previously recorded MVRNAA’s which are matched and are not effective on the day of receipt will be deleted. An ECVAA-I008 report generated manually for each MVRNAA deleted in this way.

If a recorded MVRNAA is matched and is effective on the day of receipt, then it will be terminated at (have its Effective To Date set to) the day before the Effective From Date of the received MVRNAA request. An ECVAA-I008 report generated automatically for each MVRNAA terminated in this way. In this case, the existing MVRNAA key will continue to be valid unless a new key is specifically requested.

The received authorisation will be recorded by the ECVAA as described in point 4.

The new MVRNAA details and new MVRNAA keys will be reported to the participants as described in point 3.

MVRNAA Termination Requests:

6: The ECVAA shall validate the received requests to terminate MVRNAAs. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

MVRNAA identifier;
BM Unit identifier;
Identifiers of the Lead Party, Subsidiary Party and MVRNA(s)
whether there is a corresponding VNNR.

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.;

c. the termination is submitted by either a BM Unit Lead Party, a BM Unit Subsidiary Party or a MVRNA for the relevant MVRNAA, as identified by the MVRNAA ID.

7: The ECVAA shall reject any request to terminate a MVRNAA that fails the validation described in point 6 above and notify the relevant BM Unit Lead Party, Subsidiary Party or MVRNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected termination of MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

8: The ECVAA shall notify the relevant BM Unit Lead Party, BM Unit Subsidiary Party and the relevant MVRNA(s) of any terminations to MVRNAAs that pass validation.

If the Termination Effective Date is before the Effective From date of the recorded MVRNAA, then the termination will be reported manually (ECVAA-I008; deletion).

In all other cases, the ECVAA shall report confirmed termination of MVRNAAs as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

9: The ECVAA shall update its records accordingly for each valid MVRNAA termination; the MVRNAA Effective To date shall be set to the current date, and the MVRNAA Key shall be deleted. The termination of a MVRNAA will not delete any Metered Volume Reallocation Notifications already lodged under that MVRNAA, but will prevent any further Metered Volume Reallocation Notifications under that MVRNAA.

MVRNAA Key Change Requests:

10: The ECVAA shall validate the received MVRNAA Key change requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

MVRNAA identifier;
BM Unit identifier;
Identifiers of the Lead Party, Subsidiary Party and the MVRNA(s).

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.;

c. the MVRNA requesting the MVRNAA Key change is a MVRNA to the relevant MVRNAA, as identified by the MVRNAA ID.

11: The ECVAA shall reject any MVRNAA Key change request that fails the validation described in point 9 above and notify the relevant MVRNA of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected MVRNAA Key change requests as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

12: The ECVAA shall issue a new unique MVRNAA Key for each valid MVRNAA Key change request. The ECVAA shall notify the relevant MVRNA of the new MVRNAA Key and the date/time that the new MVRNAA Key is effective.

The ECVAA shall report new MVRNAA Keys as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

Only the MVRNA requesting a key change will be issued with a new key. Where there is a second MVRNA, then the other MVRNA's key will remain unchanged.

13: The ECVAA shall update its records accordingly for each valid MVRNAA Key change.

MVRNAA reporting option Change Requests:

14: The ECVAA shall validate the received MVRNAA reporting option change requests. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

MVRNAA identifier;
BM Unit identifier;
Identifiers of the Lead Party, Subsidiary Party and the MVRNA(s).

b. the validity and consistency of data submitted, i.e. data is of the correct type and format, is consistent with the MVRNAA already approved by the ECVAA, etc.;

c. the BSC Party or the MVRNA requesting the MVRNAA reporting option change is one of the BSC Parties or MVRNAs to the relevant MVRNAA, as identified by the MVRNAA ID.

d. Reporting Option Change Requests will not be accepted before the P98 BSC Implementation Date.

15: The ECVAA shall update its records accordingly for each valid MVRNAA reporting option change request.

Any new reporting options will have immediate effect.

Note: The reporting option will indicate one of the following:

No report; the requesting organisation does not wish to receive any ECVAA-I010 (RFRs) or ECVAA-I029 (AFRs) reports resulting from the specified MVRNAA.
Feedback; the requesting organisation wishes to receive ECVAA-I010 and ECVAA-I029 reports for this MVRNAA, but that these reports should contain only feedback on MVRNs submitted by the requesting organisation.
Matching; the requesting organisation wishes to receive ECVAA-I010 and full ECVAA-I029 reports for this MVRNAA. The ECVAA-I029 reports will contain feedback on submitted MVRNs and the current positions held on behalf of both MVRNAs (if applicable) and the matched position.

The ECVAA shall report new MVRNAA reporting options as described by requirement ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback.

Non Functional Requirement:

The ECVAA Service shall process MVRNAA requests within 1 day of receipt. For the avoidance of doubt, the time of receipt of an MVRNAA request is the time of receipt of the last matching request to be received.

The ECVAA shall process MVRNAA termination requests within 1 hour of receipt when received between 8:00am and 5:00pm on Working Days (Monday-Friday) and 8:00am to 11:00am on all other days. MVRNAA termination requests received outside these working hours will be processed immediately at the start of the next Working Day.

Interfaces:

Related interface requirements:

ECVAA-I003: Receive Metered Volume Reallocation Notification Agent Authorisation Data

ECVAA-I008: Issue Metered Volume Reallocation Notification Agent Authorisation Feedback

5.5 ECVAA-F005: Process Energy Contract Volume Notifications

Requirement ID: ECVAA-F005	Status: Mandatory	Title: Process Energy Contract Volume Notifications	BSC Reference: ECVAA SD: 8.1-8.3, B8 ECVAA BPM: 3.3 CR008, CR012, CR028, CP539, P4, CP725, CP911, CP739, P98, Variation 58, P309
Man/auto: Automatic	Frequency: Continuous	Volumes: High
Functional Requirement:
The ECVAA shall receive Energy Contract Volume Notifications from ECVNAs as described by requirement ECVAA-I004: Receive Energy Contract Volume Notifications. The Energy Contract Volume Notifications shall comprise: Energy Contract Volume Notifications For Notifications submitted under Authorisations, the positions held on behalf of both Party 1 and Party 2 will be updated. Once the data has been processed, amended period data is passed to ECVAA-F014 for comparison with the other party’s latest submission. Both positions are always the same, so matching is automatic. The NETSO is permitted to notify Energy Contract Volumes just like any other counter-party. The ECVAA will be required to treat the NETSO as if it has Energy Accounts and it shall pass on Energy Contract Volumes in respect of the NETSO onto the SAA as for any other Party. Virtual Lead Parties are not allowed to notify Energy Contract Volumes.
1: The ECVAA shall validate the received Energy Contract Volume Notifications. The validation checks shall include the following: a. checks to ensure that the following data have been submitted: ECVNA identifier ECVNAA identifier; ECVNAA Key; ECVN identifier, comprising originator’s ECVNAA identifier plus a unique Reference Code; Effective From Date; Effective To Date; (An ECVN may be evergreen, i.e. the Effective To Date is null, may be for a single day, i.e. the Effective To Date equals the Effective From Date, or may be for a specified date range, i.e. the Effective To Date is after the Effective From Date ) Energy Contract Volume Data for Settlement Periods relevant to the ECVN. This comprises the Settlement Period identifier, a number in the range 1-48 (or 1-46/50 for a specific clock change day notification), along with the corresponding ECV for that Settlement Period in MWh. Omitted Data: No Change (optional); Submission Option indicating how volume data for Settlement Periods not specified in the Notification should be interpreted¹. b. consistency of ECVNAA identifier, ECVNAA Key, ECVNA identifier and BSC Party identifiers; c. validity of the ECVNAA for the Settlement Day on which the Energy Contract Volume Notification is received; d. a check to ensure that the originator’s ECVNAA identifier component of the ECVN identifier is either: the ECVNAA identifier of the ECVNA submitting the Energy Contract Volume Notification; or an ECVNAA identifier for an authorisation that has now expired but was for the same pair of trading Party Energy Accounts (specified in the same order, i.e. Party 1 and Party 2) as the authorisation of the ECVNA submitting the Energy Contract Volume Notification. Where a Notification is submitted under a new ECVNAA in this way, all validation of the received Notification must be successful with regard to the new ECVNAA; e. the following range test must be satisfied: –99,999.999 ≤ ECQ_zabj ≤ 99,999.999 ECQ_zabj denotes the 48 (46 or 50 on clock change days) elements of Energy Contract Volume Data in MWh for an Energy Contract Volume Notification involving ECVNA z and Energy Accounts a and b for the BSC Parties, for each Settlement Period j of any Settlement Day covered by the Energy Contract Volume Notification. f. a check to ensure that for each of the BSC Parties to the Energy Contract Volume Notification, i.e. Party 1 and Party 2 if the BSC Party’s current Credit Cover Percentage is greater than 90% of their Credit Limit and their ‘Credit Default Authorisation’ flag set to Yes then no component of the received notification must increase that BSC Party’s Indebtedness. The definition of notification components that increase Indebtedness is given in ECVAA-F007 point 2. g. the Effective To Date must not be on the day of receipt of the Energy Contract Volume Notification if all Settlement Periods for that day have passed the Submission Deadline. h. The Effective To Date must not be before the day of receipt. i. The Effective To Date must not be before the Effective From Date. j. not used k. A check to ensure that where the associated ECVNAA has a Notification Amendment Type of ‘Additional’ or ‘Replacement’, the use of ECVNAA and ECVN identifiers is consistent with the rules in section 2 below for additional and replacement notifications respectively.
2: The ECVAA shall input each validated Energy Contract Volume Notification into its systems. The data to be recorded for each valid Energy Contract Volume Notification shall include the following: ECVNA identifier; ECVNAA identifier; ECVNAA Key; ECVN identifier, comprising originator’s ECVNAA identifier plus a unique Reference Code; Effective From Date; Effective To Date; Energy Contract Volume Data for Settlement Periods relevant to the ECVN. This comprises the Settlement Period number in the range 1-48 (or 1-46/50 on a clock change day) along with the corresponding ECV for that Settlement Period in MWh. For the avoidance of doubt, the following rules will apply to Energy Contract Volume Notifications: ECVNs are used to determine the position submitted on behalf of both counterparties. Note that the matched position is determined separately as defined in ECVAA-F014. Initial Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier not previously notified to the ECVAA for the same combination of BSC Party Energy Accounts but where the ECVN does not overlap with an earlier ECVN (i.e. is not an Additional ECVN). An Initial ECVN is not limited by whether the ECVNAA’s Notification Amendment Type; A Replacement Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier which has previously been notified to the ECVAA for the same combination of BSC Party Energy Accounts and where the second ECVN’s Effective From Date is on or before the Effective To Date of the first ECVN. In this case the second ECVN will be considered a Replacement ECVN and will replace the previous Energy Contract Volume Notification with the same identifier; An Additional Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier not previously notified to the ECVAA for the same combination of BSC Party Energy Accounts and where Settlement Periods that the ECVN affects do overlap with an earlier ECVN’s. In this case the Additional ECVN will add to any previously submitted Energy Contract Volume Notifications for the same combination of BSC Party Energy Accounts between the dates specified; The ECVAA shall only accept Replacement or Additional ECVNs where the corresponding ECVNAA allows it. That is Replacement ECVNs will only be accepted in relation to Authorisations with a Notification Amendment Type in force at the time of the ECVN’s submission that is equal to Both or Replacement, and Additional ECVNs will only be accepted in relation to Authorisations with a Notification Amendment Type in force at the time of the ECVN’s submission that is equal to Both or Additional; For processing purposes, the Current Date is the earliest Settlement Date for which at least one Settlement Period has not passed the Submission Deadline at the time the ECVAA receives the Notification. An Energy Contract Notification will not be applied for any date before the Current Date, so the Applied From Date is either the Effective From Date in the received notification or the Current Date, whichever is the later. An Energy Contract Volume Notification Replacement will replace a previously submitted Energy Contract Volume Notification with the same identifier from the Applied From Date (see above). Note: the previous Energy Contract Volume Notification will be replaced in its entirety from the Applied From Date and earliest Settlement Period for which the Submission Deadline has not passed; In the case of a Replacement ECVN, the previous Energy Contract Volume Notification will be replaced in its entirety from the Applied From Date and earliest Settlement Period for which the Submission Deadline has not passed. Settlement Periods not included in the Energy Contract Volume Notification indicate that there is zero Energy Contract Volume for that period or that previously specified Energy Contract Volume is withdrawn. An Energy Contract Volume Notification with Energy Contract Volume data for no Settlement Periods indicates that the Energy Contract Volume Notification has been withdrawn in its entirety from the Effective From Date specified. As with other amendments, withdrawal of a notification will only be applicable from the Applied From Date, and earliest settlement period for which the Submission Deadline has not passed. The Energy Contract Volume for Settlement Periods that have passed the Submission Deadline at the time of receipt of the Energy Contract Volume Notification will be disregarded and will not be input into the ECVAA system. (Note: the relevant BSC parties and ECVNA will not be notified of Settlement Periods which are disregarded.) The Energy Contract Volumes for Settlement Periods that have not passed the Submission Deadline at the time of receipt of the Energy Contract Volume Notification will be input into the ECVAA system according to the new or amended Notification rules described above. Where an Energy Contract Volume Notification is for a range of days or is evergreen and is applicable from the Current Date, a single day view of the data will be recorded by the ECVAA system for the current date. This single day view will be a composite of previously received volumes, for Settlement Periods for which the Submission Deadline has passed, and the volumes in the notification, for the remaining Settlement Periods. In addition, the mapping rules for clock change days, as described in item 4, will be applied when recording this single day view. The remaining days of the notification will be recorded by the ECVAA system as received, i.e. with 48 Settlement Periods, but with an Effective From Date of Current Date + 1. The exception to this is where, for a non-clock change Current Date, the received notification’s pre- Submission Deadline volumes match the previously received volumes. In this case, the notification will be recorded and reported as a single notification effective from the Current Date, and with all period volumes (always 48 periods) as they are in the received notification. Refer to requirement ECVAA-I022 for details on how these notifications are reported. See Section 5.14 for clarification on the storage of Notifications. Therefore: For a new Energy Contract Volume Notification only the Energy Contract Volume for Settlement Periods that have not passed the Submission Deadline will be input into the ECVAA system. Settlement Periods that have passed the Submission Deadline will not be stored, i.e. will be null/zero. For an amended Energy Contract Volume Notification only the Energy Contract Volume for Settlement Periods that have not passed the Submission Deadline will replace Energy Contract Volumes already stored in the ECVAA system. Settlement Periods that have passed the Submission Deadline will remain as the Volumes already stored in the ECVAA system (which may be null or zero). Notes: 1. Energy Contract Volume Notification identifiers must be unique for any given BSC Party Energy Account combination regardless of the number of ECVNAs authorised to submit notifications on behalf of the parties. If identifiers are not unique this will result in new Energy Contract Volume Notifications being processed as amendments, i.e. being a replacement rather than being additive. 2. When an ECVAA System Failure or ECVAA System Withdrawal has been declared affecting some or all Notification Agents, ECVAA shall then process (as if they had arrived before the appropriate the Submission Deadline), submissions or re-submissions of Volume Notifications from those affected Notification Agents which relate to any Settlement Period having the Submission Deadline between: a. the time at which the ECVAA System Failure or ECVAA System Withdrawal began, and b. the end of the Business Day following the day on which the ECVAA notified BSCCo Ltd that the ECVAA System Failure or ECVAA System Withdrawal had ended (the ‘resubmission deadline’). BSCCo Ltd may modify the resubmission deadline to a later date if appropriate, in which case the ECVAA will be notified. Processing of notifications submitted under this rule is manual.
3: The ECVAA shall reject any Energy Contract Volume Notification that fails the validation described in point 1 above and notify the relevant BSC Parties and ECVNA(s) of the rejection, including the reasons for the rejection. If any part of the Energy Contract Volume Notification fails validation it shall be rejected in its entirety. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected Energy Contract Volume Notifications as described by requirement ECVAA-I009: Issue Energy Contract Volume Notification Feedback. The report will be sent to the submitting ECVNA and their associated BSC Party subject to the reporting option selected with the authorisation – see ECVAA-F003.
4: The ECVAA shall apply default rules to the processing of Energy Contract Volume Notifications for clock change days, unless a specific clock change day notification has been submitted. Where an Energy Contract Volume Notification is for a range of days or is evergreen the Settlement Period data is applied to a clock change day as follows. For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST): Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day notification; Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification; Settlement Periods 3 and 4 of the ‘normal’ day notification are not used on a short day. For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT): Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day notification; Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day notification; Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification. Where a single day Energy Contract Volume Notification (i.e. Effective To Date equals Effective From Date) is received for a clock change day it is assumed that the loss/gain of one hour has been taken into account and the Settlement Period data will be processed exactly as specified, i.e. the default rules described above are not applied. Note, however, that the standard additional/replacement processing rules described in point 2 will still apply. Submitting a single day clock change notification does not automatically replace all other notifications which relate to the day.
5: The data will be submitted to ECVAA-F014 for comparison with the latest submission from the other agent on behalf of the other party. The matching status of the data will be updated. For data falling in settlement dates having settlement period 1 within 36 hours (72 settlement periods) of receipt of the ECVN, the ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify interested organisations of: the position submitted on behalf of Party 1 the position submitted on behalf of Party 2 the matched position Detailed report requirements are described in ECVAA-I028: Issue Energy Contract Volume Notification (ECVN) Acceptance Feedback
6: The ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify the relevant BSC Party and ECVNA of ECVNs which are successfully loaded where settlement period 1 of the effective from date on the ECVN starts within 36 hours (72 settlement periods) of receipt of the ECVN. The ECVAA shall report accepted Energy Contract Volume Notifications as described by requirement ECVAA-I028: Issue ECVN Acceptance Feedback.
Non Functional Requirement:
The ECVAA Service shall process Energy Contract Volume Notifications automatically upon receipt and shall return rejections or acceptance feedback if applicable within 15 minutes of receipt. If a rejection feedback is not sent within 20 minutes after receipt of an Energy Contract Volume Notification, the ECVAA shall accept a re-submitted Notification, provided that the re-submitted Notification has only been amended to correct those matters which gave rise to its invalidity. The re-submitted Notification shall be deemed to have been received at the time of receipt of the original Notification. Processing of re-submitted Notifications shall be manual. The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications submitted under a given ECVNAA and ECVN Identifier, irrespective of the submitting ECVNA, have sequence numbers which follow the same order as the transaction numbers which they contain.
Interfaces:
Related interface requirements: ECVAA-I004: Receive Energy Contract Volume Notifications ECVAA-I009: Issue Energy Contract Volume Notification Feedback ECVAA-I028: Issue ECVN Acceptance Feedback

Requirement ID:

ECVAA-F005

Status:

Mandatory

Title:

Process Energy Contract Volume Notifications

BSC Reference:

ECVAA SD: 8.1-8.3, B8

ECVAA BPM: 3.3

CR008, CR012, CR028, CP539, P4, CP725, CP911, CP739, P98, Variation 58, P309

Man/auto:

Automatic

Frequency:

Continuous

Volumes:

High

Functional Requirement:

The ECVAA shall receive Energy Contract Volume Notifications from ECVNAs as described by requirement ECVAA-I004: Receive Energy Contract Volume Notifications. The Energy Contract Volume Notifications shall comprise:

Energy Contract Volume Notifications

For Notifications submitted under Authorisations, the positions held on behalf of both Party 1 and Party 2 will be updated. Once the data has been processed, amended period data is passed to ECVAA-F014 for comparison with the other party’s latest submission. Both positions are always the same, so matching is automatic.

The NETSO is permitted to notify Energy Contract Volumes just like any other counter-party. The ECVAA will be required to treat the NETSO as if it has Energy Accounts and it shall pass on Energy Contract Volumes in respect of the NETSO onto the SAA as for any other Party.

Virtual Lead Parties are not allowed to notify Energy Contract Volumes.

1: The ECVAA shall validate the received Energy Contract Volume Notifications. The validation checks shall include the following:

a. checks to ensure that the following data have been submitted:

ECVNA identifier
ECVNAA identifier;
ECVNAA Key;
ECVN identifier, comprising originator’s ECVNAA identifier plus a unique Reference Code;
Effective From Date;
Effective To Date; (An ECVN may be evergreen, i.e. the Effective To Date is null, may be for a single day, i.e. the Effective To Date equals the Effective From Date, or may be for a specified date range, i.e. the Effective To Date is after the Effective From Date )
Energy Contract Volume Data for Settlement Periods relevant to the ECVN. This comprises the Settlement Period identifier, a number in the range 1-48 (or 1-46/50 for a specific clock change day notification), along with the corresponding ECV for that Settlement Period in MWh.
Omitted Data: No Change (optional); Submission Option indicating how volume data for Settlement Periods not specified in the Notification should be interpreted¹.

b. consistency of ECVNAA identifier, ECVNAA Key, ECVNA identifier and BSC Party identifiers;

c. validity of the ECVNAA for the Settlement Day on which the Energy Contract Volume Notification is received;

d. a check to ensure that the originator’s ECVNAA identifier component of the ECVN identifier is either:

the ECVNAA identifier of the ECVNA submitting the Energy Contract Volume Notification; or
an ECVNAA identifier for an authorisation that has now expired but was for the same pair of trading Party Energy Accounts (specified in the same order, i.e. Party 1 and Party 2) as the authorisation of the ECVNA submitting the Energy Contract Volume Notification. Where a Notification is submitted under a new ECVNAA in this way, all validation of the received Notification must be successful with regard to the new ECVNAA;

e. the following range test must be satisfied:

–99,999.999 ≤ ECQ_zabj ≤ 99,999.999

ECQ_zabj denotes the 48 (46 or 50 on clock change days) elements of Energy Contract Volume Data in MWh for an Energy Contract Volume Notification involving ECVNA z and Energy Accounts a and b for the BSC Parties, for each Settlement Period j of any Settlement Day covered by the Energy Contract Volume Notification.

f. a check to ensure that for each of the BSC Parties to the Energy Contract Volume Notification, i.e. Party 1 and Party 2

if the BSC Party’s current Credit Cover Percentage is greater than 90% of their Credit Limit and their ‘Credit Default Authorisation’ flag set to Yes then no component of the received notification must increase that BSC Party’s Indebtedness. The definition of notification components that increase Indebtedness is given in ECVAA-F007 point 2.

g. the Effective To Date must not be on the day of receipt of the Energy Contract Volume Notification if all Settlement Periods for that day have passed the Submission Deadline.

h. The Effective To Date must not be before the day of receipt.

i. The Effective To Date must not be before the Effective From Date.

j. not used

k. A check to ensure that where the associated ECVNAA has a Notification Amendment Type of ‘Additional’ or ‘Replacement’, the use of ECVNAA and ECVN identifiers is consistent with the rules in section 2 below for additional and replacement notifications respectively.

2: The ECVAA shall input each validated Energy Contract Volume Notification into its systems. The data to be recorded for each valid Energy Contract Volume Notification shall include the following:

ECVNA identifier;
ECVNAA identifier;
ECVNAA Key;
ECVN identifier, comprising originator’s ECVNAA identifier plus a unique Reference Code;
Effective From Date;
Effective To Date;
Energy Contract Volume Data for Settlement Periods relevant to the ECVN. This comprises the Settlement Period number in the range 1-48 (or 1-46/50 on a clock change day) along with the corresponding ECV for that Settlement Period in MWh.

For the avoidance of doubt, the following rules will apply to Energy Contract Volume Notifications:

ECVNs are used to determine the position submitted on behalf of both counterparties. Note that the matched position is determined separately as defined in ECVAA-F014.
Initial Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier not previously notified to the ECVAA for the same combination of BSC Party Energy Accounts but where the ECVN does not overlap with an earlier ECVN (i.e. is not an Additional ECVN). An Initial ECVN is not limited by whether the ECVNAA’s Notification Amendment Type;
A Replacement Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier which has previously been notified to the ECVAA for the same combination of BSC Party Energy Accounts and where the second ECVN’s Effective From Date is on or before the Effective To Date of the first ECVN. In this case the second ECVN will be considered a Replacement ECVN and will replace the previous Energy Contract Volume Notification with the same identifier;
An Additional Energy Contract Volume Notification is an ECVN submitted with an Energy Contract Volume Notification identifier not previously notified to the ECVAA for the same combination of BSC Party Energy Accounts and where Settlement Periods that the ECVN affects do overlap with an earlier ECVN’s. In this case the Additional ECVN will add to any previously submitted Energy Contract Volume Notifications for the same combination of BSC Party Energy Accounts between the dates specified;
The ECVAA shall only accept Replacement or Additional ECVNs where the corresponding ECVNAA allows it. That is Replacement ECVNs will only be accepted in relation to Authorisations with a Notification Amendment Type in force at the time of the ECVN’s submission that is equal to Both or Replacement, and Additional ECVNs will only be accepted in relation to Authorisations with a Notification Amendment Type in force at the time of the ECVN’s submission that is equal to Both or Additional;
For processing purposes, the Current Date is the earliest Settlement Date for which at least one Settlement Period has not passed the Submission Deadline at the time the ECVAA receives the Notification. An Energy Contract Notification will not be applied for any date before the Current Date, so the Applied From Date is either the Effective From Date in the received notification or the Current Date, whichever is the later.
An Energy Contract Volume Notification Replacement will replace a previously submitted Energy Contract Volume Notification with the same identifier from the Applied From Date (see above). Note: the previous Energy Contract Volume Notification will be replaced in its entirety from the Applied From Date and earliest Settlement Period for which the Submission Deadline has not passed;
In the case of a Replacement ECVN, the previous Energy Contract Volume Notification will be replaced in its entirety from the Applied From Date and earliest Settlement Period for which the Submission Deadline has not passed.
Settlement Periods not included in the Energy Contract Volume Notification indicate that there is zero Energy Contract Volume for that period or that previously specified Energy Contract Volume is withdrawn. An Energy Contract Volume Notification with Energy Contract Volume data for no Settlement Periods indicates that the Energy Contract Volume Notification has been withdrawn in its entirety from the Effective From Date specified. As with other amendments, withdrawal of a notification will only be applicable from the Applied From Date, and earliest settlement period for which the Submission Deadline has not passed.
The Energy Contract Volume for Settlement Periods that have passed the Submission Deadline at the time of receipt of the Energy Contract Volume Notification will be disregarded and will not be input into the ECVAA system. (Note: the relevant BSC parties and ECVNA will not be notified of Settlement Periods which are disregarded.)
The Energy Contract Volumes for Settlement Periods that have not passed the Submission Deadline at the time of receipt of the Energy Contract Volume Notification will be input into the ECVAA system according to the new or amended Notification rules described above.
Where an Energy Contract Volume Notification is for a range of days or is evergreen and is applicable from the Current Date, a single day view of the data will be recorded by the ECVAA system for the current date. This single day view will be a composite of previously received volumes, for Settlement Periods for which the Submission Deadline has passed, and the volumes in the notification, for the remaining Settlement Periods. In addition, the mapping rules for clock change days, as described in item 4, will be applied when recording this single day view. The remaining days of the notification will be recorded by the ECVAA system as received, i.e. with 48 Settlement Periods, but with an Effective From Date of Current Date + 1. The exception to this is where, for a non-clock change Current Date, the received notification’s pre- Submission Deadline volumes match the previously received volumes. In this case, the notification will be recorded and reported as a single notification effective from the Current Date, and with all period volumes (always 48 periods) as they are in the received notification. Refer to requirement ECVAA-I022 for details on how these notifications are reported.
See Section 5.14 for clarification on the storage of Notifications.

Therefore:

For a new Energy Contract Volume Notification only the Energy Contract Volume for Settlement Periods that have not passed the Submission Deadline will be input into the ECVAA system. Settlement Periods that have passed the Submission Deadline will not be stored, i.e. will be null/zero.
For an amended Energy Contract Volume Notification only the Energy Contract Volume for Settlement Periods that have not passed the Submission Deadline will replace Energy Contract Volumes already stored in the ECVAA system. Settlement Periods that have passed the Submission Deadline will remain as the Volumes already stored in the ECVAA system (which may be null or zero).

Notes:

1. Energy Contract Volume Notification identifiers must be unique for any given BSC Party Energy Account combination regardless of the number of ECVNAs authorised to submit notifications on behalf of the parties. If identifiers are not unique this will result in new Energy Contract Volume Notifications being processed as amendments, i.e. being a replacement rather than being additive.

2. When an ECVAA System Failure or ECVAA System Withdrawal has been declared affecting some or all Notification Agents, ECVAA shall then process (as if they had arrived before the appropriate the Submission Deadline), submissions or re-submissions of Volume Notifications from those affected Notification Agents which relate to any Settlement Period having the Submission Deadline between:

a. the time at which the ECVAA System Failure or ECVAA System Withdrawal began, and

b. the end of the Business Day following the day on which the ECVAA notified BSCCo Ltd that the ECVAA System Failure or ECVAA System Withdrawal had ended (the ‘resubmission deadline’).

BSCCo Ltd may modify the resubmission deadline to a later date if appropriate, in which case the ECVAA will be notified.

Processing of notifications submitted under this rule is manual.

3: The ECVAA shall reject any Energy Contract Volume Notification that fails the validation described in point 1 above and notify the relevant BSC Parties and ECVNA(s) of the rejection, including the reasons for the rejection. If any part of the Energy Contract Volume Notification fails validation it shall be rejected in its entirety. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected Energy Contract Volume Notifications as described by requirement ECVAA-I009: Issue Energy Contract Volume Notification Feedback. The report will be sent to the submitting ECVNA and their associated BSC Party subject to the reporting option selected with the authorisation – see ECVAA-F003.

4: The ECVAA shall apply default rules to the processing of Energy Contract Volume Notifications for clock change days, unless a specific clock change day notification has been submitted.

Where an Energy Contract Volume Notification is for a range of days or is evergreen the Settlement Period data is applied to a clock change day as follows.

For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST):

Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day notification;
Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification;
Settlement Periods 3 and 4 of the ‘normal’ day notification are not used on a short day.

For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):

Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day notification;
Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day notification;
Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification.

Where a single day Energy Contract Volume Notification (i.e. Effective To Date equals Effective From Date) is received for a clock change day it is assumed that the loss/gain of one hour has been taken into account and the Settlement Period data will be processed exactly as specified, i.e. the default rules described above are not applied. Note, however, that the standard additional/replacement processing rules described in point 2 will still apply. Submitting a single day clock change notification does not automatically replace all other notifications which relate to the day.

5: The data will be submitted to ECVAA-F014 for comparison with the latest submission from the other agent on behalf of the other party. The matching status of the data will be updated.

For data falling in settlement dates having settlement period 1 within 36 hours (72 settlement periods) of receipt of the ECVN, the ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify interested organisations of:

the position submitted on behalf of Party 1
the position submitted on behalf of Party 2
the matched position

Detailed report requirements are described in ECVAA-I028: Issue Energy Contract Volume Notification (ECVN) Acceptance Feedback

6: The ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify the relevant BSC Party and ECVNA of ECVNs which are successfully loaded where settlement period 1 of the effective from date on the ECVN starts within 36 hours (72 settlement periods) of receipt of the ECVN.

The ECVAA shall report accepted Energy Contract Volume Notifications as described by requirement ECVAA-I028: Issue ECVN Acceptance Feedback.

Non Functional Requirement:

The ECVAA Service shall process Energy Contract Volume Notifications automatically upon receipt and shall return rejections or acceptance feedback if applicable within 15 minutes of receipt.

If a rejection feedback is not sent within 20 minutes after receipt of an Energy Contract Volume Notification, the ECVAA shall accept a re-submitted Notification, provided that the re-submitted Notification has only been amended to correct those matters which gave rise to its invalidity. The re-submitted Notification shall be deemed to have been received at the time of receipt of the original Notification. Processing of re-submitted Notifications shall be manual.

The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications submitted under a given ECVNAA and ECVN Identifier, irrespective of the submitting ECVNA, have sequence numbers which follow the same order as the transaction numbers which they contain.

Interfaces:

Related interface requirements:

ECVAA-I004: Receive Energy Contract Volume Notifications

ECVAA-I009: Issue Energy Contract Volume Notification Feedback

ECVAA-I028: Issue ECVN Acceptance Feedback

5.6 ECVAA-F006: Process Metered Volume Reallocation Notifications

Requirement ID: ECVAA-F006	Status: Mandatory	Title: Process Metered Volume Reallocation Notifications	BSC Reference: ECVAA SD: 9.1-9.3, B10 ECVAA BPM: 3.3 CR005, CR008, CR012, CR028, P4, CP725, CP911, CP739, P98, Variation 58
Man/auto: Automatic	Frequency: Continuous	Volumes: High
Functional Requirement:
The ECVAA shall receive Metered Volume Reallocation Notifications from MVRNAs as described by requirement ECVAA-I005: Receive Metered Volume Reallocation Notifications. The Metered Volume Reallocation Notifications shall comprise: Metered Volume Reallocation Notifications For Notifications submitted under Authorisations, the positions held on behalf of both the Lead Party and the Subsidiary Party will be updated. Once the data has been processed, amended period data is passed to ECVAA-F015 for comparison with the other party’s latest submission. Both positions are always the same, so matching is automatic. The NETSO is permitted to notify Metered Volume Reallocations just like any other counter-party. The ECVAA will be required to treat the NETSO as if it has Energy Accounts and it shall pass on Metered Volume Reallocation information in respect of the NETSO onto the SAA as for any other Party. Virtual Lead Parties may not notify Metered Volume Reallocations in respect of Secondary BM Units.
1: The ECVAA shall validate the received Metered Volume Reallocation Notifications. The validation checks shall include the following: a. the following data must be submitted for each Metered Volume Reallocation Notification: MVRNA identifier; MVRNAA identifier; MVRNAA Key; MVRN identifier, comprising originator’s MVRNAA identifier plus a unique Reference Code; Effective From Date; Effective To Date; (A MVRN may be evergreen, i.e. the Effective To Date is null, may be for a single day, i.e. the Effective To Date equals the Effective From Date, or may be for a specified date range, i.e. the Effective To Date is after the Effective From Date ) Metered Volume Reallocation Data for Settlement Periods relevant to MVRN. This comprises: Settlement Period identifier, a number in the range 1-48 (or 1-46/50 for a specific clock change day notification); Metered Volume Fixed Reallocation (QMFR_iaj), in MWh assigned to the Subsidiary Party for the Settlement Period; Metered Volume Percentage Reallocation (QMPR_iaj) assigned to the Subsidiary Party for the Settlement Period. Omitted Data: No Change (optional); Submission Option indicating how volume data for Settlement Periods not specified in the Notification should be interpreted.² b. consistency of MVRNAA identifier, MVRNAA Key, MVRNA identifier; c. validity of the MVRNAA for the Settlement Day on which the MVRN is received; d. a check to ensure that the originator’s MVRNAA identifier component of the MVRN identifier is either: the MVRNAA identifier of the MVRNA submitting the Metered Volume Reallocation Notification; or an MVRNAA identifier for an authorisation that has now expired but was for the same Lead and Subsidiary Party Energy Accounts as the authorisation of the MVRNA submitting the Metered Volume Reallocation Notification. Where a Notification is submitted under a new MVRNAA in this way, all validation of the received Notification must be successful with regard to the new MVRNAA; e. the following tests must be satisfied: 0.00 ≤ QMPR_aij ≤ 100.00 Σ_a QMPR_aij ≤100.00 Where QMPR_aij is the matched Metered Volume Percentage Reallocation for Subsidiary Energy Account a, BM Unit i and Settlement Period j. This test is performed in ECVAA-F015 Matching of submitted MVRNs. In addition, the Metered Volume Percentage Reallocation as notified on behalf of a Lead Party for Subsidiary Party Energy Account a, BM Unit i and Settlement Period j, whether matched or not, must meet the criteria: Σ_a QMPR_aij≤ 100.00 Where QMPR_aijis the Metered Volume Percentage Reallocation as notified by the Lead Party for Subsidiary Account a, BM Unit I and Settlement Period j. The Energy Percentage for the Lead Energy Account will default to whatever is remaining from 100.00 after the Subsidiary Energy Accounts' allocation. f. a check to ensure that for each of the BSC Parties to the Metered Volume Reallocation Notification, i.e. the Lead Party and Subsidiary Party: if the BSC Party’s current Credit Cover Percentage is greater than 90% of their Credit Limit and their ‘Credit Default Authorisation’ flag set to Yes then no component of the received notification must increase that BSC Party’s Indebtedness. The definition of notification components that increase Indebtedness is given in ECVAA-F007 point 2. g. the Effective To Date must not be on the day of receipt of the Metered Volume Reallocation Notification if all Settlement Periods for that day have passed the Submission Deadline. h. The Effective To Date must not be before the day of receipt. i. The Effective To Date must not be before the Effective From Date.
2: The ECVAA shall input each validated Metered Volume Reallocation Notification into its systems. The data to be recorded for each valid Metered Volume Reallocation Notification shall include the following: MVRNA identifier; MVRNAA identifier; MVRNAA Key; MVRN identifier, comprising originator’s MVRNAA identifier plus a unique Reference Code; Effective From Date; Effective To Date; Metered Volume Reallocation Data for Settlement Periods relevant to MVRN. This comprises: Settlement Period identifier, a number in the range 1-48 (or 1-46/50 on a clock change day); Metered Volume Fixed Reallocation (QMFR_iaj), in MWh assigned to the Subsidiary Party for the Settlement Period; Metered Volume Percentage Reallocation (QMPR_iaj) assigned to the Subsidiary Party for the Settlement Period. For the avoidance of doubt, the following rules will apply to Metered Volume Reallocation Notifications: MVRNs are used to determine the position submitted on behalf of both counterparties. Note that the matched position is determined separately as defined in ECVAA-F015. A Metered Volume Reallocation Notification submitted with a Metered Volume Reallocation Notification identifier not previously notified to the ECVAA for the same combination of Lead and Subsidiary Party Energy Accounts will be considered a new Metered Volume Reallocation Notification; A Metered Volume Reallocation Notification submitted with a Metered Volume Reallocation Notification identifier which has previously been notified to the ECVAA for the same combination of Lead and Subsidiary Party Energy Accounts will be considered an amendment to the previous Metered Volume Reallocation Notification with the same identifier; A new Metered Volume Reallocation Notification will add to any previously submitted Metered Volume Reallocation Notifications for the same combination of Lead and Subsidiary Party Energy Accounts between the dates specified; (Note: for additive Metered Volume Reallocation Notifications both the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation values will be summed.) For processing purposes, the Current Date is the earliest Settlement Date for which at least one Settlement Period has not passed the Submission Deadline at the time the ECVAA receives the Notification. A Metered Volume Reallocation Notification will not be applied for any date before the Current Date, so the Applied From Date is either the Effective From Date in the received notification or the Current Date, whichever is the later. A Metered Volume Reallocation Notification amendment will replace a previously submitted Metered Volume Reallocation Notification with the same identifier from the Applied From Date (see above). Note: the previous Metered Volume Reallocation Notification will be replaced in its entirety from the Applied From Date and the earliest Settlement Period for which the Submission Deadline has not passed; In the case of an amendment, the previous Metered Volume Reallocation Notification will be overwritten in its entirety from the Applied From Date and the earliest Settlement Period for which the Submission Deadline has not passed. Settlement Periods not included in the Metered Volume Reallocation Notification indicate that there is zero Metered Volume Reallocation for that period or that previously specified Metered Volume Reallocation is withdrawn. A Metered Volume Reallocation Notification with Metered Volume Reallocation data for no Settlement Periods indicates that the Metered Volume Reallocation Notification has been withdrawn in its entirety from the Effective From Date specified. As with other amendments, withdrawal of a notification will only be applicable from the Applied From Date, and earliest settlement period for which the Submission Deadline has not passed. Where a Metered Volume Reallocation Notification is for a range of days or is evergreen and is applicable from the Current Date, a single day view of the data will be recorded by the ECVAA system for the current date. This single day view will be a composite of previously received volumes, for Settlement Periods for which the Submission Deadline has passed, and the volumes in the notification, for the remaining Settlement Periods. In addition, the mapping rules for clock change days, as described in item 4, will be applied when recording this single day view. The remaining days of the notification will be recorded by the ECVAA system as received, i.e. with 48 Settlement Periods, but with an Effective From Date of Current Date + 1. The exception to this is where, for a non-clock change Current Date, the received notification’s pre- Submission Deadline volumes match the previously received volumes. In this case, the notification will be recorded and reported as a single notification effective from the Current Date, and with all period volumes (always 48 periods) as they are in the received notification. Refer to requirement ECVAA-I022 for details on how these notifications are reported. See Section 5.14 for clarification on the storage of Notifications. Notes: 1. Metered Volume Reallocation Notification identifiers must be unique for any given Lead and Subsidiary Party Energy Account combination regardless of the number of MVRNAs authorised to submit notifications on behalf of the parties. If identifiers are not unique this will result in new Metered Volume Reallocation Notifications being processed as amendments, i.e. being a replacement rather than an addition. 2. When an ECVAA System Failure or ECVAA System Withdrawal has been declared affecting some or all Notification Agents, ECVAA shall then process (as if they had arrived before the appropriate the Submission Deadline), submissions or re-submissions of Volume Reallocation Notifications from those affected Notification Agents which relate to any Settlement Period having the Submission Deadline between: a. the time at which the ECVAA System Failure of ECVAA System Withdrawal began, and b. the end of the Business Day following the day on which the ECVAA notified BSCCo Ltd that the ECVAA System Failure or ECVAA System Withdrawal had ended (the ‘resubmission deadline’). BSCCo Ltd may modify the resubmission deadline to a later date if appropriate, in which case the ECVAA will be notified. Processing of notifications submitted under this rule is manual The ECVAA shall report valid Metered Volume Reallocation Notifications (which have not been rejected during credit checking, see ECVAA-F007 point 2) to the SAA once a day as described by Interface I012: Issue Metered Volume Reallocation Notification Report.
3: The ECVAA shall reject any Metered Volume Reallocation Notification that fails the validation described in point 1 above and notify the relevant Lead and Subsidiary Parties and MVRNA of the rejection, including the reasons for the rejection. If any part of the Metered Volume Reallocation Notification fails validation it shall be rejected in its entirety. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected Metered Volume Reallocation Notifications as described by requirement ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback. The report will be sent to the submitting MVRNA and their associated BSC Party subject to the reporting option selected with the authorisation – see ECVAA-F004.
4: The ECVAA shall apply default rules to the processing of Metered Volume Reallocation Notifications for clock change days, unless a specific clock change day notification has been submitted. Where a Metered Volume Reallocation Notification is for a range of days or is evergreen the Settlement Period data is applied to a clock change day as follows. For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST): Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day notification; Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification; Settlement Periods 3 and 4 of the ‘normal’ day notification are not used on a short day. For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT): Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day notification; Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day notification; Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification. Where a single day Metered Volume Reallocation Notification (i.e. Effective To Date equals Effective From Date) is received for a clock change day it is assumed that the loss/gain of one hour has been taken into account and the Settlement Period data will be processed exactly as specified, i.e. the default rules described above are not applied. Note, however, that the standard addition/replacement processing rules described in point 2 will still apply. Submitting a single day clock change notification does not automatically replace all other notifications which relate to the day.
5: The data will be submitted to ECVAA-F015 for comparison with the latest submission from the other agent on behalf of the other party. The matching status of the data will be updated. For data falling in settlement dates having settlement period 1 within 36 hours (72 settlement periods) of receipt of the MVRN, the ECVAA shall (subject to reporting options selected for the BSC Party and Agent) ) notify interested organisations of: the position submitted on behalf of the Lead Party the position submitted on behalf of the Subsidiary Party the matched position Detailed report requirements are described in ECVAA-I029: Issue Meter Volume Reallocation Notification (MVRN) Acceptance Feedback.
6: The ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify the relevant BSC Parties and MVRNA of MVRNs which are successfully loaded where settlement period 1 of the effective from date on the MVRN starts within 36 hours (72 settlement periods) of receipt of the MVRN. The ECVAA shall report accepted Meter Volume Reallocation Notifications as described by requirement ECVAA-I029: Issue MVRN Acceptance Feedback.
Non Functional Requirement:
The ECVAA Service shall process Metered Volume Reallocation Notifications automatically upon receipt and shall return rejections or acceptance feedback if applicable within 15 minutes of receipt. If a rejection feedback is not sent within 20 minutes after receipt of a Metered Volume Reallocation Notification, the ECVAA shall accept a re-submitted Notification, provided that the re-submitted Notification has only been amended to correct those matters which gave rise to its invalidity. The re-submitted Notification shall be deemed to have been received at the time of receipt of the original Notification. Processing of re-submitted Notifications shall be manual. The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications submitted under a given MVRNAA and MVRN Identifier, irrespective of the submitting MVRNA, have sequence numbers which follow the same order as the transaction numbers which they contain.
Interfaces:
Related interface requirements: ECVAA-I005: Receive Metered Volume Reallocation Notifications ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback ECVAA-I029: Issue MVRN Acceptance Feedback

Requirement ID:

ECVAA-F006

Status:

Mandatory

Title:

Process Metered Volume Reallocation Notifications

BSC Reference:

ECVAA SD: 9.1-9.3, B10

ECVAA BPM: 3.3

CR005, CR008, CR012, CR028, P4, CP725, CP911, CP739, P98, Variation 58

Man/auto:

Automatic

Frequency:

Continuous

Volumes:

High

Functional Requirement:

The ECVAA shall receive Metered Volume Reallocation Notifications from MVRNAs as described by requirement ECVAA-I005: Receive Metered Volume Reallocation Notifications. The Metered Volume Reallocation Notifications shall comprise:

Metered Volume Reallocation Notifications

For Notifications submitted under Authorisations, the positions held on behalf of both the Lead Party and the Subsidiary Party will be updated. Once the data has been processed, amended period data is passed to ECVAA-F015 for comparison with the other party’s latest submission. Both positions are always the same, so matching is automatic.

The NETSO is permitted to notify Metered Volume Reallocations just like any other counter-party. The ECVAA will be required to treat the NETSO as if it has Energy Accounts and it shall pass on Metered Volume Reallocation information in respect of the NETSO onto the SAA as for any other Party.

Virtual Lead Parties may not notify Metered Volume Reallocations in respect of Secondary BM Units.

1: The ECVAA shall validate the received Metered Volume Reallocation Notifications. The validation checks shall include the following:

a. the following data must be submitted for each Metered Volume Reallocation Notification:

MVRNA identifier;
MVRNAA identifier;
MVRNAA Key;
MVRN identifier, comprising originator’s MVRNAA identifier plus a unique Reference Code;
Effective From Date;
Effective To Date; (A MVRN may be evergreen, i.e. the Effective To Date is null, may be for a single day, i.e. the Effective To Date equals the Effective From Date, or may be for a specified date range, i.e. the Effective To Date is after the Effective From Date )
Metered Volume Reallocation Data for Settlement Periods relevant to MVRN. This comprises:
Settlement Period identifier, a number in the range 1-48 (or 1-46/50 for a specific clock change day notification);
Metered Volume Fixed Reallocation (QMFR_iaj), in MWh assigned to the Subsidiary Party for the Settlement Period;
Metered Volume Percentage Reallocation (QMPR_iaj) assigned to the Subsidiary Party for the Settlement Period.
Omitted Data: No Change (optional); Submission Option indicating how volume data for Settlement Periods not specified in the Notification should be interpreted.²

b. consistency of MVRNAA identifier, MVRNAA Key, MVRNA identifier;

c. validity of the MVRNAA for the Settlement Day on which the MVRN is received;

d. a check to ensure that the originator’s MVRNAA identifier component of the MVRN identifier is either:

the MVRNAA identifier of the MVRNA submitting the Metered Volume Reallocation Notification; or
an MVRNAA identifier for an authorisation that has now expired but was for the same Lead and Subsidiary Party Energy Accounts as the authorisation of the MVRNA submitting the Metered Volume Reallocation Notification. Where a Notification is submitted under a new MVRNAA in this way, all validation of the received Notification must be successful with regard to the new MVRNAA;

e. the following tests must be satisfied:

0.00 ≤ QMPR_aij ≤ 100.00

Σ_a QMPR_aij ≤100.00

Where QMPR_aij is the matched Metered Volume Percentage Reallocation for Subsidiary Energy Account a, BM Unit i and Settlement Period j. This test is performed in ECVAA-F015 Matching of submitted MVRNs.

In addition, the Metered Volume Percentage Reallocation as notified on behalf of a Lead Party for Subsidiary Party Energy Account a, BM Unit i and Settlement Period j, whether matched or not, must meet the criteria:

Σ_a QMPR_aij≤ 100.00

Where QMPR_aijis the Metered Volume Percentage Reallocation as notified by the Lead Party for Subsidiary Account a, BM Unit I and Settlement Period j.

The Energy Percentage for the Lead Energy Account will default to whatever is remaining from 100.00 after the Subsidiary Energy Accounts' allocation.

f. a check to ensure that for each of the BSC Parties to the Metered Volume Reallocation Notification, i.e. the Lead Party and Subsidiary Party:

if the BSC Party’s current Credit Cover Percentage is greater than 90% of their Credit Limit and their ‘Credit Default Authorisation’ flag set to Yes then no component of the received notification must increase that BSC Party’s Indebtedness. The definition of notification components that increase Indebtedness is given in ECVAA-F007 point 2.

g. the Effective To Date must not be on the day of receipt of the Metered Volume Reallocation Notification if all Settlement Periods for that day have passed the Submission Deadline.

h. The Effective To Date must not be before the day of receipt.

i. The Effective To Date must not be before the Effective From Date.

2: The ECVAA shall input each validated Metered Volume Reallocation Notification into its systems. The data to be recorded for each valid Metered Volume Reallocation Notification shall include the following:

MVRNA identifier;
MVRNAA identifier;
MVRNAA Key;
MVRN identifier, comprising originator’s MVRNAA identifier plus a unique Reference Code;
Effective From Date;
Effective To Date;
Metered Volume Reallocation Data for Settlement Periods relevant to MVRN. This comprises:

Settlement Period identifier, a number in the range 1-48 (or 1-46/50 on a clock change day);
Metered Volume Fixed Reallocation (QMFR_iaj), in MWh assigned to the Subsidiary Party for the Settlement Period;
Metered Volume Percentage Reallocation (QMPR_iaj) assigned to the Subsidiary Party for the Settlement Period.

For the avoidance of doubt, the following rules will apply to Metered Volume Reallocation Notifications:

MVRNs are used to determine the position submitted on behalf of both counterparties. Note that the matched position is determined separately as defined in ECVAA-F015.
A Metered Volume Reallocation Notification submitted with a Metered Volume Reallocation Notification identifier not previously notified to the ECVAA for the same combination of Lead and Subsidiary Party Energy Accounts will be considered a new Metered Volume Reallocation Notification;
A Metered Volume Reallocation Notification submitted with a Metered Volume Reallocation Notification identifier which has previously been notified to the ECVAA for the same combination of Lead and Subsidiary Party Energy Accounts will be considered an amendment to the previous Metered Volume Reallocation Notification with the same identifier;
A new Metered Volume Reallocation Notification will add to any previously submitted Metered Volume Reallocation Notifications for the same combination of Lead and Subsidiary Party Energy Accounts between the dates specified; (Note: for additive Metered Volume Reallocation Notifications both the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation values will be summed.)
For processing purposes, the Current Date is the earliest Settlement Date for which at least one Settlement Period has not passed the Submission Deadline at the time the ECVAA receives the Notification. A Metered Volume Reallocation Notification will not be applied for any date before the Current Date, so the Applied From Date is either the Effective From Date in the received notification or the Current Date, whichever is the later.
A Metered Volume Reallocation Notification amendment will replace a previously submitted Metered Volume Reallocation Notification with the same identifier from the Applied From Date (see above). Note: the previous Metered Volume Reallocation Notification will be replaced in its entirety from the Applied From Date and the earliest Settlement Period for which the Submission Deadline has not passed;
In the case of an amendment, the previous Metered Volume Reallocation Notification will be overwritten in its entirety from the Applied From Date and the earliest Settlement Period for which the Submission Deadline has not passed.
Settlement Periods not included in the Metered Volume Reallocation Notification indicate that there is zero Metered Volume Reallocation for that period or that previously specified Metered Volume Reallocation is withdrawn. A Metered Volume Reallocation Notification with Metered Volume Reallocation data for no Settlement Periods indicates that the Metered Volume Reallocation Notification has been withdrawn in its entirety from the Effective From Date specified. As with other amendments, withdrawal of a notification will only be applicable from the Applied From Date, and earliest settlement period for which the Submission Deadline has not passed.
Where a Metered Volume Reallocation Notification is for a range of days or is evergreen and is applicable from the Current Date, a single day view of the data will be recorded by the ECVAA system for the current date. This single day view will be a composite of previously received volumes, for Settlement Periods for which the Submission Deadline has passed, and the volumes in the notification, for the remaining Settlement Periods. In addition, the mapping rules for clock change days, as described in item 4, will be applied when recording this single day view. The remaining days of the notification will be recorded by the ECVAA system as received, i.e. with 48 Settlement Periods, but with an Effective From Date of Current Date + 1. The exception to this is where, for a non-clock change Current Date, the received notification’s pre- Submission Deadline volumes match the previously received volumes. In this case, the notification will be recorded and reported as a single notification effective from the Current Date, and with all period volumes (always 48 periods) as they are in the received notification. Refer to requirement ECVAA-I022 for details on how these notifications are reported.
See Section 5.14 for clarification on the storage of Notifications.

Notes:

1. Metered Volume Reallocation Notification identifiers must be unique for any given Lead and Subsidiary Party Energy Account combination regardless of the number of MVRNAs authorised to submit notifications on behalf of the parties. If identifiers are not unique this will result in new Metered Volume Reallocation Notifications being processed as amendments, i.e. being a replacement rather than an addition.

2. When an ECVAA System Failure or ECVAA System Withdrawal has been declared affecting some or all Notification Agents, ECVAA shall then process (as if they had arrived before the appropriate the Submission Deadline), submissions or re-submissions of Volume Reallocation Notifications from those affected Notification Agents which relate to any Settlement Period having the Submission Deadline between:

a. the time at which the ECVAA System Failure of ECVAA System Withdrawal began, and

b. the end of the Business Day following the day on which the ECVAA notified BSCCo Ltd that the ECVAA System Failure or ECVAA System Withdrawal had ended (the ‘resubmission deadline’).

BSCCo Ltd may modify the resubmission deadline to a later date if appropriate, in which case the ECVAA will be notified.

Processing of notifications submitted under this rule is manual

The ECVAA shall report valid Metered Volume Reallocation Notifications (which have not been rejected during credit checking, see ECVAA-F007 point 2) to the SAA once a day as described by Interface I012: Issue Metered Volume Reallocation Notification Report.

3: The ECVAA shall reject any Metered Volume Reallocation Notification that fails the validation described in point 1 above and notify the relevant Lead and Subsidiary Parties and MVRNA of the rejection, including the reasons for the rejection. If any part of the Metered Volume Reallocation Notification fails validation it shall be rejected in its entirety. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected Metered Volume Reallocation Notifications as described by requirement ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback. The report will be sent to the submitting MVRNA and their associated BSC Party subject to the reporting option selected with the authorisation – see ECVAA-F004.

4: The ECVAA shall apply default rules to the processing of Metered Volume Reallocation Notifications for clock change days, unless a specific clock change day notification has been submitted.

Where a Metered Volume Reallocation Notification is for a range of days or is evergreen the Settlement Period data is applied to a clock change day as follows.

For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST):

Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day notification;
Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification;
Settlement Periods 3 and 4 of the ‘normal’ day notification are not used on a short day.

For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):

Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day notification;
Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day notification;
Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day notification.

Where a single day Metered Volume Reallocation Notification (i.e. Effective To Date equals Effective From Date) is received for a clock change day it is assumed that the loss/gain of one hour has been taken into account and the Settlement Period data will be processed exactly as specified, i.e. the default rules described above are not applied. Note, however, that the standard addition/replacement processing rules described in point 2 will still apply. Submitting a single day clock change notification does not automatically replace all other notifications which relate to the day.

5: The data will be submitted to ECVAA-F015 for comparison with the latest submission from the other agent on behalf of the other party. The matching status of the data will be updated.

For data falling in settlement dates having settlement period 1 within 36 hours (72 settlement periods) of receipt of the MVRN, the ECVAA shall (subject to reporting options selected for the BSC Party and Agent) ) notify interested organisations of:

the position submitted on behalf of the Lead Party
the position submitted on behalf of the Subsidiary Party
the matched position

Detailed report requirements are described in ECVAA-I029: Issue Meter Volume Reallocation Notification (MVRN) Acceptance Feedback.

6: The ECVAA shall (subject to reporting options selected for the BSC Party and Agent) notify the relevant BSC Parties and MVRNA of MVRNs which are successfully loaded where settlement period 1 of the effective from date on the MVRN starts within 36 hours (72 settlement periods) of receipt of the MVRN.

The ECVAA shall report accepted Meter Volume Reallocation Notifications as described by requirement ECVAA-I029: Issue MVRN Acceptance Feedback.

Non Functional Requirement:

The ECVAA Service shall process Metered Volume Reallocation Notifications automatically upon receipt and shall return rejections or acceptance feedback if applicable within 15 minutes of receipt.

If a rejection feedback is not sent within 20 minutes after receipt of a Metered Volume Reallocation Notification, the ECVAA shall accept a re-submitted Notification, provided that the re-submitted Notification has only been amended to correct those matters which gave rise to its invalidity. The re-submitted Notification shall be deemed to have been received at the time of receipt of the original Notification. Processing of re-submitted Notifications shall be manual.

The ECVAA shall ensure that Acceptance Feedback Reports generated in response to notifications submitted under a given MVRNAA and MVRN Identifier, irrespective of the submitting MVRNA, have sequence numbers which follow the same order as the transaction numbers which they contain.

Interfaces:

Related interface requirements:

ECVAA-I005: Receive Metered Volume Reallocation Notifications

ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback

ECVAA-I029: Issue MVRN Acceptance Feedback

5.7 ECVAA-F007: Perform Credit Check

Requirement ID:

ECVAA-F007

Status:

Mandatory

Title:

Perform Credit Check

BSC Reference:

CR012, CR028, P12, CP571, CP703, P118, P142, P188

Man/auto:

Automatic

Frequency:

Every Half Hour

Volumes:

High

Functional Requirement:

The ECVAA shall perform a credit check process immediately after each Submission Deadline. This check will be applied to the Settlement Period for which the Submission Deadline has just passed. The credit check process shall consist of the following steps for each BSC Imbalance Party.

The following requirements are discussed with reference to matched components of ECVNs and MVRNs.

1: Read all matched components of the ECVNs and MVRNs that apply to the Settlement Period for which the Submission Deadline has just passed and calculate the cumulative Indebtedness for each BSC Party (including NETSO) up to and including the Settlement Period for which the Submission Deadline has just passed as described by requirement ECVAA-F010: Calculate Party Indebtedness.

The Credit Cover Percentage is the Energy Indebtedness (determined in ECVAA-F010) represented as a percentage of a Party’s Credit Limit (as determined in ECVAA-F002).

2: If a Party's Credit Cover Percentage becomes > 100%, then, irrespective of the value of the ‘Credit Default Authorisation’ flag, the ECVAA Operator will inform BSCCo Ltd and the Party as described by requirement ECVAA-I021: Issue Party Credit Status Warning. A Party's Credit Cover Percentage is considered to have “become > 100%” if between one Settlement Period and the next the value increases from <= 100% to > 100%.

3: If Credit Cover Percentage > 90% and the ‘Credit Default Authorisation’ flag is set to Yes for the Party then perform the following.

a. Read all matched components of the ECVNs and MVRNs that apply to the Settlement Period that is 3 periods (parameterised) after the Settlement Period for which the Submission Deadline has just passed.

b. Reject notification components for that Settlement Period that increase Indebtedness.

For the avoidance of doubt, notifications are considered to increase Indebtedness where the Party is selling energy and to reduce Indebtedness where the Party is purchasing energy. Note: ‘Indebtedness’ refers to a Party’s Energy Indebtedness to BSCCo Ltd as a result of imbalance charges.

Specifically, notification components that increase Indebtedness are defined as:

For Energy Contract Volumes:

If the Party is the TO PARTY, those Energy Contract Volumes that are negative;
If the Party is the FROM PARTY, those Energy Contract Volumes that are positive.

For Meter Volume Fixed Reallocations:

If the Party is the TO PARTY, those Meter Volume Fixed Reallocations that are negative;
If the Party is the FROM PARTY, those Meter Volume Fixed Reallocations that are positive.

For Meter Volume Percentage Reallocations:

If the BM Unit Type is Consumption, those where the Party is the Subsidiary Party;
If the BM Unit Type is Production, those where the Party is the Lead Party.

Where ECQ_zabjandQMFR_aijpositive and negative values imply:

ECQ_zabj/QMFR_aij

FROM PARTY

TO PARTY

Positive

Selling Energy

Increases Indebtedness

Purchasing Energy

Decreases Indebtedness

Negative

Purchasing Energy

Decreases Indebtedness

Selling Energy

Increases Indebtedness

Note: For Energy Contract Volumes the ‘From Party’ is Party 1 and the ‘To Party’ is Party 2. For Meter Volume Fixed Reallocations the ‘From Party’ is the Lead Party and the ‘To Party’ is the Subsidiary Party.

A MVRN may include both a Fixed and Percentage Reallocation for the same Settlement Period. In this case, if either the Fixed or the Percentage Reallocation increase Indebtedness for the Settlement Period then both components (Fixed and Percentage) will be rejected.

Notification components which have not been rejected by the above process are accepted.

c. For each notification component rejected record details of the rejection including:

rejection reason;
date/time rejected.

d. For each notification rejected notify the relevant BSC Parties and ECVNA/MVRNA of the rejection, including reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected ECVN components as described by requirement ECVAA-I009: Issue Energy Contract Volume Notification Feedback. The ECVAA shall report rejected MVRN components as described by requirement ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback.

If the Party’s Credit Cover Percentage > 90% and the ‘Credit Default Authorisation’ flag is set, then the Party is considered to be in ‘Level 2 Credit Default’.

If the Party is in ‘Level 2 Credit Default’ and the Party was not in ‘Level 2 Credit Default’ in the previous Settlement Period for which the credit check process was performed then a Level 2 Credit Default message will be reported to the BMRA, as described in requirement ECVAA-I036.

If the Party’s Credit Cover Percentage <= 90% of Credit Limit or if the ‘Credit Default Authorisation’ flag is unset and the Party was in ‘Level 2 Credit Default’ in the previous Settlement Period for which the credit check process was performed, then a cleared Level 2 Default message will be reported to the BMRA, as described in requirement ECVAA-I036.

Note: While a Party’s Credit Cover Percentage > 90% of Credit Limit and the ‘Credit Default Authorisation’ flag is set to Yes then new or amended notifications will be rejected on receipt if they increase the Party’s Indebtedness (for any Settlement Period), as described by requirements ECVAA-F005: Receive ECVN and ECVAA-F006: Receive MVRN.

Note: Any Settlement Period or contiguous block of Settlement Periods during which the Party is in Level 2 Default (i.e. Credit Cover Percentage > 90% and ‘Credit Default Authorisation’ flag is set) is the Credit Default Refusal Period. The Credit Default Rejection Period commences 3 Settlement Periods after the start of a Credit Default Refusal Period and ends 3 periods after the end of the same Credit Default Refusal Period.

4: If Credit Cover Percentage > 80% for the Party, and the Party is not already in a Query Period or Level 1 Cure Period, and is not already in ‘Level 1 Credit Default’ or ‘Level 1 No Authorisation’ then the system shall log a warning message visible to the ECVAA Operator and initiate a Query Period starting when the Party breached the 80% threshold.

The ECVAA Operator will inform BSCCo Ltd and the Party of credit limit warnings as described by requirement ECVAA-I021: Issue Party Credit Status Warning, thereby issuing a ‘Level 1 Credit Default Notice’. At this point the operator will set the end of the Query Period in the ECVAA system to the shortest duration that meets both of the following criteria:

• The end time is at least 24 hours + 5 minutes from the current time; and

• The duration includes a minimum of five consecutive Business Hours in a single Working Day.

5: If a Query Period relating to a given party has ended since the previous invocation of the credit check process, then the Party’s current Credit Cover Percentage will be checked against the 80% threshold.

If the Party’s Credit Cover Percentage > 80% then the ECVAA system will notify the operator of this event and initiate a Level 1 Cure Period starting at the end of the Query Period and ending at 24:00 (local time) on the next business day. The next business day is always determined to be the first business day starting after 24:00 on the calendar day that the Query Period ends. The operator will inform BSCCo Ltd and the Party concerned of commencement of the Level 1 Cure Period. Note that the BSCCo Ltd may consider instructing the ECVAA to set the ‘Credit Default Authorisation’ flag on the basis of this information.
If the Party’s Credit Cover Percentage <= 80% then the ECVAA system will not initiate a Level 1 Cure Period and the Party’s credit status will return to normal. BSCCo Ltd and the Party will be informed of this event, cancelling the ‘Level 1 Credit Default Notice’.

6: If a Party is in a Level 1 Cure Period, then the Credit Check process will evaluate the Party’s Credit Cover Percentage against the 75% threshold.

If the Party’s Credit Cover Percentage > 75% then the Level 1 Cure Period will continue and no action will be taken by the ECVAA system.
If the Party’s Credit Cover Percentage <= 75% then the ECVAA system will terminate the Level 1 Cure Period immediately and the Party’s credit status will return to normal. The ECVAA system will inform the operator of this event. The operator will then notify the Party and BSCCo Ltd that the Level 1 Cure period has ended because Credit Cover Percentage has fallen to 75% or less.

7: If a Level 1 Cure Period relating to a given party has ended since the previous invocation of the Credit Check process, the Credit Check process will again check the Party’s Credit Cover Percentage against the 75% threshold:

If the Party’s Credit Cover Percentage > 75% and the ‘Credit Default Authorisation’ flag is set, then the party is considered to be in ‘Level 1 Credit Default’. A Level 1 Credit Default message will be reported to BMRA as described in requirement ECVAA-I036.
If the Party’s Credit Cover Percentage > 75% and the ‘Credit Default Authorisation’ flag is not set, the Party will not be in ‘Level 1 Credit Default’ but will be placed in a ‘Level 1 No Authorisation’ state.
If the Party’s Credit Cover Percentage <= 75% then the ECVAA system will return the Party’s credit status to normal.

In all 3 cases, the ECVAA system will inform the operator of the end of the Level 1 Cure Period who will, in turn, inform the Party and BSCCo Ltd of the current status of the Party.

8: If a Party is in the ‘Level 1 No Authorisation’ state and the ‘Credit Default Authorisation’ flag is set, then the party will be placed in ‘Level 1 Credit Default’ immediately. A Level 1 Credit Default message will be reported to BMRA as described in requirement ECVAA-I036.

Conversely, if a Party is in ‘Level 1 Credit Default’ and the ‘Credit Default Authorisation’ flag is unset, then the Party will be placed in a ‘Level 1 No Authorisation’ state. A Cleared Level 1 Credit Default message will be reported to BMRA as described in requirement ECVAA-I036.

In both cases, the ECVAA system will inform the operator of the end of the change in the ‘Credit Default Authorisation’ flag who will, in turn, inform the Party and BSCCo Ltd of the current status of the Party.

9: The ECVAA shall report accepted ECVN and MVRN components to the relevant BSC Parties, ECVNAs and MVRNAs at the end of each Settlement Day.

The ECVAA shall report a BSC Party’s Credit Cover Percentage (%) and Credit Limit (MWh) to the relevant BSC Party only at the end of each Settlement Day. Note: These will be the values calculated for/applicable to the last Settlement Period in the Settlement Day being reported.

The ECVAA shall report BSC Parties which have a Credit Cover Percentage > 80% and a ‘Credit Default Authorisation’ flag of Yes to other BSC Parties, ECVNAs and MVRNAs at the end of each Settlement Day.

The ECVAA shall report the above data including BSC Party’s Credit Cover Percentage and Credit Limit as described by requirement ECVAA-I014: Issue Notification Report.

10: Authorisation is required from the BSCCo Ltd before the ‘Credit Default Authorisation’ flag can be altered for a BSC Party, unless it is unset by the ECVAA system as described in item 11.

11: If a Party’s Credit Cover Percentage becomes <= 75%:

If the Party is in a Level 1 Cure Period, then the Cure Period will be terminated immediately. The ECVAA system will return the Party’s credit status to normal and will inform the operator of this event. The operator will then notify the Party and BSCCo Ltd that the Level 1 Cure Period has ended and that Credit Cover Percentage has fallen to 75% or less.
If the Party is in ‘Level 1 Credit Default’ then the ECVAA system will return the Party’s credit status to normal and will inform the operator of this event. The operator will then notify the Party and BSCCo Ltd and the Party that ‘Level 1 Credit Default’ has been cleared and that Credit Cover Percentage has fallen to 75% or less. A Cleared Level 1 Credit Default message will be reported to BMRA as described in requirement ECVAA-I036.
If the Party is in ‘Level 1 No Authorisation’ then the ECVAA system will return the Party’s credit status to normal and will inform the operator of this event. The operator will then notify the Party and BSCCo Ltd that Credit Cover Percentage has fallen to 75% or less and the Party has been returned to the normal state.
If ‘Credit Default Authorisation’ flag is set, then it will be unset by the ECVAA system.

12: Any ECVAA-I036 reports related to ‘Level 1 Credit Default’ should be issued as soon as practicable following expiry of the Level 1 Cure Period.

13: If a Party is in a Query Period, a Level 1 Cure Period, or the ‘Level 1 No Authorisation’ state, and ‘Credit Default Authorisation’ flag is not set, then the Party can, with authorisation from BSCCo Ltd, be returned immediately to the normal state. Resetting the Party’s Credit Default status in this way will immediately terminate any Query or Level 1 Cure Periods currently in effect for that Party.

14: The ‘Credit Default Authorisation’ flag can only be set when instructed by BSCCo Ltd.

The ‘Credit Default Authorisation’ flag will be unset when instructed by BSCCo Ltd who will specify one of the following reasons:

The Authorisation is withdrawn at BSCCo Ltd’s discretion.
The Authorisation is withdrawn because it has been determined that the Party’s Credit Cover Percentage did not, and has not since, breached the 80% of Credit Limit level, i.e. as a result of a trading dispute.
The Authorisation is withdrawn because the Party has been withdrawn from the BSC.

The ‘Credit Default Authorisation’ flag will be unset automatically by the ECVAA system when it is deemed that the Party’s Credit Cover Percentage has fallen to 75% or less.

The conditions under which the ‘Credit Default Authorisation’ flag was unset will be included in the ECVAA-I036 flow sent to the BMRA.

The following is given only to illustrate and summarise the requirements detailed above that are related to Level 1 default :

When a Party’s Credit Cover Percentage becomes > 80% for the first time the ECVAA will inform the Party and the BSCCo Ltd. When they have been informed, the end of the Query Period is set (point 4)
At the end of the Query Period, the Party’s status can be returned to normal or the Level 1 Cure Period is initiated (see point 5).
During the Level 1 Cure Period, the Party’s status can be returned to normal if it’s Credit Cover Percentage is calculated to be <= 75% for any Settlement Period during the Level 1 Cure Period (see points 6 and 11).
At, or after, the end of the Level 1 Cure Period, the Party can go into ‘Level 1 Credit Default’ or ‘Level 1 No Authorisation’, or be returned to normal, depending on Credit Cover Percentage and the Authorisation status (see points 7, 8, and 11)

Non Functional Requirement:

The ECVAA Service shall complete the Credit Check process, including issuing rejections, within 15 minutes of the Submission Deadline for the Settlement Period being processed.

Interfaces:

Related interface requirements:

ECVAA-I001: Receive Registration Data

ECVAA-I004: Receive Energy Contract Volume Notifications

ECVAA-I005: Receive Metered Volume Reallocation Notifications

ECVAA-I006: Receive Credit Limit Data

ECVAA-I009: Issue Energy Contract Volume Notification Feedback

ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback

ECVAA-I021: Issue Credit Limit Warning

ECVAA-I036: Publish Credit Default Report

5.8 ECVAA-F008: Aggregate Energy Contract Volumes

Requirement ID: ECVAA-F008	Status: Mandatory	Title: Aggregate Energy Contract Volumes	BSC Reference: ECVAA SD: 8.4 ECVAA BPM: 3.3 CR012
Man/auto: Automatic	Frequency: Daily	Volumes: High
Functional Requirement: The following requirements are discussed with reference to matched components of ECVNs and MVRNs
1: The ECVAA shall aggregate energy contract volumes once a day. At the end of each Settlement Day, the ECVAA shall aggregate matched energy contract volumes (which have not been rejected during credit checking, see ECVAA-F007 point 2) for that Settlement Day in order that they may be reported to the SAA as described by requirement ECVAA-I011: Issue Account Bilateral Contract Volume Report.
2: The ECVAA shall also aggregate revised energy contract volumes as required to support disputes.
3: The ECVAA shall aggregate valid matched Energy Contract Volume Notifications by Energy Account and Settlement Period giving the Account Bilateral Contract Volume in MWh for each Energy Account for each Settlement Period according to the following formula: QABC_aj = Σ_z,b ECQ_zabj Where QABC_aj is the Account Bilateral Contract Volume in MWh (sale if positive, purchase if negative) for Energy Account a and Settlement Period j.
Non Functional Requirement:
The ECVAA Service shall aggregate and report Energy Contract Volumes to the SAA once a day in order that the SAA can perform settlements according to the Settlement Calendar. Note: The ECVAA shall also report matched MVRNs to the SAA once per day (as described by Interface I012: Issue Metered Volume Reallocation Notification Report)
Interfaces: Related interface requirements: ECVAA-I011: Issue Account Bilateral Contract Volume Report

Requirement ID:

ECVAA-F008

Status:

Mandatory

Title:

Aggregate Energy Contract Volumes

BSC Reference:

ECVAA SD: 8.4

ECVAA BPM: 3.3

CR012

Man/auto:

Automatic

Frequency:

Daily

Volumes:

High

Functional Requirement:

The following requirements are discussed with reference to matched components of ECVNs and MVRNs

1: The ECVAA shall aggregate energy contract volumes once a day. At the end of each Settlement Day, the ECVAA shall aggregate matched energy contract volumes (which have not been rejected during credit checking, see ECVAA-F007 point 2) for that Settlement Day in order that they may be reported to the SAA as described by requirement ECVAA-I011: Issue Account Bilateral Contract Volume Report.

2: The ECVAA shall also aggregate revised energy contract volumes as required to support disputes.

3: The ECVAA shall aggregate valid matched Energy Contract Volume Notifications by Energy Account and Settlement Period giving the Account Bilateral Contract Volume in MWh for each Energy Account for each Settlement Period according to the following formula:

QABC_aj = Σ_z,b ECQ_zabj

Where QABC_aj is the Account Bilateral Contract Volume in MWh (sale if positive, purchase if negative) for Energy Account a and Settlement Period j.

Non Functional Requirement:

The ECVAA Service shall aggregate and report Energy Contract Volumes to the SAA once a day in order that the SAA can perform settlements according to the Settlement Calendar.

Note: The ECVAA shall also report matched MVRNs to the SAA once per day (as described by Interface I012: Issue Metered Volume Reallocation Notification Report)

Interfaces:

Related interface requirements:

ECVAA-I011: Issue Account Bilateral Contract Volume Report

5.9 ECVAA-F009: Process Exception Data

Requirement ID: ECVAA-F009	Status: Mandatory	Title: Process Exception Data	BSC Reference:
Man/auto: Automatic	Frequency: As required	Volumes: Low
Functional Requirement:
The ECVAA shall receive Exception Reports from the SAA as described by requirement ECVAA-I020: Receive Exception Report. The Exception Report data shall comprise: Exception data The ECVAA shall process Exception data as follows.
The ECVAA shall receive Exception data automatically and allow an Operator to view the nature and description of the Exception. It is subsequently the responsibility of the Operator or a Supervisor to take the necessary actions to resolve the exception.
Interfaces: Related interface requirements: ECVAA-I020: Receive Exception Report

Requirement ID:

ECVAA-F009

Status:

Mandatory

Title:

Process Exception Data

BSC Reference:

Man/auto:

Automatic

Frequency:

As required

Volumes:

Low

Functional Requirement:

The ECVAA shall receive Exception Reports from the SAA as described by requirement ECVAA-I020: Receive Exception Report. The Exception Report data shall comprise:

Exception data

The ECVAA shall process Exception data as follows.

The ECVAA shall receive Exception data automatically and allow an Operator to view the nature and description of the Exception. It is subsequently the responsibility of the Operator or a Supervisor to take the necessary actions to resolve the exception.

Interfaces:

Related interface requirements:

ECVAA-I020: Receive Exception Report

5.10 ECVAA-F010: Calculate Party Indebtedness

Requirement ID: ECVAA-F010	Status: Mandatory	Title: Calculate Party Indebtedness	BSC Reference: CR012, CR012b, CR028, P2, CP869, P140, P215, P310
Man/auto: Automatic	Frequency: Every Half Hour	Volumes: High
Functional Requirement:
The ECVAA shall calculate the cumulative Indebtedness of a BSC Party (including NETSO) over the last 29 days up to and including Settlement Period j. A number of intermediate calculations are required to determine the cumulative Indebtedness. For the avoidance of doubt, the Notification Volumes processed are those matched volumes accepted by the credit check process.
1: Calculate the Credit Assessment Credited Energy Volume (CAQCE_iaj) as follows. The calculation is different depending on the BM Unit’s characteristics: For Interconnector BM Units and BM Units which have a Credit Qualifying Status of “True” the calculation defined in 1b applies. For all other BM Units (except Secondary BM Units) the calculation defined in 1a applies. For Secondary BM Units the Credit Assessment Credited Energy Volume is not calculated.
1a: Calculation of CAQCE_iajfor all BM Units that are not Interconnector BM Units or that have a Credit Qualifying Status of “False”: For the purpose of this calculation BM Units will be categorised as either ‘Demand’ or ‘Generation’ based on the following rules: A Demand BM Unit is one where either: Its Production / Consumption Flag is set to Consumption; or Its Demand-in-Production Flag is set to “True”. A Generation BM Unit is one where its Production / Consumption Flag is set to Production and its Demand-in-Production Flag is set to “False”. ECVAA will determine whether to use a Working Day (WD) or Non-Working Day (NWD) variant of import and export capability for a given BM Unit, using a Bank Holidays calendar that it holds. For BM Units with a GSP Group Id of ‘_N’ or ‘_P’ (i.e. Scotland), ECVAA will consider a day to be a Non-Working Day if it falls on Saturday or Sunday, or if the day falls on a Scottish Bank Holiday. For BM Units with any other GSP Group Id, ECVAA will consider a day to be a Non-Working Day if it falls on Saturday or Sunday, or if the day falls on an England & Wales Bank Holiday. For Demand BM Units, which are not Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Subsidiary Accounts (a<>A) for Settlement Period j: For Working Days: CAQCE_iaj = 0.5 * WDBMCAIC_ij (QMPR_iaj/100) + QMFR_iaj or For Non-Working Days: CAQCE_iaj = 0.5 NWDBMCAIC_ij (QMPR_iaj/100) + QMFR_iaj or For Generation BM Units, or Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Subsidiary Accounts (a<>A) for Settlement Period j: For Working Days: CAQCE_iaj =0.5 WDBMCAEC_ij (QMPR_iaj/100) + QMFR_iaj For Non-Working Days: CAQCE_iaj =0.5 NWDBMCAEC_ij (QMPR_iaj/100) + QMFR_iaj where a≠A, and A is the Lead Energy Account for BM Unit i; QMFR_iaj is the Metered Volume Fixed Reallocation, a fixed volume in MWh, assigned to Energy Account a from BM Unit i in Settlement Period j; QMPR_iaj is the Metered Volume Percentage Reallocation, the percentage of the BM Unit Capacity before fixed volumes have been applied, which is allocated to Energy Account a from BM Unit i in Settlement Period j. For Demand BM Units, which are not Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Lead Energy Accounts (a=A) for Settlement Period j: For Working Days: CAQCE_iAj = 0.5 WDBMCAIC_ij - Σ_a_≠_A CAQCE_iaj For Non-Working Days: CAQCE_iAj = 0.5 * NWDBMCAIC_ij - Σ_a_≠_A CAQCE_iaj For Generation BM Units, or Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Lead Energy Accounts (a=A) for Settlement Period j For Working Days: CAQCE_iAj = 0.5 * WDBMCAEC_ij - Σ_a_≠_A CAQCE_iaj For Non-Working Days: CAQCE_iAj = 0.5 * NWDBMCAEC_ij - Σ_a_≠_A CAQCE_iaj Where Σ_a_≠_A represents a sum over all values of a, other than a=A.
1b: Calculation of CAQCE_iajfor Interconnector BM Units and BM Units that have a Credit Qualifying Status of “True”: If the Period FPN (FPN_ij) has been calculated for the current Settlement Period j, using ECVAA-F025 Calculate Period Final Physical Notification Volumes, then for Subsidiary Accounts: CAQCE_iaj = FPN_ij *(QMPR_iaj/100) + QMFR_iaj while for Lead Energy Accounts: CAQCE_iAj = FPN_ij - Σ_a_≠_A CAQCE_iaj If FPN_ij has not been calculated for the current Settlement Period j, but has been calculated for the previous Settlement Period j-1, then FPN_i(j-1)should be used in place of FPN_ijin the above equations. Otherwise if FPN_ij has been calculated for the previous Settlement Period j-2, then FPN_i(j-2)should be used in place of FPN_ijin the above equations, and so on. If FPN_ij has not been calculated previously for this BM Unit, then it will default to a pre-defined constant value, which will be zero. For any earlier Settlement Periods where the Period FPN for this BM Unit has been calculated since the previous run of the Credit Check, recalculate CAQCE_iaj. This recalculation is only done when data is received from NETSO for Settlement Periods in the Credit Check window (the last 29 days) where Actual Energy Indebtedness values have not been received
2: Aggregate Energy Contract Volume data (ECQ_zabj) to determine QABC_pj for each Party (values for Production and Consumption Accounts are summed into one value per Party).
3: Aggregate Credit Assessment Credited Energy Volume (CAQCE_iaj) over all BM Units to determine the Account CA Credited Energy Volume CAQCE_aj for each Party’s Production and Consumption Account (values are summed separately giving a single value for each Energy Account). For any earlier Settlement Periods where CAQCE_iajhas been recalculated as described in the last paragraph of section 1b, recalculate CAQCE_aj.
4: Aggregate Credit Assessment Credited Energy Volume (CAQCE_iaj) over all BM Units and both Energy Accounts to determine CAQCE_pj for each Party. For any earlier Settlement Periods where CAQCE_ajhas been recalculated as described in the last paragraph of section 3, recalculate CAQCE_pj.
5: Calculate the Credit Assessment Energy Indebtedness of each BSC Party for Settlement Period j (CEI_pj) using (QABC_pj - CAQCE_pj). The Credit Assessment Energy Indebtedness (CEI_pj, in MWh) of a Virtual Lead Party p that holds a Virtual Balancing Account in relation to a Settlement Period shall be determined as follows: CEI_pj = 0 For any earlier Settlement Periods where CAQCE_pjhas been recalculated as described in the last paragraph of section 4, recalculate CEI_pj.
6: Add the Account CA Credited Energy Volume (CAQCE_aj) for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Account Cumulative CA Credited Energy Volume (CCAQCE_aj). For any earlier Settlement Periods where CAQCE_ajhas been recalculated as described in the last paragraph of section 3, include the new value in the sum in place of the old value. Add the Account Bilateral Contract Volume (QABC_aj, calculated in ECVAA-F008)for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Account Cumulative Energy Contract Volume (CQABC_aj). Add the Credit Assessment Energy Indebtedness (CEI_pj) for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Cumulative Credit Assessment Energy Indebtedness (CCEI_pj). For any earlier Settlement Periods where CEI_pjhas been recalculated as described in the last paragraph of section 5, include the new value in the sum in place of the old value. The ECVAA shall store the cumulative Volume and Indebtedness values (calculated above) for each Settlement Day in its systems.
7: Calculate Metered Energy Indebtedness (MEI_pd) for BSC Parties for those settlement days for which they have registered effective BM Units with a Credit Qualifying Status of “True” and for which BM Unit Credit Cover Meter Volume Data have been received from CDCA. Calculate the Metered Credit Assessment Energy Volume (MAQCE_iaj) as follows: Where Metered Volume data was determined by the CDCA for the BM Unit in the Credit Cover Volume Allocation Run for Settlement Period j, then for Subsidiary Accounts: MAQCE_iaj = QM_ij * (QMPR_iaj/100) + QMFR_iaj while for Lead Energy Accounts: MAQCE_iaj = QM_ij - Σ_a MAQCE_iaj Where Metered Volume data was not determined by the CDCA for the BM Unit in the Credit Cover Volume Allocation Run for Settlement Period j then: MAQCE_iaj = CAQCE_iaj For Secondary BM Units the Metered Credit Assessment Credited Energy Volumes is not calculated. The Metered Energy Indebtedness (MEI_pj) of a Trading Party p in relation to a Settlement Period j shall be determined as: MEI_pj = – (Σ_a,i MAQCE_iaj – Σ_a QABC_aj ) Where Σa extends to the Production Energy Account and Consumption Energy Account of the Trading Party. The Metered Energy Indebtedness (MEI_pj, in MWh) of a Virtual Lead Party p that holds a Virtual Balancing Account in relation to a Settlement Period shall be determined as follows: MEI_pj = 0 The ECVAA shall store Metered Energy Indebtedness values in its systems. The Metered Energy Indebtedness values will only become available for subsequent processing at the Submission Deadline for Settlement Period 1 of a Settlement Day.
8: Calculate Actual Energy Indebtedness (AEI_pd) for BSC Parties for those settlement days for which Interim Initial Credit/Debit reports have been received from SAA as follows: Trading Charges = Energy Imbalance Cashflow + Information Imbalance Charge + Non-delivery Charge + Residual Cashflow Reallocation + BM Payments +Daily Party RR Cashflow + Daily Party RR Instruction Deviation Cashflow AEI_pd = Trading Charges / CAP Where CAP is the Credit Assessment Price effective on day d as received via ECVAA-I032. The ECVAA shall store Actual Energy Indebtedness values in its systems. The Actual Energy Indebtedness values will only become available for subsequent processing at the Submission Deadline for Settlement Period 1 of a Settlement Day.
9: The Total indebtedness for a BSC Party for a settlement day, (TEI_pd), shall be defined as: If a value for (AEI_pd) is available from step 7, then TEI_pd = AEI_pd Otherwise, if a value for (MEI_pd) is available from step 7, then TEI_pd = MEI_pd Otherwise, TEI_pd = the sum of Credit Assessment Energy Indebtedness as calculated in Step 5 for the day d The ECVAA shall have the ability to revise the Total indebtedness for a BSC Party for a Settlement Day within its systems in support of disputes.
10: Calculate the Energy Indebtedness for Party (EI_pj), as the sum of TEI_pd for the current Settlement Day and the previous 28 Days.
Interfaces: Related interface requirements: ECVAA-I001: Receive Registration Data ECVAA-I004: Receive Energy Contract Volume Notifications ECVAA-I005: Receive Metered Volume Reallocation Notifications ECVAA-I006: Receive Credit Limit Data ECVAA-I015: Receive BM Unit Credit Cover Meter Volume Data ECVAA-I032: Receive Credit Assessment Price ECVAA-I033: Receive Credit/Debit Report ECVAA-I048: Receive Physical Notification Data

Requirement ID:

ECVAA-F010

Status:

Mandatory

Title:

Calculate Party Indebtedness

BSC Reference:

CR012, CR012b, CR028, P2, CP869, P140, P215, P310

Man/auto:

Automatic

Frequency:

Every Half Hour

Volumes:

High

Functional Requirement:

The ECVAA shall calculate the cumulative Indebtedness of a BSC Party (including NETSO) over the last 29 days up to and including Settlement Period j.

A number of intermediate calculations are required to determine the cumulative Indebtedness.

For the avoidance of doubt, the Notification Volumes processed are those matched volumes accepted by the credit check process.

1: Calculate the Credit Assessment Credited Energy Volume (CAQCE_iaj) as follows.

The calculation is different depending on the BM Unit’s characteristics: For Interconnector BM Units and BM Units which have a Credit Qualifying Status of “True” the calculation defined in 1b applies. For all other BM Units (except Secondary BM Units) the calculation defined in 1a applies. For Secondary BM Units the Credit Assessment Credited Energy Volume is not calculated.

1a: Calculation of CAQCE_iajfor all BM Units that are not Interconnector BM Units or that have a Credit Qualifying Status of “False”:

For the purpose of this calculation BM Units will be categorised as either ‘Demand’ or ‘Generation’ based on the following rules:

A Demand BM Unit is one where either:

Its Production / Consumption Flag is set to Consumption; or
Its Demand-in-Production Flag is set to “True”.

A Generation BM Unit is one where its Production / Consumption Flag is set to Production and its Demand-in-Production Flag is set to “False”.

ECVAA will determine whether to use a Working Day (WD) or Non-Working Day (NWD) variant of import and export capability for a given BM Unit, using a Bank Holidays calendar that it holds. For BM Units with a GSP Group Id of ‘_N’ or ‘_P’ (i.e. Scotland), ECVAA will consider a day to be a Non-Working Day if it falls on Saturday or Sunday, or if the day falls on a Scottish Bank Holiday. For BM Units with any other GSP Group Id, ECVAA will consider a day to be a Non-Working Day if it falls on Saturday or Sunday, or if the day falls on an England & Wales Bank Holiday.

For Demand BM Units, which are not Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Subsidiary Accounts (a<>A) for Settlement Period j:

For Working Days:

CAQCE_iaj = 0.5 * WDBMCAIC_ij *(QMPR_iaj/100) + QMFR_iaj or

For Non-Working Days:

CAQCE_iaj = 0.5 * NWDBMCAIC_ij *(QMPR_iaj/100) + QMFR_iaj or

For Generation BM Units, or Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Subsidiary Accounts (a<>A) for Settlement Period j:

For Working Days:

CAQCE_iaj =0.5 * WDBMCAEC_ij *(QMPR_iaj/100) + QMFR_iaj

For Non-Working Days:

CAQCE_iaj =0.5 * NWDBMCAEC_ij *(QMPR_iaj/100) + QMFR_iaj

where a≠A, and A is the Lead Energy Account for BM Unit i; QMFR_iaj is the Metered Volume Fixed Reallocation, a fixed volume in MWh, assigned to Energy Account a from BM Unit i in Settlement Period j; QMPR_iaj is the Metered Volume Percentage Reallocation, the percentage of the BM Unit Capacity before fixed volumes have been applied, which is allocated to Energy Account a from BM Unit i in Settlement Period j.

For Demand BM Units, which are not Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Lead Energy Accounts (a=A) for Settlement Period j:

For Working Days:

CAQCE_iAj = 0.5 * WDBMCAIC_ij - Σ_a_≠_A CAQCE_iaj

For Non-Working Days:

CAQCE_iAj = 0.5 * NWDBMCAIC_ij - Σ_a_≠_A CAQCE_iaj

For Generation BM Units, or Supplier BM Units with a Generation Capacity greater than zero and a Demand Capacity equal to zero, for Lead Energy Accounts (a=A) for Settlement Period j

For Working Days:

CAQCE_iAj = 0.5 * WDBMCAEC_ij - Σ_a_≠_A CAQCE_iaj

For Non-Working Days:

CAQCE_iAj = 0.5 * NWDBMCAEC_ij - Σ_a_≠_A CAQCE_iaj

Where Σ_a_≠_A represents a sum over all values of a, other than a=A.

1b: Calculation of CAQCE_iajfor Interconnector BM Units and BM Units that have a Credit Qualifying Status of “True”:

If the Period FPN (FPN_ij) has been calculated for the current Settlement Period j, using ECVAA-F025 Calculate Period Final Physical Notification Volumes, then for Subsidiary Accounts:

CAQCE_iaj = FPN_ij *(QMPR_iaj/100) + QMFR_iaj

while for Lead Energy Accounts:

CAQCE_iAj = FPN_ij - Σ_a_≠_A CAQCE_iaj

If FPN_ij has not been calculated for the current Settlement Period j, but has been calculated for the previous Settlement Period j-1, then FPN_i(j-1)should be used in place of FPN_ijin the above equations. Otherwise if FPN_ij has been calculated for the previous Settlement Period j-2, then FPN_i(j-2)should be used in place of FPN_ijin the above equations, and so on. If FPN_ij has not been calculated previously for this BM Unit, then it will default to a pre-defined constant value, which will be zero.

For any earlier Settlement Periods where the Period FPN for this BM Unit has been calculated since the previous run of the Credit Check, recalculate CAQCE_iaj. This recalculation is only done when data is received from NETSO for Settlement Periods in the Credit Check window (the last 29 days) where Actual Energy Indebtedness values have not been received

2: Aggregate Energy Contract Volume data (ECQ_zabj) to determine QABC_pj for each Party (values for Production and Consumption Accounts are summed into one value per Party).

3: Aggregate Credit Assessment Credited Energy Volume (CAQCE_iaj) over all BM Units to determine the Account CA Credited Energy Volume CAQCE_aj for each Party’s Production and Consumption Account (values are summed separately giving a single value for each Energy Account).

For any earlier Settlement Periods where CAQCE_iajhas been recalculated as described in the last paragraph of section 1b, recalculate CAQCE_aj.

4: Aggregate Credit Assessment Credited Energy Volume (CAQCE_iaj) over all BM Units and both Energy Accounts to determine CAQCE_pj for each Party.

For any earlier Settlement Periods where CAQCE_ajhas been recalculated as described in the last paragraph of section 3, recalculate CAQCE_pj.

5: Calculate the Credit Assessment Energy Indebtedness of each BSC Party for Settlement Period j (CEI_pj) using (QABC_pj - CAQCE_pj).

The Credit Assessment Energy Indebtedness (CEI_pj, in MWh) of a Virtual Lead Party p that holds a Virtual Balancing Account in relation to a Settlement Period shall be determined as follows:

CEI_pj = 0

For any earlier Settlement Periods where CAQCE_pjhas been recalculated as described in the last paragraph of section 4, recalculate CEI_pj.

6: Add the Account CA Credited Energy Volume (CAQCE_aj) for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Account Cumulative CA Credited Energy Volume (CCAQCE_aj). For any earlier Settlement Periods where CAQCE_ajhas been recalculated as described in the last paragraph of section 3, include the new value in the sum in place of the old value.

Add the Account Bilateral Contract Volume (QABC_aj, calculated in ECVAA-F008)for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Account Cumulative Energy Contract Volume (CQABC_aj).

Add the Credit Assessment Energy Indebtedness (CEI_pj) for the current Settlement Period j to the cumulative value for the current Settlement Day (which also includes the previous 28 days) to give the Cumulative Credit Assessment Energy Indebtedness (CCEI_pj). For any earlier Settlement Periods where CEI_pjhas been recalculated as described in the last paragraph of section 5, include the new value in the sum in place of the old value.

The ECVAA shall store the cumulative Volume and Indebtedness values (calculated above) for each Settlement Day in its systems.

7: Calculate Metered Energy Indebtedness (MEI_pd) for BSC Parties for those settlement days for which they have registered effective BM Units with a Credit Qualifying Status of “True” and for which BM Unit Credit Cover Meter Volume Data have been received from CDCA.

Calculate the Metered Credit Assessment Energy Volume (MAQCE_iaj) as follows:

Where Metered Volume data was determined by the CDCA for the BM Unit in the Credit Cover Volume Allocation Run for Settlement Period j, then for Subsidiary Accounts:

MAQCE_iaj = QM_ij * (QMPR_iaj/100) + QMFR_iaj

while for Lead Energy Accounts:

MAQCE_iaj = QM_ij - Σ_a MAQCE_iaj

Where Metered Volume data was not determined by the CDCA for the BM Unit in the Credit Cover Volume Allocation Run for Settlement Period j then:

MAQCE_iaj = CAQCE_iaj

For Secondary BM Units the Metered Credit Assessment Credited Energy Volumes is not calculated.

The Metered Energy Indebtedness (MEI_pj) of a Trading Party p in relation to a Settlement Period j shall be determined as:

MEI_pj = – (Σ_a,i MAQCE_iaj – Σ_a QABC_aj )

Where Σa extends to the Production Energy Account and Consumption Energy Account of the Trading Party.

The Metered Energy Indebtedness (MEI_pj, in MWh) of a Virtual Lead Party p that holds a Virtual Balancing Account in relation to a Settlement Period shall be determined as follows:

MEI_pj = 0

The ECVAA shall store Metered Energy Indebtedness values in its systems.

The Metered Energy Indebtedness values will only become available for subsequent processing at the Submission Deadline for Settlement Period 1 of a Settlement Day.

8: Calculate Actual Energy Indebtedness (AEI_pd) for BSC Parties for those settlement days for which Interim Initial Credit/Debit reports have been received from SAA as follows:

Trading Charges = Energy Imbalance Cashflow + Information Imbalance Charge

+ Non-delivery Charge + Residual Cashflow Reallocation

+ BM Payments +Daily Party RR Cashflow + Daily Party RR Instruction Deviation Cashflow

AEI_pd = Trading Charges / CAP

Where CAP is the Credit Assessment Price effective on day d as received via ECVAA-I032.

The ECVAA shall store Actual Energy Indebtedness values in its systems.

The Actual Energy Indebtedness values will only become available for subsequent processing at the Submission Deadline for Settlement Period 1 of a Settlement Day.

9: The Total indebtedness for a BSC Party for a settlement day, (TEI_pd), shall be defined as:

If a value for (AEI_pd) is available from step 7, then TEI_pd = AEI_pd

Otherwise, if a value for (MEI_pd) is available from step 7, then TEI_pd = MEI_pd

Otherwise, TEI_pd = the sum of Credit Assessment Energy Indebtedness as calculated in Step 5 for the day d

The ECVAA shall have the ability to revise the Total indebtedness for a BSC Party for a Settlement Day within its systems in support of disputes.

10: Calculate the Energy Indebtedness for Party (EI_pj), as the sum of TEI_pd for the current Settlement Day and the previous 28 Days.

Interfaces:

Related interface requirements:

ECVAA-I001: Receive Registration Data

ECVAA-I004: Receive Energy Contract Volume Notifications

ECVAA-I005: Receive Metered Volume Reallocation Notifications

ECVAA-I006: Receive Credit Limit Data

ECVAA-I015: Receive BM Unit Credit Cover Meter Volume Data

ECVAA-I032: Receive Credit Assessment Price

ECVAA-I033: Receive Credit/Debit Report

ECVAA-I048: Receive Physical Notification Data

5.11 ECVAA-F011: Process Credit Cover Minimum Eligible Amount Request

Requirement ID: ECVAA-F011	Status: Mandatory	Title: Process Credit Cover Minimum Eligible Amount Request	BSC Reference: CP519, CP1313
Man/auto: Manual	Frequency: On request	Volumes: Low
Functional Requirement: The ECVAA shall receive Credit Cover Minimum Eligible Amount Requests from BSC Parties as described by requirement ECVAA-I024: Receive Credit Cover Minimum Eligible Amount Request. The request shall comprise: Credit Cover Minimum Eligible Amount Request The ECVAA shall process a Credit Cover Minimum Eligible Amount Request as follows:
1. The ECVAA shall, on the date of receipt of the Credit Cover Minimum Eligible Amount Request, determine whether or not the requesting Participant is in Section H Default. If the Participant is in Section H Default then ECVAA shall pass the MEA request onto BSCCo Ltd, via the ECVAA-I026, and carry out no further actions against this request. If the Participant is not in Section H Default then ECVAA shall further process the request as outlined below.
2. The ECVAA shall determine the Minimum Eligible Amount for the specified BSC Party according to either the 75% or 80% calculation rule. The 75% rule is used in all cases unless specifically advised by BSCCo. If the 75% rule is used then the Minimum Eligible Amount is defined as the lowest amount for which the BSC Party’s Credit Cover Percentage, if it were redetermined for each Settlement Period in the Waiting Period on the assumption that the BSC Party’s Credit Limit were equal to that amount, would be not greater than 75% in relation to any Settlement Period. The Waiting Period is the period of 10 Settlement Days commencing on the Settlement Day of receipt of the Credit Cover Minimum Eligible Amount Request by the ECVAA. If the 80% rule is used then the Minimum Eligible Amount is defined as the lowest amount for which the BSC Party’s Credit Cover Percentage, if it were redetermined for each Settlement Period in the Waiting Period on the assumption that the BSC Party’s Credit Limit were equal to that amount, would be not greater than 80% in relation to any Settlement Period. The Waiting Period is the period of 1 Settlement Day commencing on the Settlement Day of receipt of the Credit Cover Minimum Eligible Amount Request by the ECVAA.
3: The ECVAA shall determine the Minimum Eligible Amount for the specified BSC Party on the first Working Day after the expiry of the Waiting Period.
4: The ECVAA shall notify BSCCo Ltd, the FAA and the relevant BSC Party (through ECVAA-I025: Issue Credit Cover Minimum Eligible Amount Report) of the calculated Minimum Eligible Amount for the BSC Party on the first Working Day after the expiry of the Waiting Period.
Non Functional Requirement:
Interfaces: Related interface requirements: ECVAA-I024: Receive Credit Cover Minimum Eligible Amount Request ECVAA-I025: Issue Credit Cover Minimum Eligible Amount Report ECVAA-I026: Issue Minimum Eligible Amount Rule Request ECVAA-I027: Receive Notification of BSC Party in Section H Default

Requirement ID:

ECVAA-F011

Status:

Mandatory

Title:

Process Credit Cover Minimum Eligible Amount Request

BSC Reference:

CP519, CP1313

Man/auto:

Manual

Frequency:

On request

Volumes:

Low

Functional Requirement:

The ECVAA shall receive Credit Cover Minimum Eligible Amount Requests from BSC Parties as described by requirement ECVAA-I024: Receive Credit Cover Minimum Eligible Amount Request. The request shall comprise:

Credit Cover Minimum Eligible Amount Request

The ECVAA shall process a Credit Cover Minimum Eligible Amount Request as follows:

1. The ECVAA shall, on the date of receipt of the Credit Cover Minimum Eligible Amount Request, determine whether or not the requesting Participant is in Section H Default. If the Participant is in Section H Default then ECVAA shall pass the MEA request onto BSCCo Ltd, via the ECVAA-I026, and carry out no further actions against this request. If the Participant is not in Section H Default then ECVAA shall further process the request as outlined below.

2. The ECVAA shall determine the Minimum Eligible Amount for the specified BSC Party according to either the 75% or 80% calculation rule.

The 75% rule is used in all cases unless specifically advised by BSCCo.

If the 75% rule is used then the Minimum Eligible Amount is defined as the lowest amount for which the BSC Party’s Credit Cover Percentage, if it were redetermined for each Settlement Period in the Waiting Period on the assumption that the BSC Party’s Credit Limit were equal to that amount, would be not greater than 75% in relation to any Settlement Period. The Waiting Period is the period of 10 Settlement Days commencing on the Settlement Day of receipt of the Credit Cover Minimum Eligible Amount Request by the ECVAA.

If the 80% rule is used then the Minimum Eligible Amount is defined as the lowest amount for which the BSC Party’s Credit Cover Percentage, if it were redetermined for each Settlement Period in the Waiting Period on the assumption that the BSC Party’s Credit Limit were equal to that amount, would be not greater than 80% in relation to any Settlement Period. The Waiting Period is the period of 1 Settlement Day commencing on the Settlement Day of receipt of the Credit Cover Minimum Eligible Amount Request by the ECVAA.

3: The ECVAA shall determine the Minimum Eligible Amount for the specified BSC Party on the first Working Day after the expiry of the Waiting Period.

4: The ECVAA shall notify BSCCo Ltd, the FAA and the relevant BSC Party (through ECVAA-I025: Issue Credit Cover Minimum Eligible Amount Report) of the calculated Minimum Eligible Amount for the BSC Party on the first Working Day after the expiry of the Waiting Period.

Non Functional Requirement:

Interfaces:

Related interface requirements:

ECVAA-I024: Receive Credit Cover Minimum Eligible Amount Request

ECVAA-I025: Issue Credit Cover Minimum Eligible Amount Report

ECVAA-I026: Issue Minimum Eligible Amount Rule Request

ECVAA-I027: Receive Notification of BSC Party in Section H Default

5.12 ECVAA-F012: Process Volume Notification Nullification

Requirement ID: ECVAA-F012	Status: Mandatory	Title: Process Volume Notification Nullification	BSC Reference: P110 CP1169
Man/auto: Manual/Auto	Frequency: Ad-hoc	Volumes: Low
Functional Requirement: The ECVAA shall process Volume Notification Nullifications according to the procedure below as a result of either: Volume Notification Nullification Requests (VNNRs) received from BSC Parties as described by requirement ECVAA-I037: Receive Volume Notification Nullification Requests. or a request to nullify Notifications for a Party in Section H Default as authorised by the BSC Panel as described by requirement ECVAA-I049 Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default. The ECVAA shall process Volume Notification Nullifications as follows.
1: When received from a BSC Party (a VNNR), the ECVAA shall validate the received VNNR. The validation checks shall include the following: a. that the Authorised Signatory details are correct and correspond to a current level K signatory. b. checks to ensure that the following data have been submitted: Names and identifiers of the party and counter-party; Contact Details (name, email address and telephone number) for the party submitting the request; Production/consumption flags of the party’s and counter-party’s Energy Account Requested Nullification Effective Date and Period. c. that the submitted data is valid and consistent, i.e. data is of the correct type and format, is consistent with registration data received from the CRA, production/consumption flags are valid, etc.; d. if the VNNR is an amendment, that the Party VNNR Reference matches that of a previously submitted VNNR and, that a Volume Notification Nullification Confirmation Report has not yet been issued for the previously submitted VNNR; e. that all ECVNAAs and MVRNAAs between the two specified Energy Accounts have been terminated.
2: When received from a BSC Party (a VNNR), the ECVAA shall reject any VNNR that fails the validation described in point 1 above and notify only the party that submitted the request of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes. The ECVAA shall report rejected VNNRs as described by requirement ECVAA-I038: Issue Volume Notification Nullification Confirmation Report. The ECVAA shall also contact the party that submitted the request, by telephone, as soon as details of the rejection are known. Failure to make telephone contact will not delay nullification processing.
3: The ECVAA shall notify both the relevant BSC Parties of the acceptance of each valid Volume Notification Nullification for both VNNRs and requests to nullify Notifications for a Party in Section H Default. The ECVAA shall report confirmed Volume Notification Nullifications as described by requirement ECVAA-I038: Issue Volume Notification Nullification Confirmation Report. The ECVAA shall also contact the party and counter-party by telephone, as soon as details of the confirmation are known. Failure to make telephone contact with either the requesting Party or Counter-Party will not delay nullification processing.
4: The ECVAA shall input each valid Volume Notification Nullification into its systems. The data to be recorded for each valid Volume Notification Nullification shall include the following: Names and identifiers of the party and counter-party; Contact Details of the party and counter-party; Production/consumption flags of the party’s and counter-party’s Energy Account; Date and time of receipt of the Volume Notification Nullification; Requested Nullification Effective Date and Period. The ECVAA shall obtain the contact details for the counter-party from an appropriate contact list. The ECVAA shall determine the Nullification Effective Date and Period by calculating the Earliest Nullification Effective Date and Period, and comparing this to the Requested Nullification Effective Date and Period, as follows: If a Requested Nullification Effective Date and Period is supplied in the VNNR and is later than the Earliest Nullification Effective Date and Period, then the Requested Nullification Effective Date and Period shall be used as the Nullification Effective Date and Period; Otherwise, the Earliest Nullification Effective Date and Period shall be used as the Nullification Effective Date and Period. When received from a BSC Party (a VNNR), the Earliest Nullification Effective Date and Period shall be calculated as being the first Settlement Period for which the Submission Deadline has not passed at the time that the Volume Notification Nullification Confirmation Report is expected to be issued. Where a trading Dispute has been upheld, or a Section H default has been notified by BSCCo Ltd, the ECVAA shall set the Nullification Effective Date and Period equal to the Requested Nullification Effective Date and Period, even if the Submission Deadline has passed. In this case, the operator shall be presented with a warning which must be explicitly overridden prior to acceptance of the data.
5: For each valid Volume Notification Nullification, the ECVAA shall identify and set to zero (“nullify”) all notification volumes as held on behalf of each Notification Agent, and hence the matched volumes, where: the notification is between the Energy Accounts specified in the Volume Notification Nullification the notification is effective on or after the Nullification Effective Date and Period.
Non Functional Requirement: VNNCRs shall be issued during Business Hours only, where for the purposes of this requirement, Business Hours are defined as 9am-5pm on a Business Day. Furthermore, the ECVAA Service shall issue VNNCRs within 1 hour from receipt of the associated Volume Notification Nullification, where the hour is measured only during Business Hours. On receipt of a valid amendment VNNR from a Party, the hour will be re-started from the time of receipt of the amendment. If there are Associated Authorisation Termination Requests, these shall be processed, in sequence number / timestamp order, prior to processing the Volume Notification Nullification. The nullification process shall be prioritised, such that: earlier Settlement Period take precedence over later Settlement Periods MVRNs take precedence over ECVNs multiple Volume Notification Nullifications take equal precedence (i.e. are processed in parallel) Normal notification processing (ECVAA-F005: Process Energy Contract Volume Notifications and ECVAA-F006: Process Metered Volume Reallocation Notifications) shall take precedence over the processing of nullifications.
Interfaces: Related interface requirements: ECVAA-I037: Receive Volume Notification Nullification Request ECVAA-I038: Issue Volume Notification Nullification Confirmation Report

Requirement ID:

ECVAA-F012

Status:

Mandatory

Title:

Process Volume Notification Nullification

BSC Reference:

P110

CP1169

Man/auto:

Manual/Auto

Frequency:

Ad-hoc

Volumes:

Low

Functional Requirement:

The ECVAA shall process Volume Notification Nullifications according to the procedure below as a result of either:

Volume Notification Nullification Requests (VNNRs) received from BSC Parties as described by requirement ECVAA-I037: Receive Volume Notification Nullification Requests.

a request to nullify Notifications for a Party in Section H Default as authorised by the BSC Panel as described by requirement ECVAA-I049 Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default.

The ECVAA shall process Volume Notification Nullifications as follows.

1: When received from a BSC Party (a VNNR), the ECVAA shall validate the received VNNR. The validation checks shall include the following:

a. that the Authorised Signatory details are correct and correspond to a current level K signatory.

b. checks to ensure that the following data have been submitted:

Names and identifiers of the party and counter-party;
Contact Details (name, email address and telephone number) for the party submitting the request;
Production/consumption flags of the party’s and counter-party’s Energy Account
Requested Nullification Effective Date and Period.

c. that the submitted data is valid and consistent, i.e. data is of the correct type and format, is consistent with registration data received from the CRA, production/consumption flags are valid, etc.;

d. if the VNNR is an amendment, that the Party VNNR Reference matches that of a previously submitted VNNR and, that a Volume Notification Nullification Confirmation Report has not yet been issued for the previously submitted VNNR;

e. that all ECVNAAs and MVRNAAs between the two specified Energy Accounts have been terminated.

2: When received from a BSC Party (a VNNR), the ECVAA shall reject any VNNR that fails the validation described in point 1 above and notify only the party that submitted the request of the rejection, including the reasons for the rejection. Rejected data shall be retained for audit purposes.

The ECVAA shall report rejected VNNRs as described by requirement ECVAA-I038: Issue Volume Notification Nullification Confirmation Report. The ECVAA shall also contact the party that submitted the request, by telephone, as soon as details of the rejection are known. Failure to make telephone contact will not delay nullification processing.

3: The ECVAA shall notify both the relevant BSC Parties of the acceptance of each valid Volume Notification Nullification for both VNNRs and requests to nullify Notifications for a Party in Section H Default.

The ECVAA shall report confirmed Volume Notification Nullifications as described by requirement ECVAA-I038: Issue Volume Notification Nullification Confirmation Report. The ECVAA shall also contact the party and counter-party by telephone, as soon as details of the confirmation are known. Failure to make telephone contact with either the requesting Party or Counter-Party will not delay nullification processing.

4: The ECVAA shall input each valid Volume Notification Nullification into its systems. The data to be recorded for each valid Volume Notification Nullification shall include the following:

Names and identifiers of the party and counter-party;
Contact Details of the party and counter-party;
Production/consumption flags of the party’s and counter-party’s Energy Account;
Date and time of receipt of the Volume Notification Nullification;
Requested Nullification Effective Date and Period.

The ECVAA shall obtain the contact details for the counter-party from an appropriate contact list.

The ECVAA shall determine the Nullification Effective Date and Period by calculating the Earliest Nullification Effective Date and Period, and comparing this to the Requested Nullification Effective Date and Period, as follows:

If a Requested Nullification Effective Date and Period is supplied in the VNNR and is later than the Earliest Nullification Effective Date and Period, then the Requested Nullification Effective Date and Period shall be used as the Nullification Effective Date and Period;
Otherwise, the Earliest Nullification Effective Date and Period shall be used as the Nullification Effective Date and Period.

When received from a BSC Party (a VNNR), the Earliest Nullification Effective Date and Period shall be calculated as being the first Settlement Period for which the Submission Deadline has not passed at the time that the Volume Notification Nullification Confirmation Report is expected to be issued.

Where a trading Dispute has been upheld, or a Section H default has been notified by BSCCo Ltd, the ECVAA shall set the Nullification Effective Date and Period equal to the Requested Nullification Effective Date and Period, even if the Submission Deadline has passed. In this case, the operator shall be presented with a warning which must be explicitly overridden prior to acceptance of the data.

5: For each valid Volume Notification Nullification, the ECVAA shall identify and set to zero (“nullify”) all notification volumes as held on behalf of each Notification Agent, and hence the matched volumes, where:

the notification is between the Energy Accounts specified in the Volume Notification Nullification
the notification is effective on or after the Nullification Effective Date and Period.

Non Functional Requirement:

VNNCRs shall be issued during Business Hours only, where for the purposes of this requirement, Business Hours are defined as 9am-5pm on a Business Day. Furthermore, the ECVAA Service shall issue VNNCRs within 1 hour from receipt of the associated Volume Notification Nullification, where the hour is measured only during Business Hours. On receipt of a valid amendment VNNR from a Party, the hour will be re-started from the time of receipt of the amendment.

If there are Associated Authorisation Termination Requests, these shall be processed, in sequence number / timestamp order, prior to processing the Volume Notification Nullification.

The nullification process shall be prioritised, such that:

earlier Settlement Period take precedence over later Settlement Periods
MVRNs take precedence over ECVNs
multiple Volume Notification Nullifications take equal precedence (i.e. are processed in parallel)

Normal notification processing (ECVAA-F005: Process Energy Contract Volume Notifications and ECVAA-F006: Process Metered Volume Reallocation Notifications) shall take precedence over the processing of nullifications.

Interfaces:

Related interface requirements:

ECVAA-I037: Receive Volume Notification Nullification Request

ECVAA-I038: Issue Volume Notification Nullification Confirmation Report

5.13 ECVAA-F013 Manage ECVAA System Failure / Withdrawal

Requirement ID: ECVAA-F013	Status: Mandatory	Title: Manage ECVAA System Failure / Withdrawal	BSC Reference: CP739
Man/auto: Manual	Frequency: As Required	Volumes: Low
Functional Requirement:
1. When an ECVAA System Failure or ECVAA System Withdrawal occurs, the ECVAA shall: a. notify BSCCo Ltd as soon as possible after the beginning of the incident, giving the time at which it started, and b. in collaboration with BSCCo Ltd, use all reasonable efforts as soon as practicable to notify Trading Parties and Notification Agents of the incident and start time.
2. As soon as practicable after the end of the ECVAA System Failure or ECVAA System Withdrawal, the ECVAA shall notify BSCCo Ltd that the incident has ended.
3. In cases where an ECVAA System Failure or ECVAA System Withdrawal does not affect all Notification Agents, ECVAA shall also inform BSCCo Ltd of the Notification Agent(s) so affected;
4. In cases where a subset of Notification Agents are affected by an ECVAA System Failure, the ECVAA or BSCCo Ltd may determine that, in order to minimise disruption to Trading Parties’ operations, the Notification System should be withdrawn to allow time to remedy the problem. It may also be decided that such withdrawal should be carried out earlier than might otherwise be done by way of planned BSC Agent downtime. In this case: a. prior to the withdrawal, the ECVAA shall inform BSCCo Ltd of the time and date of the withdrawal, and b. following the repairs deemed necessary the ECVAA shall restore the Notification System to operation as soon as practicably possible.
Non Functional Requirement
An ECVAA System Failure is defined as a failure or breakdown such that any of the following occur: Notification Agents are unable to submit data to the ECVAA; the ECVAA cannot receive submissions sent from Notification Agents; the ECVAA cannot issue, or the Notification Agents cannot receive, confirmations of receipt of Volume Notifications within 20 minutes of the time of receipt. Note that any failure or breakdown due entirely to a Party's Notification System, or that of their Notification Agent, will not constitute an ECVAA System Failure. Furthermore, any failure or breakdown of the communications infrastructure will not constitute an ECVAA System Failure.
The ECVAA will be informed by BSCCo Ltd if a Trading Party or Notification Agent considers that they have not been notified of an ECVAA System Failure or ECVAA System Withdrawal correctly. The matter will be investigated promptly by BSCCo Ltd, with the ECVAA providing reasonable assistance as necessary.
Interfaces
ECVAA-I040

Requirement ID:

ECVAA-F013

Status:

Mandatory

Title:

Manage ECVAA System Failure / Withdrawal

BSC Reference:

CP739

Man/auto:

Manual

Frequency:

As Required

Volumes:

Low

Functional Requirement:

1. When an ECVAA System Failure or ECVAA System Withdrawal occurs, the ECVAA shall:

a. notify BSCCo Ltd as soon as possible after the beginning of the incident, giving the time at which it started, and

b. in collaboration with BSCCo Ltd, use all reasonable efforts as soon as practicable to notify Trading Parties and Notification Agents of the incident and start time.

2. As soon as practicable after the end of the ECVAA System Failure or ECVAA System Withdrawal, the ECVAA shall notify BSCCo Ltd that the incident has ended.

3. In cases where an ECVAA System Failure or ECVAA System Withdrawal does not affect all Notification Agents, ECVAA shall also inform BSCCo Ltd of the Notification Agent(s) so affected;

4. In cases where a subset of Notification Agents are affected by an ECVAA System Failure, the ECVAA or BSCCo Ltd may determine that, in order to minimise disruption to Trading Parties’ operations, the Notification System should be withdrawn to allow time to remedy the problem. It may also be decided that such withdrawal should be carried out earlier than might otherwise be done by way of planned BSC Agent downtime. In this case:

a. prior to the withdrawal, the ECVAA shall inform BSCCo Ltd of the time and date of the withdrawal, and

b. following the repairs deemed necessary the ECVAA shall restore the Notification System to operation as soon as practicably possible.

Non Functional Requirement

An ECVAA System Failure is defined as a failure or breakdown such that any of the following occur:

Notification Agents are unable to submit data to the ECVAA;
the ECVAA cannot receive submissions sent from Notification Agents;
the ECVAA cannot issue, or the Notification Agents cannot receive, confirmations of receipt of Volume Notifications within 20 minutes of the time of receipt.

Note that any failure or breakdown due entirely to a Party's Notification System, or that of their Notification Agent, will not constitute an ECVAA System Failure. Furthermore, any failure or breakdown of the communications infrastructure will not constitute an ECVAA System Failure.

The ECVAA will be informed by BSCCo Ltd if a Trading Party or Notification Agent considers that they have not been notified of an ECVAA System Failure or ECVAA System Withdrawal correctly. The matter will be investigated promptly by BSCCo Ltd, with the ECVAA providing reasonable assistance as necessary.

Interfaces

ECVAA-I040

5.14 ECVAA-F014: Matching of submitted ECVNs

Requirement ID: ECVAA-F014	Status: Mandatory	Title: Matching of submitted ECVNs	BSC Reference: P98
Man/auto: Automatic	Frequency: Continuous	Volumes: High
Functional Requirement: ECVAA-F005 describes requirements to process ECVNs such that a position is established on behalf of each of the BSC Parties referenced in the ECVN. ECVAA-F014 describes how the positions established on behalf of each BSC Party are correlated to give the matched position.
1: For Settlement Periods falling within the Matching Window, the ECVAA shall determine where the Energy Volume notified on behalf of both parties to the ECVNAA contain the same values. The Matching Window is defined as the current day plus the next 7 days. The matching function will consider values for the same ECVN (as identified by the ECVNAA ID and Reference Code), Settlement Day and Settlement Period for equivalence.
2: Where the volumes are the same, this matched value shall be stored for use in settlement. For the avoidance of doubt, the matched value remains in force unless and until both ECVNAs submit a new matching value. The matched value is subjected to the credit check Rejection process.
3: Only the latest value accepted in ECVAA-F005 from each ECVNA is eligible for matching.
Non Functional Requirement
The process is invoked when data is accepted from an ECVNA which falls within the Matching Window, or when a new Settlement Day is added to the Matching Window as the result of the passing of time.

Requirement ID:

ECVAA-F014

Status:

Mandatory

Title:

Matching of submitted ECVNs

BSC Reference:

P98

Man/auto:

Automatic

Frequency:

Continuous

Volumes:

High

Functional Requirement:

ECVAA-F005 describes requirements to process ECVNs such that a position is established on behalf of each of the BSC Parties referenced in the ECVN. ECVAA-F014 describes how the positions established on behalf of each BSC Party are correlated to give the matched position.

1: For Settlement Periods falling within the Matching Window, the ECVAA shall determine where the Energy Volume notified on behalf of both parties to the ECVNAA contain the same values.

The Matching Window is defined as the current day plus the next 7 days.

The matching function will consider values for the same ECVN (as identified by the ECVNAA ID and Reference Code), Settlement Day and Settlement Period for equivalence.

2: Where the volumes are the same, this matched value shall be stored for use in settlement.

For the avoidance of doubt, the matched value remains in force unless and until both ECVNAs submit a new matching value. The matched value is subjected to the credit check Rejection process.

3: Only the latest value accepted in ECVAA-F005 from each ECVNA is eligible for matching.

Non Functional Requirement

The process is invoked when data is accepted from an ECVNA which falls within the Matching Window, or when a new Settlement Day is added to the Matching Window as the result of the passing of time.

5.15 ECVAA-F015: Matching of submitted MVRNs

Requirement ID: ECVAA-F015	Status: Mandatory	Title: Matching of submitted MVRNs	BSC Reference: P98
Man/auto: Automatic	Frequency: Continuous	Volumes: High
Functional Requirement: ECVAA-F006 describes requirements to process MVRNs such that a position is established on behalf of each of the BSC Parties referenced in the MVRN. ECVAA-F015 describes how the positions established on behalf of each BSC Party are correlated to give the matched position.
1: For Settlement Periods falling within the matching window, the ECVAA shall determine where the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation notified on behalf of both parties to the MVRNAA contain the same values. The Matching Window is defined as the current day plus the next 7 days. The matching function will consider values for the same MVRN (as identified by the MVRNAA ID and Reference Code), Settlement Day and Settlement Period for equivalence.
2: Where the values match, the matched values shall be stored for use in settlement. For the avoidance of doubt, the matched values remain in force unless and until both MVRNAs submit new matching values. The matched values are subjected to the Credit Check Rejection process. A match is only achieved if matching values for both the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation (the value pair) are received on behalf of each Party. If only the Metered Volume Fixed Reallocation or Metered Volume Percentage Reallocation matches but the other does not, then the value pair does not match.
3: The matched data must satisfy the following test: Σ_a QMPR_aij ≤100.00 Where QMPR_aij is the matched Metered Volume Percentage Reallocation for Subsidiary Energy Account a, BM Unit i and Settlement Period j. In addition, where matching is performed for a newly submitted MVRN, the new value will be treated as matched for this test only. In this way, any potential new match which causes the test to fail will be rejected.
4: The ECVAA shall reject any Metered Volume Reallocation Notification that fails the validation described in point 3 above and notify the relevant Lead and Subsidiary Parties and MVRNAs of the rejection, including the reasons for the rejection. If this is the first invocation of this process for a given Settlement Period and MVRN then no matched position will be stored and the record will be deleted. If the process has been invoked before, then the positions held for each submitting MVRNA and the matched position will be restored to the values held after the previous invocation. The ECVAA shall report rejected Metered Volume Reallocation Notifications as described by requirement ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback.
5: Only the latest value accepted in ECVAA-F006 from each MVRNA is eligible for matching.
Non Functional Requirement
The process is invoked when data is accepted from an MVRNA which falls within the Matching Window, or when a new Settlement Day is added to the Matching Window as the result of the passing of time.
Interfaces
ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback

Requirement ID:

ECVAA-F015

Status:

Mandatory

Title:

Matching of submitted MVRNs

BSC Reference:

P98

Man/auto:

Automatic

Frequency:

Continuous

Volumes:

High

Functional Requirement:

ECVAA-F006 describes requirements to process MVRNs such that a position is established on behalf of each of the BSC Parties referenced in the MVRN. ECVAA-F015 describes how the positions established on behalf of each BSC Party are correlated to give the matched position.

1: For Settlement Periods falling within the matching window, the ECVAA shall determine where the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation notified on behalf of both parties to the MVRNAA contain the same values.

The Matching Window is defined as the current day plus the next 7 days.

The matching function will consider values for the same MVRN (as identified by the MVRNAA ID and Reference Code), Settlement Day and Settlement Period for equivalence.

2: Where the values match, the matched values shall be stored for use in settlement.

For the avoidance of doubt, the matched values remain in force unless and until both MVRNAs submit new matching values. The matched values are subjected to the Credit Check Rejection process.

A match is only achieved if matching values for both the Metered Volume Fixed Reallocation and Metered Volume Percentage Reallocation (the value pair) are received on behalf of each Party. If only the Metered Volume Fixed Reallocation or Metered Volume Percentage Reallocation matches but the other does not, then the value pair does not match.

3: The matched data must satisfy the following test:

Σ_a QMPR_aij ≤100.00

Where QMPR_aij is the matched Metered Volume Percentage Reallocation for Subsidiary Energy Account a, BM Unit i and Settlement Period j.

In addition, where matching is performed for a newly submitted MVRN, the new value will be treated as matched for this test only. In this way, any potential new match which causes the test to fail will be rejected.

4: The ECVAA shall reject any Metered Volume Reallocation Notification that fails the validation described in point 3 above and notify the relevant Lead and Subsidiary Parties and MVRNAs of the rejection, including the reasons for the rejection.

If this is the first invocation of this process for a given Settlement Period and MVRN then no matched position will be stored and the record will be deleted.

If the process has been invoked before, then the positions held for each submitting MVRNA and the matched position will be restored to the values held after the previous invocation.

The ECVAA shall report rejected Metered Volume Reallocation Notifications as described by requirement ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback.

5: Only the latest value accepted in ECVAA-F006 from each MVRNA is eligible for matching.

Non Functional Requirement

The process is invoked when data is accepted from an MVRNA which falls within the Matching Window, or when a new Settlement Day is added to the Matching Window as the result of the passing of time.

Interfaces

ECVAA-I010: Issue Metered Volume Reallocation Notification Feedback

5.16 Notes on Notification Processing and Reporting

In general Notifications are stored (and reported in the ECVAA-I022) using the same date range as Notified. There are some exceptions to this, and this section describes these circumstances. This processing applies equally to ECVNs and MVRNs.

Note that the Current Date is the earliest date for which not all Settlement Periods in the day have passed the Submission Deadline and the Applied From Date (as reported in the ECVAA-I028/ECVAA-I029) is the later of the Current Date and the Effective From Date in a received Notification.

Data for the Current Date is never changed for those periods where the Submission Deadline has already passed.

To determine the date range(s) stored (and reported):

If Effective From = Effective To, the Notification will be stored as received (Multi‑Day flag = "S").
Otherwise (the Notification spans multiple dates):

For Notification with Effective From Date > Current Date: the Notification will be stored as received (Multi‑Day flag = "M")
Otherwise (For a Notification with Applied From Date = Current Date):

If there is an exact match between the Notification and the data already held by ECVAA for the notification (including the case where there is currently no data on the database) for all periods for which the Submission Deadline has passed, then the Notification is stored as a single date range from the Applied From Date to the specified Effective To Date (Multi‑Day flag = "M").
Otherwise, the Notification is stored as two records, a single day for the Current Date (Multi‑Day flag = "M" unless Current Date is a Clock Change Day, in which case the Periods are converted to 46/50 period day and Multi‑Day = "S") and the remainder from Current Date+1 to specified Effective To Date (Multi‑Day flag = "M")

The following table shows how Notifications are stored (and subsequently reported) in various scenarios. Note that the “Multi‑Day” flag is not reported, but is shown here for clarity.

From ECVN/MRVN			As stored on the database
Notification Start date	Notification End date	Ref / Notes	Multi-Day Flag	Effective From date	Effective To Date	Period Data
Current Date	Current Date	A	S	Current Date	Current Date	As held pre- Submission Deadline, as notification after the Submission Deadline
Future Date	Future Date	B	S	Future Date	Future Date	As notification
Future Date	Future Date + n (>0)	C	M	Future Date	Future Date + n (>0)	As notification
Past Date or Current Date	Future Date	D**	S	Current Date	Current Date	As held pre- Submission Deadline, as notification after the Submission Deadline
			M	Current Date + 1	Future Date	As notification
		E*	M	Current Date	Future Date	As notification
Past Date	Current Date	F**	S	Current Date	Current Date	As held pre-Submission Deadline, as notification after the Submission Deadline
Past Date	Current Date	G*	M	Current Date	Current Date	As notification

* - Only where period data exactly matches previously held pre-Submission Deadline period data for Current Date and the Current Date is not a clock change day.

** - Where period data does not exactly match previously held pre-Submission Deadline data for the Current Date, or the Current Date is a clock change day. In these cases, the Current Date part will be mapped into a clock change day (46/50 periods) if appropriate.

An existing Multi‑Day Notification that starts before and ends on or after the Applied From Date of a received Notification which replaces it will have its Effective To date set to Applied From Date minus one. the “Multi‑Day” flag will remain “M”. For example,

an existing notification with Effective From Date D and Effective To Date D+5 is overwritten by a Notification with Applied From Date D+3; here the existing Notification’s Effective To Date is set to D+2, with the new Notification starting at D+3.
an existing notification with Effective From Date D and Effective To Date D+5 is overwritten by a Notification Applied From Date D+1; here the existing Notification’s Effective To Date is set to D, with the new Notification starting at D+1.

Note that in this second example, if D is a clock change day, the data will be correctly converted from 48 to 46/50 periods due to the Multi‑Day flag being set to “M”

Any Notifications stored with a single day range and the “Multi‑Day” flag set to “M” are processed by the ECVAA-I022 Forward Contract Report such that the reported data is mapped into a clock change day (46/50 periods) if appropriate.

5.17 ECVAA-F016: ECVAA Web Service Common Functionality.

Requirement ID: ECVAA-F016	Status: Mandatory	Title: ECVAA Web Service Common Functionality.	BSC Reference: P98
Mechanism: Automatic	Frequency: Continuous	Volumes: Low – 140 users querying the database twice per minute.
Functional Requirement:
1. Access restricted to the role of the logged in user; The BSC Party view shall restrict data to that submitted under authorisations involving that BSC Party, or aggregations thereof; The Notification Agent view shall restrict data to that submitted under active authorisations to which the logged in user is an agent;
2. Data refresh information and refresh capability; The latest time and date of refresh of all displayed data shall be displayed on its page. After a set time a warning message shall be displayed to indicate that the data displayed may be out of date. The set time shall be a system wide parameter and shall initially be set to 60 seconds; A data refresh shall be able to be initiated from the warning;
3. General and context sensitive Help text shall be made available to the user where appropriate;
4. For ECVNs and MVRNs, the viewer shall be able to see the latest accepted position submitted by both counterparties and the matched position where appropriate;
5. Data reported via the Web service shall be restricted to Live data. Live data in this context means contract volumes and re-allocations for the current Settlement Day and the next seven full Settlement Days.
6. Data reported via the Web service shall be restricted to Current Authorisations. Current Authorisations, in this context are Authorisations that are effective on the Current Settlement Date.
7. Historical data shall not be available on the Web service.
8. For Agents, there shall be a role defined in the users credentials file such that it may be determined if the user has permission to submit notifications from the web system.
9. For the BSC Party Web service, the logged in BSC Party shall always be represented on the left hand side of any tabulated data displays. Where the BSC Party is both parties within a notification, then Party 1 shall be displayed on the left.
10. For the ECVNA and MVRNA Web service, Party 1 shall be displayed on the left hand side of any tabulated data displays.
11. Data shall be reported to two decimal places for all high and intermediate level pages. Data displayed on detail pages shall be reported to 5 decimal places for percentages and 3 decimal places for volumes.
12. Where a detailed period view is displayed, the user shall see the appropriate number of Settlement Periods for the type of day. That is 50 Settlement Periods for the autumn (long) day, 46 Settlement Periods for the spring (short) day, and 48 periods for a normal day. Where a submitted 48 period notification spans a long or short day, 48 periods will be shown, even if viewed on the long or short day.
13. For the purposes of data entry, 50 Settlement Periods shall always be displayed. It shall be the responsibility of the user to populate the correct number of Settlement Periods for the day.
Interfaces:
Related interface requirements:
ECVAA-I043 ECVAA Web service – BSC Party View ECVNs.
ECVAA-I044 ECVAA Web service – BSC Party View MVRNs.
ECVAA-I045 ECVAA Web service – ECVNA View ECVNs
ECVAA-I046 ECVAA Web service – MVRNA View MVRNs

5.18 ECVAA-F017: ECVAA Web Service – BSC Party View ECVNs Functionality.

Requirement ID: ECVAA-F017	Status: Mandatory	Title: ECVAA Web Service – BSC Party View ECVNs Functionality.	BSC Reference: P98
Mechanism: Automatic	Frequency: Continuous	Volumes: Low – 140 users querying the database twice per minute.
Functional Requirement: 1. Navigation. The BSC Party user shall, after being notified of successful login be presented with the ECVN position page. From here it shall be possible to navigate directly to all BSC Party summary ECVN pages and to the context sensitive help pages. From the summary pages it shall be possible to navigate to the detail pages.
2. Sign Convention In the BSC Party Web service, volumes displayed shall adhere to the following sign convention:- A positive value represents a sell from the perspective of the logged in BSC Party. A negative value represents a purchase from the perspective of the logged in BSC Party. Where the logged in party is both parties to the notification being viewed, then the ‘normal’ notification sign conventions apply, reflecting the flow of energy within the notification.
3. Intra-party contract volumes shall not be included in the general, non-counterparty specific aggregated / net contract volumes displayed.
4. The pages displayed on the Web service will display information for Party 1 Agent and Party 2 Agent, although both these will be the same entity.
5. Zero values shall be displayed in their numeric format. Missing or NULL values shall be displayed as ‘-‘.
6. All data displayed on the BSC Party Web service shall be read only.
7. Common Page items. All pages shall display the following; A link to the online help; A link to the BSC Party MVRN Web service;
8. ECVN Position Page (Home page). Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 2. This page shall be displayed after notification of successful login to the BSC Party Web service. This page shall display two tables, one for the logged in BSC Party’s Production Account and the second for the logged in party’s Consumption Account. These tables will display total net matched position for each day in the matching window by day with a total for each day. Information shall be made available for the latest transaction for the Party. This information is for the latest ECVN processed and may not directly relate to other data displayed. Links to other pages; A link to display the ECVN Party / Settlement Period Summary Page for the account and date selected (Period view). A link to display the ECVN Party / Settlement Period Summary Page for the account and Counterparty (SP). The Counterparty’s name shall provide a link to the ECVN Party / Counterparty Summary Page for the account selected filtered for the Counterparty selected. The Total Net Position amount shall provide a link to the ECVN Party / Counterparty Summary Page for the account selected filtered for the Counterparty and date selected The Settlement Date shall provide a link to the ECVN Party / Settlement Day Summary Page for the account selected filtered for the date selected.
9. ECVN Party / Counterparty Summary Page This page shall be displayed after navigating the link from the ECVN Position Page. This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page. The page shall allow the user to select the data displayed by single date within the matching window. The ECVN reference shall be the ECVN ECVNAA ID and the ECVN reference code concatenated and provides a link to the ECVN Detail Viewer Page for the selected ECVN. Where this page is accessed for all counterparties. Intra-party contract volumes / notifications will be excluded. Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 3. Links to other pages; The page shall allow the user to select ECVN reference which will provide a link to the ECVN Detail Viewer page.
10. ECVN Party / Settlement Day Summary Page Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 4. This page shall be displayed after linking from the ECVN Position Page. This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page. The ECVN reference shall be the ECVN ECVNAA ID and the ECVN reference code concatenated. This reference will provide a link to the ECVN Detail Viewer Page for the selected ECVN. Links to other pages; The page shall allow the user to select the data displayed by single date within the matching window.
11. ECVN Party / Settlement Period Summary Page Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 5. This page shall be displayed after linking from the ECVN Position Page. This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page. This page will display information for a single date in the matching window, a single Counterparty and Counterparty Account, when entered from via Settlement Period (SP) link. It will also display all Counterparties and their accounts, when entered via the Period View link. All Counterparties shall be represented by a ‘*’ against the Counterparty name and against the Counterparty Account. Where this page is accessed for all Counterparties. Intra-party contract volumes / notifications will be excluded. Links to other pages; The page shall allow the user to select the data displayed by date within the matching window.
12. ECVN Detail Viewer Page Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 6. This page shall be displayed after linking from the ECVN Party / Counterparty Summary Page or the ECVN Party / Settlement Day Summary Page. This page shall display a single table for the logged in BSC Party for an individual notification for a single Settlement Date. This page will also display data about the notification displayed; A latest transaction panel will be displayed; The same value will be shown in each of the Party, Counterparty and Matched columns
Interfaces:
Related interface requirements: ECVAA-I043 ECVAA Web service – BSC Party View ECVNs

Requirement ID:

ECVAA-F017

Status:

Mandatory

Title:

ECVAA Web Service – BSC Party View ECVNs Functionality.

BSC Reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low – 140 users querying the database twice per minute.

Functional Requirement:

1. Navigation.

The BSC Party user shall, after being notified of successful login be presented with the ECVN position page. From here it shall be possible to navigate directly to all BSC Party summary ECVN pages and to the context sensitive help pages. From the summary pages it shall be possible to navigate to the detail pages.

2. Sign Convention

In the BSC Party Web service, volumes displayed shall adhere to the following sign convention:-

A positive value represents a sell from the perspective of the logged in BSC Party.

A negative value represents a purchase from the perspective of the logged in BSC Party.

Where the logged in party is both parties to the notification being viewed, then the ‘normal’ notification sign conventions apply, reflecting the flow of energy within the notification.

3. Intra-party contract volumes shall not be included in the general, non-counterparty specific aggregated / net contract volumes displayed.

4. The pages displayed on the Web service will display information for Party 1 Agent and Party 2 Agent, although both these will be the same entity.

5. Zero values shall be displayed in their numeric format. Missing or NULL values shall be displayed as ‘-‘.

6. All data displayed on the BSC Party Web service shall be read only.

7. Common Page items.

All pages shall display the following;

A link to the online help;
A link to the BSC Party MVRN Web service;

8. ECVN Position Page (Home page).

Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 2.

This page shall be displayed after notification of successful login to the BSC Party Web service. This page shall display two tables, one for the logged in BSC Party’s Production Account and the second for the logged in party’s Consumption Account. These tables will display total net matched position for each day in the matching window by day with a total for each day.

Information shall be made available for the latest transaction for the Party. This information is for the latest ECVN processed and may not directly relate to other data displayed.

Links to other pages;

A link to display the ECVN Party / Settlement Period Summary Page for the account and date selected (Period view).

A link to display the ECVN Party / Settlement Period Summary Page for the account and Counterparty (SP).

The Counterparty’s name shall provide a link to the ECVN Party / Counterparty Summary Page for the account selected filtered for the Counterparty selected.

The Total Net Position amount shall provide a link to the ECVN Party / Counterparty Summary Page for the account selected filtered for the Counterparty and date selected

The Settlement Date shall provide a link to the ECVN Party / Settlement Day Summary Page for the account selected filtered for the date selected.

9. ECVN Party / Counterparty Summary Page

This page shall be displayed after navigating the link from the ECVN Position Page. This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page.

The page shall allow the user to select the data displayed by single date within the matching window.

The ECVN reference shall be the ECVN ECVNAA ID and the ECVN reference code concatenated and provides a link to the ECVN Detail Viewer Page for the selected ECVN.

Where this page is accessed for all counterparties. Intra-party contract volumes / notifications will be excluded.

Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 3.

Links to other pages;

The page shall allow the user to select ECVN reference which will provide a link to the ECVN Detail Viewer page.

10. ECVN Party / Settlement Day Summary Page

Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 4.

This page shall be displayed after linking from the ECVN Position Page. This page shall display a single table for the logged in BSC Party’s Production or Consumption Account dependent on the choice made in the ECVN Position Page.

The ECVN reference shall be the ECVN ECVNAA ID and the ECVN reference code concatenated. This reference will provide a link to the ECVN Detail Viewer Page for the selected ECVN.

Links to other pages;

The page shall allow the user to select the data displayed by single date within the matching window.

11. ECVN Party / Settlement Period Summary Page

Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 5.

This page will display information for a single date in the matching window, a single Counterparty and Counterparty Account, when entered from via Settlement Period (SP) link.

It will also display all Counterparties and their accounts, when entered via the Period View link. All Counterparties shall be represented by a ‘*’ against the Counterparty name and against the Counterparty Account. Where this page is accessed for all Counterparties. Intra-party contract volumes / notifications will be excluded.

Links to other pages;

The page shall allow the user to select the data displayed by date within the matching window.

12. ECVN Detail Viewer Page

Data displayed on this page is detailed in ECVAA-I043: ECVAA Web service – BSC Party View ECVNs sections 1 and 6.

This page shall be displayed after linking from the ECVN Party / Counterparty Summary Page or the ECVN Party / Settlement Day Summary Page. This page shall display a single table for the logged in BSC Party for an individual notification for a single Settlement Date.

This page will also display data about the notification displayed;

A latest transaction panel will be displayed;

The same value will be shown in each of the Party, Counterparty and Matched columns

Interfaces:

Related interface requirements:

ECVAA-I043 ECVAA Web service – BSC Party View ECVNs

5.19 ECVAA-F018: ECVAA Web Service – BSC Party View MVRNs Functionality.

Requirement ID:

ECVAA-F018

Status:

Mandatory

Title:

ECVAA Web Service – BSC Party View MVRNs Functionality.

BSC Reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low – 140 users querying the database twice per minute.

Functional Requirement:

1. Access.

The BSC Party user shall, after notification of successful login, be presented with the ECVN Position page. From here it shall be possible to navigate to the MVRNA Authorisation via the link described in requirement ECVAA-I043 section 1.

2. Navigation

The BSC Party shall be able to navigate directly to the context sensitive help pages. From MVRNA Authorisation selection page it shall be possible to navigate to the Notification selection page, and from the notification selection page it shall be possible to navigate to the BSC Party MVRN details page

3. Sign Convention

In the BSC Party Web service, volumes displayed shall adhere to the following sign convention:-

A Volume sell from Lead Party to Subsidiary Party will be positive.

A Volume sell from Subsidiary Party to Lead Party will be negative.

4. The pages displayed on the Web service will display information for Lead Party Agent and Subsidiary Party Agent, although both these will be the same entity.

5. Zero values shall be displayed in their numeric format. Missing or NULL values shall be displayed as ‘-‘.

6. All data displayed on the BSC Party Web service shall be read only.

7. Common Page items.

All pages will display the following;

A link to the online help;

A link to the BSC Party ECVN Web service;

8. BSC Party MVRNAA Selection Page

Data displayed on this page is detailed in ECVAA-I044: ECVAA Web service – BSC Party View MVRNs sections 1 and 2.

This page shall be displayed after navigating by link from the ECVN Position Page.

This page shall display a single table displaying each authorisation that the logged in BSC Party is a party to.

The table shall display Authorisation data including a Notification count for each authorisation.

The Notification Count shall be the number of active Notifications for the Authorisation in the matching window.

The table contents may be filtered and sorted by each column, and be initially sorted by Notification Count so that the authorisation with the highest notification count is first in the table.

Links to other pages;

The Notification Count shall provide a link to the BSC Party MVRN Selection page.

9. BSC Party MVRN Selection Page

Data displayed on this page is detailed in ECVAA-I044: ECVAA Web service – BSC Party View MVRNs sections 1 and 3.

This page shall be displayed after navigating by link from the BSC Party MVRNAA Selection Page.

For the single Authorisation selected in the BSC Party MVRNA Authorisation view.

This page shall display two tables for the logged in BSC Party.

The first table shall display Authorisation data:

For the authorisation detailed in the first table, the second table will display Notification information;

The notifications are displayed with one reference for each settlement date comprising the notification that falls within the settlement date. If there is an unmatched volume or percentage in the underlying notification, then the notification is highlighted.

Links to other pages;

Each notification listed in the Notification Information Table shall have an associated link to the BSC Party MVR Notification Detail Page.

10. BSC Party MVR Notification Detail Page

Data displayed on this page is detailed in ECVAA-I044: ECVAA Web service – BSC Party View MVRNs sections 1 and 4.

This page shall display details about the MVRN Notification selected from the BSC Party MVRN Selection Page.

For these Notification Details, the page shall display Percentage, fixed and matched re-allocation details for each settlement period.

The latest transaction panel will be displayed.

Interfaces:

Related interface requirements:

ECVAA-I044 ECVAA Web service – BSC Party View MVRNs

5.20 ECVAA-F019: ECVAA Web Service - ECVNA Functionality.

Requirement ID:

ECVAA-F019

Status:

Mandatory

Title:

ECVAA Web Service – ECVNA Functionality.

BSC Reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low – 140 users querying the database twice per minute.

Functional Requirement:

1. Access.

The Agent user shall, after notification of successful login as an ECVNA, be presented with the BSC Party Selection Page (ECVNA Home Page).

2. Navigation

The Agent shall be able to navigate directly to the context sensitive help pages. From the ECVNA Home page it shall be possible to navigate to the ECVNAA selection page. From this page, it shall then be possible to navigate to the ECVN selection page, and from the ECVN selection page it shall be possible to navigate to the ECVN details page.

3. Sign Convention

In the ECVNA web site, volumes displayed shall adhere to the following sign convention:-

A Volume sell from Party 1 to Party 2 will be positive.

A Volume sell from Party 2 to Party 1 will be negative.

Party 1 will always be shown on the left when viewing notifications as an ECVNA

4. Zero values shall be displayed in their numeric format. Missing or NULL values shall be displayed as ‘-‘.

5. All data displayed on the ECVNA Web Site shall be read only, unless otherwise stated.

6. Common Page items.

All pages shall display the following;

A link to the online help

7. BSC Party and ECVNAA Selection Page

This page shall allow the logged in agent to select the BSC Party to represent from a list of parties that the agent has a current authorisation under.

Once a BSC Party has been selected, the user then is able to see the ECVNAA details for the selected party.

Data displayed on this page is detailed in ECVAA-I045: ECVAA Web service, ECVNA View ECVNs sections 1 and 2.

This page shall display a single table for the logged in Agent.

For each authorisation that the logged in Agent is appointed for, and filtered by the BSC party selection made, the table shall display authorisation data including a Notification count.

The table contents may be further filtered and sorted by each column, and be initially sorted by Notification Count so that the authorisation with the highest notification count is first in the table.

Links to other pages;

The Notification Count shall be the number of active Notifications for the Authorisation in the matching window, and shall provide a link to the ECVAA Notifications View.

8. ECVN Selection Page

Data displayed on this page is detailed in ECVAA-I045: ECVAA Web service, ECVNA View ECVNs sections 1 and 3.

This page shall be displayed after navigating by link from the ECVNAA selection Page.

For the single Authorisation selected in the ECVNAA page, this page shall display two tables for the logged in Agent. The first table shall display Authorisation data.

For the Authorisation detailed in the first table, the second table shall display Notification information.

The notifications are displayed with one reference for each settlement date comprising the notification that falls within the settlement date. If there is an unmatched volume in the underlying notification, then the notification is highlighted.

Links to other pages;

There shall be link made available to all users with credentials file permission to submit Notifications that will enable the user to create a new notification for an existing Authorisation. Selecting this link will navigate the user to an empty ECVN Creation page for the Authorisation detailed in the first table.
A link to view (read only) the Notification in the ECVN View Page.
A link to create a new submission based on the Agents own submission under this Notification in the ECVN Creation page (subject to credentials file permission).
A link to copy the Counterparty’s submission under this Notification as a base for a new submission in the ECVN Creation page (subject to credentials file permission).

9. ECVN Creation Page

Data displayed on this page is detailed in ECVAA-I045: ECVAA Web service, ECVNA View ECVNs sections 1 and 4.

This page shall be displayed after navigating by link from the ECVN Page. This page shall display details of the ECVN selected from the ECVN Selection Page.

The latest transaction panel will be displayed.

Links to other pages;

The page shall display a submission button to enable the user to submit new, addition, or replacement submission details.

Interfaces:

Related interface requirements:

ECVAA-I045 ECVAA Web service – ECVNA View ECVNs

5.21 ECVAA-F020: ECVAA Web Service - ECVNA ECVN Submission Functionality.

Requirement ID: ECVAA-F020	Status: Mandatory	Title: ECVAA Web Service – ECVNA ECVN Submission Functionality.	BSC Reference: P98
Mechanism: Automatic	Frequency: Continuous	Volumes: Low – 140 users querying the database twice per minute.
Functional Requirement:
1. The user shall be able to create a new ECVN for an existing authorisation based on an existing notification reference, or from new from the ECVN Creation page.
2. The ECVN Creation Page shall allow a user to submit individual ECVNs directly via the screen, or to submit multiple ECVNs by uploading a comma separated variable (csv) file containing the required notification data.
3. The submission of ECVNs from the web server may be confirmed or cancelled after using the submission button.
4. The ECVN shall be validated. The following validation shall be carried out; That there is no missing mandatory data. The format of completed data shall be checked against the ECVAA-I004 notification submission interface for compatibility. The effective to date (if it exists) shall be checked to ensure that it is not before the effective from date. The effective to date (if it exists) and the effective from date shall be checked to ensure that these dates are not in the past. Note that this validation is in addition to the normal business validation carried out on a submission after it has been acknowledged.
5. Any validation failure shall be notified to the user by a screen message requiring acknowledgement, and the user returned to the creation page.
6. A user shall not be required to submit two notifications. A single submission shall update both parties’ notification positions.
7. The file sequence of web submissions shall be known as the web submission number and shall be unrelated to the File Sequence number from a notification agents system used in file based submissions. Web based submissions shall have separate sequence numbers so that they do not interfere with the progression of file based submission sequence numbers. The web submission number shall be updated automatically when a notification is submitted.
8. On successful validation of an ECVN web submission, the user shall be required to confirm or cancel the submission. Cancellation shall result in the user being returned to the creation page with no notification submission taking place.
9. On confirmation of an ECVN web submission, the user shall receive a screen based acknowledgement of the submission, which shall include web submission number, and the date and time of submission. This confirmation will replace the ECVAA-I019 acknowledgment.
10. The data and time of submission will be the date and time of the materialisation of a file containing the notification details by the web submission process.
11. The materialised file will contain the authorisation key for the logged on agent. The credentials file security will provide the security required to verify the logged in user is valid for the submission. The authorisation key will be obtained from the database.
12. Following successful submission of an ECVN web submission, the notification file will be processed through the standard ECVN processing as described in ECVNS ECVAA-F003. The transaction number for the notification will be generated in the same way as a normal notification.
Interfaces:
Related interface requirements:
ECVAA-I045 ECVAA Web service – ECVNA View ECVNs

5.22 ECVAA-F021: ECVAA Web Service - MVRNA Functionality.

Requirement ID:

ECVAA-F021

Status:

Mandatory

Title:

ECVAA Web Service – MVRNA Functionality.

BSC Reference:

P98

Mechanism:

Automatic

Frequency:

Continuous

Volumes:

Low – 140 users querying the database twice per minute.

Functional Requirement:

1. Access.

The Agent user shall, after notification of successful login as an MVRNA be presented with the BSC Party Selection Page.

2. Navigation

The Agent shall be able to navigate directly to the context sensitive help pages. From the BSC Party Selection page the Agent shall be possible to navigate to the MVRNAA selection page. From this page, it shall then be possible to navigate to the MVRN selection page, and from the MVRN selection page it shall be possible to navigate to the MVRN details page.

3. Zero values shall be displayed in their numeric format. Missing or NULL values shall be displayed as ‘-‘.

4. The pages displayed on the Web service will display information for Lead Party Agent and Subsidiary Party Agent, although both these will be the same entity.

5. All data displayed on the MVRNA Web service shall be read only, unless otherwise stated.

6. Common Page items.

All pages shall display the following;

A link to the online help;

7. BSC Party and MVRNAA Selection Page

Data displayed on this page is detailed in ECVAA-I046: ECVAA Web service, MVRNA View MVRNs sections 1 and 2.

This page shall allow the logged in agent to select a BSC Party to represent from a list of parties that the agent has a current authorisation under.

Once a BSC Party has been selected, the user then is able to see the MVRNAA details for the selected party.

This page shall display a single table for the logged in Agent.

For each authorisation that the logged in Agent is appointed for, and filtered by the BSC party selection made, the table shall display authorisation data including a Notification count.

The Notification Count shall be the number of active Notifications for the Authorisation in the matching window.

The table contents may be further filtered and sorted by each column, and be initially sorted by Notification Count so that the authorisation with the highest notification count is first in the table

Links to other pages;

The Notification Count shall provide a link to the MVRN Selection Page.

8. MVRN Selection Page

Data displayed on this page is detailed in ECVAA-I046: ECVAA Web service, MVRNA View MVRNs sections 1 and 3.

This page shall be displayed after navigating by link from the MVRNAA Page.

For the single Authorisation selected in the MVRNAA Selection Page. This page shall display two tables for the logged in Agent, the first table shall display the Authorisation data:

For the Authorisation detailed in the first table, the second table shall display Notification information.

The notifications are displayed with one reference for each settlement date comprising the notification that falls within the settlement date. If there is an unmatched volume or percentage reallocation in the underlying notification, then the notification is highlighted.

Links to other pages;

There shall be link made available to all users with credentials file permission to submit Notifications that will enable the user to create a new notification for an existing Authorisation. Selecting this link will navigate the user to an empty MVRN Creation page for the Authorisation detailed in the first table.

A link to view (read only) the Notification in the MVRN View page.

A link to use the Agents own position under this Notification in the MVRN Creation page as a base for a new submission (subject to credentials file permission).

A link to copy the Counterparty’s position under this Notification as a base for a new submission in the MVRN Editor (subject to credentials file permission).

9. MVRN Creation Page

Data displayed on this page is detailed in ECVAA-I046: ECVAA Web service, MVRNA View MVRNs sections 1 and 4.

This page shall be displayed after navigating by link from the MVRN Selection Page.

This page shall display the details about the MVRN selected from the MVRN Selection Page;

For these Notification Details, the page shall display settlement period data.

The latest transaction panel will be displayed.

Links to other pages;

The page shall display a submission button to enable the user to submit submission details.

Interfaces:

Related interface requirements:

ECVAA-I046 ECVAA Web service – MVRNA View MVRNs.

5.23 ECVAA-F022: ECVAA Web Service - MVRNA MVRN Submission Functionality.

Requirement ID: ECVAA-F022	Status: Mandatory	Title: ECVAA Web Service -MVRNA MVRN Submission Functionality.	BSC Reference: P98
Mechanism: Automatic	Frequency: Continuous	Volumes: Low – 140 users querying the database twice per minute.
Functional Requirement:
1. The user shall be able to create a new submission based on an existing MVRN position for a notification, or create a new MVRN for an existing authorisation from the MVRN Creation page.
2. The MVRN Creation Page shall allow a user to submit individual MVRNs directly via the screen, or to submit multiple MVRNs by uploading a comma separated variable (csv) file containing the required notification data.
3. The submission of MVRNs from the web server may be confirmed or cancelled after successful validation.
4. The MVRN shall be validated. The following validation shall be carried out; That there is no missing mandatory data. The format of completed data shall be checked against the ECVAA-I005 notification submission interface for compatibility. The effective to date (if it exists) shall be checked to ensure that it is not before the effective from date. The effective to date (if it exists) and the effective from date shall be checked to ensure that these dates are not in the past. Where a submission contains percentage reallocations, validation shall be carried out to ensure that any applied percentage is less than or equal to 100%. For a new notification, all fixed re-allocation periods shall default to zero, and all percentage re-allocations shall default to 100%. Note that this validation is in addition to the normal business validation carried out on a submission after it has been acknowledged.
5. Any validation failure shall be notified to the user by a screen message requiring acknowledgement, and the user returned to the creation page.
6. A user shall not be required to submit two notifications. A single submission shall update both parties' notification positions.
7. The file sequence of web submissions shall be known as the web submission number and will be unrelated to the File Sequence number from a notification agents system. The Web submission number shall be updated automatically when a notification is submitted.
8. On successful validation of an MVRN web submission, the user shall be required to confirm or cancel the submission. Cancellation shall result in the user being returned to the creation page with no notification submission taking place.
9. On confirmation of an MVRN web submission, the user shall receive a screen based acknowledgement of the submission, which shall include web submission number and the date and time of submission. This confirmation will replace the ECVAA-I019 acknowledgment.
10. The data and time of submission will be the date and time of the materialisation of a file containing the notification details by the web submission process.
11. The materialised file will contain the authorisation key for the logged on agent. The credentials file security will provide the security required to verify the logged in user is valid for the submission. The authorisation key will be obtained from the database.
12. Following successful submission of an MVRN web submission, the notification file will be processed through the standard MVRN processing as described in MVRNs ECVAA-F005. The transaction number for the notification will be generated in the same way as a normal notification.
Interfaces:
Related interface requirements:
ECVAA-I046 ECVAA Web service – MVRNA View MVRNs

5.24 ECVAA-F023: Banning/Unbanning Individual User Access to the ECVAA Web service Functionality

Requirement ID:

ECVAA-F023

Status:

Mandatory

Title:

Banning/Unbanning Individual User Access to the ECVAA Web service Functionality.

BSC Reference:

P98

Mechanism:

Manual

Frequency:

Low

Volumes:

Low – exceptional circumstances only

Functional Requirement:

1. The ECVAA Service shall receive and action, from time to time, requests to ban and unban specific credentials files.

2. Where a participant is unable to ban / un-ban one of its users itself, then the Participant may submit a I042 form requesting that the ECVAA ban or unban a specific credentials file. Such a request must be sanctioned by a category ‘Z’ signatory. This manual process is available only within business hours.

Interfaces:

Related interface requirements:

ECVAA-I042 Banning/Unbanning Individual User Access to the ECVAA Web service

5.25 ECVAA-F024: Process Withdrawing Party Authorisation and Notification Details

Requirement ID:

ECVAA-F024

Status:

Mandatory

Title:

Process Withdrawing Party Authorisation and Notification Details

BSC Reference:

CP974

Man/Auto:

Manual

Frequency:

On request

Volumes:

Low

Functional Requirement:

The ECVAA shall provide the information specified in interface ECVAA-I042 to the CRA, on request.

Authorisation and notification details shall be matched with the request by means of the participant name and / or participant id registered in ECVAA.

Non Functional Requirement:

Interfaces:

Related interface requirements:

ECVAA-I047: Issue Withdrawing Party Authorisation and Notification Details.

5.26 ECVAA-F025: Calculate Period Final Physical Notification Volumes

Requirement ID:

ECVAA-F025

Status:

Mandatory

Title:

Calculate Period Final Physical Notification Volumes

BSC Reference:

P140, P215

Man/auto:

Automatic

Frequency:

Once per Settlement Period, as values are received from NETSO.

Volumes:

Functional Requirements:

Final Physical Notification (FPN_ij) is calculated for BM Units which are Interconnector BM Units or which have a Credit Qualifying Status of “True”. (For other BM Units, the Point FPN data is loaded by ECVAA, but not used in any calculations).

This calculation is only done by ECVAA when Point FPN data is received from NETSO via BMRA. Any subsequent FPN data corrections will be ignored by ECVAA.

1: The value of Final Physical Notification, FPN_ij(t) shall be defined for times, t, falling within Settlement Period j by linear interpolation from the values of Point FPN (^fFPN_it), submitted for that Settlement Period j, for BM Unit i.

2: The Period FPN (FPN_ij) shall be calculated for each BM Unit i, by integrating the value of Final Physical Notification FPN_ij(t) across all times t, falling within Settlement Period j. The Period FPN is quoted in MWh.

Non-Functional Requirement:

Interfaces:

Related interface requirements:

ECVAA-I048: Receive Physical Notification Data

5.27 ECVAA-F026: Process removal of ECVNs / MVRNs from ECVAA for a Party in Section H Default

Requirement ID: ECVAA-F026	Status: Mandatory	Title: Removal of ECVNs / MVRNs from ECVAA for a Party in Section H Default	BSC Reference: CP1140 CP1169
Man/Auto: Manual	Frequency: On request	Volumes: Low
Functional Requirement:
The ECVAA Service shall receive and action, from time to time, requests to remove all ECVNs and MVRNs from ECVAA for a specific Party where that Party is in Section H Default. Removal will be effective from the Settlement Date and Period specified by the request. This removal also involves terminating the Party’s right to submit* (or have submitted on their behalf) ECVNs and MVRNs. *Where the Party additionally acts as an Agent
1. The ECVAA shall receive an ECVAA-I049: Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default.
2. ELEXON will be informed of the receipt of the ECVAA-I049 via ECVAA-I050. Processing beyond this step should commence as soon as possible after the Submission Deadline for the Period immediately prior to the notified Effective From Period.
3. ECVN and MVRN data for the specified Party will be logically deleted for any periods ahead. This is achieved by suspending Authorisations and removing ECVN/ MVRN data effective from settlement period one of the next settlement day as a first stage and then any necessary volume notification nullifications are processed to nullify data from the effective from period of the effective from settlement day where required. (Refer to ECVAA-F012: Process Volume Notification Nullification).
4. The ECVAA shall terminate with immediate effect ECVNA and MVRNA Authorisations by setting the effective to date of the authorisations to the day before the removal effective date provided in the removal request.
5. ELEXON shall be informed of the successful removal and termination by the ECVAA via ECVAA-I050.
6. The ECVAA shall recover any Credit Checks for missing periods where required, and/or process any volume notification nullifications that are required.
7. ELEXON shall be informed that the Credit Check steps and/or volume notification nullification steps have been completed via ECVAA-050.
8. The ECVAA shall make checks to ensure that the performed notification tables remain empty for the defaulting Party.
9. ELEXON shall be informed of the completion of the final performed notification checks by the ECVAA via ECVAA-I050.
Notes:- There may be a delay between the receipt of the ECVAA-I049 and the actual removal of ECVNs and MVRNs. The removal process may involve some outage of the ECVAA service. This requirement does not cover any other possible action in respect of a Section H Default. Liability for the use of this process rests with ELEXON
Interfaces:
Related interface requirements: ECVAA-I049: Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default ECVAA-I050: Remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default Feedback

6 Interfaces Requirements

The ECVAA Service shall provide an interface to the following external parties.

Other Service Providers:

Central Registration Agent (CRA)
Funds Administration Agent (FAA)
Settlement Administration Agent (SAA)
Balancing Mechanism Reporting Agent (BMRA)
Central Data Collecting Agent (CDCA)

Other external parties:

BSC Party
Energy Contract Volume Notification Agent (ECVNA)
Metered Volume Reallocation Notification Agent (MVRNA)
BSCCo Ltd

The ECVAA Service shall provide inbound and outbound interfaces as summarised in the following table. Each interface requirement is described in detail below.

Details of the contents of interfaces relevant to ECVAA are contained in the Interface Definition and Design (IDD). In the event of discrepancies between the URS and IDD, the interface document takes precedence.

Reqt No.	Interface Requirement	Inbound/ Outbound	Interface User (IU)	Mechanism
ECVAA-I001	Receive Registration Data	Inbound	CRA	Automatic
ECVAA-I002	Receive Energy Contract Volume Notification Agent Authorisation Data	Inbound	BSC Party, ECVNA	Manual
ECVAA-I003	Receive Meter Volume Reallocation Notification Agent Authorisation Data	Inbound	BSC Party, MVRNA	Manual
ECVAA-I004	Receive Energy Contract Volume Notifications	Inbound	ECVNA	Automatic
ECVAA-I005	Receive Meter Volume Reallocation Notifications	Inbound	MVRNA	Automatic
ECVAA-I006	Receive Credit Limit Data	Inbound	FAA	Automatic
ECVAA-I007	Issue Energy Contract Volume Notification Agent Authorisation Feedback	Outbound	BSC Party, ECVNA	Manual/ Automatic
ECVAA-I008	Issue Meter Volume Reallocation Notification Agent Authorisation Feedback	Outbound	BSC Party, MVRNA	Manual/ Automatic
ECVAA-I009	Issue Energy Contract Volume Notification Feedback (Rejection)	Outbound	BSC Party, ECVNA	Automatic
ECVAA-I010	Issue Meter Volume Reallocation Notification Feedback (Rejection)	Outbound	BSC Party, MVRNA	Automatic
ECVAA-I011	Issue Account Bilateral Contract Volume Report	Outbound	SAA	Automatic
ECVAA-I012	Issue Metered Volume Reallocation Notification Report	Outbound	SAA	Automatic
ECVAA-I013	Issue Authorisation Report	Outbound	BSC Party, ECVNA, MVRNA	Automatic
ECVAA-I014	Issue Notification Report	Outbound	BSC Party, ECVNA, MVRNA	Automatic
ECVAA-I015	Receive BM Unit Credit Cover Meter Volume Data	Inbound	CDCA	Automatic
ECVAA-I016	Issue Exception Report	Outbound	CRA, FAA	Automatic
ECVAA-I017	Issue ECVAA Performance Report	Outbound	BSCCo Ltd	Manual
ECVAA-I018	Receive Acknowledgements	Inbound	All automatic outbound IU	Automatic
ECVAA-I019	Issue Acknowledgements	Outbound	All automatic inbound IU	Automatic
ECVAA-I020	Receive Exception Reports	Inbound	SAA	Automatic
ECVAA-I021	Issue Credit Limit Warning	Outbound	BSCCo Ltd	Manual
ECVAA-I022	Forward Contract Report	Outbound	BSC Party	Automatic
ECVAA-I023	ECVAA BSC Schedule D Charging Data	Outbound	BSCCo Ltd	Manual
ECVAA-I024	Receive Credit Cover Minimum Eligible Amount Request	Inbound	BSC Party	Manual
ECVAA-I025	Issue Credit Cover Minimum Eligible Amount Report	Outbound	BSC Party, FAA	Manual
ECVAA-I026	Issue Minimum Eligible Amount Request	Outbound	BSCCo Ltd	Manual
ECVAA-I027	Notification of BSC Party in Section H Default	Inbound	BSCCo Ltd	Manual
ECVAA-I028	Issue ECVN Acceptance Feedback	Outbound	BSC Party, ECVNA	Automatic
ECVAA-I029	Issue MVRN Acceptance Feedback	Outbound	BSC Party, MVRNA	Automatic
ECVAA-I030	Receive Notification Agent Termination Request	Inbound	CRA	Manual
ECVAA-I031	Issue Notification Agent Termination Feedback	Outbound	CRA	Manual
ECVAA-I032	Receive Credit Assessment Price	Inbound	BSCCo Ltd	Manual
ECVAA-I033	Receive Credit/Debit Report	Inbound	SAA	Automatic
ECVAA-I034	Reserved for future use
ECVAA-I035	Receive Forward Contract Report Start Period Override	Inbound	BSC Party	Manual
ECVAA-I036	Publish Credit Default Report	Outbound	BMRA	Automatic
ECVAA-I037	Receive Volume Notification Nullification Request	Inbound	BSC Party	Manual
ECVAA-I038	Issue Volume Notification Nullification Confirmation Report	Outbound	BSC Party	Manual
ECVAA-I039	Issue Nullification Completion Report	Outbound	BSC Party	Manual
ECVAA-I040	Issue Notification System Status Report	Outbound	BSCCo Ltd	Manual
ECVAA-I041	Receive Party Credit Default Authorisation Details	Inbound	BSCCo Ltd	Manual
ECVAA-I042	Banning/Unbanning Individual User Access to the ECVAA Web service	Inbound	BSC Party, ECVNA, MVRNA	Manual
ECVAA-I043	ECVAA Web service – BSC Party View ECVNs.	Outbound	BSC Party	Automatic
ECVAA-I044	ECVAA Web service – BSC Party View MVRNs.	Outbound	BSC Party	Automatic
ECVAA-I045	ECVAA Web service – ECVNA View ECVNs.	Outbound	ECVNA	Automatic
ECVAA-I046	ECVAA Web service – MVRNA View MVRNs.	Outbound	MVRNA	Automatic
ECVAA-I047	Issue Withdrawing Party Authorisation and Notification Details	Outbound	CRA	Manual
ECVAA-I048	Receive Physical Notification Data	Inbound	BMRA	Automatic
ECVAA-I049	Request to remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default	Inbound	BSCCo Ltd	Manual
ECVAA-I050	Remove all ECVNs and MVRNs from ECVAA for a Party in Section H Default Feedback	Outbound	BSCCo Ltd	Manual

The following diagrams illustrate these interface requirements.

ECVAA Service: Inbound Interface Requirements

ECVAA Service: Outbound Interface Requirements

7 Non-Functional Requirement

This section describes the non-functional requirements specific to the ECVAA Service. Requirements common to all the NETA Central Services are described in the appendices of the CRA URS.

7.1 ECVAA-N001: Web Security Requirements

Requirement ID: ECVAA-N001	Status: M	Title: Web Interface Security Requirements	BSC Reference: P98, P197
Man/auto: As required	Frequency: As required	Volumes: As required
Non Functional Requirement:
1. A secure site shall be provided for the systems required to support the Internet web based access of the ECVAA Service. The systems and data shall be protected against unauthorised access and corruption of data.
2. The ECVAA system shall provide a Web Interface accessible via the Public Internet and the Private NETA WAN. The performance of this service shall be commensurate with the low grade BMRA web site. (Availability figures are still subject to forthcoming contractual discussions.)
3. All data passed in either direction between the ECVAA webserver and a user’s client web browser shall be encrypted using the industry-standard encryption/decryption facilities provided by the HyperText Transport Protocol (Secure) (HTTPS) protocol.
4. The encryption key length used by the HTTPS protocol shall be such that adequate security is provided (cf. current public internet banking websites)
5. Access beyond the ECVAA website login page shall only be granted by providing correct and authenticated Party/Agent ID, User ID and password values.
6. Any failure during the login process shall normally return the user to the main login page without any indication of which part of the login authentication actually failed. The exception to this is when the user provides the correct User ID and password information, but some other restriction in their credentials file prevents login (e.g. credentials file expired, incorrect login day, incorrect source IP address).
7. Users must select the Party or Agent ID to which they wish to operate under during the login process.
8. Users must provide a suitably formatted Credentials file at login that has been previously encrypted using their selected organisation’s NETA Public Key Infrastructure (PKI).
9. The ECVAA Web service shall ensure that any password used is at least 8 alphanumeric characters in length containing a mixture of letters with at least one in uppercase and one in lowercase.
10. The ECVAA Web service shall provide facilities that allow passwords to be changed in a secure manner.
11. Passwords shall have validity for a controllable period of time.
12. All data displayed to users once logged in is commercially sensitive to their organisation and therefore only data pertinent to the Party or Agent that the user selected at login may be accessible to the user.
13. The ECVAA Web service shall automatically disconnect a user after a configurable system default period of user inactivity has elapsed.
14. The user-supplied Credentials file shall contain an optional user-configurable section to allow the user to reduce the timeout below the system default.
15. The ECVAA Web service shall allow connection from any IP address.
16. The user-supplied Credentials file shall contain an optional user-configurable section to allow the user to specify an IP address, set of IP addresses or domains from which it is acceptable for the user to connect from.
17. The ECVAA Web service shall allow connection 24 hours a day, 7 days a week.
18. The user-supplied Credentials file shall contain an optional user-configurable section to allow the user to specify the time of day for working and non-working days at which it is acceptable for the user to initiate a connection.
19. Access to the ECVAA Web service credentials file software shall be granted and controlled by Authorisation category ‘Z’ signatories.
20. Parties that withdraw from or are expelled from being a Qualified BSC Party shall have their access to the ECVAA Web service withdrawn simultaneously to their access to other ECVAA services.
21. Access to the Web service shall be granted to users by role. These roles shall be; Read Only, Edit, and Admin. BSC Parties will be provided with Read Only access to the BSC Party Web Site, ECVNA’s and MVRNA’s may be provided with Read Only of Edit access to their respective Web Sites as required. The credentials file issued shall contain the role that it has been issued for a separate credentials file shall be issued for each role granted to a user.
22. Audit requirements shall include; Details of notification submitted The submitting organisation and role code The time of receipt Processing details [Job and transaction parameters] Events generated

8 Service Requirements

This section describes the service delivery requirements specific to the ECVAA Service. Requirements common to all the NETA Central Services are described in the appendices of the CRA URS.

8.1 ECVAA-S001: Service Availability

Requirement ID:

ECVAA-S001

Status:

Title:

Service Availability

BSC Reference:

ECVAA SD: 2.1, 3.1

Man/auto:

Manual & Automatic

Frequency:

Volumes:

Non Functional Requirement:

Note: This requirement is subject to contract negotiations.

1. The ECVAA shall provide a 24x7 service, to enable support of its near real-time notification processing requirements.

2. The ECVAA shall perform the responsibilities and obligations of the service for all Settlement Days for which the ECVAA is appointed by the Customer.

8.2 ECVAA-S002: Volumetric Requirements

Requirement ID:

ECVAA-S002

Status:

Title:

Volumetric Requirements

BSC Reference:

RETA SCH: C4

RETA ITT: A3

Man/auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

The following tables list the ECVAA workloads as defined in the document Volumetric Assumptions [VOL].

The following table gives the assumptions on ECVNA Workload:

ECVNA Work	Go Live	Future
ECVNA Authorisations initial load	1000
ECVNA New authorisations per week	50	50
ECVNA Authorisation terminations per week	50	50
Parties trading at one contracts/period	100	250
Parties trading at 200 contracts/period	6	50
Trades per period	650	5125
ECVN per day	31200	246000
ECV Notifications rejected per year (credit checks)	6	6

The following table gives the assumptions on MVRNA Workload:

MVR	Go Live	Future
MVRNA Authorisations initial load	500
MVRNA Authorisations per week	10	10
BMUs with 2 MVR, notifying every 5 days	200	200
BMUs with 6 MVR, notifying every 5 days	150	150
BMUs with 6 MVR, notifying every period	0	50
MVRN day notifications submitted per day	260	260
MVRN period notifications submitted per day	0	15000
Total MVRN submitted per day	260	15260
MVR Notifications rejected per year (credit checks)	6	6
Number of BM Units with MVR split	350	400
Avg number of parties in an MVR split	3.7	4
MVRN in effect in any period	1300	1600

The following table gives the assumptions on Web service workloads:

Load	Go Live	Future
Simultaneous users	140	140
Query rate (per min/user.)	2	2

8.3 ECVAA-S003: Resilience Requirements

Requirement ID:

ECVAA-S003

Status:

Title:

Resilience Requirements

BSC Reference:

Man/auto:

Manual & Automatic

Frequency:

As required

Volumes:

Non Functional Requirement:

1. The ECVAA system shall run on a very high availability and resilient dual processor architecture, and support an automatic fail over capability if either processor node fails.

2. The ECVAA system shall automatically detect and highlight to the operator any significant errors to allow timely actions to be taken and a high level of service to be achieved.

9 User Roles and Activities

The user roles which will support the day to day operation of the ECVAA service are common to those supporting the CRA Service, and so are described in the CRA URS.

These roles and activities will be refined and developed in more detail during detailed business process definition.

The following parties are associated with the ECVAA business processes in the wider context, and may thus be considered as “users” of the service. The detailed functional requirements and data interfaces necessary to support these parties are described earlier in this chapter.

Role	Summary of Activities related to ECVAA
Central Registration Agent (CRA)	Provides registration data to the ECVAA which defines the set of items such as the BM Units relevant to each trading period.
Funds Administration Agent (FAA)	Provides credit limit data to the ECVAA to allow the credit exposure of BSC Parties to be determined.
Settlement Administration Agent (SAA)	Receives aggregated energy contract volumes and metered volumes reallocations from the ECVAA for the settlement of BSC Parties financial trading positions.
Central Data Collecting Agent (CDCA)	Provides BM Unit meter volume data which is used to derive participant energy indebtedness.
BSC Party	Provides energy contract volume and metered volume reallocation authorisations to the ECVAA jointly with the appointed notification agent.
Energy Contract Volume Notification Agent (ECVNA)	Provides energy contract volume notifications to the ECVAA to allow calculation of account bilateral contract volumes for BSC Parties.
Metered Volume Reallocation Notification Agent (MVRNA)	Provides metered volume reallocation notifications to the ECVAA to for validation.
BSCCo Ltd	Receives performance reports from the ECVAA.

10 Future Enhancements

No future enhancements to the ECVAA Service have been identified at this stage.

Appendix A Glossary

A standard NETA glossary is included in the CRA URS.

Appendix B Requirements Compliance Matrix

The following table shows the mapping of requirements defined in this URS document to the requirements set out in the Service Description for Energy Contract Volume Aggregation [ECVAA SD].

Service Description Requirement Number or CR number	URS Requirement Reference Number	Notes
1		Overview section therefore no mapping of requirements
2.1	ECVAA-S001
3.1	ECVAA-S001
4.1	ECVAA-F001 ECVAA-I001
4.2	ECVAA-F001 ECVAA-I016
5.1	ECVAA-F002 ECVAA-I006
5.2	ECVAA-F002 ECVAA-I016
6.1	ECVAA-F003 ECVAA-I002
6.2	ECVAA-F003 ECVAA-I007
6.3	ECVAA-F003 ECVAA-I007
6.4	ECVAA-F003 ECVAA-I007
6.5	ECVAA-F003
6.6	ECVAA-F003 ECVAA-I002
6.7	ECVAA-F003 ECVAA-I007
6.8	ECVAA-F003 ECVAA-I007
6.9	ECVAA-F003
7.1	ECVAA-F004 ECVAA-I003
7.2	ECVAA-F004 ECVAA-I008
7.3	ECVAA-F004 ECVAA-I008
7.4	ECVAA-F004 ECVAA-I008
7.5	ECVAA-F004
7.6	ECVAA-F004 ECVAA-I003
7.7	ECVAA-F004 ECVAA-I003 ECVAA-I008
7.8	ECVAA-F004 ECVAA-I008
7.9	ECVAA-F004
8.1	ECVAA-F005 ECVAA-I004
8.2	ECVAA-F005
8.3	ECVAA-F005 ECVAA-I009
8.4	ECVAA-F008
8.5	ECVAA-I011
9.1	ECVAA-F006 ECVAA-I005
9.2	ECVAA-F006 ECVAA-I010 ECVAA-I012
9.3	ECVAA-F006
9.4	ECVAA-I012
10.1	ECVAA-F007
11.1	GEN-S005
CR005	ECVAA-F004 ECVAA-F006 ECVAA-I003 ECVAA-I005 ECVAA-I008
CR008	ECVAA-F003 ECVAA-F005 ECVAA-F006 ECVAA-I004 ECVAA-I005
CR012	ECVAA-F002 ECVAA-F005 ECVAA-F006 ECVAA-F007 ECVAA-F008 ECVAA-F010 ECVAA-I001 ECVAA-I006 ECVAA-I009 ECVAA-I010 ECVAA-I014 ECVAA-I016 ECVAA-I017 ECVAA-I021
CR051	ECVAA-I022
CR065	ECVAA-I023
Clarification: ‘ECVAA Authorisation Keys’	ECVAA-F003 ECVAA-F004 ECVAA-I002 ECVAA-I003 ECVAA-I007 ECVAA-I008
P4	ECVAA-F005 ECVAA-F006 ECVAA-I022 ECVAA-I028 ECVAA-I029
CP539	ECVAA-F005
CP519	ECVAA-F011 ECVAA-I017 ECVAA-I024 ECVAA-I025 ECVAA-I026 ECVAA-I027
Release 2 Variation 14 (override Report Start Period) amendment to P4/P17	ECVAA-I022 ECVAA-I035	This “variation” is an amendment to the solution for P4 & P17 and so is not explicitly referenced in the “ITT ref” section of the interfaces.
CP503	ECVAA-F001 ECVAA-I030 ECVAA-I031
CP547	ECVAA-F003 ECVAA-F004 ECVAA-I002 ECVAA-I003 ECVAA-I007 ECVAA-I008
P2	ECVAA-F010 ECVAA-I032 ECVAA-I033
Release 2 Variation 9	ECVAA-F011 ECVAA-I024 ECVAA-I025	This “variation” is an amendment to the solution for CP519 and so is not explicitly referenced in the “ITT ref” section of the interfaces.
CP571	ECVAA-F003 ECVAA-F004 ECVAA-F007 ECVAA-I007 ECVAA-I008
CP703	ECVAA-F007 ECVAA-I009 ECVAA-I010 ECVAA-I036
CP725	ECVAA-F005 ECVAA-F006 ECVAA-I022 ECVAA-I028 ECVAA-I029
CP877	ECVAA-I022	Removal of sub flow 2
Variation 43	ECVAA-I022
Variation 44	ECVAA-I022
Variation 49	ECVAA-F003 ECVAA-F004
P98	ECVAA-F003 ECVAA-F004 ECVAA-F005 ECVAA-F006 ECVAA-F014 ECVAA-F015 ECVAA-F016 ECVAA-F017 ECVAA-F018 ECVAA-F019 ECVAA-F020 ECVAA-F021 ECVAA-F022 ECVAA-F023 ECVAA-I002 ECVAA-I003 ECVAA-I004 ECVAA-I005 ECVAA-I007 ECVAA-I008 ECVAA-I009 ECVAA-I010 ECVAA-I013 ECVAA-I028 ECVAA-I029 ECVAA-I042 ECVAA-I043 ECVAA-I044 ECVAA-I045 ECVAA-I046 ECVAA-N001
CP975	ECVAA-I001 ECVAA-I041
CP974	ECVAA-F024 ECVAA-I047
P142	ECVAA-F007
CP1009	ECVAA-F003 ECVAA-F004
P140	ECVAA-F010 ECVAA-F025 ECVAA-I048
CP1140	ECVAA-F026 ECVAA-I049 ECVAA-I050
CP1169	ECVAA-F012 ECVAA-F026 ECVAA-I038 ECVAA-I039 ECVAA-I049 ECVAA-I050
P197	ECVAA-N001
P215	ECVAA-F010 ECVAA-F025 ECVAA-F001 ECVAA-I014 ECVAA-I015
CP1373	ECVAA-F020 ECVAA-F021
P307	ECVAA-F007
P309	ECVAA-F003 ECVAA-F005 ECVAA-F019

Appendix C Not used

Appendix D Business Process Model

This area is addressed outside the scope of this document.

1 The Omitted Data functionality has been developed, but is disabled.

2 The Omitted Data functionality has been developed, but is disabled.

User Requirements Specifications

CONTENTS

Energy Contract Volume Aggregation Agent

1. Management Summary

1.1 Purpose

1.2 Scope

2 Introduction

3 Scope of Specification

4 Business and System Overview

4.1 Summary of Business Requirements

4.1.1 ECVNAA Approval

4.1.2 MRVNAA Approval

4.1.3 Notification Collection

4.1.4 Credit Checking

4.1.5 Aggregation and reporting to SAA

4.2 Service Context

4.3 User Requirements Source Documents

4.4 Requirements Summary

4.5 Numbering Scheme for Requirements Definitions

4.6 Attributes of Individual Requirements

5 Functional Requirements

5.1 ECVAA-F001: Process Registration Data

5.2 ECVAA-F002: Process Credit Limit Data

5.3 ECVAA-F003: Process ECVNAA

5.4 ECVAA-F004: Process MVRNAA

5.5 ECVAA-F005: Process Energy Contract Volume Notifications

5.6 ECVAA-F006: Process Metered Volume Reallocation Notifications

5.7 ECVAA-F007: Perform Credit Check

5.8 ECVAA-F008: Aggregate Energy Contract Volumes

5.9 ECVAA-F009: Process Exception Data

5.10 ECVAA-F010: Calculate Party Indebtedness

5.11 ECVAA-F011: Process Credit Cover Minimum Eligible Amount Request

5.12 ECVAA-F012: Process Volume Notification Nullification

5.13 ECVAA-F013 Manage ECVAA System Failure / Withdrawal

5.14 ECVAA-F014: Matching of submitted ECVNs

5.15 ECVAA-F015: Matching of submitted MVRNs

5.16 Notes on Notification Processing and Reporting

5.17 ECVAA-F016: ECVAA Web Service Common Functionality.

5.18 ECVAA-F017: ECVAA Web Service – BSC Party View ECVNs Functionality.

5.19 ECVAA-F018: ECVAA Web Service – BSC Party View MVRNs Functionality.

5.20 ECVAA-F019: ECVAA Web Service - ECVNA Functionality.

5.21 ECVAA-F020: ECVAA Web Service - ECVNA ECVN Submission Functionality.

5.22 ECVAA-F021: ECVAA Web Service - MVRNA Functionality.

5.23 ECVAA-F022: ECVAA Web Service - MVRNA MVRN Submission Functionality.

5.24 ECVAA-F023: Banning/Unbanning Individual User Access to the ECVAA Web service Functionality

5.25 ECVAA-F024: Process Withdrawing Party Authorisation and Notification Details

5.26 ECVAA-F025: Calculate Period Final Physical Notification Volumes

5.27 ECVAA-F026: Process removal of ECVNs / MVRNs from ECVAA for a Party in Section H Default

6 Interfaces Requirements

7 Non-Functional Requirement

7.1 ECVAA-N001: Web Security Requirements

8 Service Requirements

8.1 ECVAA-S001: Service Availability

8.2 ECVAA-S002: Volumetric Requirements

8.3 ECVAA-S003: Resilience Requirements

9 User Roles and Activities

10 Future Enhancements

Appendix A Glossary

Appendix B Requirements Compliance Matrix

Appendix C Not used

Appendix D Business Process Model