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

Consumption unit, injection and offtake capacity of gas storage facilities has thermal capacity in MW. How can it be measured in other units?


Answer:

If the time element of the event is considered, the thermal capacity can be converted into units of energy. For a consumption unit, the unavailable capacity is the total technical capacity which cannot be used in the period of the outage, even if under normal circumstances it is not utilised at full capacity.

The time element of an event allows for the conversion from units of power into units of energy. Further, storage withdrawal and injection capacity availabilities can be expressed in MWh/d.

Using GWh/d or MWh/d is the general practice for measuring outages in the gas market.

Example on how to convert MW into MWh/d for a loss in the gas consumption: Assuming we have a gas power plant with a technical capacity of 200 MW and a net efficiency of 46%. If this unit would be completely unavailable it would result in an unavailable capacity of 200MW*24h/0.46 ≈ 10435 MWh/d.

However, for a five minute partial outage in which the average unavailability will be a rough estimate the extrapolation for the whole day may be somehow less accurate. Nevertheless, according to the samples collected by ACER the number of outages which lasted less than half an hour were extremely low in recent years. Therefore, based on the evidence currently available, ACER does not see a need to expand the list of available units of measurement with MW for gas related UMMs.

RSS_Icon Last update: 31/03/2016  

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

Should the measurement unit be identical for all fields?


Answer:

For fields (9) ‘’Unavailable Capacity’’, (10) ‘’Available Capacity’’ and (11) ‘’Installed capacity’’ the unit of measurement is by default the same. A single unit of measurement is selected in data field (8) “Unit of measurement” for field (9), (10) and (11).

RSS_Icon Last update: 31/03/2016  

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

Regarding fields 16 (“Affected Asset or Unit”) and 17 (“Affected Assets or Unit EIC Code”), shall market participants submit only one message when there is an event that affects several units or assets due to the same reason?


Answer:

The provision of web feeds should be simultaneous to the disclosure of inside information under Article 4(1) of REMIT. If more than one message is published then more than one should be submitted.

If the UMM disclosed publicly refers to more than one facility, and as the schema for reporting only allows the identification of one facility per web feed message, the message needs to be desegregated by facility for data collection purposes. Another option is to use a single web feed message according to the 3rd schema type – “Other market information” in case the event affects a large number of facilities (e.g.: in case of general strike, floods affecting hydro generation etc.).

RSS_Icon Last update: 31/03/2016  

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

Regarding fields 16 (“Affected Asset or Unit”) and 17 (“Affected Assets or Unit EIC Code”), shall market participants submit only one message when there is an event that affects several units or assets due to the same reason?


Answer:

The provision of web feeds should be simultaneous to the disclosure of inside information under Article 4(1) of REMIT. If more than one message is published then more than one should be submitted.

If the UMM disclosed publicly refers to more than one facility, and as the schema for reporting only allows the identification of one facility per web feed message, the message needs to be disaggregated by facility for data collection purposes. Another option is to use a single web feed message according to the 3rd schema type – “Other market information” in case the event affects a large number of facilities (e.g.: in case of general strike, floods affecting hydro generation etc.).

RSS_Icon Last update: 16/06/2016  

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

Will ACER provide a testing environment for market participants to test the exchange of UMM information prior to releasing the web feed into production? Will ACER validate and report back to the platform whether information is generated correctly in the web feed?


Answer:

The Agency will not provide testing arrangements for individual market participants and no automated feedback mechanism will be implemented to provide receipts for non-compliant messages. Nevertheless the Agency reserves the right to contact reporting entities on performance issues on an ad hoc basis. Please note that recurrent issues will be reported to NRAs for appropriate action.

RSS_Icon Last update: 31/03/2016  

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

Can the Agency provide technical specifications that describe how ACER’s system will connect to platform’s RSS feed and what kind of information the RSS feed will extract?


Answer:

Please consult the REMIT Guidance on the implementation of web feeds for Inside Information Platforms.

RSS_Icon Last update: 08/01/2019  

RSS_Icon Subscribe to this Category’s RSS