skip to Main Content

The User Acceptance Test (GAT) for Theme release 2021 (TR2021) – Tranche 1 Allocatie 2.0 highlighted 4 topics that resulted in local findings by several market parties. We advise you to check for these common findings in your own system. Do this well in advance of the go live on Saturday 19 March so that it does not hinder your organisation’s transition.

Time stamp
It appears that the time stamp often has the wrong format. The notation that you should use can be found below. Make sure that the start and end dates, for the period that metering data is supplied, have the following notation in UTC: YYYY-MM-DDThh:mm:ssZ:

  • Example start and end date calendar day electricity (winter time): 2020-02-08T23:00:00Z / 2020-02-09T23:00:00Z;
  • Example start and end date gas day (winter time): 2020-02-08T05:00:00Z / 2020-02-09T05:00:00Z;
  • Example start and end date calendar day electricity (summer time): 2020-06-08T22:00:00Z / 2020-06-09T22:00:00Z.
  • Example start and end date gas day (summer time): 2020-06-08T04:00:00Z / 2020-06-09T04:00:00Z.

These examples can be found in the service descriptions for TR2021 – Tranche 1.

We also have the date/time when the message was compiled; the so-called CreationTimestamp in the EDSN BusinessDocumentHeader. The notation for this date/time is as follows: YYYY-MM-DDThh:mm:ssTZD. The TZD is the Time Zone Designator and must be Z, +hh:mm or -hh:mm.

The use of fractions of a second has been prescribed in the W3C DTF Note ISO 8601 specifications. But the sector uses: YYYY-MM-DDThh:mm:ssTZD (thus without decimals that represent fractions of seconds). This is not merely a recommendation; it is mandatory. You can find various examples in the NEDU/EDSN Design choices.

Correlation ID
A Request for Change (RFC) for the Correlation ID will be presented during the NEDU General Meeting of Members on 9 March. This will be RFC A2.0.1 ‘Use of Correlation ID’. The RFC will be approved on 9 March and will immediately come into effect once the go live for Tranche 1 has been completed smoothly. You must have implemented the RFC before the go live for Tranche 2. The RFC stipulates that both ID’s must be the same. The advice until then: do not make things difficult for yourself. If possible, make sure that the ID’s are identical.

Several metering responsible parties and balance responsible parties (BRP’s) have already responded by using identical ID’s for T1.

However, this is merely a recommendation, and different ID’s are still possible (until the RFC comes into effect after 19 March). In any case, you will have to use the same ID once Tranche 2 has gone live.

ProcessTypeID messages do not comply with the XSD because process type N90 is missing in the EDSNDocumentHeader. Bear this in mind and, wherever necessary, make adjustments in accordance with the Business Service Uitwisseling herzieningsverzoeken (Exchange revision requests). The Business Service section that addresses this matter can be found below:

The following fields must be completed in the EDSN BusinessDocumentHeader for Allocatie 2.0:

  • MessageID (mandatory, enforced by the XSD);
  • CreationTimestamp (mandatory, enforced by the XSD);
  • ReceiverID (mandatory, enforced by the XSD);
  • SenderID (mandatory, enforced by the XSD);
  • ProcessTypeID (mandatory, this is a process-related agreement for Allocatie 2.0 (see concerned service description), not enforced by the XSD);
  • CorrelationID (optional, if the sending party has added a ‘completed’ CorrelationID in the message, only then must the receiving party return this CorrelationID in the return message).

Because a ProcessTypeID is missing, the message does not comply with agreements about using this field for Allocatie 2.0 messages.

Sink and Source
The proposed approach involves coordinating directions in the N11 and N12 (per connection point) with the 2 involved grid operators and the metering responsible party.

In recent weeks, our activities have involved testing the N11/N12 messages. This relates to grid-to-grid connections, where Sink and Source are used to identify the connected grid areas. We discovered that there may be ambiguity about how energy flow directions are included in the message. The Business Service is clear in this case; an explanation has been provided below using the old and new situations:

Old situation (E66)

  • If energy goes from Source to Sink: positive values in the message
  • If energy goes from Sink to Source: negative values in the message

New situation (N11/N12)

  • If energy goes from Source to Sink, this will appear as Acquisition (A17) in the N11/N12
  • If energy goes from Sink to Source, this will appear as Feed-in (A18) in the N11/N12

The confusion arises when we look at the current directions in the regular E66:

  • negative = acquisition
  • positive = feed-in

If we look at it from a Source perspective: positive values mean ‘acquisition’ in the old situation. In the N11/N12, positive values (not settled) are regarded as ‘feed-in’. This means that the N11/N12 appears to have switched compared to the grid-to-grid E66.

This switch could lead to confusion and disputes. In any case, it is important to implement the new situation and to coordinate matters with the concerned grid operators and metering responsible party.

Terug naar overig nieuws