FAQs on transaction reporting – Question II.3.1.31

Table1 document is rejected because of missing quantity tag. Update from user:

During the 02.25th webinar it was definitely stated, that not necessary to provide quantity value in execution.

Please give us an official recommendation how we can calculate MW value in case:

  1. We have 1-1 for-a-month aggregated delivered energy value for peak, off-peak, deep-offpeak periods.– The unit price is known, and is different at peak, offpeak, and deep-off-peak period.
  2. The 1-1 total amount (cost) is known for peak, offpeak, deep-offpeak period.
  3. Not kwown that how many hours was operating the unit during the contracted periods.
  4. Example :

We have 1000000 HUF total cost, 100 MWh total delivered energy for January for a generating unit, the unit price is 10000 HUF (/MWh). All of the values concerns now the peak period.

What should we calculate for MW value if not known the number of operating hours of the unit in question.


Answer:

Based on the information provided above, it is our view that given that operating hours are not known, this type of contract should be reported using Table 2; Table 1 should be used for the EXECUTION.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.32

Reference to documents: TRUM

We are a utility and fall under the REMIT regulation. We ask you to answer us the following questions concerning transaction reporting:

  1. There is a non-standard contract with a defined price and a fixed (no flexibility) volume for the delivery period. The profile of the volume is shaped (every hour another volume). Is it necessary to report executions for this contract, although it is possible to determine the notional amount (data field 38) and the total notional contract quantity (data field 41) for table 1 of the trum?
  2. Market participants are required to report (within table 1) the data fields „Load delivery intervals“ (data field 54), „Delivery capacity“(data field 55), „Quantity unit used in field 55“ (data field 56) and „Price/time interval quantity“ (data field 57). The examples in the annex II of the TRUM implicate that these data fields only have to be populated in case of deals/contracts which have been concluded at an OMP (e.g. an auction). In all other examples in the annex II (including examples for non standard deals) these data fields aren´t populated. Given that we ask you to answer us the following questions:
    1. Have these data fields to be populated in case of OMP contracts/deals only or also in the case of non-OMP deals/contracts?
    2. Have these data fields to be populated only in case of standard contracts or also in case of non-standard-contracts (executions of non-standard-contracts)?
  3. The examples of the annex II in the TRUM indicate that the load type for gas deals is in all cases “Gas day (GD)” irrespective if the load is variable or not variable. Is this correct or do we have to define the load type of deals with variable load profile as “shaped” (as in the case of power contracts)?

Example for 1:

Delivery Period: 01.01.16 (06:00) – 01.01.17 (06:00)

Price: 25 EUR/MWh

Total Volume: 20.000 MWh

Hourly Volume:

01.01.16 06:00 2,3 MWh

01.01.16 07:00 1,8 MWh

01.01.17 06:00 1,2 MWh

Our interpretations of the two cases are

The contract has to be reported using Table 1 of the Implementing Acts because it has a defined price and volume. It’s not necessary to report executions.


Answer:

Based on the information provided above, it is our understanding that, since the contract has defined price and volume, it has to be reported using Table 1 of Commission Implementing Regulation (EU) No 1348/2014. It is not necessary to report executions.

Annex II to the TRUM suggests that examples from one type of contract can be used to report another type of contract.

Based on the information provided above, it is our understanding that the reporting will depend on the contract. If the contract defines the shape, then the shape should be reported. If the contract defines the amount of gas for a day but nomination can be done at any hour of the day, then the gas day values should be reported.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.33

I have a few questions related to REMIT reporting I am hoping you can help with.

  1. Is the aggregate delivery point or the sub terminal delivery point required? For example, for Beach contracts at Bacton, would we report the main Bacton terminal, or Bacton SEAL, which is the sub terminal?
  2. In table 1 – fields 38 (notional amount) and 41 (total notional contract quantity) – since we can report non-standard executions after invoicing, do these fields refer to the value of the invoice for that month, rather than the full agreement (which is not a defined amount) which may stretch over a year?

Answer:

Based on the information provided in the first question above, it is our understanding that the delivery point should be reported according to the terminal indicated in the contract. For example, if the contract indicates the sub-terminal, then both parties should use that EIC code.

OR

If the delivery point is at a terminal (e.g. for Beach contracts at Bacton), then the EIC code for the aggregate main terminal can be reported.

With regard to question 2, please see Annex II to the TRUM. (To be finalised)

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.34

For transactions with a load profile is there the whole profile to be reported? 365 * 24 * 4 = 35040 quarterly hour values for a year profile?

Example: Shaped transaction (load profile) for 2017.

I don’t need to provide the whole load profile but just the information “shaped”.


Answer:

If transactions with a load profile have different quantity and price for each time interval, each time interval should be reported within the report. If a shaped transaction has 365 * 24 * 4 = 35040 quarterly hour values, all of them should be reported.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.35

Reference to documents: Implementing regulation No. 1348/2014, Annex (Details of reportable contracts), Table 1, data field 32 Linked Transaction ID

Reporting geographical swaps across EU borders (e.g. one leg with delivery in EU, other leg with delivery out of EU).

Example:

  1. EU market participant performing geographical swap – selling in Germany, Buying in Switzerland
  2. EU market participant performing geographical swap – selling in Hungary, buying in Serbia

Possible interpretations:

  1. Only transaction with delivery in EU is reportable. Linked transaction outside EU is out of scope of REMIT. The respective EU leg is reported as a single transaction

Or

Both legs of geographical swap is reportable as linked transactions as long as one side of trade is in EU.


Answer:

In case of a geographical swap where one leg has delivery in the Union and the other leg has delivery outside the Union, only the leg with the delivery in the Union shall be reported according to Article 3(1)(a) of Commission Implementing Regulation (EU) No 1348/2014.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.36

We are a service providers for public utilities. We will conduct REMIT messages for our customers. Regarding the reports we have a question.

Please tell us, if also load profile data, in an hourly (gas) or quarter-hourly granularity (power), must in addition be reported with the messages for shaped gas products (with fixed price)? Or must the shaped-products be reported as standard products (without additional load data)?

Profiled gas contracts with a defined price and quantity should be reported with Table 1.

Must load profile data, in an hourly (gas) or quarter-hourly granularity (power), in addition be reported with the table1-messages?

Example for shaped product:

Company A sells 6000 MWh @ €21 to Company B. The profile of the delivery is:

Jan16: 1,0 MW

Feb16: 2,0 MW

Mrz16: 1,5 MW

Apr16: 0,8 MW

May16: 0 MW

Jun16: 0,2 MW

… etc.

we believe that no load profiles must be reported additionally to the table1-Data.


Answer:

If transactions with a load profile have different quantity and price for each time interval, each time interval should be reported within the report. If a shaped transaction has 365 * 24 * 4 = 35040 quarterly hour values, all of them should be reported.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.37

Reference to documents: REMIT Implementing Regulation Article 5

Definitions of known price and volume for reportable executions are unclear. For non-standard supply contracts of gas or electricity, where there is not a fixed price commodity rate defined in the contract, which volume and price is considered to be the reportable execution?

Example: If a customer makes multiple forward-purchases ahead of a delivery month through their supplier for a specific volume for this specific delivery month at a specific price, with any remaining un-hedged volume then priced on a market index; all of which are subsequently used in calculating a weighted average invoice unit rate; what should the customer report?

  1. Each trade made at the time of trade, only.
  2. Each trade made at the time of trade, and the remaining volume on the index price at time of invoicing (once volume and price are known).
  3. Just the final weighted-average unit rate and total consumption at time of invoicing (and then a final monthly average, or each settlement period price).

Our view: Option 1 above.

It is our understanding that only the executions for forward purchases are reportable as it is these transactions which could affect the market.


Answer:

Based on the information provided above, it is our view that all the contracts have to be reported. If the forwards with defined price and quantity are agreed and the price remains unchanged, then these contracts have to be reported as BILATERAL contracts. Any remaining un-hedged volume priced on a market index should be reported as EXECUTIONS. Please see FAQ 3.1.28

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.38

Reference to documents: Ref [1]: The XSD that defines how the Table1 fields can be put together in the XML: ”REMITTable1_V2.xsd” Ref [2]: ACER_REMIT_TRUM_ANNEX_II_v2.0.pdf

We want to repeat the Delivery Profile section of Table1 for each “Delivery point or zone”. This does not seem to be possible according to Ref [1].

For example: We have a non-std contract (using Table2) for a “delivery point or zone”= Sweden (“10YSE-1——–K”). For this contract we will have executions (using Table1 for this), in up to four different “delivery point or zone”s (LUL:”10Y1001A1001A44P”, SUN:“10Y1001A1001A45N”, STO:“10Y1001A1001A46L”, MAL:“10Y1001A1001A47J”).

What we really would like is to be able to repeat only the fields: [48, 55 and 57] four times, i e we want to state “Delivery capacity” and “Price/time interval quantity” for each of the four delivery points respectively, while all other fields in the report are the same. This does not seem to be possible according to ref [1].

We have seen examples in the pdf that are close to what we want, see ref [2]:

– pages 210-211: field 48 is multiplied

– page 58: fields 54-57 are multiplied

– page 131: fields 49-57 are multiplied.

Our question is whether our example with having at least these three fields together, repeated [48,55 and 57], also could be possible?

Our interpretation is that with the current XSD it is not possible to achieve what we want to do.


Answer:

Based on the information provided above, it is our understanding that each execution for each delivery point should be reported separately. The FAQs document on transaction reporting has already addressed this question, please see Question 3.1.6.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.39

As we do not find a relevant transaction reporting examples suitable to our case, please find enclosed the description of our specific transaction and how we propose to submit it.

For its procurement of grid losses, TSO X tenders on yearly basis a certain amount of power to the market:

  • This is a yearly shaped profile with a fixed volume, e.g. 10 lots à 43395 MWh per lot for the year 2017 (8760 hours) were tendered in 2015/ 2016 with a certain shape.
  • Market participants willing to participate in the tender could offer their prices for the overall profile (e.g. EUR 31, 69) and the market participants with the cheapest price are contracted.
  • We consider that as a non-standardized transaction, but with a fixed volume and price, so will use TABLE 1 for reporting, see example below.
  • For field 40 “Quantity / Volume” we will use the average clip size rounded with two decimal places, i.e. 43.395 MWh / 8760 hours = 4,95 MW.
  • In field 54 “Load Delivery Intervals” we enter “00:00/24:00” per default.

Please find the complete example and how we intend to report in the Excel file enclosed.

We would welcome, if you could approve our suggestion and add the example to the ANNEX II of the TRUM, so we could communicate accordingly to our counterparties.


Answer:

Based on the information provided above, it is our understanding that this is a BILATERAL contract with shaped profile. Each hour with different quantity and price should be reported in the report.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.40

Related documents: Article 2, Article 2(2) and (3) of 1348/2014, Article 5(1) а,b (2) of 1348/2014; Article 7 (2) of 1348/2014; Regarding field TRUM Table 1 Transaction Timestamp field 30 and reporting Table 1 – bilateral in T+1

How to classify (standard or non-standard) complex day-ahead hourly electricity products executed bilaterally outside the organised market place is not admitted to trading at an organised market place and if classified different than our view then when to report and with which table?

  1. With some of our partners we trade day-ahead hourly electricity products executed within the framework of general/master agreement bilaterally outside the organised market place. This master agreement sets the rules for trading activity of the two counterparties to the contract and it is specifying the range of the volumes available for trading as sometimes these volumes can differ regarding the buy and sell positions in the counterparties portfolios and these positions, during the trade period (one month) will be technically still open until the end of the month when is the invoicing date and the correct price and quantity can be discovered.

In our opinion, this contract may be classified as non-standard complex shaped/profile contract as it is not traded at an organised market place, but only bilaterally between the two parties and it is not admitted to trading at an organised market place (not visible to the market, not available for trading to market participants, would be traded only once and would then expire and not be tradable any more).

Our understanding is that we should report the abovementioned trade with Table 1 to identify the details of transactions executed within the framework of non-standard contract reported with Table 2. This execution will be reported once the delivered quantity and the price are known after the invoicing cycle, but no later than 30 days after the discovery of price and quantity. Can you confirm this?

Also, could we use the details (time of the invoicing) from the invoice for filling the Transaction Timestamp in the Table 1 field? For this kind of contract our positions will become clear and will be known after the invoicing cycle, so that is our only reasonable option.

  1. With other partners we have master agreement and annex based executions with clear and closed positions regarding the price and quantity. In our opinion, this annex may be classified as non-standard contract for base load, pick load off-pick load annex contract as it is not traded at an organized market place, but only bilaterally between the two parties. Could we report this contract just with Table 1 as Bilateral on T+30 or Bilateral on T+1?
  2. The qualification whether the contract is “standard contract” or “non-standard contract” is specified by ACER`s list of standard wholesale energy contracts as it defines the types of such contracts. Decisive for the reporting as standard contract or non-standard is the fact whether a contract is or is not listed as such in the Agency’s REMIT database.

According to the primary criterion stated by Article 2(2) and (3) of the REMIT Implementing Regulation if contract (for example in our case day-ahead hourly electricity products) has been traded bilaterally and has not been admitted to trading at an organised market place (not visible to the market and not available for trading to market participants and would be traded only once and would then expire and not be tradable any more), but in the same time this kind of contract has been published in the ACER list of standard contracts, (for example Bulgaria Baseload (CET 00-24) with delivery zone 10YCB-BULGARIA-F). Does the fact that the contracts which have been published in ACER`s list as standard for 10YCB-BULGARIA-? delivery zone makes these contracts standard, despite the fact that are traded bilaterally and have not been admitted to trading at an organised market place? How do we need to report, for example this year contract Baseload 00-24 CET with delivery zone 10YCA-BULGARIA-R? Could you please answer when do we need to report the contract: on T+1 or T+30 as Bilateral with Table 1?


Answer:

Please see FAQ 3.1.28.

RSS_Icon Last update: 26/04/2017  

RSS_Icon Subscribe to this Category’s RSS