FAQs on transaction reporting – Question III.4.2.13

According to the schema for gas transportation transactions reporting: urn-easee-gas-eu-edigas-remit-gascapacityallocationsdocument-5-1.xsd, the only currency code allowed is EURO.

Please see the document Edig@s Message Implementation Guidelines, schema: Gas Capacity Allocation, element 3.1.3.15 Currency.Code.

Does ACER intend to change this schema/element in order to be able to accept reports for transactions performed in other currencies (valid for UK, and the EU countries outside the monetary union Eurozone)?

Or does the Agency require conversion from the different currencies to EURO? If yes, what are requirements for this conversion?

What exchange rate shall be used?


Answer:

The Agency, after consulting relevant parties, established procedures, standards and electronic formats based on established industry standards for reporting of information referred to in Articles 6, 8 and 9 of the Implementing Acts. The current schemas foreseen for data reporting to the Agency under REMIT are the result of extensive consultations with stakeholders during 2014 and 2015.

This includes the accepted values for the currency code in the above-mentioned schema. The Agency will base data collection as of 7 April 2016 on the currently applicable schemas in order to facilitate reporting for all reporting parties. This is why the Agency, for reasons of legal certainty and consistency, will currently not modify the schema in the near future. The Agency is currently aiming at reviewing the current schemas for data reporting in early 2017. The Agency will consult relevant parties on material updates of the referred procedures, standards and electronic formats.

In the light of the above, the only currency code allowed for the relevant schema is EUR. Prices which were originally not expressed in EUR should be converted to EUR.

The Agency recommends using the last available ECB reference rate for the currency conversion at the time before the trade is concluded. Please refer to https://www.ecb.europa.eu/stats/exchange/eurofxref/html/index.en.html for further details on the ECB’s reference rate updates.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.14

According to the schema for gas transportation transactions reporting: urn-easee-gas-eu-edigas-remit-gascapacityallocationsdocument-5-1.xsd, the only Primary Market Participant identification coding scheme allowed is 305 (EIC). Please see the document

Edig@s Message Implementation Guidelines, schema: Gas Capacity Allocation, element 3.1.4.2.

In case that a TSO shall report data about a transportation contract concluded outside an OMP and the respective client of the TSO (Primary Market Participant) is not registered as Market participant, neither possess EIC, how shall it be identified in the report file when the only allowed coding scheme is 305?


Answer:

The Agency, after consulting relevant parties, established procedures, standards and electronic formats based on established industry standards for reporting of information referred to in Articles 6, 8 and 9 of the Implementing Acts. The current schemas foreseen for data reporting to the Agency under REMIT are the result of extensive consultations with stakeholders during 2014 and 2015. As a result of the aforementioned consultations, only EIC codes are accepted for identifying the reporting parties when reporting gas and electricity transportation contracts.

All reporting parties need to make sure to apply for an EIC code if they do not have one. The EIC codes can be obtained from the local issuing office. Since the EIC code will be used for reporting, it must be registered by the market participant’s registration as market participant according to Article 8 of REMIT.

Please note that it is the market participant’s responsibility for the completeness, accuracy and timely submission of data to the Agency and, where required so, to national regulatory authorities. Where a market participant reports those data through a third party, the market participant shall not be responsible for failures in the completeness, accuracy or timely submission of the data which are attributable to the third party. In those cases the third party shall be responsible for those failures, without prejudice to Articles 4 and 18 of Regulation (EC) No 543/2013 on submission of data in electricity markets. Market participants using a third party for reporting purposes shall nevertheless take reasonable steps to verify the completeness, accuracy and timeliness of the data which they submit through third parties. This includes the completeness and accuracy of the market participant identification through a relevant identification code.

Potential sanctions for the breach of reporting obligations as laid down in Article 8 of REMIT are defined at national level. In case reporting parties are facing technical issues when reporting data to the Agency, the Agency has established a contingency plan for Registered Reporting Mechanisms which provides all instructions on what reporting parties have to do in case of different scenarios that may impact the reporting. Any such possible technical issues should not be confused with possible breaches of the reporting obligations under REMIT.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.15

Reference to Articles 6(2) and 7(2) of the Implementing Acts

Article 6(2) of the Implementing Acts state that TSOs or third parties acting on their behalf shall report details of contracts referred to in Article 3(1)(b)(i) of the Implementing Acts including matched and unmatched orders.

Article 7(2) of the Implementing Acts state that in the case of auction markets where orders are not made publicly visible, only concluded contracts and final orders shall be reported. They shall be reported no later than on the working day following the auction.

How should TSOs understand the provisions of Articles 6(2) and 7(2) of the Implementing Acts?

Shall the TSOs or third parties acting on their behalf report all orders (matched and unmatched) or only information about the concluded contracts as the result of successful orders?


Answer:

It is the Agency’s current understanding that each auction rounds can impact the final price for transmission capacity.

Accordingly, all orders matched and unmatched which were taken into consideration for the calculation of any auction round need to be reported.

Please note that orders (matched or unmatched) are not relevant for back loading.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.16

Reference to Article 7(5) of the Implementing Acts  in case of Over-nomination.

Article 7(5) of the Implementing Acts stipulate that details of contracts referred to in Article 3(1)(b)(i) shall be reported as soon as possible but no later than on the working day following the availability of the allocation results. Any modification or the termination of the concluded contracts shall be reported as soon as possible but no later than on the working day following the modification or termination.

Over-nomination:

(According to Article 3(12) Regulation (EU) No 984/2013, CAM NC):

Network user nominates more than transport customer has booked.  According to CAM rule this constitutes a booking of interruptible within-day capacity.

How to understand the provisions of Article 7(5) of the Implementing Acts  in case of Over-nomination?

Should the cases of Over-nomination be reported?

If yes, as a new contract or as a modification of existing one?

What PROCESS_TRANSACTION.TYPE (corresponding to TRUM field 9 Transportation transaction type) shall be used in case of process not included in the Edig@s coding scheme such as:

  • over-nomination;
  • open Subscription Window;
  • open season;
  • storage allocation;
  • non-ascending clock pay-as-bid auction?

Answer:

The Agency, after consulting relevant parties, established procedures, standards and electronic formats based on established industry standards for reporting of information referred to in Articles 6, 8 and 9 of the Implementing Acts. The current schemas foreseen for data reporting to the Agency under REMIT are the result of extensive consultations with stakeholders during 2014 and 2015. As a result of the aforementioned consultations, the accepted values are limited to the relevant EDIGAS Code list document for valid codes.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.1

Which code should we use to identify an organised market place (Data Field No (2)) of gas transportation contract schema when no market organiser exists, e.g. when allocated transportation capacity is traded on secondary market?


Answer:

Version 2.0 of the TRUM states that in case of absence of the organised market place EIC code the field should be populated with “XXXXXXXXXXXXXXXX” if the capacity was allocated outside an organised market place. After consultation with the relevant stakeholders and the authors of the schema it was concluded that this code does not represent good business standards. As a consequence ENTSOG issued an EIC code to be used instead when no market organiser exists: 21X-XXXXXXXXXXXY.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.17

Regarding EDIG@s field 3.1.3.9 ISSUER_MARKETPARTICIPANT.MARKETROLE.CODE.

The currently allowed field values do not cover the case and do not offer the possibility for defining the right market role of the reporting entity when a Solution provider company (Technical Manager of a system), that could be subsidiary or parent undertaking company of a TSO, will report data to ACER on behalf the TSO, SSO and LSO (all related undertakings – companies with a holding/company group).

What shall be reported in these examples for the mentioned field?


Answer:

If a solution provider is reporting it should use the role of the company for which it is reporting, e.g. if the third party RRM reports on behalf of TSO, SSO and LSO, the coding ZSO should be used.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.2

According to Edig@s REMIT MIG the field PROCESS_TRANSACTION.IDENTIFICATION is mandatory, and as such it could not be left blank.

How the transactions for bilateral capacity allocations (Shipper-Shipper) and transactions concluded outside of an Organized Market Place shall be identified?

Could we input a free text in the field PROCESS_TRANSACTION.IDENTIFICATION or a predefined set of values should be used?

Do you intend to change the schema in order to allow the field PROCESS_TRANSACTION.IDENTIFICATION to left blank?


Answer:

The field cannot be left blank. In case of Shipper-Shipper transactions a free text of maximum 35 characters should be used for the Process Identification.

As indicated in the TRUM this field should be a Unique Identification of the process only in case of auction process. For other processes concluded outside an organised market place the code shall be defined by the capacity allocating entity (i.e. the internal coding rule of the allocating entity applies, e.g. one code for single process or multiple processes identification possible).

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.18

Regarding EDIG@s field 3.1.3.18 PROCESS_TRANSACTION.TYPE, which corresponds to TRUM field 9.

The current list of type of processes is not exhausted. It does not cover and does not provide identification of the processes like:

  • over-nomination;
  • open Subscription Window;
  • open season;
  • storage allocation;
  • non-ascending clock pay-as-bid auction.

What should be reported for these examples?


Answer:

The process transaction types for the above examples (Over-nomination, Open Subscription Window, Open season, Storage allocation, Non-ascending clock pay-as-bid auction) shall be identified by the following code:

ZSY

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.3

According to Edig@s MIG for the approved by ACER schema for gas transportation transactions reporting: urn-easee-gas-eu-edigas-remit-gascapacityallocationsdocument-5-1.xsd, the field “PROCESS_TRANSACTION.ACTION_STATUS.CODE”  accepts the following values:

62G = Active.

63G = Cancelled.

66G = Changed.

Definition of element:

Status code of the report to be reported in accordance with current applicable industry standards as specified in gas network code on Interoperability and data exchange.

According to TRUM field (14) Action type, the following codes are permitted:

62G = Active

63G = Cancelled

66G = Changed

Which status is provided to define the field – the status of the reported transaction or the status of the XML file?


Answer:

The element “PROCESS_TRANSACTION.ACTION_STATUS.CODE” is dedicated to define the status of the reported transactions.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.4

Which value should be send to ARIS in case of primary transactions for TRUM field 41 – Bid quantity, if during an auction a minimum value and a maximum value were given by the bidder?


Answer:

The maximum value should be reported for bid quantity.

RSS_Icon Last update: 26/03/2016  

RSS_Icon Subscribe to this Category’s RSS