7.1 Data fields related to common data for total primary and secondary allocation process

7.1 Data fields related to common data for total primary and secondary allocation process

This section includes the following fields:

Field No. Field name Primary allocation Secondary allocation
1 Sender identification M M
2 Organised market place identification M M
3 Process identification M M
4 Type of gas M* M*
5 Transportation transaction identification M M
6 Creation date and time M M
7 Auction open date and time M* M*
8 Auction end date and time M* M*
9 Transportation transaction type M M
10 Start date and time M M
11 End date and time M M
12 Offered capacity M* M*
13 Capacity category M* -

M = mandatory; O = optional; - = does not apply; * = conditionally required; DV = default value specified in TRUM

Data Field (1) Sender Identification

No. Field Identifier Description
1 Sender identification Identification of the party that is the owner of the document and is responsible of its content.
Description of Accepted Values Type Length Examples
EIC X Alphanumeric 16 10X1001A1001A450

This field indicates the identification of the owner and sender of the document. The sender of the document is identified by a unique EIC identification code. This code identifies the party that is the “owner” of the information being transmitted in the document and who is responsible for its content. EDIGAS message includes “Standard header information” and requires the indication of the coding schema attribute. For EIC codes, the coding schema attribute shall be equal to “305”.

It should be borne in mind that for the reporting of transportation contracts, the Agency had to rely on existing industry schemas which were originally defined for different purposes and therefore have to be understood in a way that they comply with the REMIT transaction reporting regime. For its original purpose, the field and its values assume that the sender is normally a TSO or another market participant.

However, for the purpose of reporting under REMIT, the sender may not only be a self-reporting market participant, but also a third-party RRM. When the reporting entity is a third-party RRM, the third-party RRM has certain responsibilities for the document content as they have to validate the data they receive from market participants, ensure completeness, accuracy and timely submission of the data according to Article 11(2) of the REMIT Implementing Regulation and, if necessary, correct and resubmit the rejected data in line with Article 11(2) of the REMIT Implementing Regulation. This is why the sender identification has to identify the third-party RRM in cases where a third-party RRM reports.

Both the identification and the coding scheme are mandatory for primary and secondary allocations.

This field corresponds to the ISSUER_MARKETPARTICIPANT.IDENTIFICATION field in the schema.

Data Field (2) Organised market place identification

No. Field Identifier Description
2 Organised market place identification Identification of organised market place.
Description of Accepted Values Type Length Examples
EIC X Alphanumeric 16 10X1001A1001A450

This field identifies the organised market place or booking platform[1] where the allocation of capacity was executed.

If the allocation was executed at an organised market place, the organised market place identification field must contain the Energy Identification Coding (EIC X-type) as reported in the list of the organised market places published by ACER.

If the capacity allocation occurred on a booking platform, different from an organised market place, this field is expected to be populated with the identification code (EIC X-type) of the relevant operator of the booking platform.

Where the allocation procedure (primary or secondary) does not take place on an organised market place or on a booking platforms (e.g. open season process, over-nomination, bilateral allocation…), this field should be populated with 21XXXXXXXXXXXXY.

Both the identification and the coding scheme are mandatory for primary and secondary allocations.

This field corresponds to the field ORGANISEDMARKETPLACE_MARKETPARTICIPANT.IDENTIFICATION in the schema.

Data Field (3) Process identification

No. Field Identifier Description
3 Process identification The identification of the auction or other process as defined by the capacity allocating entity.
Description of Accepted Values Type Length Examples
Up to 35 alphanumerical digits. Alphanumeric Up to 35 590825

This field identifies the auction where the capacity was allocated. The code is uniquely assigned by the auction platform (being an organised market place or a booking platform) that hosts the capacity allocation. The process identification should be unique within a particular auction platform, but the same code can also be used by other auction platforms.

The value reported for the population of this field shall match the relevant auction code as indicated in public information by the auction platforms.

The field is mandatory also if the capacity was allocated bilaterally (shipper – shipper, TSO – shipper, TSO – network user), outside of an organised market place or outside of a booking platform. In such a case, the field shall be populated with an identification code of the allocation agreed bilaterally by the counterparties.

This field corresponds to the PROCESS_TRANSACTION.IDENTIFICATION field in the schema.

Data Field (4) Type of gas

No. Field Identifier Description
4 Type of gas Identifies the type of gas.
Description of Accepted Values Type Length Examples
  • HC1 = High Calorific
  • LC1 = Low Calorific
Alphanumeric HC1

The field identifies the type of gas to which the capacity allocation refers to, if with high (H-gas) or low (L-gas) calorific power.

This field is mandatory for allocations occurring via an auction.

This field corresponds to the field PROCESS_TRA NSACTION.TAXONOMY.ENERGY PRODUCTTY PE in the schema.

Data Field (5) Transportation transaction identification

No. Field Identifier Description
5 Transportation transaction identification A uniquely assigned identification number for the capacity allocation as assigned by the organised market place or TSO.
Description of Accepted Values Type Length Examples
Up to 35 digits. Alphanumeric Up to 35 111-67A4552

This field provides the identification of the transportation transaction.

For primary allocations, the value reported in this field provides a unique code that clearly identifies primary capacity allocation as assigned by the auction platform or by the TSO.

In case of successful transaction that ends with an allocated capacity to a market participant whose bid is accepted in the auction, the referred unique code that identifies the capacity allocation corresponds to the identifier of the concluded transaction between the TSO and the “successful MP”. Such code is assigned by the auction platform or by the TSO.

In case of unmatched orders, that do not end with a transaction and thus with allocated capacity, the referred “unique code” is still assigned by the auction platform or by the TSO with the aim to identify the bidding behaviour of the relevant “unsuccessful MP” during the allocation process. In this framework, the Agency is aware that it is the TSO practice to generate the Transportation transaction identification (for both successful and unsuccessful MPs) as:

Process identification (Data Field (3)), followed by “-“ (dash), followed by the EIC code of the relevant Network User.

For secondary allocations, the value reported in this field provides a uniquely assigned identification number for the allocation made between the transferor and transferee as assigned by the Platform Operator or as agreed between the Balancing group(s)/shipper(s) for bilaterally agreed capacity allocations. The value reported in this field by the transferor shall thus be equal to the one reported by the transferee.

This field is mandatory for primary and secondary allocations.

This field corresponds to the IDENTIFICATION TRANSPORTATION_TRANSACTION field in the schema.

Data Field (6) Creation date and time

No. Field Identifier Description
6 Creation date and time Creation date and time of the transaction.
Description of Accepted Values Type Length Examples
ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35:56Z

This field indicates the date and time of the execution of the transaction indicating time zone as expressed by ISO 8601 date format / UTC time format (i.e. represents the transaction timestamp). For example, if the allocation occurs via auction, this field shall reflect the time of the announcement of the auction results or any subsequent modifications or cancellations of the trade transaction. However the Agency is aware that sometimes reporting parties might not be in the position to know the exact time of the announcement of the auction results. In such cases, the data field can be populated with the gate closure of the auction. For secondary transaction it means the moment the two counterparties agree upon the conclusion of the deal.

This field is mandatory for primary and secondary allocations.

This field corresponds to the PROCESS_TRANSACTION.TRANSACTION_DATETIME field in the schema.

Clarification on Data Field (6) Creation date and time in the schema

Data Field (6) Creation date and time in TRUM corresponds to the attribute
in Edig@s schema, and should provide information on the date and time at which the transaction was executed (i.e. the transaction timestamp).

TRUM Data Field (6) shall not be confused with element in the Edig@s schema, that reflects the date and time at which the electronic report file was created. The Agency understands that there might be a delay between the execution time of the transaction and the time of xml file creation.

Data Field (7) Auction open date and time

No. Field Identifier Description
7 Auction open date and time The date and time when an auction opens for bidding.
Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time Up to 30 2014-01-29T10:35:56Z

This field indicates the date and time when an auction opens for bidding. Auction open date and time expressed by ISO 8601 date format / UTC time format.

This field is mandatory if the primary or secondary allocations occur via auctions, but shall be left blank if the process of allocation does not involve an auction or call for orders.

This field corresponds to the PROCESS_TRANSACTION.AUCTIONOPEN_DATETIME field in the schema.

Data Field (8) Auction end date and time

No. Field Identifier Description
8 Auction end date and time The date and time when an auction closes.
Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time Up to 30 2014-01-29T10:35:56Z

This field indicates the date and time when an auction closes for bidding, i.e. the last point in time when a participant to that market can submit orders and when trading can occur. Auction End Date and Time as expressed by ISO 8601 date format / UTC time format.

For primary or secondary allocations via auction markets, this fields is mandatory and shall reflect the gate closure.

If the process of allocation does not involve an auction (e.g. secondary allocations outside an organised market place), or in case of call for orders, this field shall be left blank.

This field corresponds to the PROCESS_TRANSACTION.AUCTIONEND_DATETIME field in the schema.

Data Field (9) Transportation transaction type

No. Field Identifier Description
9 Transportation transaction type The type identifies the nature of transportation transaction to be reported in accordance with current applicable industry standards as specified by Gas Network code on Interoperability and Data Exchange.
Description of Accepted Values Type Length Examples

 

  • ZSW = Ascending clock auction
  • ZSX = Uniform price auction
  • ZSY = First come first served
  • ZSZ = Secondary market procedure
Alphanumeric 3 ZSX

The field identifies the nature of specific transportation transaction to be reported choosing among the values reported above. For secondary allocations, transactions shall be reported populating this field with ZSZ.

In case of Over-nomination, Open Subscription Window, Open season, Storage allocation, Non-ascending clock pay-as-bid auction, this field shall be populated with ZSY.

This field is mandatory for primary and secondary allocations.

This field corresponds to the PROCESS_TRANSACTION.TYPE field in the schema.

Examples of the transaction reporting of the above procedures are available in the Annex II of TRUM.

Data Field (10) Start date and time

No. Field Identifier Description
10 Start date and time Date and time of the start of the transportation transaction runtime.
Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time Up to 30 2018-01-29T04:00Z

This field indicates the start date and time of the transportation period (“transaction runtime” in the Edig@s schema). Date and time shall be expressed as: YYYY-MM-DDThh:mmZ.

This field is mandatory for primary and secondary allocations.

The information on the Start date and time of the transaction period corresponds to the first value to be reported in the TRANSPORTATION PERIOD TIMEINTERVAL field in the schema.

Data Field (11) End date and time

No. Field Identifier Description
11 End date and time Date and time of the end of the transportation transaction runtime.
Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time Up to 30 2014-01-29T10:35Z

This field indicates the end date and time of the transportation period (“transaction runtime” in the Edig@s schema). Date and time shall be expressed as: YYYY-MM-DDThh:mmZ.

This field is mandatory for primary and secondary allocations.

The information on the End date and time of the transaction period corresponds to the second value to be reported in the TRANSPORTATION PERIOD TIMEINTERVAL field in the schema.

Data Field (12) Offered capacity

No. Field Identifier Description
12 Offered capacity The quantity of capacity available in the auction expressed in the measure unit. Only relevant for bidding behaviour monitoring.
Description of Accepted Values Type Length Examples
Up to 17 numerical digits (decimal mark included) in the format xxxxx.yyyyy. Numeric Up to 17 200.5

The field represents the total quantity of capacity offered in the specific allocation process (i.e. offered capacity by the TSO in the auction). Hence such value is allocation-process-specific and does not depend on the bidding activity of the market participants.

The value that shall be reported in this field is the capacity available in the auction or call for orders expressed in the Measure unit indicated in Data Field (16).

The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).

This field is mandatory for allocations occurring via auctions or call for orders procedures.

This field corresponds to the field OFFEREDCAPACITY_QUANTITY.AMOUNT in the schema.

Data Field (13) Capacity category

No. Field Identifier Description
13 Capacity category Applicable capacity category.
Description of Accepted Values Type Length Examples

 

  • Z04 = Available total firm capacity
  • Z05 = Interruptible (booked)
  • Z06 = Firm (booked)
  • ZEQ = Freely allocable capacity
  • ZER = Capacity with allocation restrictions and usage restrictions
  • ZES = Restricted-allocable capacity
  • ZET = Dynamically allocable capacity
  • ZEU = Temperature related and restricted capacity
  • ZEW = Published technical capacity
  • ZFA = Available interruptible capacity
  • ZFB = Available firm capacity
  • ZFD = Available total interruptible capacity
Alphanumeric 3 Z06

The field identifies the specific type of capacity allocated based on the particular allocation procedure. Capacity category refers to the result of the allocation procedure (booked interruptible, booked firm capacity).

This field is mandatory for primary allocations occurring via auctions.

This field corresponds to the PROCESS_TRANSACTION.TAXONOMY.AVAILABILITYTYPE field in the schema.


[1] As defined in the Commission Regulation (EU) 2017/459 of 16 March 2017 establishing a network code on capacity allocation mechanisms in gas transmission systems and repealing Regulation (EU) No 984/2013.

Updated: 
31/03/2022