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 |
ACER code EIC X |
Alphanumeric |
12 16 |
A0643278W.EU 10X1001A1001A450 |
This field indicates the identification of the owner and sender of the document. The sender of the document is identified by a unique identification code which shall be either ACER code or EIC X code.
The unique identification 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 scheme attribute. If EIC X code is used for identification, the coding scheme attribute shall be equal to “305”. For ACER codes, it shall be equal to “ACE”.
The sender may not only be a TSO or 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 |
ACER code EIC X |
Alphanumeric |
12 16 |
A0643278W.EU 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 ACER code as reported in the List of the Organised Market Places published by ACER or Energy Identification Coding (EIC X-type).
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 or ACER code) 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 21X-XXXXXXXXXXXY.
Both the identification and the coding scheme are mandatory for primary and secondary allocations. If EIC X code is used for the identification, the coding scheme attribute shall be equal to “305”. For ACER codes, it shall be equal to “ACE”.
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 |
|
Alphanumeric | 3 | 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 field TRANSPORTATION_TRANSACTION identification 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
|
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 |
|
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.
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 field TRANSPORTATION PERIOD TIMEINTERVAL 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 field TRANSPORTATION PERIOD TIMEINTERVAL 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 |
|
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.