Efficient IT Support for Energy Market Processes

2. Teknik- og implementeringsgruppen Møde 28. februar 2019

4. medlemmer af Ti 2019

5. Medlemmer af TI • Formålet med gruppen er at sikre en effektiv it-understøttelse af eksisterende og fremtidige markedsprocesser på tværs af elmarkedet • Medlemmer af TI-gruppen udpeges af Energinet DataHub. For Energinet DataHub er det vigtigt, at udpegede medlemmer – i kraft af deres kompetencer – kan repræsentere bredt og se ud over egne interesser, sådan at løsninger implementeres til størst mulig gavn for helheden. • Forventningen er, at medlemmer af TI kan afse 2-3 dage hvert kvartal til arbejdet i TI – omfattende både forberedelse, mødedeltagelse og gennemlæsning af referat.

6. Medlemmer af TI - fortsat • Et medlem er personligt udpeget, og medlemskabet kan således ikke overdrages til anden repræsentant fra medlemmets selskab (koncern), ligesom det ikke er muligt at deltage i TI´s møder med suppleant. • Da Energinet DataHub ønsker at sikre en bred repræsentation fra branchen, forbeholder Energinet DataHub sig ret til, i fald et medlem skifter ansættelse til en koncern som i forvejen er repræsenteret i TI, at tilbagekalde udpegningen af den ene af koncernens repræsentanter. • Energinet DataHub vil ultimo hvert kalenderår tage stilling til, hvorvidt udtrådte medlemmer skal erstattes med repræsentant fra den kategori, hvorfra medlemmet er udtrådt.

7. TI opgaver • Udarbejde forslag til ændringer i it-understøttelsen af markedsprocesser, som kan medvirke til effektiviseringer eller reduktion af fejl • Udarbejde forslag til it-understøttelse af nye markedsprocesser • Drøfte og foreslå ændringer i BRS- og RSM-dokumenterne • Drøfte planer og tidsfrister for implementering af systemændringer • Sikre fælles regler for test • TI er et samarbejdsfora, og det har ikke nogen beslutningskompetence

8. Møder og materiale • Vi har planlagt 4 ordinære møder i 2019 • Energinet udsender dagsorden pba input fra såvel deltagere som Dialogforum • Dagsorden udsendes senest 1 uge inden mødet – vi vil stræbe mod 2 uger før • Efter hvert møde udarbejder Energinet DataHub referat af møder – målet er medlemmerne har dette senest 1 uge efter mødets afholdelse • Medlemmerne har en uge til kommentering af referat • Referat og præsentation vil efter kommentering blive lagt på Energinets hjemmeside. • Indstillinger og arbejdsmateriale til TI medlemmer offentliggøres ikke!

9. Datahub – program 2019 • For 2019 er planlagt funktionsreleases i februar, april, juni, september og november • Pipeline er mere end fuld – følgende udviklingsopgaver er pt. prioriteret: • Fuld Flex for et netområde – herunder at nettabsberegning timeopgøres • Implementering af struktur for Reaktiv Energi – herunder rykning for manglende data • Opdatering af Jaspersoft som er grundlag for dataudtræk/rapporter • NTG 6 med anden opgørelsesdato end 1/1 • Skemaændringer • Ny aktørrolle til ENS • E-sett

11. Agenda • Formål og indhold • Overordnede milepæle • Status Ti-møde 28. februar 2019

12. 1. Formål og indhold • Energinets succeskriterier for det kommende Eloverblik og Tredjepartsadgang ligger indenfor disse 3 hovedområder Systemets funktionalitet & performance Systemets visuelle udtryk & brugervenlighed Det understøttende driftssetup hos Energinet • Projektets hovedkomponenter: • 2 portaler: Eloverblik og Tredjepartsadgang • API’er for tredjeparter og kunder • Bagvedliggende system og database Ti-møde 28. februar 2019

13. 2. Overordnede milepæle i projektet • Detaljeret idriftsættelsesplan er ved at blive udarbejdet. • Nedenfor ses forventede planlagte eksterne milepæle i projektet. Nedlukning for fuldmagtsgivning i eksisterende systemer – for migrering Varsling af registrerede tredjeparter om IT-ændringer i det tekniske interface Test af API’er og autentifikation i testmiljø kan påbegyndes Idriftsættelse af nyt Eloverblik og Tredjepartsadgang Trykprøvning af skærmbilleder i projektets referencegruppe Ti-møde 28. februar 2019

14. 3. Status • Projektaktiviteter hos Energinet netop nu • Beskrivelse og udvikling af funktionalitet • Bl.a. login- og søgefunktionalitet samt tekniske API’er • Varsling til tredjeparter om IT-ændringer • Ændringer i API’er • Planlagte milepæle i tidsplanen • Brugervenlighed og design • Mockups på skærmbilleder og processer er udarbejdet Mockup på et kommende skærmbillede Ti-møde 28. februar 2019

16. Serielle målere • Energinet, Dansk Energi og Intelligent Energi samarbejder om at identificere muligheder for håndtering af målinger. • Projektet varetages i MSU • Der kigges på tekniske løsninger og regler • Der kigges på et pilotprojekt indenfor eksisterende markeds- og DataHub-rammer • Definitionen aggregator indføres i 2019 i forskrifterne • Endeligt indføres modellen som defineret i Clean Energy Package

18. Nettabsmålepunkt ved fuld Flex • Opmærksomheds punkt: • Når et område er overgået til fuld flex og har markering herfor, beregnes det timeopgjorte nettab og dette udsendes til såvel elleverandør som netvirksomhed. • Bemærk netvirksomhed skal være i stand til at modtage disse timedata.

20. BRS og RSM guider • Punkt 5.1 stamdata – spørgsmål til betydning af: Kun for forbrugsmålepunkter og nettabskorrektion (D13) Hvis målepunkt i nettoafregningsgruppe 1 eller 2 skal målepunkt være time eller flex afregnet ? • Svar: Jf. aftalte valideringer for NTG gælder at E17 i NTG 1 og NTG ikke må være skabelon. Nettabskorrektionen D13 beregnes pr. time • Punkt 6.3.4 – spørgsmål til start eller stop dato – her tilføjet D15 • Svar: Det er helt korrekt en fejl – der er ikke dato felt på D15 • Punkt 11.1.1 – spørgsmål hvorfor nævnes skift fra NTG 2 til 6 • Svar: Det er en fejl, og tekst slettes – der kommer ikke til at ske skift til NTG 6 fra NTG 2. • Punkt 11.1.1 – spørgsmål ny beregning ved nyt forventet årsforbrug på E17. • Svar: Det er en fejl – nyt EYC på E17 trigger ikke en ny beregning

22. ProjektSkemaændringer - Indhold • 2. Kvalitet på tællerstande • Forslag: • Der introduceres et nyt felt til håndtering af tællerstand status. Feltet vil være tilsvarende kvantum status, og kan indeholde en af koderne målt eller estimeret fra kodelisten • Ændring: • For det nye felt tællerstand status vil det kun være koderne 56 (Estimated/skønnet) og E01 (As read/Målt), som er tilladt. • Der udarbejdes en validering, som hindrer anvendelse af øvrige koder.

23. ProjektSkemaændringer - Indhold • 3. Branchekoder - Lukket

24. ProjektSkemaændringer - Indhold • 4. Stamdatafelt på målepunkt til at angive anlægsteknologi • Forslag: • Der oprettes et nyt felt som part af målepunkts stamdata til at beskrive, hvilke anlægs teknologi der er anvendt til at lave elektricitet på målepunktet. • En kodeliste vil blive anvendt til at beskrive teknologien. Eksempler af indholdet kan være solceller, vind eller biogas. • Ændring: • Der introduceres et nyt felt til håndtering af anlægsteknologi, hvor anlægsteknologi angives som en kode. • Da der forventes oprettet flere koder, end der skal anvendes fra start af, udarbejdes en validering, der tjekker at kun korrekte koder anvendes. • Anlægsteknologi skal være obligatorisk for produktionsmålepunkter (E18) og forbrugsmålepunkter (E17), hvor nettoafregningsgruppe <> 0.

25. ProjektSkemaændringer - Indhold • 5. Ny kode til tællerstande på flex målepunkter ved rykning • Forslag: • I forskrift D1: Afregningsmåling angives det, at der skal indsendes tællerstand månedligt for et flexafregnet målepunkt. Det gør at der også skal indføres en rykkerprocedure for manglende indsendelser. • Der introduceres en ny årsagskode til at angive rykning af manglende indsendelse af tællerstande på flex målepunkter • Ændring: • Årsagskode (BusinessReasonCode) D24 vil blive anvendt ved rykning af tællerstande. • Tællerstande for flex målepunkter skal sendes 1 gang månedligt (Dato i meddelelse angives i UTC tid i meddelelse som første dag i måned kl. 00, ex. 2018-10-24T22:00:00Z) og hvis ingen tællerstand modtages inden udløb af tidsfrist, vil DataHub generere og udsende en rykker for manglende tællerstand.

26. ProjektSkemaændringer - Indhold • 6. Ny årsagskode til Merge (netområdesammenlægning) • Forslag: • I forbindelse med sammenlægning af netområder har det været et ønske, at der kunne komme en særskilt årsagskode på de målepunkts stamdata, der udsendes i den forbindelse. • Ændring: • Årsagskode (BusinessReasonCode) D16 vil blive anvendt ved udsendelse af målepunktsstamdata i forbindelse med en netområdesammenlægning.

27. ProjektSkemaændringer - Indhold • 7. BRS-005: Anmodning om stamdata • Forslag: • Der er besluttet at udvide søgemulighederne i anmodning om stamdata, således det vil være muligt at søge på en dato eller en periode. Desuden skal det være muligt at angive om stamdata for child målepunkter skal medtages. Ændringen er bl.a. foranlediget af, at der ved HTX-rettelser ikke bliver udsendt meddelelser med stamdataændringer. Denne ændring gør det muligt at fremsøge disse stamdata. • Ændring: • Til håndtering af dato- og intervalsøgning søgning indføres to nye felter (start- og slutdato). Desuden indføres et felt til angivelse af om stamdata på child målepunkter skal medsendes.

28. ProjektSkemaændringer - Indhold • 8. Hemmelig adresse • Forslag: • Når en person har fået registreret navne- og adressebeskyttelse (hemmelig adresse), gælder beskyttelsen som udgangspunkt for et år - også selvom man flytter adresse. Hvis man efter perioden ønsker at få adressebeskyttelsen forlænget, skal der ansøges igen på Borger.dk eller på kommunens hjemmeside. Det er eget ansvar at huske, at ansøge om forlængelse af Beskyttet. • Der etableres et nyt felt, der angiver om navn og adresse er hemmelig. • Hvis hemmelig adresse er angivet, vil det kun nuværende elleverandør og netvirksomhed (samt speciel brugerrolle ved Energinet), der kan se navn på person. • Ændring: • Der etableres et nyt felt for kundenavne og begge kontaktinformationer (i alt 3 felter) til at angive om navn og adresse er hemmelig. • Bemærk, at det i princippet er navne der er hemmelige. Søgning på adresse er muligt, men navne vil for kontakt- og kundenavne være blanke. • Vær opmærksom på at markering af hemmelig adresse gælder for begge kundenavne. • At hemmelig adresse er angivet betyder, at attributter med navne kun fremsendes til nuværende elleverandør og netvirksomhed.

29. ProjektSkemaændringer - Indhold • 9. Identisk med MP • Forslag: • ”Identisk med MP” blev introduceret for at gøre det muligt for systemer at formindske størrelse på xml meddelelser i forbindelse med udveksling af stamdata, men har ikke virket efter hensigten. Desuden er der et ønske om at e-mail og telefonnumre skal medsendes, hvilket ikke er muligt når ”Identisk med MP” er sat. • Feltet ”Identisk med MP” skal fjernes fra kundedata kontaktinformation, således at elleverandøren skal tage aktivt stilling til hvilke navne og adresser, der skal medtages. • Ændring: • Feltet ”Identisk med MP” skal fjernes fra systemet – både xml meddelelser, GUI og database. • Fjernelse ”Identisk med MP” vil efterlade kontaktadresser uden information, ved fremtidige kunde stamdata opdateringer vil disse blive opdateret, idet begge kontaktinformationer er obligatoriske.

30. ProjektSkemaændringer - Indhold • 10. Antal kontaktadresser • Forslag: • Dialogforum og TI har vedtaget at skære antal af kontaktadresser fra 4 til 2, således der fremover kun vil være en teknisk og en juridisk adresse. • De nuværende 4 kontakt adresser skal reduceres til 2. • I fremtiden vil kontaktadresser være obligatoriske og elleverandør er ansvarlig for kontaktinformation. • Ændring: • Koder og indhold for D01 (afbryderkort) og D04 (adresse 4) vil være de fortsættende koder for kontaktinfo. Navnene er ændret til teknisk adresse og juridisk adresse. • Indhold på nuværende indhold af kontaktinformation for typerne D02 og D03 skal slettes ved ikrafttrædelse (navne er rettet til ”reserved for later”).

31. ProjektSkemaændringer - Indhold • 11. BRS-046: Fremsendelse af kontaktadresser fra netvirksomhed • Forslag: • Der har været en del udfordringer for netvirksomhederne med at få de korrekte kontaktinformationer registreret på et målepunkt og holde dem ajourført. Ved netvirksomhedens anvendelse af BRS-046 til at fremsende forslag, er der flere elleverandører, som ikke reagerer på de modtagne forslag. For at forbedre kvaliteten på kontaktinformation er der foreslået forskellige tiltag, som bl.a. at samle kontaktinformationen i to adresser en teknisk og en juridisk. • En netvirksomhed må kun fremsende forslag til kontaktinformation på den tekniske adresse. • Ændring: • Kun forslag på kontaktinformation for den teknisk adresse (D01) er tilladt.

32. ProjektSkemaændringer - Indhold • 12. Proces variant • Forslag: • Proces variant er en attribut, der anvendes internt i DataHub ved refiksering -og korrektionsafregningskørslerne, hvor den fortæller, hvilken variant (1. refiksering, 2. refiksering, 3. refiksering, 1. korrektionsafregning eller endelig korrektionsafregning), vi afvikler kørslen for. • Attributten Proces variant tilføjes til skemaer, således den kan inkluderes i anmodninger og fremsendelse af beregnede energitidsserier og aggregering af engrosydelser. Det skal desuden gøres muligt at anvende den i forbindelse med anmodning om beregnede energitidsserier og ved anmodning om aggregerede abonnementer, gebyrer og tariffer. • Ændring: • I skemaerne tilføjes attributten Proces variant, der angives som en kode. • Kodeliste ProcessVariantCode vil indeholde 10 koder, hvoraf kun de 3 første koder vil blive anvendt p.t. • Ved forespørgsler skal attributten Proces variant også kunne anvendes.

33. ProjektSkemaændringer - Indhold • 13. BRS-039: Anmodning om serviceydelser hos netvirksomheden. • Forslag: • Der har været flere forslag til forbedring af denne proces. Enkelte forbedringer er allerede på vej i DataHub, fx at processen lukkes med besked, hvis elleverandør mister målepunkt. • I forbindelse med den forstående skemaændring gennemføres to nye tiltag - et bemærkningsfelt og mulighed for at annullere en anmodning. • Ændring: • Der foretages følgende ændringer i anmodning om serviceydelser: • Ændring A: Feltet bemærkning skal tilføjes til relevante skemaer og system. Bemærkning skal kunne anvendes af både elleverandør og netvirksomhed. Det vil sige både i anmodning og svar. Feltet skal også være tilgængelig i forbindelse med BRS-002: Leveranceophør. Dette betyder, at netvirksomheden enten kan tilføje til elleverandørens bemærkning eller overskrive teksten.Anvendelse af bemærkningsfelt skal ske i henhold til persondataforordningen og aktørerne er ansvarlig for indholdet.DataHub vil slette indhold jævnfør beskrivelse i aktøraftalen. • Ændring B: Der skal etableres en proces for annullering af en anmodning. • Ændringerne skal kunne foretages gennem både B2B og i GUI.

34. ProjektSkemaændringer - Indhold • 14. Generel annulleringsproces (RSM-beskrivelser) • Forslag: • En del aktører har udtrykt ønsket om, at flere og flere processer kan annulleres. • I stedet for nye RSM’er til at håndtere de enkelte annulleringer som hidtidig, vil der blive lavet en generel annullerings flow baseret på en standard fra ebIX. • Ændring: • Der laves 2 nye RSM’er (RSM-024 og RSM-025) til håndtering af annulleringer m.m. • RSM’erne bliver introduceret i BRS-039 i forbindelse med tilføjelse af annulleringsrutine i denne proces og i BRS-040: Skift af balanceansvarlig aktør.

35. ProjektSkemaændringer - Indhold • 15. Ny rolle i forbindelse med Energistyrelsen • Forslag: • I forbindelse med udfasning af Panda og overflytning af ansvar til Energistyrelsen skal der findes en løsning, således at Energistyrelsen stadig kan få adgang til de data, de har behov for. • Det er ikke fuldt afklaret, hvad der skal fremsendes til Energistyrelsen, men i forskrift D1 er angivet at måledata på produktionsmålepunkter skal sendes. Ændringen har ingen betydning for øvrige aktør. • Ændring: • Der tilføjes en ny rolle til kodelisten BusinessRoleCode, som skal anvendes til udsendelse af data til Energistyrelse, og til eventuel adgang til Markedsportalen. • Måledata fra målepunkter af typen E18, D01 og D04, samt ca. 200-300 E17 målepunkter skal kunne fremsendes.

36. ProjektSkemaændringer - Indhold • 16. Nye koder til senere brug • Forslag: • I forbindelse med nye tiltag og ændringer er der ofte behov for nye koder i DataHub. Dette kræver for nuværende altid skemaændringer, hvilket er en tung/omstændig proces, som kræver ændringer hos alle systemer. Derfor oprettes en række nye koder i relevante kodelister til senere brug. • Ændring: • Koderne D46 til D60 tilføjes til (de mange) skemaer

37. ProjektSkemaændringer - Indhold • 17. Adresse format • Forslag: • Ifølge forskrift I skal vi ved udveksling af adresse information følge Dansk Adresse Register • (DAR). • DataHub skal ændres, således at standard i DAR følges ved angivelser af adresseinformationer. • Ændring: • Der er udarbejdet en liste (i notatet), der angiver den fremtidige adresse struktur i DataHub – både installationsadresse og kontaktadresser.

38. ProjektSkemaændringer - Indhold • 18. BRS-001: Leverandør skifte med 24 timers varsel • Forslag: • EU har i vinterpakken lagt op til at frist for leverandørskifte skal nedsættes. Forslaget har været diskuteret i TI og Dialogforum. Der ligger også et forslag til en forskrifts ændring. • Der introduceres en ny årsagskode til at angive påmindelse om manglende indsendelse af stamdata til elleverandør i forbindelse med BRS-001. Koden implementeres ikke i processen før ændring af BRS-001 gennemføres – med andre ord: DataHub forberedes til en kommende ændring på leverandørskifte processen. • Ændring: • Årsagskode (BusinessReasonCode) D23 vil blive anvendt ved påmindelse om manglende stamdataindsendelse. I EventCode anvendes kode for den proces, som påmindes om, f.eks. E03 for leverandørskifte. • Der sendes kun en påmindelse i modsætning til den normale rykker procedure. • Der skal også åbnes for at elleverandøren kan modtage en RSM-018 Fremsend rykkerlog.

39. ProjektSkemaændringer - Indhold • 19. Proces ID/ Transaktions ID • Forslaget om at introducere et proces ID i forretningsprocesser blev lukket, da en fuld gennemførelse ville kræve en omfattende systemudvikling. • Der blev fremsat et alternativ forslag om at anvende reference til transaktions ID til identificerer den oprindelige proces med. Forslaget kan gennemføres ved at udskifte RSM-004 med RSM-025 meddelelser. • Dette forslag vil ikke flere kræve flere skemaændringer, men da et større analysearbejde skal laves, skal det overvejes om der er tid til at implementere dette i oktober 2019. Efter en intern diskussion hos Energinet var konklusionen, at det efter Energinets opfattelse ikke kan færdiggøres under nuværende projekt. Men da en sådan ændring ikke vil kræve skemaændringer kun systemændringer hos DataHub og aktører, kan en eventuel ændring gennemføres, når der råderum til en dette.

40. ProjektSkemaændringer - Indhold • 20. Fjern IgnorerObligatoriskGrænse • Forslag: • IgnorerObligatoriskGrænse blev introduceret for at gøre det nemmere at kontrollere andelstal for Energinet og netvirksomhederne. IgnorerObligatoriskGrænse bliver ikke altid anvendt efter intentionerne og da beslutning om skift af skabelonafregnede målepunkter til flex er færdiggennemført ved udgang af 2020 er behovet for IgnorerObligatoriskGrænse ikke til stede mere. • Ændring: • Feltet IgnorerObligatoriskGrænse fjernes fra systemet – både xml meddelelser, GUI og database. • Feltet vil også blive fjernet fra DataHub database ved ikrafttrædelse.

41. ProjektSkemaændringer - Indhold • 21. Skift af balance ansvarligaktør for et produktionsmålepunkt • Forslag: • Der har været en interesse for at kunne håndtere skift af produktionsbalanceansvarlig aktør via B2B meddelelser. TI har derfor accepteret en udvidelse til BRS-040 således dette bliver muligt. • Ændring: • Der udarbejdes en ny forretningsproces til at håndtere skift af produktions balanceansvarlig aktør på et målepunkt.

42. ProjektSkemaændringer - Indhold • 22. Anvendelse af koderne 36 og D01 for kvalitet i forbindelse med måledata • Forslag: • TI har vedtaget at fjerne muligheden for at anvende kvalitetskoden korrektion i forbindelse med måledata. • Mulighed for anvendelse af korrektion (36) fjernes ved måledata ved hjælp af en validering. • Der åbnes samtidig op for anvendelse af koden beregnet (D01). • Ændring: • Der laves en validering, der forhindrer anvendelse af kvalitetskode 36 ved indsendelse af måledata. • DataHub ændres således der ikke udsendes med koden. For beregnede værdier vil D01 blive anvendt. Det betyder bl.a. kvalitetskode på udsendelse af elvarme (D14) ændres til D01, dette vil også omfatte D15 og D04 målepunktstyper. • I GUI fjernes mulighed for at anvende kode 36 (Korrektion) helt.

44. Nye skemaer - Testmiljøer IT systemtest (Pre03 ) IT systemtest (Pre03 ) Data = Syntetiske IT-System test (Pre03) Data = Prod + Syntetiske IT-System test (Pre##) Temporær Data = Syntetiske Ingen Elvarme eller Beregninger Aktør test (Pre04) Opgraderes til Ny version Aktør test (Pre04) Data = Prod + Syntetiske Aktør test (Pre04)

45. Nye skemaer - Test • IT-leverandører • Aktører • Overvågning • IT-leverandører skal gennemføre begrænset antal testscenarier • Ingen krav om gennemførelse af test • Energinet vil overvåge testmiljøer og kontakte IT-leverandører og aktører, hvis det findes nødvendigt

46. Nye skemaer – test Data - Grundlag • IT-Systemtest • (PreXX) • Aktørtest • (Pre04) • Syntetiske data • Kontrol mod produktion • Undgå anonymisering • Anonymiserede produktions data • Cyklus følger releases • Ny overførsel fra produktion planlægges til 2. halvår 2019

48. Flexkonvertering af gruppe 6 – hvornår? • DataHubskal understøtte flexafregning af nettoafregningsgruppe 6 med løbende årsopgørelsestidspunkt – dog altid den 1. i måneden. • Planlagte ændringer • BRS-006: Fremsendelse af stamdata • BRS-012: Skift af afregningsform Juni 2019 OBS! 38.838 anlæg har årsopgørelsesdato forskellig fra den 1. i en given måned. Netvirksomhederneskal allerede nu sikre, at disse anlæg har en årsopgørelsesdato, der falder den 1. i måneden.

49. Planlagte ændringer i DataHub

50. Flexafregning og elvarme – hvad så? • Når et målepunkt i nettoafregningsgruppe 6 er konverteret til flexafregning vil en ændring i afgiftstilknytning udløse en aperiodisk opgørelse. Forbrugeren afregnes fuld elafgift af evt. nettoforbrug Forbrugeren afregnes reduceret elafgift af evt. nettoforbrug Standardopsætning af målepunkt inkl. tilknytning af EA-001 på D15 Markering for elvarme og opsætning af D14-målepunkt, inkl. tilknytning af EA-002 på D15