FAQs on transaction reporting – Question II.2.1.37

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract. The delivery point of the gas under the contract conditions (where the commodity changes hands) is an Entry point ABC from production facility. The point ABC is a connection point between the production facility and the gas transmission system of the TSO.

For reporting purposes under the requirements of Article 3(1)(a) of Commission Implementing Regulation (EU) N1348/2014, what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE – the EIC of the Entry point ABC or the EIC of the Balancing zone to which the gas is entering?

If the EIC of the Entry point ABC shall be filled in the XML field DELIVERY POINT OR ZONE, the MP needs to add said EIC code to the list of valid EICs. Could you please confirm that it will be possible to add such an EIC via the Agency’s web-tool for mapping/supply of EIC information, e.g. via using “Other” in the point type drop down?


Answer:

The EIC of the Balancing zone should be reported. There is no need to add the Entry point ABC via the Agency’s web-tool for mapping/supply of EIC information.

The same would apply to Domestic/Industrial aggregate points and Distribution zones/networks. If these points are connected to a balancing zone from where the gas/electricity is withdrawn/supplied from, the EIC of the balancing zone should be reported.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.38

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract.

The delivery point of the gas under the contract conditions (where the commodity changes hands) is a connection point between a storage facility and gas transmission system. The point name is XYZ. Point XYZ is bidirectional.

XYZ (entry) is the point direction from the Storage facility to the Gas transmission system;

XYZ (exit) is the point direction from the Gas transmission system to the Storage facility.

Q. 1  For reporting purposes under the requirements of Article 3(1)(a) of Commission Implementing Regulation (EU) No 1348/2014, what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2:

  • DELIVERY POINT OR ZONE, if the commodity changes hands at XYZ (entry) or
  • the EIC of the connection point between a storage facility and gas transmission system (XYZ entry) or the EIC of the Balancing zone to which the gas is entering?

Q. 2  For reporting purposes under the requirements of Regulation (EU) No 1348/2014, point 3.1 (a), what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE, if the commodity changes hands at XYZ (exit)?


Answer:

Q 1. The Balancing zone the gas is entering into.

Q 2. The Balancing zone the gas storage facility belongs to.

Q 3. There is no need to add a connection point between a storage facility and gas transmission system via the Agency’s web-tool for mapping/supply of EIC information.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.39

Data Field (48)

Could the Agency clarify the reporting of EICs and their mapping to the balancing zones/areas, interconnection points, LNG and storage facilities?


Answer:

In the Transaction Reporting User Manual (TRUM) after consulting the industry through two public consultations, the Agency has indicated that the Energy Identification Code (EIC) to be reported for transaction reporting purposes for Table 1 and Table 2 has to identify the commodity delivery point or zone.

This field reports the EIC Y code (or an alternative code to be agreed with the Agency if the EIC is not available) to identify the delivery and/or balancing point for the contract. In addition, the TRUM clarifies that since gas can also be delivered at the interconnection point, then the EIC Z Code for that interconnector may be used.

Furthermore, in the FAQs on transaction reporting – Question II.3.1.23, the Agency has indicated that where the gas is delivered at an LNG or a gas storage facility, then the EIC W code for that facility should be reported.

Based on more than 1 billion transactions (Table 1 and Table 2) reported to the Agency, it was found that market participants and organised market places are using more than 4000 codes to indicate the delivery points. In some occasions more than 1000 different codes were used to indicate the same balancing zone.

Since the Agency (supported by the input provided by the industry) does not find this diversification reasonable and has seen that 95% of the overall transactions have been reported with the correct EICs, on 26 June 2017 the Agency has published Annex VI to the TRUM (including the list of accepted EICs) in the REMIT portal and will only consider the codes listed in the list of accepted codes.

In the Agency’s view, if 95% of the reported transactions are compliant with REMIT, there is no reason for the remaining 5% of transactions to be reported with alternative codes.

Market participants that use different codes for nomination purposes at domestic/industrial aggregate points, distribution zones/networks or production sites should report in any case the EIC of the balancing zone these points are connected to. While they may want to keep using those codes for nomination purposes, they will need to translate those codes into the EIC of the balancing zone they are related to when reporting the transaction to the Agency for REMIT purposes.

With regard to interconnection points, the Agency has explained in Annex VI to the TRUM that the reportable Y EIC code has to belong to the interconnection point where gas is delivered and then transferred to the other side of the interconnection point by the system operator. This case applies to unbundled interconnection capacity only.

In Annex VI to the TRUM the Agency has explained that only the EICs in the list of accepted codes are reportable codes. All the other codes available in the sheet “EICs Validity Check” and flagged as “Invalid” , “ENTSO-E” and “Missing” (please carefully read Annex VI to the TRUM) are not considered compliant with the Agency’s guidance according to Article 5(2) of Commission Implementing Regulation (EU) No 1348/2014.

However, in order to help market participants and organised market places to comply with REMIT, the Agency has given the opportunity to clear their transaction reporting history (related to the EICs) through the online “EIC mapping form” (please see Annex VI to the TRUM for the link).

The online form allows reporting parties to map a previously reported EIC (Missing, Invalid, ENTSO-E list) to a code listed in the “List of Accepted EICs” and to report a code for a zone/area/facility that is not included in the “List of Accepted EICs” (or changing its name/function).

However, market participants that have submitted new codes for domestic/industrial aggregate points, distribution zones/networks or production sites connected to a balancing zone, should not expect the inclusion of those codes in the list of accepted codes, unless the Agency believes there is reasonable ground for their inclusion in the list.

The Agency has already updated the list of EICs codes to accommodate TSOs or market participants requests where the Agency believed there was a reasonable ground for the inclusion of new EICs (this is visible in the EIC list of accepted codes spreadsheet attached to Annex VI to the TRUM).

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.40

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract. The location where commodity changes hands under the contract conditions is a Gas storage facility.

For reporting purposes under the requirements of Regulation (EU) No 1348/2014, point 3.1 (a), what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE – the EIC of the Gas storage facility or the EIC of the Balancing zone to which the Gas storage facility belongs?


Answer:

 

Assuming that the seller is withdrawing the gas from the system and injecting it into the storage, then handing it over to the buyer, or if the seller sells the gas that he already owns in the storage to the buyer, the EIC of the Gas storage facility should be reported.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.41

Data Fields (49) and (50)

Using putting a time of 24:00:00 for end times is not possible using industry standard development tools that we use – it gets translated to 00:00:00. This applies to Fields 28 (contract trading hours) and Field 54 (Load Delivery Intervals)

Please accept that instead of the below in your example

<deliveryProfile>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>24:00:00</loadDeliveryEndTime>

</deliveryProfile>

That we can use to mean the same thing

<deliveryProfile>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

This is consistent with the interpretation for gas contracts available in the TRUM where start time = end time.

deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>


Answer:

According to ACER’s schemas and to the ISO 8601 standard which says “Midnight is a special case and may be referred to as either “00:00” or “24:00”. It is our understanding that midnight may be represented as either 00:00:00 or 24:00:00 or 23:59:59.

All of them have the same meaning. The same applies to 06:00:00 and 05:59:59. All of them have the same meaning. The same applies to 06:00:00 and 05:59:59 to represent the end of a gas day.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.42

Data Fields (49) and (50)

Could the Agency clarify further “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017.“ statement available on its Open letter on REMIT transaction reporting data quality?


Answer:

As indicated in the letter, market participants should refer to the Agency’s guidance on transaction reporting, namely the TRUM, Annex II to the TRUM and the FAQs on transaction reporting and they should also liaise with the RRMs reporting on their behalf as they may provide with additional instructions.

Based on the Agency’s schemas, and the ISO 8601 standard which says “Midnight is a special case and may be referred to as either “00:00” or “24:00″, our understanding is that midnight may be represented as either 00:00:00, 24:00:00 or 23:59:59.

For example, 2016-08-01 00:00:00 represents the same date and time of 2016-07-31 23:59:59 or 2016-07-31 24:00:00.

However, according to the guidance, 23:59:59 and 24:00:00 should not be reported for delivery start time. Time 23:59:59 or 24:00:00 on Day X should be reported as 00:00:00 in day X+1. The same applies to 06:00:00 and 05:59:59 to represent the end of a gas day.

Example: a typical yearly electricity baseload contract is wrongly reported if the delivery start date and time is 2016-12-31 00:00, 2016-12-31 23:59:59 or 24:00:00. The delivery start date and time should be reported as 2017-01-01 00:00:00.

With regard to “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017” reporting parties should pay attention to the guidance.

REMIT transaction reporting fields include Field N. (53) “Days of the week” which plays a pivotal role in the simplification of the reporting of delivery profiles. Please see also FAQs on transaction reporting – Question II.2.1.40.

When “Days of the week” is reported correctly, the reported delivery profile will always be the same of the “actual delivery profile” of the contract.

Case 1 – delivery period falls within the calendar period

For electricity contracts, e.g. see example 2.11 in Annex II to the TRUM, a report for the monthly electricity peak load delivery for August 2014. The hourly delivery profile is defined by the fields:

Field N. (49) “Delivery Start Date”: 01/08/2014 identifies the date at which the delivery of the commodity starts as specified in the contract.

Field N. (50) “Delivery End Date”: 31/08/2014 identifies the date at which the delivery of the commodity ends as specified in the contract.

Field N. (53) “Days of the week”: WD identifies on which days of the week the delivery takes place, i.e. week days, as specified in the contract.

Field N. (54) “Load Delivery Intervals”: 08:00/20:00, as specified in the contract

In this specific case 1 August 2014 is Friday, therefore the physical delivery starts on that date. 31 August 2014 is Sunday, thus the physical delivery ends on Friday 29 August.

Case 2 – delivery period falls outside the calendar period

Furthermore, reporting parties should also pay attention to some special circumstances.

For gas contracts, e.g. see example 2.8 in Annex II to the TRUM, given a gas day 06:00 on day D to 06:00 to D+1 may affect the reporting of their monthly contracts. A monthly gas delivery for August 2014, with physical delivery starting on 1 August 2014 delivers gas from 06:00 to 06:00 and the actual physical delivery ends on 1 September 2014 at 06:00. Therefore, the correct way of reporting this contract is:

Field N. (49) “Delivery Start Date”: 01/08/2014

Field N. (50) “Delivery End Date”: 01/09/2014

Field N. (53) “Days of the week”: empty to indicate every day

Field N. (54) “Load delivery intervals”: 06:00/06:00 Another special circumstance is when a monthly electricity off-peak load delivery for August 2014 start at 19:00:00 on 31/07/2014. These are typical monthly contracts but the delivery period falls outside the calendar days, rather than within them.

We are aware that these are industry standards and are used by Organised Market Places (OMPs) and the Agency would expect the reporting of delivery Start and End Date as shown above and in Annex II to the TRUM. The Agency is also aware that in most cases the same standards are used in bilateral trades (non-OMPs trades).

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.43

Data Field (51)

Field 51 (Duration) previously contained a value of ‘HH’ representing ‘Half Hour’. This appears to be no longer available. Should we just use ‘O’ for ‘Other’ now?


Answer:

Field 51 (Duration) it is not currently in use. Please refers to trading examples in Annex II of the TRUM available at https://www.acer-remit.eu/portal/data-submission where all the examples show that field 51 (Duration) is not required to be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.44

Data Field (52)

ACER Transaction Reporting User Manual – Reporting of Standard Supply Contracts – Field 52

How to correctly map to the ACER load type values ‘Shaped’ and ‘Other’ What is the difference between these two values?

We trade the following structures:

Overnights (Blocks 1+2)

Extended Peaks (Blocks 3+4+5+6)

Weekday Block 4

Would these load types be ‘Shaped’ or ‘Other’?

We think the above fall under ‘Other’


Answer:

If the price is the same for all the hours within the blocks, then BH for block hours should be used. If the price is different per each hour of the blocks, then it is a shaped product. In some cases it is possible to have a shaped product that has the same price for all the hours, but still a shaped product. Usually this is an OTC bilateral contract or voice brokered.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.45

Data Field (53)

Please can you provide some sample messages using the IB and XB notation, so including or excluding bank holidays.  I can see them in the TRUM but am having problems visualising practically how they would work.

An Eastern European off-peak trade that delivers

M-F excluding bank holidays from 0-8

M-F excluding bank holidays from 20-24

Sat-Sun 0 – 24

AND Bank holidays 0-24

The problem is I can’t see how to use IB and XB – the daysOfTheWeek tags are restricted in a way that I can’t see how to store what I think should be the case i.e. adding XB to the MOtoFR days designation.

Is this the kind of detail you were intending? An example would be great. Thanks

<deliveryProfile>

<daysOfTheWeek>MOtoFRXB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>MOtoFRXB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>SAtoSUIB</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>


Answer:

XB indicates that on Bank Holidays that profile does not apply and it is excluded. IB indicates that on Bank Holidays the same profile applies. In order to correctly use XB and IB, the field <daysOfTheWeek> </daysOfTheWeek> has to be reported twice in order to indicate the exclusion or inclusion of Bank Holidays. For example:

For XB:

<deliveryProfile>

<daysOfTheWeek>MOtoFR</daysOfTheWeek>

<daysOfTheWeek>XB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

For IB:

<deliveryProfile>

<daysOfTheWeek>SAtoSU</daysOfTheWeek>

<daysOfTheWeek>IB</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.46

Data Field (53)

As per the TRUM document, Days of the week allows the value ” ” which means “All days”.

But the specification in the ACER XSD says;

<xs:simpleType name=”daysOfTheWeekType”>

<xs:restriction base=”xs:string”>

<xs:pattern

value=”((SU|MO|TU|WE|TH|FR|SA)to(SU|MO|TU|WE|TH|FR|SA))|(SU|MO|TU|WE|TH|

FR|SA|XB|IB|WD|WN)”/>

</xs:restriction>

</xs:simpleType>

Due to this restriction, XML file fails validation wherever days of the week is ” “.

We would like to flag this to ACER. As a solution to this issue, should we have to display SUtoSA for All Days instead of “ “. Please advise.


Answer:

The symbol “ “ means blank and it means all days. Please note that the field is not mandatory.

RSS_Icon Last update: 16/11/2015  

RSS_Icon Subscribe to this Category’s RSS