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.


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


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.


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.


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.


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.


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


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

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


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

How to use the field “Event Status”?


The UMM schema describes the use of three status values that are defined in the following way:


1. ‘Dismissed’ – for situations of cancellation or withdrawal of the message and when the message was updated.

2. ‘Inactive’ – UMM that contains the most recent update of an event that has already occurred in the past.

3. ‘Active’ – UMM that contains the most recent update on an event that will occur in the future or is occurring.


To smooth the implementation process the Agency will give additional freedom to use the “Event status” field values in the following way:


1. ‘Dismissed’

  • The change of the “Event Status” in the web feed is only obligatory in case of cancellation and withdrawal: when a message is withdrawn as erroneous, or the event of the message is cancelled then the status of the UMM has to be changed to ‘Dismissed’.
  • In case the parameters of the UMM change, i.e. a new version is published, the “Even Status” of the original UMM does not have to be changed to ‘Dismissed’.

2. ‘Inactive’

  • It is not obligatory to use this status value when the date and time of the event has expired, the status value ‘Active’ can be maintained for these UMMs.

3. ‘Active’

  • This value remains the default value for UMMs.

This approach will not only ease the work of the data providers, but will also limit the amount of messages initially expected to be received.

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?


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

Field (4/a) Type of Event includes as accepted value the option ‘‘Other unavailability’’. What kind of assets or units can such a UMM refer to?


The selection ‘‘Other unavailability’’ is used when the available values ‘production’, ‘consumption’ or ‘connection unavailability’ are not appropriate. For example, such event could refer to an electricity storage unit unavailability.

RSS_Icon Last update: 31/03/2016  

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

Are message versions 100% immutable or not? Is it possible to update the status of a message by updating the status of the latest thread item?


Published versions of the messages are 100% immutable and any change that may occur needs to be published as a new updated version. Any update or change in the data fields – including Data Field (2) Event Status – will result in a new message, with a new ‘Version number’.

RSS_Icon Last update: 31/03/2016  

RSS_Icon Subscribe to this Category’s RSS