FAQs on fundamental data and inside information – Question III.4.1.15

When will the Agency start collecting inside information web feeds from individual Market Participants’ websites?


Answer:

The Agency will not be collecting web feeds from Market Participants’ websites until further notice.

RSS_Icon Last update: 18/05/2017  

FAQs on fundamental data and inside information – Question III.4.1.16

How should this particular event be presented for inside information reporting on LNG deliverability restrictions (within UMM)?

Case: the event lasts more than one gas day.

  • Event start: 2015-11-06 01:00 (am)
  • Event stop: 2015-11-08 18:00

The event lasts 3 gas days and contains 3 sub-periods that differ in the number of the affected hours and the values of the availability and unavailability per day as follows:

Technical availability in normal circumstances: (6,78 GWh/h*24h) = 162,72 GWh per gas day

o 5 hours during the 1st gas day, the unavailability is 33,9 GWh

o 24 hours during the 2nd gas day, for 24 hours the unavailability is

162,72 GWh

o 12 hours during the 3rd gas day, the unavailability is 81,36 GWh

The values of the availability and unavailability could vary each sub-period.

Gas day: 2015-11-06 2015-11-07 2015-11-08
Gas

hour:

Availability

GWh/h

Unavailability

GWh/h

Availability

GWh/h

Unavailability

GWh/h

Availability

GWh/h

Unavailability

GWh/h

6 6,78 0 0 6,78 0 6,78
7 6,78 0 0 6,78 0 6,78
8 6,78 0 0 6,78 0 6,78
9 6,78 0 0 6,78 0 6,78
10 6,78 0 0 6,78 0 6,78
11 6,78 0 0 6,78 0 6,78
12 6,78 0 0 6,78 0 6,78
13 6,78 0 0 6,78 0 6,78
14 6,78 0 0 6,78 0 6,78
15 6,78 0 0 6,78 0 6,78
16 6,78 0 0 6,78 0 6,78
17 6,78 0 0 6,78 0 6,78
18 6,78 0 0 6,78 6,78 0
19 6,78 0 0 6,78 6,78 0
20 6,78 0 0 6,78 6,78 0
21 6,78 0 0 6,78 6,78 0
22 6,78 0 0 6,78 6,78 0
23 6,78 0 0 6,78 6,78 0
24 6,78 0 0 6,78 6,78 0
1 0 6,78 0 6,78 6,78 0
2 0 6,78 0 6,78 6,78 0
3 0 6,78 0 6,78 6,78 0
4 0 6,78 0 6,78 6,78 0
5 0 6,78 0 6,78 6,78 0
=128,82 GWh = 33,9 GWh = 0 GWh = 162,72 GWh = 81,36 GWh = 81,36 GWh

According to the Manual of Procedures (MoP) on data reporting: ANNEX VI Fundamental data reporting, VI.V XML SCHEMA FOR LNG DATA document, presentation of this event for LNG data on unavailability (within the fundamental data reporting to ACER) is:

Case:

  • Event start: 2015-11-06 01:00 (am)
  • Event stop: 2015-11-08 18:00

o 5 hours during the 1st gas day, the unavailability is 33,9 GWh

o 24 hours during the 2nd gas day, for 24 hours the unavailability is

162,72 GWh

o 12 hours during the 3rd gas day, the unavailability is 81,36 GWh

Then unavailability = (33,9 GWh + 162,72 GWh + 81,36GWh)/3 gas days = (277,98 GWh)/3 gas days = 92,66 GWh/d

Unavailability = average per gas day is 92,66 GWh/d

According to the Manual of Procedures (MoP): ANNEX VII Data fields for inside information reporting, UMM schema II. and FAQs on REMIT fundamental data and inside information collection (3rd edition, 15 November 2016) documents, the presentation of this event for inside information reporting on LNG deliverability restrictions (within UMM) should be:

There are three events and three UMMs are published:

The first UMM: 001_001

  1. Event start: 2015-11-06 01:00 (am) – event end: 2015-11-07 05:59:
  • the unavailability is 6,78 GWh/h * 5h = 33,9 GWh
  • the availability is 6,78 GWh/h * 19h= 128,82 GWh

The unavailability for the first gas day is 33,9 GWh

The second UMM:002_001

2) Event start: 2015-11-07 06:00 – event end: 2015-11-08 05:59

  • unavailability is 6,78 GWh/h * 24h = 162,72 GWh
  • the availability is 6,78 GWh/h * 0h= 0 GWh

The unavailability for the second gas day is 162,72 GWh

The third UMM:003_001

3) Event start: 2015-11-08 06:00 – event stop: 2015-11-08 18:00:

  • the unavailability is 6,78 GWh/h *12h=81,36 GWh
  • the availability is 6,78 GWh/h *12h =81,36 GWh

The unavailability for the second gas day is 81,36 GWh

Conclusion:

For this particular event:

  • ACER receives information within fundamental data reporting that the unavailability is, on average, 92,66 GWh per gas day for the whole event.

The market within UMM publications (and ACER within RSS for UMMs) receives information that the unavailability is respectively: 33,9 GWh (for the first gas day), 162,72 GWh (for the second gas day) and 81,36 GWh (for the third gas day).


Answer:

  1. Fundamental Data reporting

MoP on data reporting: The unavailability report is used to report any planned or unplanned unavailability of a facility for a gas day or period within a gas day. The unavailableCapacity shall be reported with a GWh/d unit.

In the example provided above one lngUnavailabilityReport shall be sent to the Agency:

lngUnavailabilityReport

  • unavailabilityStart: 2015-11-07 01:00 – unavailabilityEnd: 2015-08-18:00
  • unavailableCapacity: 6,78 GWh/h*24h/d=162,72 GWh/d

2. Inside Information

This is one event:

  • Event start: 2015-11-07 01:00 – Event stop: 2015-11-08 18:00
  • the unavailable capacity is 6,78 GWh/h = 6,78 GWh/h*24h/d = 162,72 GWh/d

Please note the recent update of the MoP on data reporting v 4.0; the GWh/d unit can be selected for LNG deliverability restrictions events.

 

RSS_Icon Last update: 18/05/2017  

FAQs on fundamental data and inside information – Question II.3.2.11

From the MoP on data reporting: “The LNG Unavailability Report should be provided by the LNG System Operator in accordance with Article 9(3) c. The data element “lngUnavailabilityReport” is used by the Reporting Party to identify any periods where the facility is unavailable for the reloading and unloading of LNG to participants, whether this is a planned or unplanned activity. To be sent as soon as information becomes available. The unavailability report is used to report any planned or unplanned unavailability of a facility for a gas day or period within a gas day. Each LNG System Operator shall identify the dates and time on which the planned or unplanned outages of the LNG facility occur and the capacity which is affected.”

 

The bold part would refer to the jetty only. Does ACER really want to know the unavailability of the jetty?


Answer:

According to Article 9 (3) (c) of Commission Implementing Regulation (EU) No 1348/2014 LNG, system operators shall report planned and unplanned unavailability announcements of the LNG facility including the time of the announcement and the capacities concerned.

The notion of LNG facility is defined in Article 2(11) of Directive 2009/73/EC as a terminal which is used for the liquefaction of natural gas or the importation, offloading, and re-gasification of LNG, and includes ancillary services and temporary storage necessary for the re-gasification process and subsequent delivery to the transmission system, but does not include any part of the LNG terminals used for storage. Therefore, any unavailability of the facility that falls within the definition of the LNG facility shall be reported with lngUnavailabilityReport.

RSS_Icon Last update: 18/05/2017  

FAQs on fundamental data and inside information – Question II.3.3.5

Should fundamental data be reported during the decommissioning and the blowdown phase, and if so, how?

During the decommissioning phase, there are no commercial contracts applicable, which is why the facility report values are zero. However, in some types of storage facilities, as part of the blowdown / decommissioning phase, cushion gas should be withdrawn from the storage and sold to the market.

Should fundamental data be reported until cushion gas is taken out? Or is transaction reporting for the sale of the cushion gas sufficient?

If fundamental data reporting is still necessary, our understanding is that the total volumes DTMTI, DTMTW, DTMTS, storages volume, injected daily volume und withdrawn daily volume should be zero. Should the daily withdrawal volume show the volumes of cushion gas and the other requested data be reported as zero only in case of a cushion gas takeout?


Answer:

The cushion or base gas (permanent inventory in a storage reservoir) should not be counted as a normal working gas volume. The Agency’s understanding is that the removal of cushion gas is the last step of the decommissioning phase.

If there are no commercial activities during the decommissioning phase and cushion gas is still in a storage reservoir, the SSO should report zero values “0” in the fields: storage, injection, withdrawal, technicalCapacity, contractedCapacity, availableCapacity of Storage Facility Report until cushion gas is sold/taken out.

When cushion gas is sold/taken out, the Agency’s understanding is that the SSO has to make nominations and report movements of gas via the “withdrawal” field in the Storage Facility Report. Fields storage, injection, technical, available and contracted capacity of the storageFacilityReport should be reported with zero values “0”.

If the SSO needs to, for example, inject gas for operational purposes during the decommissioning phase, the Agency’s understanding is that the SSO has to make nominations and report movements of gas via the “injection” field in the Storage Facility Report. Fields storage, withdrawal, technical, available and contracted capacity of the storageFacilityReport should be reported with zero values “0”.

RSS_Icon Last update: 18/05/2017  

FAQs on fundamental data and inside information – Question III.5.1.9

Could you advise us how to fill the field 10 “Available Capacity” in case of overlapping partial unavailability? Or could you reconsider to make the field “Available Capacity” optional?

Practical Example

A generation, production, or consumption unit may have different, overlapping unavailabilities with different reasons, types, start and end dates. In such cases, the “available capacity” of the entire facility may change over the duration of an individual event. Since a reader can easily calculate the available capacity from the fields 9 and 11/a-11/b by aggregating over all open events at a certain point in time, requiring field 10 does not add any further information.

In our opinion, field 10 should be optional, as any mandatory usage of the field could be misleading.


Answer:

Please find below the graphical representation of two overlapping unavailabilities with different start and end dates including examples on how to populate UMM reports:

UMM Reports:

10 am

1st Report (Event 1)

Message ID:12345-28X-TradingAG-BR-C_001

Event Start and Stop: 10 and 12pm

Available capacity: 70

Unavailable capacity:30

 

11 am

2nd Report (Event 2)

Message ID:12345-28X-TradingAG-SD-D_001

Event Start and Stop: 11 and 1pm

Available capacity: 30

Unavailable capacity:40

Optional: “Remarks” field in the 2nd Report : “Additional Unavailability to ID:12345-28X-TradingAG-BR-C_001”

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.5.1.10

In the Agency’s Manual of Procedures, v.3 and 4, in the part describing the requirements of the attributes of the two types of UMM XMLs, the description of the “Message ID” attribute says:

“The field ‘Message ID’ consists of two parts: ‘UMM thread ID’ and ‘Version Number’ separated by the underscore character. ‘Message ID’ = ‘UMM thread ID’_‘Version Number’

‘UMM thread ID‘part is the identifier of a series of UMMs reporting on the same event after potential updates. The ‘UMM thread ID‘remains unchanged even if the UMM is updated. The format of the ‘UMM thread ID‘part is to be set by the entity disclosing the information but should include no more than 25 alphanumeric characters.

‘Version Number’ is the unique identifier of UMM versions in a single UMM thread. It helps to reconstruct the history of prior publications. ‘Version Number’ consists of a sequential number with 3 numeric characters where 001 stands for the first UMM in a thread, 002 marks the first update, 003 the second update and so on.

Context of the question:

  • UMMs publication by an MP on any Platform for Inside Information publication and on its own web-site;
  • definition of convention for creation of the “UMM thread ID” part of the ”Messaged ID”.

Question:

How should we interpret the requirement: “The ‘UMM thread ID‘part is the identifier of a series of UMMs reporting on the same event after potential updates. The ‘UMM thread ID‘remains unchanged even if the UMM is updated. The format of the ‘UMM thread ID‘part is to be set by the entity disclosing the information”?

Who should define the ‘UMM thread ID’ – the MP or the Platform for publication of inside information? Do you require the published ‘UMM thread ID’ and the one submitted to ARIS to be one and the same?

In case that an MP would like to publish UMMs on its own web-site and on a Platform for disclosure of Inside information, it is reasonable to expect the Message ID for both publications for one and the same event to be equal.

One interruption event of gas infrastructure may affects many assets or units (points). If an MP publishes one single UMM for one event, including all of its affected points, both on its own web-site and on a Platform for Inside Information disclosure,

  • According to the Agency’s Manual of Procedures’ requirements, the information for every single affected asset or unit shall be made available via web-feeds to the Agency by individual XMLs.

Possible approaches:

Taking the above-mentioned into consideration, the Platform operator would have two options for identifying the messages submitted/made available via web-feeds to the Agency:

1) The Platform operators uses the Message ID (‘UMM thread ID’) provided by the MP for the UMM publication and replicates it for all XMLs for each affected by an event assets or units (points). Thus, in case of several affected points within one event, there will be several UMM XMLs (made available via web-feeds to the Agency) with one and the same Message ID (‘UMM thread ID’). It will still be possible to differentiate them via the “Affected asset or unit name” attribute content.

OR

2) The Platform operator generates completely new Message ID for every single XML (made available via web-feeds to the Agency), per affected asset or unit (point) by an event. The Message IDs (‘with the original Message ID (‘UMM thread ID’), used for the UMM publication on the MP web-site and on the Platform for Inside Information disclosure. It could be possible to see both Message IDs when accessing the published UMMs on the Platform operator/MP web-site, but the XMLs made available to the Agency will contain only the Message ID (‘UMM thread ID’) defined by the Platform operator.


Answer:

The Message ID is to be set either by a Market Participant or the entity disclosing the information on behalf of the Market Participant. The Message ID shall be unique per XML, thus if multiple assets are affected by the same event each XML specifying the affected asset will have its unique Message ID.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.5.1.11

Separation of more than one market participant or market participant codes (inside information).

Field 17 allows to indicate more than one market participant. It is not clear how different names shall be separated if the unit concerned is owned by various market participants.

Field 18 refers to the market participant code. We were of the opinion that various names in field 17 would have to be accompanied by the same number of market participant codes in field 18. However, the number of eligible character leaves it open whether this is really meant.

There might be owners of a unit who do not have a market participant code such as pension funds. It is not clear who to indicate that.

We suggest to use a semicolon “;” in fields 17 and 18 for the separation of different market participants and different market participant codes. If a market participant has no code we recommend to use “NA”.

This makes sure that there is always the same number of owners and respective codes or respective “NA” and helps to cross-reference publications for any market participant if needed.


Answer:

Fields 17 and 18 are unbounded in the XML schema meaning that you can repeat multiple values (multiple MPs’ names and EIC codes) inside the schema. The number of Market Participants in field (17) ‘Market Participant’ has to be the same as the number of EIC codes provided in field (18) ‘Market Participant code’. The obligation to publish inside information rests with the Market Participant. If the unit’s owner is not a Market Participant then it should not be reported in fields (17) and (18).

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.5.1.12

ANNEX VII p77/90 Data Field No. 4b Type of Event – It would appear that we can only select one value. As a SSO where we have a TOTAL outage, does this mean that we have to report the loss of injection and withdrawal capacity separately? Hence we would have 2 UMMs for the same event detailing loss in both directions?

In the case of bidirectional sites we would expect to see loss of capacity in both directions on a single UMM however we have interpreted the Data field above as 2 UMMs reporting loss of availability, one for injection and one for withdrawal.


Answer:

In case of a total outage of a gas storage facility when a loss of both injection and withdrawal capacity occurs, the value ‘Storage unavailability’ shall be provided in the (4/b) Type of Event field. The value ‘Storage unavailability’ represents a combination of both ‘Injection unavailability’ and ‘Withdrawal unavailability’ and hence only 1 UMM is reportable for a total outage.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.8

Where the “other market information” schema (annex VII .111) is produced by a market participant – does this require reporting through the “Storage Unavailability report” (pg 69)?

Our interpretation is that the “storage unavailability report” will not be sent where we are reporting “other market information”.


Answer:

The “Storage Unavailability Report” is designed for reporting of fundamental data according to Article 9(5) of Commission Implementing Regulation (EU) No 1348/2014 while the “Other market information” is designed for inside information reporting according to Article 10(1) of Commission Implementing Regulation (EU) No 1348/2014. The reporting of the “Other market information” report does not replace the obligation to provide the “Storage Unavailability Report”.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.9

Thank you for the clarifications made in the FAQ on REMIT fundamental data and insider information collection.

Related to question 5.1.8 I have another question. According to the answer, all events shall be reported as per affected unit. This means that one event that affects three units shall be reported in three unique web feed messages.

Now considering the case of an event affecting one unit but with a time varying capacity (e.g. three different values for capacity for the different time frames). Shall this event also be reported as three separate web feed messages each containing only one capacity value?

Our proposal earlier was in this case was to only report the lowest capacity value. That solution would mean that one event maps to one web feed message. Depending on your answer to the question above, the alternative would be to map one event with three web feed messages when we have time varying capacity. In any case, our design is highly dependent on a clarification of the raised point and I hope you are able to give some guidance on this matter.


Answer:

The Agency has discussed possible solutions on how to report the above mentioned event during the Inside Information Platforms roundtable meetings and concluded the following guidance for the reporting of planned and unplanned unavailability:

Planned unavailability: three separate UMMs are published for each of the three intervals.

The three messages should be published with the same timestamps unless they are different events.

Unplanned unavailability: one UMM is published (e.g. at 10 am). The UMM will be updated at 11:30 am and 12:30 pm. The three messages should have different timestamps.

RSS_Icon Last update: 15/11/2016  

RSS_Icon Subscribe to this Category’s RSS