ITX

Indholdsfortegnelse

Ændringslog

Version

Dato

Ændringer siden sidste version

Version

Dato

Ændringer siden sidste version

4.2.2

(aktuel version)

21-11-2023

Ændringslog er tilføjet direkte på siden som erstatning for den tidligere samlede ændringslog for hele BRS-dokumentet.

4.2.1

 

30-06-2022

Indholdet af denne side stemmer overens med indholdet af kapitel 9 fra det tidligere BRS-dokument “Forretningsprocesser for det danske elmarked til DataHub 3 (EDI guide - BRS)”, version 4.2.

Dog er nedennævnte rettelser foretaget:

  • Nummerering af overskrifter/afsnit er fjernet, da dette ikke understøttes som standard i det nye digitale format.

  • Referencer til de tidligere overskrifts-/afsnitsnumre er opdateret, inkl. tilføjelse af direkte links.

  • Indholdsfortegnelse er tilføjet.

Introduktion

I det følgende findes en overordnet gennemgang af procesmotoren i DataHub, som kaldes ITX. ITX står for Interacting Transaction eXecution og har flere funktioner. Den primære opgave er at afvikle processer korrekt i forhold til hinanden, men der håndteres også andre ting, som modtagelse og annullering af processer. 

Forståelsen for ITX er vigtig, da det er ITX, som annullerer en proces, hvis den har lavere rang end en anden proces eller hvis et fremtidigt leverandørskift skal annulleres på grund af en tilflytning. For eksakte regler henvises til det regneark indeholdende ITX-regler, som findes på Energinets hjemmeside sammen med BRS-guiden.

En proces er i denne sammenhæng en BRS. Processerne opdeles overordnet i to typer: 

  1. Straks-processer: Disse processer behandles og lagres i DataHub øjeblikkeligt. Dermed vil de data, som medsendes i sådan en proces blive kendt overfor andre processer. Et eksempel er BRS-007 - Nedlæggelse af målepunkt med en skæringsdato i fremtiden. Hvis man efterfølgende laver en BRS-009 - Tilflytning med en senere skæringsdato, vil denne blive afvist fordi DataHub ved, at målepunktet er nedlagt på en given dato i fremtiden.

  2. Afventende processer: Disse processer sættes i en kø og er, så længe de står i køen, uden betydning for øvrige processer. Kun afsenderen kan arbejde videre med processen, så længe den står i køen. På et foruddefineret tidspunkt før skæringsdatoen (oftest ved annulleringsfristens udløb), sker der en prioritering og behandling af processerne i køen. På dette tidspunkt kan det ske, at en proces som hidtil har været godkendt, bliver annulleret grundet en anden proces. Processer i kategorien Afventende processer er:

ITX styrer prioriteringen og afviklingen af processerne i forhold til hinanden og på grund af det store antal af processer, giver det et meget stort antal kombinationsmuligheder. Til at beskrive disse forhold er der lavet en række regeltabeller, som findes i et særskilt regelregneark. Nedenstående er en kort beskrivelse af regeltabellerne

  • Tabel 1.x beskriver de indbyrdes afvisningsregler mellem processer ved modtagelsen af en proces.

  • Tabel 2 beskriver prioriteringen af afviklingen, hvis to processer ligger til samme skæringsdato.

  • Tabel 3.x beskriver hvilke andre processer, som skal annulleres grundet den eksekverede proces, som blev valgt i tabel 2 og hvordan annulleringen meddeles til aktøren.

  • Tabel 4.x beskriver, hvilke fremtidige elleverandører, der får hvilke informationer som følge af den eksekverede proces, som blev valgt i tabel 2. Beskeder med faktisk skæringsdato før leverancestart indeholder skæringsdato svarende til leverancestart. Den senest modtagne besked indeholder samtlige opdateringer forud for leverancestart.

  • Tabel 5.x beskriver hvilke tilpasninger, der skal ske i den eksekverede proces og/eller andre processer på grund af den eksekverede proces.

  • Tabel 6 beskriver, hvordan data skal håndteres i eventuelle senere processer i forhold til den eksekverede proces.

 

Nedenstående figur viser et overblik over den samlede ITX-funktionalitet:

Numrene i figuren modsvarer de regeltabeller, som er nævnt ovenfor. Det skal bemærkes, at en proces, som er kommet i kø-systemet, kan komme ud af køen på to måder. Enten ved at den er eksekveret og lagret i DataHub som en gennemført proces, eller ved at den er annulleret. En annulleret proces vil altid fremgå i DataHub i transaktionslisten som annulleret. De eksakte regler for de forskellige tabeller fremgår af ITX-regel regnearket. 

Særligt for eksekverede processer

Det kan ske, at der som en del af eksekveret proces medfølger en RSM-004 med stop af leverance med det samme. Dette skyldes, at der ligger en kendt fremtidig hændelse i forhold til den indsendte skæringsdato. For eksempel ved indsendelse af et leverandørskift til om 10 dage og der ligger en nedlæg målepunkt senere, så vil man sammen med leverandørskiftet modtage en RSM-004 for nedlukningen af målepunktet i samme proces.

Særligt for ITX-annullerede processer

En proces kan blive annulleret via processen selv eller via ITX. Ved annullering udsendes RSM-004 med en årsagskode. Årsagskoden fremgår af ITX regnearket og modsvarer typisk den proces som annullerer processen jævnfør BRS-Guiden. Hvis der i ITX regnearket står koden ’X99’, så betyder det, at DataHub ikke meddeler annulleringen til nogen aktører.