Please insert at least 3 characters

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?


Answer:

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  

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

Shall the version number – that is part of the ‘Message ID’ – be incremented with any update to the UMM thread? If so, will the increment of version number always result in a new UMM published to RSS/Atom feed?


Answer:

As explained in the MoP Annex VII each ‘Message ID’ includes 29 characters in total and consists of 3 parts:

  • ‘UMM thread ID’ – 25 characters
  • One underscore (‘_’)
  • ‘Version number’ – 3 characters

Underscores (‘_’) should not be used within the 25 characters of the UMM thread and also it shall not be possible to submit a message with a ‘Message ID’ of less than 29 characters in total.
Any change in the UMM results in a change on the ‘Message ID’. If the same UMM thread is considered, the change will impact the last part of the ID which is the UMM ‘Version number’. It is the responsibility of the reporting parties to put in place appropriate arrangements ensuring proper sequencing of this number.

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


Answer:

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


Answer:

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

RSS_Icon Subscribe to this Category’s RSS