Idd part 1 Interfaces with bsc parties and their Agents




старонка76/82
Дата канвертавання24.04.2016
Памер4.34 Mb.
1   ...   72   73   74   75   76   77   78   79   ...   82

7.23 ECVAA-I039: (output) Issue Nullification Completion Report


Interface ID:

ECVAA-I039



User:

BSC Party



Title:

Issue Nullification Completion Report



BSC reference:

P110 CP1169



Mechanism:

Manual - via email



Frequency:

As required



Volumes:

Low


Interface Requirement:

The ECVAA Service shall issue a Nullification Completion Report to BSC Parties.


The Nullification Completion Report shall comprise:
Party ID

Party Name

Party Energy Account Production/Consumption Flag

Counter-Party ID

Counter-Party Name

Counter-Party Energy Account Production/Consumption Flag

Nullification Effective Date and Period

Party VNNR Reference or the words ‘SECTION H’ in the case of a BSC Panel authorised Volume Notification Nullifications for a Section H Default.

ECVAA Reference

Completion date and time (GMT)




Physical Interface Details:
The ECVAA systems shall generate and send the Nullification Completion Report as emails.



7.24 Additional Clarification on ECVAA Interfaces

7.24.1 Sign Convention


This section clarifies the notes given in the spreadsheets regarding the sign conventions used for Energy Contract Volume Notifications (ECVAA-I004) and the reporting of this data in the subsequent Notification Reports (ECVAA-I014) and Forward Contract Reports (ECVAA-I022). The table below details the Sign Convention where Party 1 is selling and Party 2 is buying and then vice versa.

Party

Buying /

Selling


I004

I014

I022

1

Selling

Positive

Positive

Positive

2

Buying

Positive

Positive

Negative

1

Buying

Negative

Negative

Negative

2

Selling

Negative

Negative

Positive

In summary the ECVAA-I004 flows and ECVAA-I014 reports always use the sign relative to Party 1, but the ECVAA-I022 report uses the sign specific to the Party who is receiving the report.

7.24.2 Notes on functionality


The following text is provided for additional clarification. It is included in the IDD for convenience. However, this information is outside the scope of the IDD and the IDD is not the definitive location for such functional detail. For definitive information on functionality, the reader is referred to the ECVAA URS, and in the event of inconsistency between the text here and the URS, it is the URS that prevails.

This section explains how the ECVN interface is used, with examples.

ECVN Ids:

1) Each Notification (ECVN) will include the ECVNA Id (in the header record), ECVNAA Id, ECVNAA Key, and ECVN Id (ECVNAA Id + reference code).

2) The ECVNAA Id exists twice in each Notification - once to determine the Agent and Parties to this Notification, and then again within the ECVN Id to enable the uniqueness of a Notification for a given pair of trading Parties.

3) The ECVN Id is unique across all Agents. It is a combination of 2 attributes - the ECVNAA Id of the Agent, followed by a reference code.

4) The ECVNAA Id within the ECVN Id has restrictions applied to it. It must either be the ECVNAA Id of the Agent submitting the ECVN, or the ECVNAA Id of an Agent whose ECVNAA has now expired and who once submitted ECVNs for the same pair of trading Parties.

5) The reference code should be unique within an ECVNAA Id to ensure that the ECVN Id is unique and is hence processed as an Additive Notification. If the reference code is not unique within the ECVNAA Id then the ECVN will be processed as an Overwrite Notification.

EXAMPLE:

Consider trading relationships between Party A and Party B, and Party B and Party C.

Party A and B use both ECVNA1 and ECVNA2 (ECVNAA Id 101 and ECVNAA Id 102)

Party B and C use ECVNA1 (ECVNAA Id 103)

Notification

Here ‘ECV’ followed by a 6 character integer is being used as the reference code.

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000001 is an Additive notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000001 is an Additive notification for Party A and B

- Agent ECVNA1, ECVNAA Id 103, ECVN Id 103 ECV000001 is a Additive notification for Party B and C

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000002 is a Additive notification for Party A and B

- Agent ECVNA1, ECVNAA Id 101, ECVN Id 101 ECV000001 is a Overwrite notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 101 ECV000001 is rejected as ECVNAA Id 101 belongs to another active Agent

The Parties are responsible for ensuring their other agents are able to maintain their Notifications. If ECVNAA Id 101 is then terminated (i.e. Agent ECVNA1 no longer acts on behalf of Parties A and B), then the Parties must inform another agent of their Notifications. The following Notification could then be submitted:

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 101 ECV000001 is a Overwrite notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000002 is an Additive notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 102 ECV000002 is an Overwrite notification for Party A and B

- Agent ECVNA2, ECVNAA Id 102, ECVN Id 101 ECV000005 is rejected as this does not exist to be overwritten

7.24.3 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 the 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 Gate Closure 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 Gate Closure has already passed.

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



  • If Effective From = Effective To, the Notification will be stored as received (MultiDay flag = "S").

  • Otherwise (the Notification spans multiple dates):

  • For Notification with Effective From Date > Current Date: the Notification will be stored as received (MultiDay 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 Gate Closure has passed, then the Notification is stored as a single date range from the Applied From Date to the specified Effective To Date (MultiDay flag = "M").

  • Otherwise, the Notification is stored as two records, a single day for the Current Date (MultiDay flag = "M" unless Current Date is a Clock Change Day, in which case the Periods are converted to 46/50 period day and MultiDay = "S") and the remainder from Current Date+1 to specified Effective To Date (MultiDay flag = "M")

The following table shows how Notifications are stored (and subsequently reported) in various scenarios. Note that the “MultiDay” 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-Gate Closure, as notification after gate closure

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-Gate Closure, as notification after Gate Closure




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-Gate Closure, as notification after Gate Closure

G*

M

Current Date

Current Date

As notification

* - Only where period data exactly matches previously held pre-Gate Closure 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-Gate Closure 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 MultiDay Notification which starts before and ends on or after the Applied From Date of a received Notification which overwrites it will have its Effective To date set to Applied From Date minus one. the “MultiDay” 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 MultiDay flag being set to “M”

Any Notifications stored with a single day range and the “MultiDay” 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.

The following examples illustrate some of these scenarios and how received Notification data is reported in the ECVAA-I022 report; in each case the current date is the 29th March 2003, and the 30th March 2003 is a short clock change day. In each case the “Ref” refers to the table above, but it is not intended that every case should be covered:

7.24.3.1 MultiDay Notification Received in-day before a Clock Change (Ref D)


Received as:

Effective From Date: 26th March 2003

Effective To Date: 30th March 2003

Period Data: 48 Periods

Reported as:

Effective From Date: 29th March 2003 (note the Applied From Date is Current Date)

Effective To Date: 29th March 2003

Period Data: 48 Periods; 0 up to Gate Closure, as received after that

Effective From Date: 30th March 2003

Effective To Date: 30th March 2003

Period Data: 46 Periods; 1,2,5-48 mapped to short clock change day Periods 1-46 (stored as 48 periods with Multi-Day flag set to “M”)

7.24.3.2 MultiDay Notification Received in-day before a Clock Change (overwrite Notification received in 7.24.3.1) (Ref E)


Received as:

Effective From Date: 26th March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods (data same as 7.24.3.1 up to Gate Closure)

Reported as:

Effective From Date: 29th March 2003 (note the Applied From Date is Current Date)

Effective To Date: NULL

Period Data: 48 Periods as received in 7.24.3.2.



7.24.3.3 Future MultiDay Notification starting on Clock Change day (Ref C)


Received as:

Effective From Date: 30th March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods

Reported as:

Effective From Date: 30th March 2003

Effective To Date: NULL

Period Data: 48 Periods as received



7.24.3.4 Future MultiDay Notification (overwrite Notification received in 7.24.3.3) (Ref C)


Received as:

Effective From Date: 31st March 2003

Effective To Date: NULL (i.e. open ended)

Period Data: 48 Periods

Reported as:

Effective From Date: 30th March 2003

Effective To Date: 30th March 2003

Period Data: 46 Periods; 1,2,5-48 as received in 7.24.3.3, but mapped to short clock change day Periods 1-46 (stored as 48 periods with Multi-Day flag set to “M”)

Effective From Date: 31st March 2003

Effective To Date: NULL

Period Data: 48 Periods as received in 7.24.3.4

1   ...   72   73   74   75   76   77   78   79   ...   82


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка