Energidata ind i BBR Systemdesign Version 3

Energidata ind i BBR Systemdesign Version 3

Indholdsfortegnelse 1. Indledning... 4 2. Systemarkitektur... 5 3. Use cases - diagram... 7 4. Use cases - primære aktører... 8 4.1 Indberetningsklient... 8 4.2 OIS... 8 4.3 Systemtimer... 8 4.4 EBST/KOMBIT... 8 5. Use cases specifikation... 9 5.1 01 - Indberet energiforbrug... 9 5.2 02 - Forespørg på indlæsningsstatus... 12 5.3 03 - Behandl indberetninger... 15 5.4 04 - Videregiv energiforbrug til OIS... 16 5.5 05 - Indberet hemmelige adresser... 19 5.6 06 - Indberet energiselskaber... 20 6. Informationsmodel... 23 6.1 Indberetningssklient... 23 6.2 Indberetningsrequest... 24 6.3 Indberetning... 24 6.4 Modtagelsesstatus... 24 6.5 Tilstandsstatus... 24 6.6 Statistiskstatus... 24 6.7 Behandlingsstatus... 24 6.8 Behandlingsfejl... 25 6.9 Valideringsfejl... 25 6.10 Tilknytningsfejl... 25 6.11 Energiforbrug... 25 6.12 Afregningsstatus... 25 6.13 Forsyningsart... 26 6.14 Måleenhed... 26 6.15 Energiforsyningsselskab... 26 6.16 BBREntitet (BBR)... 26 6.17 Bruger (BBR)... 26 6.18 Systemopsætning (BBR)... 26 7. Databasemodel... 27 8. Valideringsregler... 28 8.1 Skemavalidering... 28 8.2 Krævede felter og databasekonsistens... 28 9. Snitfladebeskrivelse... 29 9.1 EnergyConsumptionReport... 29 9.2 EnergyConsumptionStatus... 32 9.3 Konfiguration af energiselskaber... 33 9.4 Konfiguration af hemmelige adresser... 34 10. Sikkerhed... 35 10.1 Autorisation... 35 10.2 Ekstern webservice... 35 Version 3.0 Side 2 af 41

10.3 Sikkerhedshensyn... 35 11. Tilknytning af energiforbrugsindberetning til BBR-entitet.... 37 12. Hemmelige adresser... 41 Version 3.0 Side 3 af 41

1. Indledning Dette dokument beskriver systemdesignet for Energidata ind i BBR. Energidata ind i BBR dækker over de udvidelser, som laves i BBR for at opfylde kravspecifikationen: Kravspecifikation Energiforbrugsindberetning 1.5. Dette dokument skal ses som en udvidelse til BBR s systemdokumentation. Endvidere henvises til bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygningsog Boligregistret (BBR) BEK nr 1264 af 16-11-2010. Kapitel 2 giver en overordnet beskrivelse af systemarkitekturen. Kapitel 3, 4 og 5 beskriver de use cases, som systemet understøtter. Disse use cases er identificeret ved en gennemgang af kravspecifikationen. I kapitel 6 er informationsmodellen beskrevet. Modellen er ligeledes et resultat af gennemgangen af kravspecifikationen og viser de identificerede begreber og deres logiske sammenhæng. Kapitel 7 viser de nødvendige tilføjelser til BBR s fysiske datamodel. Kapitel 8 beskriver de valideringer, som foretages, når der indberettes energiforbrug. Kapitel 9 beskriver webservice snitfladen til Energidata ind i BBR. Snitfladen består af to kald: EnergyConsumptionReport og EnergyConsumptionStatus. Kapitel 10 beskriver specielle forhold omkring autentifikation, autorisation og sikkerhedshensyn. I kapitel 11 beskrives algoritmen for at knytte en energiforbrugsindberetning til en BBR entitet i detaljer. Kapitel 12 beskriver, hvordan systemet håndterer hemmeligholdelse af energiforbrug. Version 3.0 Side 4 af 41

2. Systemarkitektur Denne tegning viser den overordnede systemarkitektur for Energidata ind i BBR : Indberetningsklient Internet OWSA model T (SSL) Præsentationsserver Service Gateway (med Energi service) WCF Applikationsserver Service Interface Lag (med Energi service) Service Contract Service Adapter Batch Windows Service (til behandling af energiforbrug) Forretnings Lag (med Energi entiteter) Forretnings Logik Data Access Lag (med Energi entiteter) Data Access Logik Data Version 3.0 Side 5 af 41

En indberetningsklient indberetter energiforbrug gennem BBR s servicegateway, som udvides med en webservice til indberetning af energiforbrug samt forespørgsel på status. Servicegateway en kalder BBR s applikationsserver, hvor serviceinterface lag, forretningslag og databaselag udvides med Energi entiteter. Applikationsserveren opdaterer og forespørger i BBR s database, som ligeledes udvides med BBR Entiteter. De indberettede energiforbrug gemmes midlertidigt, indtil de behandles. På passende tidspunkter initierer en Windows Service behandlingen af de indberettede energiforbrug dvs. validerer dem og knytter dem til passende BBR entiteter (grund, bygning eller enhed). Windows Servicen kan konfigureres til at køre på bestemte tidspunkter (om natten og i weekenden), så behandlingen af energiforbrug ikke belaster svartiderne i BBR Kommune. Det nuværende OIS udtræk udvides til også at indeholde Energidata ind i BBR - entiteter. Version 3.0 Side 6 af 41

3. Use cases - diagram Dette use case diagram viser de use cases, som systemet understøtter. Disse use cases er identificeret ved en gennemgang af kravspecifikationen: I kapitel 5 gives en detaljeret beskrivelse af disse use cases. Version 3.0 Side 7 af 41

4. Use cases - primære aktører 4.1 Indberetningsklient En indberetningsklient er det system, som kalder Energidata ind i BBR for at indberette energiforbrug. En indberetningsklient kan være FIE eller et andet system, som er certificeret til at foretage indberetninger i Energidata ind i BBR. I første omgang understøttes kun FIE som indberetningsklient. 4.2 OIS OIS modtager de indberettede energioplysninger fra Energidata ind i BBR. 4.3 Systemtimer Aktiverer behandlingen af indberetninger på et bestemt tidspunkt samt initierer videregivelse af energiforbrug til OIS sammen med de øvrige BBR oplysninger. 4.4 EBST/KOMBIT Indberetter energiselskaber og hemmelige adresser. Version 3.0 Side 8 af 41

5. Use cases specifikation 5.1 01 - Indberet energiforbrug Prioritet: Høj. Formål: At kunne indberette energiforbrug bestående af en mængde indberetninger til Energidata ind i BBR. Primær aktør: Indberetningsklient. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: En indberetningsklient vil indberette energiforbrug. Involverede forretningsbegreber: Indberetningsklient, Indberetningsrequest, Indberetning, Modtagelsesstatus. Startbetingelser: Energiforbrug er indsendt fra energiselskaber til en indberetningsklient, som har behandlet og valideret energiforbrug. Sluttilstand succes: Energiforbrug er gemt råt I Energidata ind i BBR databasen. Der er endnu ikke foretaget validering, og energiforbrug er endnu ikke knyttet til en BBR entitet. Tilstandsstatus er sat til Venter. Indberetningsklienten leverer en entydig Token, som efterfølgende kan benyttes til use casen 02 Forespørg på Indlæsningsstatus. Sluttilstand fejl: Energiforbrug er ikke gemt, fordi der er opstået en fejl undervejs. Indberetningsklienten får en fejl besked retur. Normalforløb: 0. Indberet energiforbrug Alternative forløb: 1. Indberet energiforbrug fejl ved skemavalidering 2. Indberet energiforbrug fejl ved bruger autorisation 3. Indberet energiforbrug anden systemfejl Version 3.0 Side 9 af 41

Regler: - Frekvens: Spidsbelastning omkring og lige efter 1. marts. Normalforløb: 0. Indberet energiforbrug 0 Primær aktør System A En Indberetningsklient sammensætter et Indberetningsrequest bestående af højst MaxGraense Indberetninger og kalder OIO WebService metoden til at indberette energiforbrug. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer rettigheder. 3. Gemmer Indberetningsrequest og de enkelte Indberetninger råt i databasen. 4. Returnerer ReturnMessage OK og sætter Tilstandsstatus til Venter. C Modtager ReturnMessage OK Alternativt forløb: 1. Indberet energiforbrug fejl ved skemavalidering 1 Primær aktør System A Sammensætter et Indberetningsrequest bestående af højst MaxGraense Indberetninger og kalder OIO WebService metoden til at indberette energiforbrug. B 1. Foretager skemavalidering. Skemavalideringen fejler. 2. Returnerer SoapFault med beskrivelse af skemavalideringsfejlen. C Modtager SoapFault. Retter op på fejlen og sender Indberetningsrequestet igen. Alternativt forløb: 2. Indberet energiforbrug fejl ved bruger autorisation 2 Primær aktør System A Sammensætter et Indberetningsrequest bestående af højst MaxGraense Indberetninger og kalder OIO WebService metoden til at indberette energiforbrug. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer Version 3.0 Side 10 af 41

2 Primær aktør System rettigheder. Brugeren er ikke autoriseret. 3. Returnerer ReturnMessage med oplysning om, at der er opstået en autorisationsfejl. C Modtager ReturnMessage Fejl. Retter op på fejlen og sender Indberetningsreqeustet igen. Alternativt forløb: 3. Indberet energiforbrug anden systemfejl 3 Primær aktør System A Sammensætter et Indberetningsrequest bestående af højst MaxGraense Indberetninger og kalder OIO WebService metoden til at indberette energiforbrug. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer rettigheder. 3. Der opstår en fejl ved gem af Indberetningsrequest og Indberetninger i databasen. 4. Returnerer ReturnMessage med oplysning om, at der er opstået en anden systemfejl. C Modtager ReturnMessage Fejl. Venter et stykke tid og prøver at sende Indberetningsrequestet igen. Version 3.0 Side 11 af 41

5.2 02 - Forespørg på indlæsningsstatus Prioritet: Høj. Formål: At kunne forespørge på indlæsningsstatus (bestående af Tilstandsstatus, Statistiskstatus og Behandlingsstatus) på de indberettede energiforbrug. Primær aktør: Indberetningsklient. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: En indberetningsklient ønsker at forespørge på indlæsningsstatus. Involverede forretningsbegreber: Indberetningsklient, Indberetningsrequest, Indberetning, Tilstandsstatus, Statistiskstatus, Behandlingsstatus. Startbetingelser: Energiforbrug er indberettet fra en indberetningsklient via use casen 01 Indberet energiforbrug. Sluttilstand succes: Indberetningsklienten får en status på forløbet dvs. oplysninger om Tilstandsstatus, Statistiskstatus og Behandlingsstatus på indberetninger i den mængde, som er indberettet via use casen 01 Indberet energiforbrug. Sluttilstand fejl: Der opstår en systemfejl, så indberetningsklienten ikke får indlæsningsstatus retur. Normalforløb: 0. Forespørg på indlæsningsstatus Alternative forløb: 1. Forespørg på indlæsningsstatus fejl ved skemavalidering 2. Forespørg på indlæsningsstatus fejl ved bruger autorisation 3. Forespørg på indlæsningsstatus anden systemfejl Regler: - Version 3.0 Side 12 af 41

Frekvens: - Normalforløb: 0. Forespørg på indlæsningsstatus 0 Primær aktør System A En Indberetningsklient kalder OIO WebService metoden til at forespørge på indlæsningsstatus med det Token, som blev leveret med i et tidligere indberetningskald. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer rettigheder. 3. Returnerer en status bestående af Tilstandsstatus, Statistiskstatus og Behandlingsstatus på et Indberetningsrequest med det angivne Token. Hvis Tilstandsstatus er Venter eller I gang, returneres ikke Behandlingsstatus. C Modtager status på et Indberetningsrequest. Hvis Tilstandsstatus er Venter eller I gang, kalder Indberetningsklienten igen på et senere tidspunkt på det forventede behandlingstidspunkt, som returneres i Tilstandsstatus. Alternativt forløb: 1. Forespørg på indlæsningsstatus fejl ved skemavalidering 1 Primær aktør System A En Indberetningsklient kalder OIO WebService metoden til at forespørge på indlæsningsstatus med det Token, som blev leveret med i et tidligere indberetningskald. B 1. Foretager skemavalidering. Skemavalideringen fejler. 2. Returnerer SoapFault med beskrivelse af skemavalideringsfejlen. C Modtager SoapFault. Retter op på fejlen og kalder igen. Alternativt forløb: 2. Forespørg på indlæsningsstatus fejl ved bruger autorisation 2 Primær aktør System A En Indberetningsklient kalder OIO WebService metoden til at forespørge på indlæsningsstatus med det Token, som Version 3.0 Side 13 af 41

2 Primær aktør System blev leveret med i et tidligere indberetningskald. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer rettigheder. Brugeren er ikke autoriseret. 3. Returnerer ReturnMessage med oplysning om, at der er opstået en autorisationsfejl. C Modtager ReturnMessage Fejl. Retter op på fejlen og kalder igen. Alternativt forløb: 3. Forespørg på indlæsningsstatus anden systemfejl 3 Primær aktør System A En Indberetningsklient kalder OIO WebService metoden til at forespørge på indlæsningsstatus med det Token, som blev leveret med i et tidligere indberetningskald. B 1. Foretager skemavalidering. 2. Autoriserer brugeren og kontrollerer rettigheder. 3. Der opstår en anden systemfejl. 4. Returnerer ReturnMessage med oplysning om, at der er opstået en anden systemfejl. C Modtager ReturnMessage Fejl. Venter et stykke tid og prøver at kalde igen. Version 3.0 Side 14 af 41

5.3 03 - Behandl indberetninger Prioritet: Høj. Formål: At behandle de indberettede energiforbrug dvs. validere dem samt knytte dem til BBR entiteter. Primær aktør: Systemtimer. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: Det er tid til at behandle (validere og tilknytte) de midlertidig gemte indberetninger, som er kommet ind via use casen 01 Indberet energiforbrug. Systemtimer igangsætter behandlingen. Det er muligt at konfigurere de tidspunkter, hvor behandlingen foregår. Involverede forretningsbegreber: Indberetning. Startbetingelser: Der skal være foretaget indberetninger via use casen 01 Indberet energiforbrug. Sluttilstand succes: Alle midlertidig gemte indberetninger er valideret. Hvis en indberetning er valideret ok, bliver energiforbruget gemt og knyttet til en BBR entitet. Indberetningen får status Behandlingsstatus OK. Hvis en indberetning ikke er valideret ok, bliver energiforbruget ikke gemt. Indberetningen får Behandlingsstatus Fejl. Tilstandsstatus (for hele requested) er sat til Færdig. Sluttilstand fejl: Ikke alle midlertidig gemte indberetninger er behandlet. Tilstandsstatus er I gang. Normalforløb: 0. Behandl indberetninger Alternative forløb: 1. Behandl indberetninger anden systemfejl Regler: - Version 3.0 Side 15 af 41

Frekvens: - Normalforløb: 0. Behandl indberetninger 0 Primær aktør System A En systemtimer trigger, at det nu er tid til at behandle indberetninger. B 1. Alle Indberetningsrequest s med status Venter eller I gang gennemløbes. 2. Alle Indberetninger uden Behandlingsstatus i disse requests behandles efter Modtagelsestidspunkt. Indberetningerne valideres i henhold til fastlagte valideringsregler, og den BBR entitet, som indberetningen skal knyttes til i henhold til de fastlagte regler, fremfindes. 3. Hvis en indberetning kan validere, og en BBR entitet kan findes, gemmes Energiforbruget og knyttes til den fundne BBR entitet. Behandlingsstatus sættes til OK. 4. Hvis et Energiforbrug har samme forretningsnøgle som et tidligere indberettet Energiforbrug, gøres det tidligere indberettede Energiforbrug historisk. 5. Hvis en indberetning ikke kan validere, eller en BBR entitet ikke kan findes, oprettes en eller flere Behandlingsfejl (enten Valideringsfejl eller tilknytningsfejl), og Behandlingsstatus sættes til Fejl. 6. Tilstandsstatus for det samlede request sættes til 2/Færdig. Alternativt forløb: 1. Behandl indberetninger anden systemfejl 1 Primær aktør System A En systemtimer trigger, at det nu er tid til at behandle indberetninger. B 1. Der opstår en systemfejl i løbet af gennemløbet af Indberetninger. 2. Tilstandsstatus er uændret dvs. der kan stadig ligge Indberetningsrequests med status Venter og I gang. 5.4 04 - Videregiv energiforbrug til OIS Prioritet: Høj. Version 3.0 Side 16 af 41

Formål: At videregive de indberettede energiforbrug til OIS sammen de øvrige BBR data. Primær aktør: Systemtimer. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: Det er tid til at videregive BBR oplysninger (herunder de indberettede energiforbrug) til OIS. Systemtimer igangsætter behandlingen. Involverede forretningsbegreber: Energiforbrug. Startbetingelser: - Sluttilstand succes: Alle Energiforbrug, som er knyttet til en BBR Entitet, er overført til OIS sammen med øvrige BBR data. Sluttilstand fejl: Der er opstået en fejl ved overførslen, som gør at ingen eller kun en del af de tilknyttede energiforbrug er overført til OIS. Normalforløb: 0. Videregiv energiforbrug til OIS. Alternative forløb: 1. Fejl ved videregivelse af en eller flere energiforbrug til OIS. Regler: - Frekvens: - Normalforløb: 0. Videregiv energiforbrug til OIS 0 Primær aktør System A En systemtimer trigger, at det nu er tid til at åbne udtræksvindue. B Opretter et snapshot af databasen (et konsistens øjebliksbillede). Version 3.0 Side 17 af 41

0 Primær aktør System C En systemtimer trigger, at det nu er tid til at udtrække energi forbrug. D 1. Læser tidspunkt for senest udtræk. 2. Udtrækker data siden sidste udtræk, herunder sker der også følgende: a) Frasorterer energiforbrug på adresser, der skal hemmligholdes. b) Nulstiller felter, hvis den tilhørende entitet er sikkerhedsklassificeret. c) Finder det yngste timestamp i udtrækket. 3. Zipper udtrækket. 4. Flytter den den zipped fil ud på ftp-site, så OIS kan hente udtrækket. 5. Hvis der ingen fejl er i de foregående punkter, gemmes det yngste timestamp som seneste udtrækstidspunkt. E En systemtimer trigger, at det nu er tid til at lukke udtræksvinduet. F Nedlægger database snapshot. Alternativt forløb: 1. Fejl ved videregivelse af en eller flere energiforbrug til OIS 1 Primær aktør System A En systemtimer trigger, at det nu er tid til at udtrække energi forbrug. B 1. Der opstår en systemfejl i løbet af udtræksforløbet. 2. Seneste udtræks tidspunkt er uændret dvs. data vil medtages i næste udtræk. Version 3.0 Side 18 af 41

5.5 05 - Indberet hemmelige adresser Prioritet: Høj. Formål: At kunne indberette de adresser for hvilke, der ikke må videregives energiforbrug. Primær aktør: EBST/KOMBIT. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: EBST laver en liste over de adresser for hvilke, der ikke må videregives energiforbrug. Denne liste afleveres som en csv-fil på BBR s ftp server. Involverede forretningsbegreber: Hemmeligadresse Startbetingelser: - Sluttilstand succes: Alle hemmelige adresser, som er angivet i den afleverede csv-fil er indlæst i Energidata ind i BBR. Sluttilstand fejl: Der er opstået en fejl ved indlæsningen, som gør at ingen eller kun en del af de hemmelige adresser er indlæst i Energidata ind i BBR. Normalforløb: 0. Indberet hemmelige adresser. Alternative forløb: 1. Fejl ved indberetning af en eller flere hemmelige adresser. Regler: - Frekvens: - Version 3.0 Side 19 af 41

Normalforløb: 0. Indberet hemmelige adresser 0 Primær aktør System A Afleverer en csv-fil med samtlige hemmelige adresser på BBR s ftp server og informerer BBR s 2. level support om, at der ligger en ny fil til indlæsning. B 1. Eventuelle eksisterende hemmelige adresser gøres historiske 2. De nye hemmelige adresser indlæses. Alternativt forløb: 1. Fejl ved indberetning af en eller flere hemmelige adresser 1 Primær aktør System A Afleverer en csv-fil med samtlige hemmelige adresser på BBR s ftp server og informerer BBR s 2. level support om, at der ligger en ny fil til indlæsning. B 1. Eventuelle eksisterende hemmelige adresser gøres historiske 2. Der opstår en fejl ved indlæsning af de nye hemmelige adresser. 3. De hemmelige adresser, som tidligere blev gjort historiske, gøres aktive igen. 4. BBR s 2. level support kontakter EBST/KOMBIT og informerer om fejlen. C EBST/KOMBIT fremsender en ny fil. 5.6 06 - Indberet energiselskaber Prioritet: Høj. Formål: At kunne indberette de energiselskaber for hvilke, der må indberettes energiforbrug. Primær aktør: EBST/KOMBIT. Interessenter: EBST har i henhold til Lov nr. 1276 af 16/12-2009 til opgave at modtage energiforbrug fra energiselskaberne. Initiering: EBST laver en liste over de energiselskaber for hvilke, der må indberettes energiforbrug. Denne liste afleveres som en csv-fil på BBR s ftp server. Version 3.0 Side 20 af 41

Involverede forretningsbegreber: Energiforsyningsselskab Startbetingelser: - Sluttilstand succes: Alle energiselskaber, som er angivet i den afleverede csv-fil er indlæst i Energidata ind i BBR. Indlæsningen kan både forårsage oprettelse, rettelse og sletning af energiselskaber. Sletning betyder at et energiselskab gøres historisk. Sluttilstand fejl: Der er opstået en fejl ved indlæsningen, som gør at ingen eller kun en del af energiselskaberne er indlæst i Energidata ind i BBR. Normalforløb: 0. Indberet energiselskaber. Alternative forløb: 1. Fejl ved indberetning af et eller flere energiselskaber. Regler: - Frekvens: - Normalforløb: 0. Indberet energiselskaber 0 Primær aktør System A Afleverer en csv-fil med alle energiselskaber på BBR s ftp server og informerer BBR s 2. level support om, at der ligger en ny fil til indlæsning. B 1. Energiselskaberne indlæses (dvs. oprettes, rettes eller slettes). Energiselskaber, som ikke i forvejen findes i Energidata ind i BBR, oprettes. Energiselskaber, som i forvejen findes i Energidata ind i BBR, rettes. Energiselskaber, som findes i Energidata ind i BBR men ikke er med i den afleverede liste, slettes (dvs. gøres historiske). Alternativt forløb: 1. Fejl ved indberetning af et eller flere energiselskaber 1 Primær aktør System A Afleverer en csv-fil med alle Version 3.0 Side 21 af 41

1 Primær aktør System energiselskaber på BBR s ftp server og informerer BBR s 2. level support om, at der ligger en ny fil til indlæsning. B 1. Der opstår en fejl under indlæsningen. 2. Der rulles tilbage til den tidligere tilstand. 3. BBR s 2. level support kontakter EBST/KOMBIT og informerer om fejlen. C EBST/KOMBIT fremsender en ny fil. Version 3.0 Side 22 af 41

6. Informationsmodel Dette kapitel beskriver informationsmodellen for Energidata ind i BBR. Informationsmodellen er en logisk model, som definerer de identificerede begreber og deres sammenhænge. 6.1 Indberetningssklient En Indberetningsklient er en klient, som kan indberette energiforbrug i BBR. En Indberetningsklient er knyttet til en BBR Bruger. Gennem denne tilknytning Version 3.0 Side 23 af 41

håndteres rettigheder. For at kunne indberette energiforbrug, skal denne Bruger have en speciel rolle. Persist: Ja 6.2 Indberetningsrequest En mængde af Indberetninger, som modtages i et request. MaxGraense angiver det maksimale antal Indberetninger, som kan modtages i et enkelt request. Token: Sendes med af klienten. Kan efterfølgende benyttes til at forespørge på status. Persist: Ja, hver Indberetning i et Indberetningsrequest gemmes som "rå xml" som en Indberetning. 6.3 Indberetning En enkelt indberetning i et Indberetningsrequest. Persist: Ja, som "rå xml". 6.4 Modtagelsesstatus Modtagelsesstatus returneres til Indberetningsklienten, når denne har afsendt et Indberetningsrequest med energiforbrug. Kode = 0 (OK). FejlTekst = "OK" Kode <> 0 (Fejl), FejlTekst = <Beskrivelse af fejlen> Persist: Nej 6.5 Tilstandsstatus En tilstandsstatus på indlæsningsprocessen. Kode/Tekst: 0/Venter, 1/I gang, 2/Færdig. Persist: Ja 6.6 Statistiskstatus En statistisk status på indlæsningsprocessen. AntalIalt, AntalFejlede og AntalOk Persist: Nej (kan udledes ud fra Behandlingsstatus på Indberetningerne) 6.7 Behandlingsstatus Status på behandlingen af en enkelt indberetning i et indberetningsrequest. Behandlingsstatus består af 0 til mange Behandlingsfejl. Hvis en Indberetning er behandlet OK - dvs. valideret korrekt og energiforbruget er knyttet til en BBR entitet, er der 0 Behandlingsfejl knyttet til en Behandlingsstatus. Version 3.0 Side 24 af 41

Hvis der opstår fejl under behandlingen, er der mindst én Behandlingsfejl knyttet til Behandlingsstatus'en. Kode = 0 (OK, ingen valideringsfejl eller tilknytningsfejl, og energiforbruget er knyttet til en BBR entitet). FejlTekst = "OK" Kode = 1 (Fejl), FejlTekst = "Check validerings- og tilknytningsfejl". Persist: Ja 6.8 Behandlingsfejl En behandlingsfejl er enten en Valideringsfejl eller en Tilknytningsfejl. Kode = 0 (OK). FejlTekst = "OK" Kode <> 0 (Fejl), FejlTekst = <beskrivende fejltekst, som gør klienten i stand til at identificere årsagen til fejlen>. Persist: Ja 6.9 Valideringsfejl En Valideringsfejl er en Behandlingsfejl, som opstår i forbindelse med valideringen af en Indberetning. 6.10 Tilknytningsfejl En Tilknytningsfejl er en Behandlingsfejl, som opstår i forbindelse med at et Energiforbrug skal knyttes til en BBR Entitet. 6.11 Energiforbrug Energiforbrug som defineret i bekendtgørelse 1264. Samt: Valideringstidspunkt: Tidspunkt for behandlingen af energiforbruget. Ophørttidspunkt: Tidspunkt, hvor energiforbruget er gjort historisk - ellers null. 6.12 Afregningsstatus Status for afregningen. Status kan antage en af følgende værdier: "Aflæst", "Anslået" eller "Korrigeret". "Aflæst" - Hvis mængden er normalt aflæst og afregnet. "Anslået" - Hvis mængden der er afregnet er anslået af energileverandøren. "Korrigeret" - Tidligere fremsendt mængde som med denne fremsendelse hermed ændres. Leveret Oplyses ved leverance af fyringsolie Oplysningen er krævet. Det er forretningsnøglen, som bestemmer, om indberetninger erstatter tidligere indberetninger. Der tages i denne forbindelse ikke hensyn til værdien i dette felt. Persist: Ja Version 3.0 Side 25 af 41

6.13 Forsyningsart Forsyningsart. Kan lige nu antage værdierne (i henhold til bekendtgørelse 1264): Naturgas: Her angives værdien "Naturgas". Fjernvarme: Her angives værdien "Fjernvarme-vand" eller "Fjernvarme-damp". Fyringsolie: Her angives værdien "Fyringsolie". Bygas: Her angives værdien Bygas. Eksempel: "Fjernvarme-vand" og "Fyringsolie". Persist: Ja 6.14 Måleenhed Måleenhed. Kan lige nu antage værdierne (i henhold til bekendtgørelse 1264): Måleenheden angives i den enhed, som fremgår af afregningen til forbrugeren. Naturgas: Her angives "kwh", "MWh", kbm, M3 eller ØM3. Fjernvarme: Her angives "kwh", "MWh", kbm eller M3. Fyringsolie: Her angives "Liter". Bygas: Her angives kbm eller M3 Persist: Ja 6.15 Energiforsyningsselskab Energiforsyningsselskab. Energiforsyningsselskabets CVR nummer og navn. Dataformat jævnfør: OIOXML CVRnumberIdentifier. Eksempel: "12345678". Persist: Ja 6.16 BBREntitet (BBR) Den BBR entitet (Kan være en Grund, Bygning eller Enhed), som energiforbruget er knyttet til. Relationen mellem Energiforbrug og den konkrete BBR entitet defineres ud fra en id og en entitetstype, som angiver om id'en hører til en Grund, Bygning eller Enhed. 6.17 Bruger (BBR) Den bruger i BBR, som rettigheder knyttes til. 6.18 Systemopsætning (BBR) MaxGraense angiver det maksimale antal Indberetninger, som kan sendes i ét Indberetningsrequest. MaxGraense oprettes og kan konfigureres som en systemparameter i BBR's nuværende SystemParameter tabel. Version 3.0 Side 26 af 41

7. Databasemodel Dette diagram viser databasemodellen for Energidata ind i BBR dvs. de nødvendige udvidelser til BBR s fysiske datamodel: Version 3.0 Side 27 af 41

8. Valideringsregler 8.1 Skemavalidering Som for de øvrige BBR OIOXML services foretages en skemavalidering af de indkommende forespørgsler. Dette foretages for at sikre konsistens i forhold til hvad servicen skal processere og for at afvise evt. angreb på servicen så hurtigt som muligt. 8.2 Krævede felter og databasekonsistens For at leve op til Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) og sikre konsistens i databasen kræves for hver energiindberetning at 1. Energiforsyningsselskab er udfyldt og findes i tabellen EnergiForsyningsselskab. 2. Leverancested ID er udfyldt. 3. Forsyningsart er udfyldt og findes i tabellen EnergiForsyningsart. 4. Indberettet dato er udfyldt og er en gyldig dato. 5. Periode start er udfyldt og er en gyldig dato. 6. Periode slut er udfyldt og er en gyldig dato. 7. Måleenhed udfyldt og findes i tabellen EnergiMaaleenhed samt at der via krydstabellen EnergiForsyningsartMaaleenhed er en relation til den angivne Forsyningsart. 8. Mængde er udfyldt og er et gyldigt tal. 9. Status for aflæsning/afregning er udfyldt og findes i tabellen EnergiAfregningsstatus At der er tilstrækkelig information til at kunne knytte data til en BBR entitet. Reglerne for dette er beskrevet i kapitel 11 i dette dokument. Version 3.0 Side 28 af 41

9. Snitfladebeskrivelse Dette kapitel beskriver webservice snitfladen til Energidata ind i BBR samt muligheden for at konfigurere energiselskaber og hemmelige adresser. Webservicen består af 2 kald: EnergyConsumptionReport EnergyConsumptionStatus Wsdl samt skemafiler for webservicen kan findes i zip-filen EnergyV1.zip. 9.1 EnergyConsumptionReport EnergyCunsumptionReport benyttes til indrapportering af energiforbrug til BBR. Input strukturen til kald af EnergyConsumptionReport hedder EnergyConsumptionReportRequestStructure og ser således ud: EnergyCunsumptionReportRequestStructure indeholder en et antal understrukturer. En understruktur kan enten være en EnergyConsumptionInsertStructure eller en EnergyConsumptiondeleteStructure samt en EnergyReportUniversalIdentifier, som er en UUID, som entydigt identificerer den afleverede mængde energiforbrug. EnergyReportUniversalIdentifier kan benyttes til efterfølgende kald af EnergyConsumptionStatus EnergyConsumptionInsertStructure benyttes, hvis et energiforbrug skal indberettes og ser således ud: Version 3.0 Side 29 af 41

Version 3.0 Side 30 af 41

EnergyConsumptionInsertStructure indeholder en EnergyConsumption struktur, som definerer et energiforbrug. EnergyConsumptionDeleteStructure benyttes, hvis et energiforbrug skal annulleres og ser således ud: EnergyConsumptionDelete indeholder en EnergyConsumptionKeys struktur, som definerer nøglen til det energiforbrug, som skal annulleres. Output strukturen til kald af EnergyConsumptionReport hedder EnergyCunsumptionReportResponseStructure og ser således ud: EnergyConsumptionReportResponseStructure indeholder en ReturnMessage, som fortæller, om kaldet er gået godt. ReturnMessage ser således ud: ReturnMessage strukturen benyttes flere forskellige steder til at angive en status på et kald eller en handling. Generelt gælder, at hvis ResponseReturnIdentifier er 0, er kaldet eller handlingen forløbet OK. Hvis ResponseReturnIdentifier ikke er 0, indeholder ResponseReasonIdentifier og ResponseReasonText detaljer om fejlen. For ReturnMessage i EnergyConsumptionReportResponseStructure er der følgende mulige værdier for ResponseReasonIdentifier og ResponseReasonText, hvis ResponseReturnIdentifier ikke er 0: 6013 Indberetningsklient blev ikke fundet 6020 Grænsen for antal indberetninger er overskredet. Grænsen er: <værdi> 6024 Der findes flere indberetninger med den samme nøgle 9999 <Alvorlig uventet fejl> Hvis der opstår en skema-valideringsfejl, returneres en SOAP Fault, som beskriver fejlen. Version 3.0 Side 31 af 41

9.2 EnergyConsumptionStatus EnergyConsumptionStatus benyttes til forespørgsel af status. Input strukturen til kald af EnergyConsumptionStatus hedder EnergyConsumptionStatusRequestStructure og ser således ud: EnergyConsumptionStatusRequestStructure indeholder en EnergyReportUniversalIdentifier, som entydigt identificerer et tidligere kald til EnergyConsumption- Report. Output strukturen til kald af EnergyConsumptionStatus hedder EnergyConsumptionStatusResponseStructure og ser således ud: EnergyConsumptionStatusResponseStructure indeholder en ReturnMessage, som fortæller, om kaldet er gået godt. Hvis kaldet ikke er gået godt (ResponseReturnIdentifer ikke er 0), er der følgende mulige værdier for ResponseReasonIdentifier og ResponseReasonText: 6014 Indberetningsrequest blev ikke fundet 9999 <Alvorlig uventet fejl> Hvis kaldet er gået godt (ResponseReturnIdentifier er 0), returneres endvidere en EnergyReportProgressCode, som fortæller, hvordan det går med behandlingen (Inactive, Active eller Completed). Endvidere returneres en EnergyReport- ProgressStatistics struktur, som fortæller hvor mange energiforbrug, der i alt skal behandles, hvor mange energiforbrug, der er behandlet uden fejl, og hvor mange energiforbrug, der er behandlet med fejl. Hvis EnergyReportProgressCode er Completed, returneres endvidere en Energy- ConsumptionCompletedStructure, som for det enkelte energiforbrug (defineret ved en EnergyConsumptionKeys struktur) fortæller, hvordan behandlingen er gået. Hvis behandlingen ikke er gået godt, findes en eller flere ReturnMessage strukturer, hvor ResponseReturnIdentifier ikke er 0. I disse ReturnMessage strukturer er der følgende mulige værdier for ResponseReasonIdentifier og ResponseReasonText: 6000 Energiforsyningsselskab med CVR nummer <værdi> er ikke oprettet i BBR databasen Version 3.0 Side 32 af 41

6001 Energiforsyningsart <værdi> er ikke oprettet i BBR databasen 6002 Energimåleenhed <værdi> er ikke oprettet i BBR databasen 6003 Valideringsfejl ved oprettelse af energiforbrug: <værdi> 6004 Energiafregningsstatus <værdi> er ikke oprettet i BBR databasen 6005 Kommunenummer <værdi> er ikke gyldigt 6006 Postnummer <værdi> er ikke gyldigt 6007 Husnummer <værdi> er ikke gyldigt 6008 Vejkode <værdi> er ikke gyldigt 6009 Ejendomsnummer <værdi> er ikke gyldigt 6010 Bygningsnummer <værdi> er ikke gyldigt 6011 Energiforbruget kunne ikke tilknyttes til en BBR entitet 6012 Energiforbrug med den angivne nøgle findes ikke 6015 Der blev ikke fundet en enhedsadresse med de angivne adresseoplysninger 6016 Der blev ikke fundet en enhed med den angivne enhedsadresse 6017 Der blev ikke fundet en adgangsadresse med de angivne adresseoplysninger 6018 Der blev ikke fundet en bygning eller en grund med den angivne adgangsadresse 6019 Der blev ikke fundet nogle grunde med den (hhv. det) angivne adgangsadresse (hhv. ejendomsnummer) 6021 Energimåleenhed <værdi1> må ikke benyttes sammen med forbrugsart <værdi2> 6023 Der blev ikke fundet en udskrivningsmatrikel på ejendommen med det angivne ejendomsnummer 6025 Der kunne ikke knyttes til en bygning gennem kommunenummer/ejendomsnummer/bygningsnummer, da ikke alle felter er udfyldt 6026 Der kunne ikke knyttes til en grund gennem kommunenummer/ejendomsnummer, da begge felter ikke er udfyldt 6027 Der blev ikke fundet en grund med det angivne ejendomsnummer 6028 Der blev ikke fundet en bygning med det angivne kommunenummer, ejendomsnummer, bygningsnummer 9999 <Alvorlig uventet fejl> Hvis behandlingen er gået godt, er der præcis én ReturnMessage struktur med ResponseReturnIdentifier 0, og der returneres endvidere en reference til den BBR-entitet, som energiforbruget er knyttet til. Hvis der opstår en skema-valideringsfejl, returneres en SOAP Fault, som beskriver fejlen. 9.3 Konfiguration af energiselskaber EBST laver en liste over de energiselskaber for hvilke, der må indberettes energiforbrug. Denne liste afleveres som en csv-fil på BBR s ftp server og BBR s 2. level support informeres om, at der ligger en ny fil til indlæsning. csv-filen består en en eller flere linjer. Hver linje indeholder oplysningerne om et energiselskab. Hver linje skal afsluttes med ny linje (ASCII CR+LF) og de enkelte datafelter i linjen skal adskilles af et separatortegn, et semikolon (;). Tegnsættet skal være Codepage 865. Rækkefølgen af datafelter skal være som angivet her: Version 3.0 Side 33 af 41

1. cvr nummer: Jf. OIOXML CVRnumberIdentifier. 2. navn: Maksimalt 300 tegn. Eksempel: 12345678;Energiselskab 1 23456789;Energiselskab 2 BBR s 2. level support sørger for indlæsning af energiselskaber. 9.4 Konfiguration af hemmelige adresser EBST laver en liste over de adresser for hvilke, der ikke må videregives energiforbrug. Denne liste afleveres som en csv-fil på BBR s ftp server og BBR s 2. level support informeres om, at der ligger en ny fil til indlæsning. csv-filen består en en eller flere linjer. Hver linje indeholder oplysningerne om en hemmelig adresse. Hver linje skal afsluttes med ny linje (ASCII CR+LF) og de enkelte datafelter i linjen skal adskilles af et separatortegn, et semikolon (;). Tegnsættet skal være Codepage 865. Rækkefølgen af datafelter skal være som angivet her: 1. kommunenummer: Jf. OIOXML MunicipalityCode. 2. vejkode: Jf. OIOXML StreetCode. 3. husnummer: Jf. OIOXML StreetBuilingIdentifier. Eksempel: 0461;1234;45 0461;0345;56 0461;3456;100A Version 3.0 Side 34 af 41

10. Sikkerhed Sikkerheden baserer sig på den eksisterende sikkerhedsmodel i BBR. Det er dog nødvendig at udvide denne model pga. den tværkommunale tilgang. 10.1 Autorisation Adgangen til at benytte webservicen til at indberette energiforbrug og forespørge på status styres ud fra rollen, OIOEnergyService. Denne rolle tildeles i første omgang kun til FIE brugeren direkte fra SQL. 10.2 Ekstern webservice Sikkerheden i webservicen er baseret på OWSA model T. Kort fortalt benytter denne sikkerhedsmekanisme HTTPS til sikker transport mellem to sikkerhedsdomæner og OCES-certifikater som autentifikation af Service Aftager. Nedenstående er et link til OWSA Model T beskrivelsen: http://www.itst.dk/arkitektur-ogstandarder/standardisering/standarder-for-serviceorienteretinfrastruktur/standarder-for-webservices/oio-web-servicearkitekturen For at benytte webservicen skal Service Aftager : være autoriseret i BBR og have tilknyttet et gyldigt OCES virksomheds- eller medarbejdercertifikat til autorisationen medsende ovennævnte certifikat ved alle webservicekald have installeret OCES-rodcertifikat I øvrigt henvises til IT- og Telestyrelsens beskrivelse af OWSA model T. 10.3 Sikkerhedshensyn Alle felter i BBR har en sikkerhedsklassifikation. Den kan antage værdien 1, 2 eller 3. Den har kun betydning, hvis en entitet er omfattet af sikkerhedshensyn. Sikkerhedsklassifikationens koder betyder: 1. Der blokeres for visning af og inddatering til feltets data. 2. Kun brugere med bestemte roller kan se feltets data. Kun brugere med bestemte roller kan ændre feltets data. 3. Alle autoriserede brugere kan se feltets data. Kun brugere med bestemte roller kan ændre feltets data. Data kan videregives til anvendelser uden for kommunen i overensstemmelse med bestemmelserne i BBR-loven. Er den til energiforbruget tilknyttede BBR entitet omfattet af sikkerhedshensyn, vil data fra energiforbruget også være det. De enkelte felters sikkerhedsklassifikation vil afgøre om data kan videregives. Version 3.0 Side 35 af 41

Det er besluttet at energidata skal have sikkerhedsklassifikation 2. Det betyder at hvis den BBR entitet som energiforbruget er knyttet til er omfattet af sikkerhedshensyn videregives energidata ikke. Version 3.0 Side 36 af 41

11. Tilknytning af energiforbrugsindberetning til BBR-entitet. For en given energiforbrugsindberetning skal der mappes fra angiven adresseangivelse/ejendoms/bygningsangivelse til en BBR-entitet, enten Grund, Bygning eller Enhed. Hensigten er at få det mest detaljerede match der er muligt. Det skal sikres at et givet input af adresse og/eller ejendom altid resulterer i samme tilknytning (under forudsætning af at BBR-forhold er uændrede). Hvis den BBR entitet (grund, bygning eller enhed), som et energiforbrug knyttes til, ændres på et senere tidspunkt, vil energiforbruget følge BBR entiteten. Hvis fx en BBR entitet ændrer adresse, vil det energiforbrug, som en gang er knyttet til entiteten forblive tilknyttet. Hvis fx en entitet ophører, vil et eventuelt tilknyttet energiforbrug ligeledes forblive tilknyttet. Som input fra energiforbrugsindberetningen kan anvendes følgende: Adgangsadresse ID Enhedsadresse ID Kombination af Postnummer, Vejnavn, Husnummer, evt. Etagebetegnelse, evt. Dørbetegnelse Kombination af Kommunekode, Vejkode, Husnummer, evt. Etagebetegnelse, evt. Dørbetegnelse Kombination af Kommunekode, ejendomsnummer Kombination af Kommunekode, ejendomsnummer og bygningsnummer I den nedenstående er beskrevet en søgeliste der kan gås frem efter for at finde en relevant BBR-entitet. Noget af søgningen er fremfinding af mellemresultater, enten adresse eller grund. Såfremt der findes et match, stoppes videre søgning. Hvis der ikke findes et match fortsættes til det næste step i søgelisten. Såfremt der ikke findes et match overhovedet, returneres en fejl til indberettende klient. Når der findes et match, bliver der ikke foretaget yderligere konsistenscheck. Hvis der fx findes en adgangsadresse ud fra en Adgangsadresse ID, bliver det ikke kontrolleret, om den evt. medsendte kombination af kommunenummer/vejkode/husnummer svarer til den fundne adgangsadresse. Nedenstående skal gælde uanset om bygningen eller enheden ligger som stameller nybyggeri. Søgning A. Tilknytning via enhedsadresse Der fremsøges en enhedsadresse på følgende måde: Hvis Enhedsadresse ID er angivet og valid og identificerer en stam- eller foreløbig enhedsadresse, anvendes denne. Ellers, hvis kombination af Postnummer, Vejnavn, Husnummer, evt. Etagebetegnelse, evt. Dørbetegnelse er udfyldt og identificerer en enkelt stam- eller foreløbig enhedsadresse, anvendes denne. Version 3.0 Side 37 af 41

Ellers, hvis kombination af Kommunekode, Vejkode, Husnummer, evt. Etagebetegnelse, evt. Dørbetegnelse er udfyldt og identificerer en enkelt stam- eller foreløbig enhedsadresse, anvendes denne. Hvis enhedsadresse er fundet: 1. Hvis der findes præcis én stam- eller nybyggeri-enhed, som er knyttet til enhedsadressen Indberetning tilknyttes enheden. 2. Hvis der IKKE findes præcis én stam- eller nybyggeri-enhed, som er knyttet til enhedsadressen Der fortsættes til Søgning B. Hvis enhedsadresse IKKE er fundet: Der fortsættes til Søgning B. Søgning B. Tilknytning via kommunenummer, ejendomsnummer og bygningsnummer 1. Hvis der findes præcis én stam- eller nybyggeri-bygning med det angivne kommunenummer, ejendomsnummer og bygningsnummer: Indberetning tilknyttes bygningen. 2. Hvis der IKKE findes præcis én stam- eller nybyggeri-bygning med det angivne kommunenummer, ejendomsnummer og bygningsnummer: Der fortsættes til Søgning C Søgning C. Tilknytning via adgangsadresse Der fremsøges en adgangsadresse på følgende måde: Hvis Adgangsadresse ID er angivet og valid og identificerer en stam- eller foreløbig adgangsadresse, anvendes denne. Ellers, hvis kombination af Postnummer, Vejnavn, Husnummer er udfyldt og svarer til en enkelt stam- eller foreløbig adgangsadresse, anvendes denne. Ellers, hvis kombination af Kommunekode, Vejkode, Husnummer er udfyldt og svarer til en enkelt stam- eller foreløbig adgangsadresse, anvendes denne. Hvis adgangsadresse er fundet: 1. Hvis der findes præcis én stam- eller nybyggeri-bygning, som er knyttet til adgangsadressen, og forsyningsarten stemmer overens med bygningens varmeinstallation (i feltet BYG.56) og opvarmningsmiddel (i feltet BYG.57) (se bemærkning sidst i dette afsnit): Indberetning tilknyttes bygningen. 2. Hvis der findes præcis én stam- eller nybyggeri-bygning, som er knyttet til adgangsadressen, og forsyningsarten IKKE stemmer overens med bygningens varmeinstallation (i feltet BYG.56) og opvarmningsmiddel (i feltet BYG.57) (se bemærkning sidst i dette afsnit): Indberetning tilknyttes den grund, hvorpå bygningen ligger. Version 3.0 Side 38 af 41

3. Hvis der findes flere stam- eller nybyggeri-bygninger, som er knyttet til adgangsadressen: A. Hvis præcis én af disse bygninger er opvarmet med forsyningsarten: Indberetning tilknyttes bygningen. B. Hvis ingen af disse bygninger er opvarmet med forsyningsarten Indberetningen tilknyttes den grund, hvorpå bygningen (blandt bygningerne med korrekt adresse) med den laveste bygningsanvendelseskode ligger. Hvis der er flere sådanne bygninger, vælges den grund, hvor bygningen med det laveste bygningsnummer findes. C. Hvis flere af disse bygninger er opvarmet med forsyningsarten OG præcis én af disse bygninger har bygningsanvendelseskode mindre end 900: Indberetningen tilknyttes bygningen. D. Hvis flere af disse bygninger er opvarmet med forsyningsarten OG ingen eller flere af disse bygninger har bygningsanvendelseskode mindre end 900: Indberetningen tilknyttes den grund, hvorpå bygningen (blandt bygningerne med korrekt forsyningsart) med den laveste bygningsanvendelseskode ligger. Hvis der er flere sådanne bygninger, vælges den grund, hvor bygningen med det laveste bygningsnummer findes. 4. Hvis der IKKE findes stam- eller nybyggeri-bygninger, som er knyttet til adgangsadressen, MEN der findes en stam-grund, som er knyttet til adgangsadressen: Indberetningen knyttes til grunden. 5. Hvis der IKKE findes stam- eller nybyggeri-bygninger, som er knyttet til adgangsadressen, OG der IKKE findes en stam-grund, som er knyttet til adgangsadressen: Der fortsættes til søgning D. Hvis adgangsadresse IKKE er fundet: Der fortsættes til søgning D. Søgning D. Tilknytning via kommunenummer og ejendomsnummer Alle stam-grunde med det angivne kommunenummer og ejendomsnummer fremfindes: 1. Hvis der findes præcis én stam- eller nybyggeri-bygning på disse grunde, og forsyningsarten stemmer overens med bygningens varmeinstallation (i feltet BYG.56) og opvarmningsmiddel (i feltet BYG.57) (se bemærkning sidst i dette afsnit): Indberetning tilknyttes bygningen. 2. Hvis der findes præcis én stam- eller nybyggeri-bygning på disse grunde, og forsyningsarten IKKE stemmer overens med bygningens varmeinstallation (i feltet BYG.56) og opvarmningsmiddel (i feltet BYG.57) (se bemærkning sidst i dette afsnit): Indberetning tilknyttes den grund, hvorpå bygningen ligger. 3. Hvis der findes flere stam- eller nybyggeri-bygninger på disse grunde: Version 3.0 Side 39 af 41

A. Hvis præcis én af disse bygninger er opvarmet med forsyningsarten: Indberetning tilknyttes bygningen. B. Hvis ingen af disse bygninger er opvarmet med forsyningsarten Indberetningen tilknyttes den grund, hvorpå bygningen (blandt bygningerne med korrekt adresse) med den laveste bygningsanvendelseskode ligger. Hvis der er flere sådanne bygninger, vælges den grund, hvor bygningen med det laveste bygningsnummer findes. C. Hvis flere af disse bygninger er opvarmet med forsyningsarten OG præcis én af disse bygninger har bygningsanvendelseskode mindre end 900: Indberetningen tilknyttes bygningen. D. Hvis flere af disse bygninger er opvarmet med forsyningsarten OG ingen eller flere af disse bygninger har bygningsanvendelseskode mindre end 900: Indberetningen tilknyttes den grund, hvorpå bygningen (blandt bygningerne med korrekt forsyningsart) med den laveste bygningsanvendelseskode ligger. Hvis der er flere sådanne bygninger, vælges den grund, hvor bygningen med det laveste bygningsnummer findes. 4. Hvis der IKKE findes stam- eller nybyggeri-bygninger på disse grunde: Indberetningen knyttes til den grund, som indeholder udskrivningsmatriklen. Bemærk: For at afgøre, om forsyningsarten på et energiforbrug stemmer overens med bygningens varmeinstallation (i feltet BYG.56) og opvarmningsmiddel (i feltet BYG.57), benyttes følgende algoritme: 1. Hvis Varmeinstallation (BYG.56) er 1 og forsyningsart er Fjernvarme-vand eller Fjernvarme-damp : OK 2. Ellers, hvis Opvarmningsmiddel (BYG.57) er 7 og forsyningsart er Naturgas : OK 3. Ellers, hvis Opvarmningsmiddel (BYG.57) er 3 og forsyningsart er Fyringsolie : OK 4. Ellers, hvis Opvarmningsmiddel (BYG.57) er 2 og forsyningsart er Bygas : OK 5. Ellers: Ikke OK Version 3.0 Side 40 af 41

12. Hemmelige adresser I dette afsnit beskrives, hvordan hemmelige adresser håndteres. EBST vedligeholder listen af hemmelige adresser specificeret ved hjælp af adgangsadressen (som består af kommunenummer, vejkode og husnummer). De hemmelige adresser leveres og indlæses som beskrevet i afsnit 9.4. Når et energiforbrug behandles (dvs. oprettes), undersøges om energiforbruget er knyttet til en grund/bygning/enhed med en hemmelig adresse. Hvis dette er tilfældet, stemples energiforbruget med et HemmeligTimestamp. Hvis et energiforbrug har et HemmeligTimestamp, videregives det ikke til OIS. Hvis et energiforbrug er blevet videregivet til OIS og efterfølgende får et Hemmelig- Timestamp, sendes en besked til OIS om, at energiforbruget skal slettes. Når der modtages en ny liste med hemmelige adresser, gennemløbes alle energiforbrug. Energiforbrug, som er knyttet til en grund/bygning/enhed med en hemmelig adresse, får et HemmeligTimestamp. Energiforbrug, som har et HemmeligTimestamp, men som ikke længere er knyttet til en grund/bygning/enhed med en hemmelig adresse får fjernet HemmeligTimestamp. Det er kun, når energiforbruget behandles (dvs. oprettes) eller der modtages en ny liste med hemmelige adresser, at HemmeligTimestamp ændres på energiforbrug. HemmeligTimestamp ændres ikke, når en entitet fx ændrer adresse i BBR. Version 3.0 Side 41 af 41