Annex II
Examples of Transaction Reporting
For actual examples, please download the PDF version of Annex II
| Version | Effective Date |
|
Annex II Version 5.0¨(included additional non-standard examples related to LNG supply contracts and reliability options, updated non-standard examples on PPAs and LNG supply contracts) |
13 March 2024 |
|
Annex II Version 5.1 |
30 September 2024 |
1 Introduction
Annex II to the TRUM presents examples of transaction reporting for transactions, including orders to trade, related to contracts reportable to the Agency pursuant to Article 3(1) of the REMIT Implementing Acts. The examples in this Annex show what has to be included in the transaction reports of wholesale energy products traded either on organised market places or bilaterally.
|
Important: if reporting entities do not find relevant transaction reporting examples in this document, they are advised to submit a trading example to the Agency. The trading examples should describe the trading scenario and provide suggestions on what to report for each specific transaction. The template for the submission of additional trading examples is available on the REMIT Documents section here and should be sent to transaction.reporting@acer.europa.eu once completed. If reporting entities are still unsure about what has to be included in the transaction reports even after consulting this document, they are advised to contact the Agency via the REMIT Query Form available on the ACER website at https://support.acer-remit.eu/forms/remit-query-form (the relevant question categories related to Transaction Reporting – TRUM Annex II should be selected) |
2 The structure of Annex II
Annex II is composed of three sections: Section 1, Section 2 and Section 3:
a) Section 1: reporting of orders and trades with Table 1 of the Annex to the REMIT Implementing Regulation:
- I. Examples related to auction contracts
- II. Examples related to continuously traded contracts on exchange OMPs
- III. Examples related to continuously traded contracts on broker OMPs (including voice-brokered)
- IV. Examples related to bilaterally traded contracts (off-organised market place)
b) Section 2: reporting of non-standard contracts using Table 2 of the Annex to the REMIT Implementing Regulation:
c) Section 3: reporting of transportation contracts using Table 3 and Table 4 of the Annex to the REMIT Implementing Regulation:
- I. Examples related to electricity transportation contracts
- II. Examples related to gas transportation contracts
3 The different parts of Table 1 and Table 2
Table 1 of the Annex to the REMIT Implementing Regulation is composed of seven sections:
- Parties to the contract
- Order details
- Contract details
- Transaction details
- Option details
- Delivery profile
- Lifecycle information
Table 2 of the Annex to the REMIT Implementing Regulation is composed of six sections:
- Parties to the contract
- Contract details
- Fixing index details
- Option details
- Delivery profile
- Lifecycle information
4 Trading scenarios
The present Annex shows what shall be reported according to Table 1, Table 2, Table 3 and Table 4 of the Annex to the REMIT Implementing Acts.
Trading scenarios included in Annex II encompass transactions, including orders to trade, related to both standards and non-standards contracts. Annex II shows what shall be reported for a specific trading scenario, while the technical implementation is not covered in this Annex. The descriptions of relevant trading scenarios have been included for each example.
It is mandatory to provide input in all the fields that are populated in the examples for each type of transaction. Fields that are blank are not required to be reported for that type of transaction. If reporting entities find that the examples are insufficient to cover their trading scenario because some additional fields need to be populated in order to properly represent it, the reporting entities are invited to submit that trading example to the Agency using the template available on the ACER website (REMIT Documents section).
|
It is the responsibility of the reporting parties to make sure their transaction reports comply with the reporting details set out in the REMIT Implementing Regulation, which are further defined in the TRUM, and the examples provided in Annex II. If reporting parties do not find trading examples that represent their scenarios in Annex II, they are advised to submit the missing trading scenarios to the Agency by completing the template available on the REMIT Documents section at Templates for submitting trading examples published on the ACER website and sending it to transaction.reporting@acer.europa.eu. |
However, before reporting parties submit their additional trading examples, they should make sure that Annex II contains no relevant examples or any combination of examples which may already represent their scenario. The list of examples represented in Annex II will not be able to cover all possible trading scenarios, but combining the examples should make it possible to represent the majority of scenarios.
For example: if a 15-minute contract trading scenario is not represented in the examples of transactions relevant for continuous markets, this should not prevent the reporting party from using the 15-minute delivery profile details used in the examples of transactions relevant for auction markets.
In case reporting parties have any doubts as to what to include in their trading scenarios, it is their responsibility to contact the Agency via the REMIT Query Form available on the ACER website at https://support.acer-remit.eu/forms/remit-query-form, where they should select the relevant question categories related to Transaction Reporting – TRUM Annex II.
As regards the technical implementation of transaction reporting and the submission of the XML files, reporting parties should refer to the Manual of Procedures available on the REMIT Documents section at the ACER website (https://www.acer.europa.eu/remit-documents/remit-reporting-guidance).
|
Please read carefully The fields populated in the trading examples below are mandatory for each type of transaction. Blank fields in the examples are not expected to be populated when reported for that type of transaction. The mandatory nature of the fields in the examples below is in line with the latest version of the TRUM, which provides clarifications on the cardinality of fields from the data reporting point of view. In some circumstances, reporting parties may provide additional information not required or described in the trading examples simply because it is easier to report what is in their system than it is to sift through the information. This may be the case for the field ‘Total notional amount’ in the order report, where reporting parties may decide to provide this value in the order to trade report even if this field is not required. Such additional information may be reported on the condition that it does not violate the validation rules set by the Agency. In general, the Agency will not reject files containing non-required additional information, unless this is incompatible with the data validation rules set out in the ‘ACER REMIT Information System Data Validation Document’ published in the REMIT Documents section of the ACER website. Please contact your RRM in case of any further questions about this topic. For phase one of REMIT transaction reporting (started on 7 October 2015), as regards the technical implementation of transaction reporting and the submission of the XML files, market participants had to liaise with the RRMs that submitted the reports on their behalf. For phase two of REMIT transacting reporting (started on 7 April 2016), i.e. the submission of trades occurring outside organised markets, market participants were able to gain access to the technical standards if they decided to report their own transactions as an RRM. |
|
Clarification of standard vs non-standard contract (1) Trades not reported under EU financial legislations (2) Contracts admitted to trade at organised market places and traded bilaterally (3) Non-standard contracts with a defined price and quantity (indicated as ‘BILCONTRACT’ in the transaction report under Contract Name in Data Field (22)) and details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price (indicated as ‘EXECUTION’ in the transaction report under Contract Name in Data Field (22)) shall be reported using Table 1 of the Annex to REMIT Implementing Regulation. |
|
Decision tree for the reporting of standard and non-standard contracts and the use of Table 1 or Table 2
|
4.1 Reporting bilateral contracts traded outside organised market places and executions under non-standard contracts: Table 1
In order to facilitate the reporting of bilateral contracts traded outside organised market places (standard and non-standard contracts with a defined price and quantity) and executions under non-standard contracts, some validation rules for these bilateral contracts are more relaxed than those for orders to trade and trades concluded on organised market places.
Reporting parties shall report bilateral contracts traded outside organised market places and executions under non-standard contracts with Table 1 of the Annex to the Implementing Regulation. Before the backloading exercise expired according to the deadlines specified in the Implementing Acts, Table 1 was also used for the reporting of the backloading of standard contracts. Reporting parties are expected to report the value of ‘BILCONTRACT’, or ‘EXECUTION’ under Contract Name in Data Field (22) according to the trading scenarios available in this Annex.
Please note that Article 5(1) of the Implementing Regulation states that ‘Details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex’. This implies that even if a contract is considered a non-standard contract (reportable no later than within 30 days of its execution) but has an agreed price and quantity, the contract has to be reported using Table 1 of the Implementing Regulation. See point 3.2.5 of the TRUM.
‘BILCONTRACT’: should be reported under Contract Name in Data Field (22) of Table 1 to identify standard contracts and non-standard contracts (that have a defined price and quantity, irrespective of default clauses’ application) that are traded outside organised market places.
‘EXECUTION’: should be reported under Contract Name in Data Field (22) of Table 1 to identify the reporting of the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price. These executions under the framework of non-standard contracts are reportable no later than 30 days after the invoicing date.
‘BACKLOADING’ (no longer applicable): had to be reported under Contract Name in Data Field (22) of Table 1 to identify the reporting of details of wholesale energy contracts which were concluded before the date on which the reporting obligation became applicable and remained outstanding on that date. These contracts had to be reported to the Agency within 90 days of the reporting obligation becoming applicable.
Please see also ‘Additional clarification on the back loading requirement’ available in the TRUM (point 3.2.7).
Please be aware that the backloading exercise has expired according to the deadlines specified in the Implementing Regulation.
For the purpose of reporting the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price, reportable with Table 1, the Agency understands that these transactions should be reported according to the billing cycle industry standards, as the invoicing date is the last point in time that the price and quantity can be discovered.
The Agency understands that the billing cycle industry standards refer to calendar months and therefore twelve transactions per year (if the executions take place every month of the year) are expected to be reported no later than 30 days after the discovery of price and quantity. However, nothing prevents market participant from reporting the details of transactions executed within the framework of nonstandard contracts on a more frequent basis even if the Agency would not expect it
4.2 Reporting of non-standard contracts: Table 2
n drafting the guidance on the reporting of non-standard contracts and executions under non-standard contracts, the Agency widely consulted its stakeholders to obtain their valuable input. The Agency and the industry have aligned their understanding of the reporting of non-standard contracts and executions under non-standard contracts and have created some basic reporting rules.
For the purpose of the reporting of non-standard contracts that do not have a defined price and quantity (at the time entering into the contract), non-standard contracts may have different characteristics based on:
a) volume scenarios;
b) price scenarios; and
c) delivery scenarios.
Each of the above scenarios has some variations; their descriptions can be found below. In the contract scenario descriptions below, each volume scenario is represented by scenarios (V1) to (V5), each price scenario by scenarios (P1) to (P5), and each delivery scenario by scenarios (D1) to (D4).
a) Volume Scenarios
1. Fixed Flat Volume Scenario (V1): Supply to a customer in Europe for a term of one calendar year (e.g. 2016) with a fixed daily supply. No customer volume optionality.
2. Simple Nominated Volume Scenario (V2): The customer must nominate changes in offtake within a defined period prior to delivery period. For example, the delivery is for the 2016 calendar year and the customer sends a monthly nomination three days before the start of the delivery month. The offtake nomination must be within a contract-defined MIN/MAX range.
3. Cascade Nominated Volume Scenario (V3): The customer can choose to nominate changes in offtake using a time cascade of deadlines. The customer could nominate a next month delivery three days before the end of the month prior to delivery month, or choose to nominate volume a day ahead, or could use a combination of both, nominating ‘certain’ volume a month ahead and refining that offtake with day-ahead nominations. The offtake nomination must be within a contract-defined MIN/MAX range.
4. Not Nominated (full supply) Volume Scenario (V4): The customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but on any day offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.
5. Fixed Shape Volume Scenario (V5): The customer contract defines the daily volume that will be delivered during the summer and a separate (different) daily volume that will be delivered during the winter. The customer has no flexibility to change the defined seasonal deliveries – daily delivered volume will be the same for every day of the season.
b) Price Scenarios
1. Fixed Price Scenario (P1): Supply to a customer for a term of one calendar year at a fixed price, e.g. 20 EUR/unit for the year.
2. Trigger Price Scenario (P2): The customer can choose to fix the price of a future delivery period at the closing forward price (e.g. as published by an organized market place or a price intelligence service) for that forward period on the day the trigger is pulled. However, if the price is not fixed, the contract price will default to a contract-specified index, e.g. day-ahead.
3. Index Basket Scenario (P3): First, the contract price is determined by a basket of indexes calculated over a specified period (for the average of closing prices), then the contract is characterised by a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’), and finally the calculated price is applied to a specified delivery period (model X-Y-Z). For example, for a calendar year 2016 delivery with the calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.
4. Index Switch Scenario (P4): The contract price is determined by one of two defined indexes, where three days prior to the pricing period the customer can nominate one index for the calculation. For the chosen index there is a specified period (for the calculation of the average of closing prices), a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’) and a specified delivery period to which the calculated price applies (model X-Y-Z as described above). For example, for a calendar year 2016 delivery with the calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.
5. Simple Index Scenario (P5): The contract price for the month of delivery for a calendar year 2016 delivery is calculated as the average of the closing price of the front-month futures contract for the last calendar month of trading days prior to the month of delivery. For example, the price for the delivery of the calendar year contract ‘January 2016’ is the average of the January 2016 futures closing prices during the month of December 2015.
c) Delivery Scenarios[1]
1. Fixed Delivery Scenario (D1): Delivery to a single identified delivery point over a one year period with the same volume delivered every hour of every day.
2. Delivery Point Switching Scenario (D2): The customer can choose to be 100% supplied at one of two different locations specified in the contract (with two separate EIC codes[2]) and must nominate their choice three days before the delivery for the next month starts. This choice will be valid until the end of the contract, or until a new nomination is done three days before a new delivery month starts.
3. Multiple Fixed Point Delivery Scenario (D3): Same as the Fixed delivery scenario, but the delivery is split using fixed percentages (that add up to 100%) between three different locations. The fixed percentages cannot change during the contract term.
4. Multiple Variable Point delivery Scenario (D4): Same as the Multiple fixed point delivery scenario, but the customer can change the percentage split (possible for up to two percentages to be 0% but the total must add up to 100%) between three different locations. The customer must nominate their choice three days before the delivery for the next month starts. The choice will be valid until the end of the contract, or until a new nomination is done three days before a new delivery month starts.
a) Volume scenarios: table reporting volume scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Please note that “blank” means empty field
b) Price scenarios: table reporting price scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts
| P1 | P2 | P3 | P4 | P5 | ||
| Field # | Field name | Fixed | Trigger | Index Basket | Index Switch | Simple Index |
| 15 | Price or price Formula | 20 | Simplified Formula | Simplified Formula | Simplified Formula | Simplified Formula |
| Short definition: | If volume, shape, price and duration are known on the contract date then populate, otherwise blank | |||||
| 16 | Estimated notional amount | Price x daily volume x days | Blank | Blank | Blank | (Price x Winter daily vol. x winter days) + (Price x summer daily vol. x summer days) |
| 17 | Notional currency | EUR | EUR | EUR | GBP | EUR |
| Short definition: | Price classified as fixed, simple index (single underlying), complex price formula (multiple underlying), or other | |||||
| 24 | Type of index price | F | O | C | C | I |
| Short definition: | List all indexes used in the formula (if there is one) otherwise blank | |||||
| 25 | Fixing index | Blank | Blank | GO FM mid, NG FM mid, CPI UK | GO FM mid, NG FM mid | FM Close |
| Short definition: | Futures, Forward or other. Completed in sequence (Data Fields (24) to (30)) for each index | |||||
| 26 | Fixing index types | Blank | DAH | FU, FW, OT | FU, FW | FU |
| Short definition: | Publication source. Completed in sequence (Data Fields (24) to (30)) for each index | |||||
| 27 | Fixing index sources | Blank | Heren | ICE, Heren, UK Stats | ICE, Heren | ICE |
| Short definition: | Earliest date when the first price is included for the calculation of that index - e.g. For a front-month index (average of closing prices for last month before expiry) then January 2016 front month will be the average of closing January futures prices averaged from 1 December to 26 December 2015, so this field would be populated as 01-12-2015 | |||||
| 28 | First fixing date | Blank | 2015-12-01 | 2015-12-01 | 2015-12-01 | 2015-12-01 |
| Short definition: | Similar to Data Field (28), but the last day. So if contract is calendar 2016 deliveries with front-month pricing, then the last date would be the last pricing date of December 2016 futures contract, say, 27 November 2016, so populate field as 27-11-2016 | |||||
| 29 | Last fixing date | Blank | 2016-12-30 | 2016-09-30 | 2016-09-30 | 2016-11-27 |
| Short definition: | How long is the closing price averaging period | |||||
| 30 | Fixing frequency | Blank | O | Q | Q | M |
Please note that “blank” means empty field
c) Delivery scenarios: table reporting delivery scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts
| D1 | D2 | D3 | D4 | ||
| Field # | Field name | Fixed | Delivery switch | Multiple points (Fix %) | Multiple points (Variable %) |
| Short definition: | Table 2 fields do not enable you to distinguish between switching between delivery points or adjusting the volume delivered at multiple points, so include all delivery points where it is possible to deliver (according to the contract) | ||||
| 41 | Delivery point or zone | 10YCB-EUROPEU--8 |
|
|
|
| Short definition: | First delivery date according to contract | ||||
| 42 | Delivery start date | 2016-01-01 | 2016-01-01 | 2016-01-01 | 2016-01-01 |
| Short definition: | Last possible date of delivery according to the contract | ||||
| 43 | Delivery end date | 2016-12-31 | 2016-12-31 | 2016-12-31 | 2016-12-31 |
| Short definition: | Identification of the delivery profile (base load, peak load, off-peak, block of hours or other). Considering an example on natural gas contract, the shape for natural gas is always GD | ||||
| 44 | Load type | GD | GD | GD | GD |
Please note that “blank” means empty field
4.2.1 Combining the volume, price and delivery scenarios: examples
The combination of a volume scenario with a price scenario and a delivery scenario should be able to represent most of the non-standard contracts that have to be reported to the Agency. Based on the scenarios above, there are 100 (5 volume X 5 price X 4 delivery) possible scenarios that market participants and reporting parties should be able to represent.
Example 1: a market participant may want to report a contract with the following combinations:
a) Volume scenario: (V4) - Not Nominated (full supply)
b) Price scenario: (P5) - Simple Index Scenario
c) Delivery scenarios: (D1) - Fixed Delivery Scenario
Contract Description:
a) V4: The customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but, on any day, the offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.
b) P5: Contract for a calendar year 2016 delivery. The contract price for the month of delivery is calculated as the average closing price of the front-month futures contract for the last calendar month (only trading days)prior to the month of delivery i.e. January 2016 delivery price is the average of the January 2016 futures closing prices during the month of December 2015.
c) D1: Delivery to a single identified delivery point over a one-year period with the same volume delivered every hour of every day.
| Full Supply / Simple Index Price / Fixed Delivery Point | |||
| N | Field Identifier | (buyer side) | (seller side) |
| Contract details | |||
| 11 | Contract ID | LTC0001 | LTC0001 |
| 12 | Contract date | 2015-07-18 | 2015-07-18 |
| 13 | Contract type | FW | FW |
| 14 | Energy commodity | NG | NG |
| 15 | Price or price formula | Avg(FMC(month-1)) | Avg(FMC(month-1)) |
| 21 | Volume optionality | V | V |
| Fixing index details | |||
| 24 | Type of index price | I | I |
| 25 | Fixing index | Front Month Close | Front Month Close |
| 26 | Fixing index types | FU | FU |
| 27 | Fixing index sources | ICE | ICE |
| 28 | First fixing date | 2015-12-01 | 2015-12-01 |
| 29 | Last fixing date | 2016-11-27 | 2016-11-27 |
| 30 | Fixing frequency | M | M |
| 31 | Settlement method | P | P |
| Delivery profile | |||
| 41 | Delivery point or zone | 10YCB-EUROPEU--8 | 10YCB-EUROPEU--8 |
| 42 | Delivery start date | 2016-01-01 | 2016-01-01 |
| 43 | Delivery end date | 2017-12-31 | 2017-12-31 |
| 44 | Load type | GD | GD |
Example 2: a market participant may want to report a contract with the following combinations:
a) Volume scenario: (V3) - Cascade Nominated Volume Scenario
b) Price scenario: (P3) - Index Basket Scenario
c) Delivery scenarios: (D3) - Multiple Fixed Point Delivery Scenario
Contract Description:
a) V3: The customer can choose to nominate changes in offtake using a time cascade of deadlines. The customer could nominate next month delivery three days before the end of the month prior to delivery month, or choose to nominate volume a day ahead, or could use a combination of both, nominating ‘certain’ volume a month ahead and refining that offtake with day-ahead nominations. In this example, delivery is for the calendar year 2016.
b) P3: First, the contract price is determined by a basket of indexes calculated over a specified period (for the average of closing prices), then the contract is characterised by a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’), and finally the calculated price is applied to a specified delivery period (model X-Y-Z). For example, for a 2016 calendar year delivery with calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.
c) D3: Same as Fixed delivery scenario, but the delivery is split using fixed percentages (that add up to 100%) between three different locations. The fixed percentages cannot change during the contract term.
| Cascaded Nom / Index Basket Price / Multiple Fixed Delivery Points | |||
| N | Field Identifier | (buyer side) | (seller side) |
| Contract details | |||
| 11 | Contract ID | LTC0001 | LTC0001 |
| 12 | Contract date | 2015-07-18 | 2015-07-18 |
| 13 | Contract type | FW | FW |
| 14 | Energy commodity | NG | NG |
| 15 | Price or price formula | Avg(GO FM mid,NG FM mid) | Avg(GO FM mid,NG FM mid) |
| 19 | Volume optionality capacity | 0-2400 | 0-2400 |
| 20 | Notional quantity unit | MW | MW |
| 21 | Volume optionality | M | M |
| 22 | Volume optionality frequency | D | D |
| 23 | Volume optionality intervals | 2015-12-29 / 2016-12-30 | 2015-12-29 / 2016-12-30 |
| Fixing index details | |||
| 24 | Type of index price | C | C |
| 25 | Fixing index | GO Front Month mid | GO Front Month mid |
| 26 | Fixing index types | FU | FU |
| 27 | Fixing index sources | ICE | ICE |
| 28 | First fixing date | 2015-12-01 | 2015-12-01 |
| 29 | Last fixing date | 2016-09-30 | 2016-09-30 |
| 30 | Fixing frequency | Q | Q |
| 24 | Type of index price | C | C |
| 25 | Fixing index | NG Fronth Month mid | NG Fronth Month mid |
| 26 | Fixing index types | FW | FW |
| 27 | Fixing index sources | Heren | Heren |
| 28 | First fixing date | 2015-12-01 | 2015-12-01 |
| 29 | Last fixing date | 2016-09-30 | 2016-09-30 |
| 30 | Fixing frequency | Q | Q |
| 31 | Settlement method | P | P |
| Delivery profile | |||
| 41 | Delivery point or zone | 10YCB-EUROPEU--8 | 10YCB-EUROPEU--8 |
| 41 | Delivery point or zone | 10YCB-EUROPEU-9 | 10YCB-EUROPEU-9 |
| 41 | Delivery point or zone | 10YCB-EUROPEU--7 | 10YCB-EUROPEU--7 |
4.2.2 Reporting of executions under the framework of non-standard contracts
The executions under the framework of non-standard contracts shall be reported with Table 1 of the Annex to the Implementing Regulation.
To see examples please download the PDF version of Annex II below.
|
Disclaimer on TRUM Annex II examples [NEW] The examples in the TRUM Annex II are intended to provide guidance to market participants and reporting parties on how standard, non-standard, and transportation contracts shall be reported to the Agency within the data reporting obligations. All identification codes, including delivery point or zones or contract ID and contract names adopted in the examples in following sections, are fictitious and are not based on any real events or codes. In particular, when dealing with Data Field (48) Delivery point or zone, typically the following codes have been adopted in the examples: 10YXX-EUROPOW--8 or 10YXX-EUROPOW—8 or 10YXX-EUROPOW--9 or 10YXX-EUROPOW--10 (electricity contracts) 10YXX-EUROGAS--8 or 10YEU-EUROGAS--8 (natural gas contracts) Such codes are not intended to represent real delivery point or zone codes. Data Field (48) Delivery point or zone should be populated according to Annex VI of the TRUM and the List of the Accepted EIC codes available in the REMIT Documents section of the ACER website. |
| Version history | Effective Date |
| Annex II Version 1.0 | 06 May 2015 |
| Annex II Version 2.0 | 30 September 2015 |
| Annex II Version 2.0* *(with comments on non-standard contract examples) | 16 November 2015 |
| Annex II Version 2.1 (included additional non-standard contract examples an corrected a few typos in non-standard examples) | 15 February 2016 |
| Annex II Version 3.0 (included Electricity and Gas transportation contract examples) | 23 March 2016 |
| Annex II Version 4.0 (included additional standard and non-standard examples including market coupling, added the scenario description for each example, and corrected some examples in order to ensure consistency with TRUM 4.0) | 30 April 2021 |
| Annex II Version 4.1 (included new Gas transportation contract examples) | 31 March 2022 |
| Annex II Version 4.2 (included additional standard examples and corrected few typos) | 16 November 2022 |
[1] Delivery points or locations to be indicated in Data Field(48) in Table 1 and Data Field (41) in Table 2 have to be chosen among the EIC codes reported in the List of Accepted EIC codes published in the REMIT Documents section of the ACER website.
[2] Please see footnote 1.