skip to Main Content

Uit de Gebruikersacceptatietest (GAT) voor de Themarelease 2021 (TR2021) – Tranche 1 Allocatie 2.0 zijn 4 onderwerpen naar voren gekomen die hebben geleid tot decentrale bevindingen bij meerdere marktpartijen. We raden je aan deze veelvoorkomende bevindingen in je eigen systeem te controleren. Doe dit ruim vóór de livegang van zaterdag 19 maart zodat dit de transitie van jouw organisatie niet in de weg staat.



Timestamp
Gebleken is dat de timestamp vaak het onjuiste format heeft. Hieronder staat welke notatie je moet gebruiken. Zorg ervoor dat de start- en einddatum van de periode waarover de meetgegevens worden aangeleverd in UTC zijn, conform de notatie: YYYY-MM-DDThh:mm:ssZ:

  • Voorbeeld start- en einddatum kalenderdag elektriciteit (wintertijd): 2020-02-08T23:00:00Z / 2020-02-09T23:00:00Z;
  • Voorbeeld start- en einddatum gasdag (wintertijd): 2020-02-08T05:00:00Z / 2020-02-09T05:00:00Z;
  • Voorbeeld start- en einddatum kalenderdag elektriciteit (zomertijd): 2020-06-08T22:00:00Z / 2020-06-09T22:00:00Z.
  • Voorbeeld start- en einddatum gasdag (zomertijd): 2020-06-08T04:00:00Z / 2020-06-09T04:00:00Z.

Deze voorbeelden staan in de servicebeschrijvingen van TR2021 – Tranche 1.

Daarnaast hebben we de datum/tijd wanneer het bericht is opgesteld, de zogeheten CreationTimestamp in de EDSN BusinessDocumentHeader. Notatie van deze datum/tijd is als volgt: YYYY-MM-DDThh:mm:ssTZD. De TZD is de Time Zone Designator en moet Z of +hh:mm of -hh:mm zijn.

Het gebruik van fractie van een seconde valt binnen de W3C DTF Note ISO 8601-specificatie. Maar in de sector hanteren wij: YYYY-MM-DDThh:mm:ssTZD (dus zonder die decimalen die de fracties van de seconden representeren). Dat is geen aanbeveling, maar een verplichting. In de NEDU/EDSN Ontwerpkeuzes kun je diverse voorbeelden vinden.

Correlation ID
Voor de Correlation ID wordt in de ALV NEDU van 9 maart een Request for Change (RFC) aangeboden. Het is RFC A2.0.1 ‘Gebruik Correlation ID’. De RFC zal per 9 maart worden vastgesteld en zal bij een happy flow van de livegang van Tranche 1 direct daarna van kracht zijn. Je moet de RFC voor livegang van Tranche 2 hebben geïmplementeerd. In de RFC wordt afgedwongen om beide ID’s gelijk te houden. Advies is dan ook tot die tijd: maak het jezelf niet te moeilijk. Als het mogelijk is, zorg je ervoor dat de ID’s gelijk zijn.

Er zijn al enkele meetverantwoordelijken en balance responsible parties (BRP’s, programmaverantwoordelijken) die daar gehoor aan geven en bij T1 de ID’s gelijk houden.

Het blijft echter een advies, dus afwijkende ID’s blijven mogelijk (tot de RFC in werking treedt na 19 maart). Na de succesvolle livegang van Tranche 2 zul je de ID sowieso gelijk moeten maken.

ProcesTypeID
De ProcesTypeID-berichten voldoen niet aan de XSD omdat het procestype N90 in de EDSNDocumentHeader ontbreekt. Wees hier alert op en pas het waar nodig is aan conform de Business Service Uitwisseling herzieningsverzoeken. Hieronder staat de sectie uit deze Business Service waarin dit wordt vermeld:

Voor Allocatie 2.0 moeten de volgende velden gevuld worden in de EDSN BusinessDocumentHeader:

  • MessageID (verplicht, wordt afgedwongen door de XSD);
  • CreationTimestamp (verplicht, wordt afgedwongen door de XSD);
  • ReceiverID (verplicht, wordt afgedwongen door de XSD);
  • SenderID (verplicht, wordt afgedwongen door de XSD);
  • ProcessTypeID (verplicht, is een procesafspraak voor Allocatie 2.0 (zie desbetreffende servicebeschrijving), wordt niet afgedwongen door de XSD);
  • CorrelationID (optioneel, alleen indien de sturende partij een ‘gevulde’ CorrelationID opneemt in het bericht dan dient de ontvangende partij dit CorrelationID in het antwoordbericht te retourneren).

Het ontbreken van een ProcessTypeID betekent dat het bericht niet voldoet aan de afspraken over het verplichte gebruik van dit veld voor de Allocatie 2.0-berichten.

Sink en Source
De voorgestelde werkwijze is om de richtingen in de N11 en N12 per koppelpunt af te stemmen met de 2 betrokken netbeheerders en de meetverantwoordelijke.

In de afgelopen weken zijn wij onder andere bezig geweest met het testen van de N11/N12-berichten. Dit gaat om net-op-net-aansluitingen, daarbij wordt met Sink en Source de netgebieden aangegeven waartussen de aansluiting zich bevindt. We hebben geconstateerd dat er onduidelijkheid kan ontstaan over hoe de energiestroomrichtingen in het bericht horen. De Business Service is hier wel duidelijk in, hieronder vind je een toelichting aan de hand van de oude en de nieuwe situatie:

Oude situatie (E66)

  • Als energie van Source naar Sink gaat: positieve waarden in het bericht
  • Als energie van Sink naar Source gaat: negatieve waarden in het bericht

Nieuwe situatie (N11/N12)

  • Als energie van Source naar Sink gaat, wordt dat Afname (A17) in de N11/N12
  • Als energie van Sink naar Source gaat, wordt dat Invoeding (A18) in de N11/N12

De verwarring ontstaat als we kijken naar de huidige richtingen in de reguliere E66:

  • negatief = afname
  • positief = invoeding

Als we kijken vanuit het perspectief van de Source: in de oude situatie betekenen positieve waardes ‘afname’. In de N11/N12 worden de positieve waardes (ongesaldeerd) neergezet als ‘invoeding’. Dit zorgt ervoor dat de N11/N12 gedraaid lijkt te worden ten opzichte van de net-op-net-E66.

Mogelijk dat deze omdraaiing tot verwarring en discussies kan leiden. Belangrijk is in elk geval om de nieuwe situatie te implementeren en dit af te stemmen met betrokken netbeheerders en meetverantwoordelijke.

Terug naar overig nieuws