Please insert at least 3 characters

FAQs on transaction reporting – Question III.4.1.1

Who reports the nomination data cross border capacity allocation in case a single point nomination mechanism exists between two bidding zones under the jurisdiction of two TSOs?


Answer:

In order to avoid double reporting, the Agency will accept one report for the nomination data allocated cross border capacity from one of the TSOs reporting on behalf of both or by a third party RRM reporting on their behalf. The Agency needs to be informed of the preferred reporting method through the RRM registration process. The reporting delegation will also have to be identified in the market participation registration form of the relevant TSOs.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question III.4.1.2

How to report when a continuous explicit intraday cross border capacity allocation method is in place?


Answer:

In case the relevant allocation rules define that the allocated intraday cross border capacity is automatically nominated with no possibility of intervention from the market participant and that the amounts of allocated and nominated intraday cross border capacity are equal, then there is no need for the relevant TSOs or third party acting on their behalf to submit both allocated and nominated information. Only the nominated cross border capacity will be reported to the Agency by the reporting party.

In case the relevant allocation rules allow the freedom of the market participant to nominate a different amount of cross border capacity to the allocated amount, then both the allocated and the nominated reports will have to be submitted to the Agency.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question III.4.1.3

Reference to documents: Implementing Acts – Article 7 (5)

What is the reporting timeframe for Secondary Power & Gas Transportation under Table 3 & 4?  Per the Implementing Acts, Article 7 (5), the reporting timeframe for Primary Transportation has been defined as T+1, but there is no mention of Secondary Transportation.

Reporting timeframes for REMIT reportable transactions are generally either T+1 or T+30.  Could ACER confirm what is the timeframe for Secondary transportation?


Answer:

Details of contracts referred to in Article 3(1)(b)(i) of Commission Implementing Regulation (EU) No 1348/2014 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.

The Agency currently considers secondary transportation contracts are not standard contracts and they therefore have to be reported on a T+1 month basis.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question III.4.1.4

We have finished our preparations to be able to report transactions. It is unclear to us however, how we should report our transactions.

Our assumptions are based on the document ACER: FAQs_on_Transaction_Reporting_20160324.pdf, more specifically on question 1.1.15

We uses 2 types of contracts:

  1. Master agreement in which we agree with our customer (utility/producer/consumer) to automatically close its hourly open position against APX/BELPEX prices (bilaterally, we are not a member of the exchange and not an OMP. At the end of the month we create an invoice.
  2. Master agreement in which we agree with our customer that he can buy from us or sell to us intraday (ex-post) volume. At the end of the month we create an invoice or credit note where we settle the volumes against the imbalance price.

We believe both types of contract are non-standard contracts with a volume and a price that are known during the month. That would mean that we would be allowed to report monthly.

Can you confirm this interpretation?

– Both master agreements should be reported as non-standard contracts.

– Volumes and prices can be reported as Table 1 transactions

Then there is the question of how to handle the fact that the same transaction (1 per day per market and per customer) can contain both buy and sell volumes.

Then there are 3 options:

– use the “C” and use either positive or negative values for buy and sell in the individual hours

– use the “B” and use negative values if we are the seller

– split the transaction in a “B” and an “S”

The last option is not preferable, as we don’t really have 2 transactions.


Answer:

Based on the information provided above, “C” should be used.

In addition, the Agency has addressed the issue of reporting of master agreements in the FAQs on transaction reporting.

RSS_Icon Last update: 10/07/2017  

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.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.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  

FAQs on transaction reporting – Question III.4.2.5

Price in the secondary Market:

Regarding TRUM v. 2.0 field 35 – Data Field – Price, it is foreseen to include the price concluded in transactions on the secondary market.

TSOs do not have this kind of information as the price is determined in agreements that take place strictly between shippers.

It is important for the TSOs to inform ACER also about these kind of transactions directly to ARIS and not only via booking platforms because these kind of transactions entail changes in contracts which need to be updated?


Answer:

The field 35 is mandatory for secondary market allocations. The reporting obligation for secondary market lies with the market participants. Therefore there should be no problem for the TSOs in case they lack the specific information on the price. In case the TSO acts as the third-party RRM it is the responsibility of the market participant(s) to provide the necessary information to the TSO as the RRM for complete and successful data reporting.

RSS_Icon Last update: 26/03/2016  

FAQs on transaction reporting – Question III.4.2.6

Mechanism established for secondary market and underlying price:

TRUM field 29 – Procedure applicable, requires that the TSO is obliged to determine which mechanism is used in the Secondary market.

In this respect TSOs that use FCFS would need to fill in TRUM field 34 – Price paid to TSO (Underlying Price).

Do you mean that through TRUM field 34 information about the price that Shipper 1 pays to the TSO in first instance for capacity booking (before the transaction on secondary market takes place) shall be submitted to ARIS? Please clarify.


Answer:

TRUM field 29 is only applicable in case of secondary market allocations. It is not the responsibility of the TSO to determine the mechanism (field 29), but of the involved market participants. The same applies for field 34.

The underlying price is the price that Shipper 1 pays to the TSO in first instance for capacity booking (before the transaction on secondary market takes place).

RSS_Icon Last update: 26/03/2016  

RSS_Icon Subscribe to this Category’s RSS