FAQs on transaction reporting – Question II.2.1.41

Data Fields (49) and (50)

Using putting a time of 24:00:00 for end times is not possible using industry standard development tools that we use – it gets translated to 00:00:00. This applies to Fields 28 (contract trading hours) and Field 54 (Load Delivery Intervals)

Please accept that instead of the below in your example

<deliveryProfile>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>24:00:00</loadDeliveryEndTime>

</deliveryProfile>

That we can use to mean the same thing

<deliveryProfile>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

This is consistent with the interpretation for gas contracts available in the TRUM where start time = end time.

deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>


Answer:

According to ACER’s schemas and to the ISO 8601 standard which says “Midnight is a special case and may be referred to as either “00:00” or “24:00”. It is our understanding that midnight may be represented as either 00:00:00 or 24:00:00 or 23:59:59.

All of them have the same meaning. The same applies to 06:00:00 and 05:59:59. All of them have the same meaning. The same applies to 06:00:00 and 05:59:59 to represent the end of a gas day.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.42

Data Fields (49) and (50)

Could the Agency clarify further “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017.“ statement available on its Open letter on REMIT transaction reporting data quality?


Answer:

As indicated in the letter, market participants should refer to the Agency’s guidance on transaction reporting, namely the TRUM, Annex II to the TRUM and the FAQs on transaction reporting and they should also liaise with the RRMs reporting on their behalf as they may provide with additional instructions.

Based on the Agency’s schemas, and the ISO 8601 standard which says “Midnight is a special case and may be referred to as either “00:00” or “24:00″, our understanding is that midnight may be represented as either 00:00:00, 24:00:00 or 23:59:59.

For example, 2016-08-01 00:00:00 represents the same date and time of 2016-07-31 23:59:59 or 2016-07-31 24:00:00.

However, according to the guidance, 23:59:59 and 24:00:00 should not be reported for delivery start time. Time 23:59:59 or 24:00:00 on Day X should be reported as 00:00:00 in day X+1. The same applies to 06:00:00 and 05:59:59 to represent the end of a gas day.

Example: a typical yearly electricity baseload contract is wrongly reported if the delivery start date and time is 2016-12-31 00:00, 2016-12-31 23:59:59 or 24:00:00. The delivery start date and time should be reported as 2017-01-01 00:00:00.

With regard to “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017” reporting parties should pay attention to the guidance.

REMIT transaction reporting fields include Field N. (53) “Days of the week” which plays a pivotal role in the simplification of the reporting of delivery profiles. Please see also FAQs on transaction reporting – Question II.2.1.40.

When “Days of the week” is reported correctly, the reported delivery profile will always be the same of the “actual delivery profile” of the contract.

Case 1 – delivery period falls within the calendar period

For electricity contracts, e.g. see example 2.11 in Annex II to the TRUM, a report for the monthly electricity peak load delivery for August 2014. The hourly delivery profile is defined by the fields:

Field N. (49) “Delivery Start Date”: 01/08/2014 identifies the date at which the delivery of the commodity starts as specified in the contract.

Field N. (50) “Delivery End Date”: 31/08/2014 identifies the date at which the delivery of the commodity ends as specified in the contract.

Field N. (53) “Days of the week”: WD identifies on which days of the week the delivery takes place, i.e. week days, as specified in the contract.

Field N. (54) “Load Delivery Intervals”: 08:00/20:00, as specified in the contract

In this specific case 1 August 2014 is Friday, therefore the physical delivery starts on that date. 31 August 2014 is Sunday, thus the physical delivery ends on Friday 29 August.

Case 2 – delivery period falls outside the calendar period

Furthermore, reporting parties should also pay attention to some special circumstances.

For gas contracts, e.g. see example 2.8 in Annex II to the TRUM, given a gas day 06:00 on day D to 06:00 to D+1 may affect the reporting of their monthly contracts. A monthly gas delivery for August 2014, with physical delivery starting on 1 August 2014 delivers gas from 06:00 to 06:00 and the actual physical delivery ends on 1 September 2014 at 06:00. Therefore, the correct way of reporting this contract is:

Field N. (49) “Delivery Start Date”: 01/08/2014

Field N. (50) “Delivery End Date”: 01/09/2014

Field N. (53) “Days of the week”: empty to indicate every day

Field N. (54) “Load delivery intervals”: 06:00/06:00 Another special circumstance is when a monthly electricity off-peak load delivery for August 2014 start at 19:00:00 on 31/07/2014. These are typical monthly contracts but the delivery period falls outside the calendar days, rather than within them.

We are aware that these are industry standards and are used by Organised Market Places (OMPs) and the Agency would expect the reporting of delivery Start and End Date as shown above and in Annex II to the TRUM. The Agency is also aware that in most cases the same standards are used in bilateral trades (non-OMPs trades).

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.43

Data Field (51)

Field 51 (Duration) previously contained a value of ‘HH’ representing ‘Half Hour’. This appears to be no longer available. Should we just use ‘O’ for ‘Other’ now?


Answer:

Field 51 (Duration) it is not currently in use. Please refers to trading examples in Annex II of the TRUM available at https://www.acer-remit.eu/portal/data-submission where all the examples show that field 51 (Duration) is not required to be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.44

Data Field (52)

ACER Transaction Reporting User Manual – Reporting of Standard Supply Contracts – Field 52

How to correctly map to the ACER load type values ‘Shaped’ and ‘Other’ What is the difference between these two values?

We trade the following structures:

Overnights (Blocks 1+2)

Extended Peaks (Blocks 3+4+5+6)

Weekday Block 4

Would these load types be ‘Shaped’ or ‘Other’?

We think the above fall under ‘Other’


Answer:

If the price is the same for all the hours within the blocks, then BH for block hours should be used. If the price is different per each hour of the blocks, then it is a shaped product. In some cases it is possible to have a shaped product that has the same price for all the hours, but still a shaped product. Usually this is an OTC bilateral contract or voice brokered.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.45

Data Field (53)

Please can you provide some sample messages using the IB and XB notation, so including or excluding bank holidays.  I can see them in the TRUM but am having problems visualising practically how they would work.

An Eastern European off-peak trade that delivers

M-F excluding bank holidays from 0-8

M-F excluding bank holidays from 20-24

Sat-Sun 0 – 24

AND Bank holidays 0-24

The problem is I can’t see how to use IB and XB – the daysOfTheWeek tags are restricted in a way that I can’t see how to store what I think should be the case i.e. adding XB to the MOtoFR days designation.

Is this the kind of detail you were intending? An example would be great. Thanks

<deliveryProfile>

<daysOfTheWeek>MOtoFRXB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>MOtoFRXB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>SAtoSUIB</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>


Answer:

XB indicates that on Bank Holidays that profile does not apply and it is excluded. IB indicates that on Bank Holidays the same profile applies. In order to correctly use XB and IB, the field <daysOfTheWeek> </daysOfTheWeek> has to be reported twice in order to indicate the exclusion or inclusion of Bank Holidays. For example:

For XB:

<deliveryProfile>

<daysOfTheWeek>MOtoFR</daysOfTheWeek>

<daysOfTheWeek>XB</daysOfTheWeek>

<loadDeliveryStartTime>08:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>20:00:00</loadDeliveryEndTime>

</deliveryProfile>

For IB:

<deliveryProfile>

<daysOfTheWeek>SAtoSU</daysOfTheWeek>

<daysOfTheWeek>IB</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.46

Data Field (53)

As per the TRUM document, Days of the week allows the value ” ” which means “All days”.

But the specification in the ACER XSD says;

<xs:simpleType name=”daysOfTheWeekType”>

<xs:restriction base=”xs:string”>

<xs:pattern

value=”((SU|MO|TU|WE|TH|FR|SA)to(SU|MO|TU|WE|TH|FR|SA))|(SU|MO|TU|WE|TH|

FR|SA|XB|IB|WD|WN)”/>

</xs:restriction>

</xs:simpleType>

Due to this restriction, XML file fails validation wherever days of the week is ” “.

We would like to flag this to ACER. As a solution to this issue, should we have to display SUtoSA for All Days instead of “ “. Please advise.


Answer:

The symbol “ “ means blank and it means all days. Please note that the field is not mandatory.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.47

Data Field (54)

Load Delivery Intervals in standard schema is defined as time in HH:MM format. How to distinguish between the normal second hour and the third hour that is changed to 2’clock during the Long clock change?

The only way is to repeat the hours:

00:00/01:00 – first hour

01:00/02:00 – second hour

02:00/03:00 – third hour

02:00/03:00 –  fourth hour

because there is no unique identification of traded period. But in this case ACER loos track what was traded in third period and what was traded in fourth period.


Answer:

The above representation is the correct way to report the third and fourth hour of the day on the day of the clock change. The third and fourth hour should be ordered in a chronological order.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.1

We understand that an order will not be required for Click & Trade as per Annex II of the Trum, but is there a way of indicating that the Trade is a Click and Trade so that it won’t get rejected for not having a valid Order associated with it?

Suggested solution:  We think the answer to this is already in the .XML sample.  There’s an optional tag called ‘clickAndTradeDetails’ which we would use to indicate the Trade type.


Answer:

It is our understanding that a Click & Trade is a Limit order which aggresses the initiator order. When reporting click an trade transactions the reporting parties have two options:

1) to create a Limit Order and report it as an order; or

2) to report a transaction with the ‘clickAndTradeDetails’ filled in (i.e. “LIM” for Limit Order in the order type).

Please see examples in Annex II to the TRUM and XML examples related to them available on the REMIT portal at https://www.acer-remit.eu/portal/data-submission

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.2

Different but valid interpretations of delivery profiles

As an example –  an off peak trade I currently build as

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

but it could equally, legally be described as this.

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

We would prefer our version as it is clearer, does it matter? They are both schema valid and correct to our mind

Same question for NBP gas. We currently generate this

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

but equally it could be this

<deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

again, we prefer our version as being clear, again does it matter – will ACER accept both?

We would prefer AER to accept all variants of this , otherwise ACER will have to describe a “reference” implementation for everything , which takes time to do and then time for everyone to implement and time is something that we don’t have a lot of.


Answer:

With regard to the code:

1.    <deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

2.    <deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

In the first case (1) this would be mean that Mon 20:00 to 00:00 and Tue 00:00 to 08:00 and 20:00 to 00:00, etc. but that means it misses the period between 00:00 to 08:00 on Mon

With regard to the code:

<deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

This applies to every day delivery from 06:00 am to 06:00 am irrespective of the day.

While WD from 06:00 am to 06:00 am + WN from 06:00 am to 06:00 am may represent the same thing of all days from 06:00 am to 06:00 am, the use of the smallest possible set of information is the correct way to report such a transaction: e.g. all days 06:00 am to 06:00 am and not WD + WN.

The reporting of WD + WN profiles should be avoided when it is not needed.  For example: a yearly forward contract for the delivery of gas from 06:00 am to 06:00 am every day of the year can be represented with one delivery period for all days as seen above, WD + WN profiles or it can be repeated 365 days, one per each deliver day. Since the all-day from 06:00 am to 06:00 am profile is the simplest one, this should be used.

Reporting parties that aim at a successful transaction reporting should pay attention to the trading examples reported in Annex II of the TRUM and should not deviate from it unless previously discussed with the Agency.

In addition, for electricity delivery profiles that start at 23:00, e.g. a baseload contract delivery starts at 23:00 on Sunday and delivery ends at 23:00 on Friday, this should be reported as SUtoFR from  23:00 to 23:00

<deliveryProfile>

<daysOfTheWeek>SUtoFR</daysOfTheWeek>

<loadDeliveryStartTime>23:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>23:00:00</loadDeliveryEndTime>

</deliveryProfile>

The profile WD from 23:00 to 23:00 :

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>23:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>23:00:00</loadDeliveryEndTime>

</deliveryProfile>

would not represent the same thing and it should not be used.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.3

Due to idiosyncrasies of the Gas market, on certain times every month there are contracts that are in effect duplicates of each other, from a delivery point of view.

For example, on Fri 24th July, both the “Balance of Month” and “Working days next week” contract quoted on screen will result in delivery of the same commodity – from 27-31st July inclusive.

These are shown as 2 different contracts on the broker screen so have 2 different order books and clients can place orders and trade in either contract.

We would like to check that reports of, for example, 2 orders on 2 different contract IDs would be accepted, even though the details of the two contracts and delivery profiles would in effect be the same.

We can see the test ARIS system accepts this, we just want assurance that you do not think that this violates any rules.

We can see why this may be undesirable as you would not want people making up different contract IDs all of the time, however in this instance the traders see 2 distinct order book on the screen and we feel that it is valid to report in this way, if the order books are separate.


Answer:

If there are two different contracts and these are shown as two different contracts on the broker screen, so they have two different order books and the traders see two distinct order books on the screen, these contract should be reported with different IDs.

The fact that on certain times every month there are contracts that are in effect duplicates of each other, from a delivery point of view, it does not mean that they are the same. They are two different contracts with the same delivery profiles (and they may trade at the same price, but traded in two different order books and they should be reported separately.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS