6. Dataudveksling med andre systemer... 2

Transkript

1 Indholdsfortegnelse 6. Dataudveksling med andre systemer Kontekstdiagram for Nyt BBR Kort om NYT BBR s dataudveksling Udtræk fra NYT BBR Total udtræk (Totalkopi) Udtrækkenes formater Data fra Nyt BBR til OIS Oversættelsesliste mellem NYT BBR, OIS og OIOXML BBR Snitfladerne De generelle oioxml-snitflader OIOXML-snitflade for bygninger og boliger OIOXML-snitfladen for adresser OIOXML-snitfladen for adressegeometri OIOXML-snitfladen Utility Eksempel på WSDL erne OIOXML-snitfladerne & BBR-Kommune Masseopdatering Inddataboks Type Supplerende varme Systemspecifikke snitflader Overordnede betragtninger Integration ud fra hændelser Skabelon til beskrivelse af systemintegration BBR KMS BBR - ESR Online opslag, som henter hændelser fra ESR On-line opslag, som henter oplysninger fra ESR On-line opslag, som sender oplysninger til ESR BBR Bossinf-STB BBR CPR BBR OIS Periodevise kørsler, dataudtræk mv Påmindelser ved overskridelse af tidsfrister Kapitel 6 version 7.0 Side 1 af 53

2 5. Dataudveksling med andre systemer Dataudveksling med andre systemer vil i Nyt BBR fortrinsvis foregå som systemtil-system integration. Dataudvekslingen sker dels vha. udtræk og dels vha. snitflader. Snitfladerne kan opdeles i de helt generelle oioxml-snitflader og i de systemspecifikke snitflader. Dokumentationen (vejledningerne) for oioxml-snitfladerne ligger på bbr.dk og specifikationerne er tilgængelige på Digitaliser.dk så snart de er godkendte af ITST. Kapitel 6 version 7.0 Side 2 af 53

3 5.1 Kontekstdiagram for Nyt BBR Dette diagram illustrerer grafisk NYT BBR s dataudveksling med øvrige systemer. Signaturforklaring = Kommer senere = I drift Kontekstdiagram for Nyt BBR = Delvis i drift Statens Arkiver KMS Danmarks Statistik CPR KMD BBR Nyt BBR Plansystem.dk KRR OIS ESR Skattemappen OIOsnitflader Inddataboksen Print/ e-boks Certificeringscenter Version 1.5 Kapitel 6 version 7.0 Side 3 af 53

4 5.1.1 Kort om NYT BBR s dataudveksling KMS Geografisk sammenhæng for matrikler, benyttes til dannelse og vedligeholdelse af grunde. (se beskrivelse i underafsnit 6 i afsnit BBR KMS om vedligeholdelse af matrikulære data i Nyt BBR) Kortforsyningen benyttes til at hente koordinater. CPR Vi henter dagligt oplysninger fra CPR. De skal bruges ved oprettelse af adresser i Nyt BBR. Folkeregistrene skal have adgang til en standard webservice i Nyt BBR. Plansystem.dk Nyt BBR henter data fra Plansystem.dk til skærmbilledet Ejendomsoplysninger (a la det skærmbillede som man tidligere kendte som C182 i KMD BBR). Statens Arkiver Der skal hvert år afleveres en komplet kopi af landsdækkende BBR-data (stamdata). Formatet skal overholde krav fra Statens Arkiver. Danmarks Statistik Danmarks Statistik skal kunne foretage online udtræk af landsdækkende BBR-data (såvel stamdata som sagsdata). OIS Daglige online overførsler. OIS bruges til adresseopslag i forbindelse med BBR-meddelelser. Skattemappen BBR-Meddelelser udsendes via eller E-boks i PDF-format med et følgebrev og kan kobles til Skattemappen. Certificeringscenter Denne snitflade bruges i forbindelse med logon med certificater (medarbejder- og virksomhedscertifikater). Print/e-Boks BBR-Meddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev og kunne kobles til Skattemappen. e-boks leverer liste over de danskere der er tilmeldt E-boks. OIO-snitflader Alle BBR-data skal udstilles via webservices og snitflader i OIOXMLformat. Inddataboksen Med Inddataboksen får kommunen mulighed for at godkende rettelser til udvalgte BBR data. Her gennemfører vi samme maskinel validering og kvalitetssikring som når data ryger direkte ind. Kapitel 6 version 7.0 Side 4 af 53

5 ESR ESR udstiller en lang række hændelser (matrikulære, ejerskifte mm.) som nyt BBR abonnerer på. I forbindelse med udskrift af BBR-Meddelelser hentes ejere fra ESR. KRR Krydsreferencen holdes opdateret via synkroniseringen og udstillede webservices. KMD BBR KMD BBR holdes opdateret via synkroniseringen. Kapitel 6 version 7.0 Side 5 af 53

6 5.2 Udtræk fra NYT BBR Der kan foretages udtræk af landsdækkende BBR-data (såvel stamdata som sagsdata) Total udtræk (Totalkopi) Total udtræk af BBR-data, foretages på baggrund af den fysiske implementering af databasen. Udtrækket laves som semikolonsepareret filer, en fil pr. tabel, med en række pr. record. Udtrækket leveres med afblænding af felter der er omfattet af sikkerhedsklassifikation. Udtrækket består af data fra 26 tabeller (hvor tabellen antal er en tabel der angiver hvor mange rækker der er i de øvrige tabeller): AdgangsAdresse Adressesag Antal Brugsenhed By Byggesag Bygning Ejerskab Enhed EnhedEnhedsAdresse EnhedOpgang EnhedsAdresse Etage Geometri Grund KommunaltEjerlav Kommune Lokalitet Matrikel Notat Opgang Postdistrikt Rum Tekniskanlaeg Vej Vejstykke Kapitel 6 version 7.0 Side 6 af 53

7 5.2.2 Udtrækkenes formater Det er muligt at levere udtræk fra NYT BBR i følgende formater: Standard formater OIO-XML og CSV-filer Særlige formater OIS-XML Statens Arkivers formater Eksempler på modtagere Skat EBST Danmarks Statistik Modtagere OIS Statens Arkiver Data fra Nyt BBR til OIS Der skal dagligt køres et program der skaber et udtræk, dette udtræk placeres på et ftp server, hvorfra OIS henter data. Dataformatet er lavet i overensstemmelse med OIS s krav til snitflade, som OIS har beskrevet i dokumentet OIS_DBvaert_XML_Snitflade. De daglige udtræk består af de ændringer der er foretaget i Nyt BBR siden sidste udtræk. De enkelte entiteters timestamp bestemmer, hvilke data der skal overføres. Disse timestamps udløser en xml-record til OIS som følgende: OpretTimestamp AendrtTimestamp OphoertTimestamp O Opret record R Ændrings record S Slette record Oversættelsesliste mellem NYT BBR, OIS og OIOXML Til dette kapitel følger et bilag med en oversættelsesliste mellem NYT BBR, OIS og OIOXML. Listen indeholder: BBR s feltnavn i den fysiske database BBR-feltets XML navn når det afleveres til OIS Navnet på det tilsvarende felt/element i OIOXML OIOXML- metadatabeskrivelsen OIOXML navnet på engelsk OIOXML- metadatabeskrivelsen på engelsk Kapitel 6 version 7.0 Side 7 af 53

8 5.3 BBR Snitfladerne De generelle oioxml-snitflader Nyt BBR s funktionalitet bliver stillet til rådighed som OIOXML-baserede webservices, således at de generelt vil kunne tilfredsstille andre systemers behov for data og opdatering. OIOXML-skemaer og WSDL-beskrivelser publiceres på Digitaliser.dk. Dokumentationen for oioxml-snitfladerne (vejledningerne) ligger på bbr.dk OIOXML-snitflade for bygninger og boliger En af de OIOXML-snitflader, som BBR systemet stiller til rådighed, er BuildingDwelling.wsdl. Baggrunden for denne snitflade er, at man ønsker at registrere og opdatere Bygninger og boliger -data i BBR ved webservicebaseret overførsel fra et eksternt system i OIOXMLformat. Snitfladen giver kort sagt mulighed for fremsøgning samt opdatering af data om bygninger og boliger i BBR, herunder grunde, bygninger, opgange/indgange, etager, enheder, tekniske anlæg, rum, brugsenheder og ikke mindst byggesager OIOXML-snitfladen for adresser Snitfladen Address.wsdl dækker over BBR systemets adressedel og stiller metoder til hentning og opdatering af adgangs- og enhedsadresser til rådighed. Snitfladen for adresser kan det samme som snitfladen for adressegeometri. Adressegeometrisnitfladen er blot mere rettet mod GISleverandørerne end adressesnitfladen OIOXML-snitfladen for adressegeometri Baggrunden for denne snitflade er, at man ønsker at registrere og opdatere adressepunkter (geografiske adressekoordinater) i NYT BBR ved webservicebaseret overførsel fra et ekstern GIS eller kortsystem i OIOXML format. Adressegeometrisnitfladen stiller to operationer til rådighed: Fremsøgning af adressekoordinater Opdatering af adressekoordinater OIOXML-snitfladen Utility Snitfladen Utility.wsdl stiller funktionalitet til rådighed, som er relevant både når man benytter de øvrige ovennævnte snitflader. Snitfladen indeholder følgende funktionalitet: Hentning af alle vejnavne og vejkoder i en kommune Hentning af alle adgangsadresser i en kommune Hentning af rettigheder Hentning af kodelister Kapitel 6 version 7.0 Side 8 af 53

9 Eksempel på WSDL erne Alle services beskrives i et WSDL-dokument. Herunder er et eksempel på et WSDL-dokument (eksemplet er hentet fra oioxml-snitfladen Utility ). <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl=" xmlns:soap=" xmlns:http=" xmlns:xs=" xmlns:soapenc=" xmlns:mime=" xmlns:tns="urn:oio:bbr:wsdl:1.0.0" targetnamespace="urn:oio:bbr:wsdl:1.0.0" xmlns:ns="urn:oio:bbr:1.0.0"> <wsdl:types> <xs:schema targetnamespace="urn:oio:bbr:1.0.0" elementformdefault="qualified"> <xs:include schemalocation="../xsd/municipalitystreetnamesgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/municipalitystreetnamesgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/streetnameaddressesgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/streetnameaddressesgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitygetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitygetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetbyentityrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetbyentityresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetbyentityfieldrequeststructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetbyentityfieldresponsestructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entityfieldgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entityfieldgetresponsestructure.xsd"/> </xs:schema> </wsdl:types> <wsdl:message name="municipalitystreetnamesgetrequest"> <wsdl:part name="request" element="ns:municipalitystreetnamesgetrequeststructure"/> </wsdl:message> <wsdl:message name="municipalitystreetnamesgetresponse"> <wsdl:part name="response" element="ns:municipalitystreetnamesgetresponsestructure"/> </wsdl:message> <wsdl:message name="streetnameaddressesgetrequest"> <wsdl:part name="request" element="ns:streetnameaddressesgetrequeststructure"/> </wsdl:message> <wsdl:message name="streetnameaddressesgetresponse"> <wsdl:part name="response" element="ns:streetnameaddressesgetresponsestructure"/> </wsdl:message> <wsdl:message name="entitygetrequest"> <wsdl:part name="request" element="ns:entitygetrequeststructure"/> </wsdl:message> <wsdl:message name="entitygetresponse"> <wsdl:part name="response" element="ns:entitygetresponsestructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetbyentityrequest"> <wsdl:part name="request" element="ns:entitypermissiongetbyentityrequeststructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetbyentityresponse"> <wsdl:part name="response" element="ns:entitypermissiongetbyentityresponsestructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetrequest"> <wsdl:part name="request" element="ns:entitypermissiongetrequeststructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetresponse"> <wsdl:part name="response" element="ns:entitypermissiongetresponsestructure"/> </wsdl:message> <wsdl:message name="codelistgetbyentityfieldrequest"> <wsdl:part name="request" element="ns:codelistgetbyentityfieldrequeststructure"/> </wsdl:message> <wsdl:message name="codelistgetbyentityfieldresponse"> <wsdl:part name="response" element="ns:codelistgetbyentityfieldresponsestructure"/> Kapitel 6 version 7.0 Side 9 af 53

10 </wsdl:message> <wsdl:message name="codelistgetrequest"> <wsdl:part name="request" element="ns:codelistgetrequeststructure"/> </wsdl:message> <wsdl:message name="codelistgetresponse"> <wsdl:part name="response" element="ns:codelistgetresponsestructure"/> </wsdl:message> <wsdl:message name="entityfieldgetrequest"> <wsdl:part name="request" element="ns:entityfieldgetrequeststructure"/> </wsdl:message> <wsdl:message name="entityfieldgetresponse"> <wsdl:part name="response" element="ns:entityfieldgetresponsestructure"/> </wsdl:message> <wsdl:porttype name="utility"> <wsdl:operation name="municipalitystreetnamesget"> <wsdl:input name="municipalitystreetnamesgetrequest" message="tns:municipalitystreetnamesgetrequest"/> <wsdl:output name="municipalitystreetnamesgetresponse" message="tns:municipalitystreetnamesgetresponse"/> </wsdl:operation> <wsdl:operation name="streetnameaddressesget"> <wsdl:input name="streetnameaddressesgetrequest" message="tns:streetnameaddressesgetrequest"/> <wsdl:output name="streetnameaddressesgetresponse" message="tns:streetnameaddressesgetresponse"/> </wsdl:operation> <wsdl:operation name="entityget"> <wsdl:input name="entitygetrequest" message="tns:entitygetrequest"/> <wsdl:output name="entitygetresponse" message="tns:entitygetresponse"/> </wsdl:operation> <wsdl:operation name="entitypermissiongetbyentity"> <wsdl:input name="entitypermissiongetbyentityrequest" message="tns:entitypermissiongetbyentityrequest"/> <wsdl:output name="entitypermissiongetbyentityresponse" message="tns:entitypermissiongetbyentityresponse"/> </wsdl:operation> <wsdl:operation name="entitypermissionget"> <wsdl:input name="entitypermissiongetrequest" message="tns:entitypermissiongetrequest"/> <wsdl:output name="entitypermissiongetresponse" message="tns:entitypermissiongetresponse"/> </wsdl:operation> <wsdl:operation name="codelistgetbyentityfield"> <wsdl:input name="codelistgetbyentityfieldrequest" message="tns:codelistgetbyentityfieldrequest"/> <wsdl:output name="codelistgetbyentityfieldresponse" message="tns:codelistgetbyentityfieldresponse"/> </wsdl:operation> <wsdl:operation name="codelistget"> <wsdl:input name="codelistgetrequest" message="tns:codelistgetrequest"/> <wsdl:output name="codelistgetresponse" message="tns:codelistgetresponse"/> </wsdl:operation> <wsdl:operation name="entityfieldget"> <wsdl:input name="entityfieldgetrequest" message="tns:entityfieldgetrequest"/> <wsdl:output name="entityfieldgetresponse" message="tns:entityfieldgetresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="utility" type="tns:utility"> <soap:binding style="document" transport=" <wsdl:operation name="municipalitystreetnamesget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#municipalitystreetnamesget" style="document"/> <wsdl:input name="municipalitystreetnamesgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> Kapitel 6 version 7.0 Side 10 af 53

11 <wsdl:output name="municipalitystreetnamesgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="streetnameaddressesget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#streetnameaddressesget" style="document"/> <wsdl:input name="streetnameaddressesgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="streetnameaddressesgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entityget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entityget" style="document"/> <wsdl:input name="entitygetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitygetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entitypermissiongetbyentity"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entitypermissiongetbyentity" style="document"/> <wsdl:input name="entitypermissiongetbyentityrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitypermissiongetbyentityresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entitypermissionget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entitypermissionget" style="document"/> <wsdl:input name="entitypermissiongetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitypermissiongetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="codelistgetbyentityfield"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#codelistgetbyentityfield" style="document"/> <wsdl:input name="codelistgetbyentityfieldrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="codelistgetbyentityfieldresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="codelistget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#codelistget" style="document"/> <wsdl:input name="codelistgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="codelistgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entityfieldget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entityfieldget" style="document"/> <wsdl:input name="entityfieldgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> Kapitel 6 version 7.0 Side 11 af 53

12 <wsdl:output name="entityfieldgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="utility"> <wsdl:port name="utility" binding="tns:utility"> <soap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> OIOXML-snitfladerne & BBR-Kommune Der findes to adgange til BBR: BBR-Kommune, dvs. klienten, som er kommunernes webadgang til BBR Kommuneklienten, dvs. OIOXML-snitfladerne, som tilgår BBR via en service gateway Begge adgange tilgår den samme applikationsserver og har dermed adgang til samme forretningslogik. Kapitel 6 version 7.0 Side 12 af 53

13 Masseopdatering I forbindelse med masseopdateringer af Nyt BBR vil det være hensigtsmæssigt at benytte sig af den funktionalitet, der er stillet til rådighed via de generelle OIOXML-baserede snitflader, som sikrer at alle felter kan opdateres (for så vidt som man har autorisation til det) og at alle forretningsreglerne bliver overholdt. Kapitel 6 version 7.0 Side 13 af 53

14 5.3.2 Inddataboks BBR Inddataboks giver mulighed for modtagelse af BBR data fra eksterne interessenter. Eksterne interessenter kan indsende sager til BBR Inddataboksen via standardiserede snitflader. Sagerne indeholder kort sagt information om indberetteren samt BBR data, der ønskes indberettet til BBR systemet. BBR Inddataboksen giver endvidere via fanebladet Inddataboks - mulighed for at sagsbehandle disse sager. Hvis sagerne godkendes, opdateres BBR systemet med de indsendte BBR data. En indberetter (det er typisk ejeren) indberetter BBR data (for indberetningstypen Supplerende varme vil det være data vedr. supplerende varme for en bygning hhv. enhed) til Inddataboksen via en ekstern applikation. BBR data bliver sammen med indberetterens kontaktoplysninger sendt til Inddataboksen via en webservice. Så snart indberetningen er modtaget i Inddataboksen, udsendes en kvittering via til indberetteren. Kommunen kan nu tilknytte en sagsbehandler til sagen. Den ansvarlige sagsbehandler vil efterfølgende modtage en om den nye indberetning. Kapitel 6 version 7.0 Side 14 af 53

15 Sagsbehandleren kan nu overføre, afvise eller godkende sagen. Resultatet af sagsbehandlingen sendes via til indberetteren. Hvis sagen godkendes, opdateres data direkte i BBR. Hvis sagen overføres til anden afdeling, afsluttes sagen i Inddataboks og sagsbehandlingen foretages uden for Inddataboksens kontekst. I denne version af Inddataboksen kan indsendte sager kun have én type og det er: - Supplerende varme På længere sigt er det dog planen, at Inddataboksen kan modtage mange forskellige indberetninger til BBR systemet. Der vil blive udviklet en webservice til hver type Type Supplerende varme Via en snitflade kan Inddataboksen modtage ændringer til feltet Supplerende varme på bygnings- og enhedsniveau. Webservicen hedder InputBox.wsdl Systemspecifikke snitflader Overordnede betragtninger I forbindelse med system-til-system integration er der nogle overordnede overvejelser, der skal foretages for at denne integration kan fungere så optimalt som muligt. System-til system integration vil altid introducere en ekstra kompleksitet i de implicerede systemer, hvad angår tilgængelighed, synkronisering og performance. Det vil her være hensigtsmæssigt at skelne mellem databærende og dataanvendende system. Ideelt set skal det være det databærende system, der indeholder dets data og som udstiller dem via et sæt af services, som andre systemer kan tilgå. Imidlertid giver dette problemer omkring søgning, tilgængelighed og svartider, når det anvendende system til stadighed skal tilgå. Måden hvorpå man håndterer dette er i reglen ved at introducere dataredundans i de anvendende systemer, således at de relevante data kan fremfindes på en hurtig måde, hvilket imidlertid giver et problem omkring opdateringer og pålideligheden af de relevante data. Håndteringen af problemstillingen (redundante data vs. opdaterede data) kan ske på tre forskellige måder: 1) Man opgiver dataredundans og fremfinder de relevante data i det databærende system. 2) Man lader det databærende system opdatere det eller de anvendende systemer. 3) Man anvender en publisher/subscriber mekanisme til at håndtere opdateringen, således at det data-anvendende system abonnerer på ændringer i det databærende system. På denne måde afkobles relationen mellem de to systemer og det databærende system skal ikke bekymre sig om at opdatere de anvendende systemer. Kapitel 6 version 7.0 Side 15 af 53

16 Alle tre løsninger har fordele og ulemper. Vanskelighederne ved 1) har allerede været nævnt, mens 2) introducerer en kompleksitet i det databærende system, som bliver forøget betragteligt, hvis der er mange systemer der skal opdateres. Hvis blot et af de systemer der skal opdateres ikke er tilgængeligt, kan opdateringen ikke gennemføres, hvis den skal være pålidelig. I en SOA orienteret verden, er det en løsning der så vidt muligt skal undgås. 3) derimod har ikke disse vanskeligheder, til gengæld kan den ikke sikre at data er pålidelige. Nedenstående skema opsumerer de vigtigste forskelle i fordele og ulemper mellem de forskellige metoder: Pålidelighed Tilgængelighed Simpelhed 1) Ingen dataredundans ) Opdatering fra databærende system + (-) - 3) Publish/Subscribe - + (+) I forbindelse med Nyt BBR vil det være nødvendigt at inddrage disse overvejelser med hvert enkelt tilfælde af system-til-system integration Integration ud fra hændelser I det følgende beskrives overordnet hvilke systemer der integreres i forbindelse med hvilke hændelser: BBR/KMS 1) Hent GSH-oplysninger fra KMS 2) Ajourføring af adressedata 3) Hentning af matrikelkoordinater 4) Søgning af matrikel i KMS på basis af adressekoordinater 5) Søgning af matrikel i KMS på basis af bygningskoordinater BBR/ESR On-line opslag som henter hændelser fra ESR 1) Opdatering af ejerforholdskode i ESR 2) Ejerskifte 3) Opdatering af etagemeter (tinglyst areal) i ESR 4) Oprettelse af matrikel i ESR 5) Sletning af matrikel i ESR 6) Flytning af matrikler i ESR Kapitel 6 version 7.0 Side 16 af 53

17 7) Approbationer i ESR 8) Opdatering af ejerlavskoder og tekster i ESR 9) Ret udskrivningsmatrikel i ESR 10) Ret KMS_SFENR i ESR Online opslag som henter oplysninger fra ESR 11) Hent ejerforholdskode i ESR 12) Hent CPRnr/CVRnr/løbenr og alternativ adresse 13) Hent matrikelsammenhæng (København & Frederiksberg) 14) Hent ejerlejligheds-oplysninger 15) Hent ejendomsoplysninger fra ESR til Ejendomsoversigten i NYT BBR 16) Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Online opslag som sender oplysninger til ESR 17) Ajourføring af adressedata BBR/BOSSINF 1) Hentning af offentlig støtte i BOSSINF på enhed BBR/CPR 1) Hentning af adresser ud fra CPR-nummer 2) Opslag fra CPR af adresse i Nyt BBR 3) Opdatering af Udlejningsforhold 2 ved samkøring af ESR, CPR og NYT BBR. BBR/OIS 1) Hentning af navn og adresser ud fra kommuenr. og ejendomsnr. Kapitel 6 version 7.0 Side 17 af 53

18 Skabelon til beskrivelse af systemintegration Nedenfor præsenteres en skabelon for de services, der skal udvikles i forbindelse med Nyt BBR s integration til andre systemer samt nogle eksempler. Disse vil tjene både til udvikling og dokumentation af de udviklede services. Skabelonen er godkendt af KOMBIT som model til beskrivelse af de enkelte services. Klient <den der bruger servicen> Server <den der udfører servicen> Beskrivelse: <Overordnet beskrivelse af snitfladen> Inputparametre: <Hvilke inputparametre skal anvendes> Outputparametre: <Hvilke outputparametre skal anvendes> Entitet: <Hvilke entiteter arbejdes der på> Attributter: <Hvilke attributter> Entitet: <Hvilke entiteter arbejdes der på> Attributter: <Hvilke attributter> Betingelse: <Hvilke betingelser skal programmæssigt være opfyldt> Resultat: <Resultat af servicens eksekvering, ie. Hvilken tilstand er serveren i> Sikkerhed: <Hvilke sikkerhedsmæssige aspekter er involveret> Fejlhåndtering: <Hvorledes rapporteres fejl til klienten (afhængig af hvordan servicen implementeres)> Isolation/Uafhængighed: <Hvilken indflydelse har servicen på systemernes funktionalitet> On-line tilgængelighed: <Er det nødvendigt at informationen er tidstro> Svartider: <Er svartiden kritisk> Synkronisering: <Er sync af databaser essentiel> Kompleksitet: <Er servicen kompleks i forhold til afhængigheder, betingelser og operationer> Logistik: <Med hvem og hvad skal der aftales> Overholdelse af Kontrakten: Kommentarer: <Kommentarer i øvrigt> To Do: <Hvad skal der gøres> To Do: <Hvad skal der gøres> Status: <Status for implementering af service> Kapitel 6 version 7.0 Side 18 af 53

19 BBR KMS 1. Webservice GSH-oplysninger fra KMS Klient Nyt BBR Server KMS Beskrivelse: Webservicen skal ud fra en matrikelidentifikation returnere en liste med samtlige matrikelidentifikationer og deres geografiske sammenhæng for den samlede faste ejendom, som den kaldende matrikelidentifikation indgår i. Inputparametre: Landsejerlavskode, Matrikelnummer Outputparametre: En liste af nedenstående data for samtlige matrikler for den samlede faste ejendom, som den kaldende matrikelidentifikation indgår i: Landsejerlavskode Matrikelnummer SFE nummer GSHkode (Geografisk SammenHængskode), GSHkode en entydig kode for de matrikelnumre der er geografisk sammenhængende indenfor en samlet fast ejendom. Koden genereres af KMS. Entitet: Grund, matrikel Attributter: Betingelse: Matrikel skal eksistere Resultat: Implementering: KMS udstiller en webservice Sikkerhed: Fejlhåndtering: Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. 2. Ajourføring af adressedata KMS Klient Nyt BBR Server KMS Beskrivelse: Overfører adressedata til KMS ved oprettelse, ændring eller sletning af adgangsadresser og enhedsadresser. Når der sker ændringer i adgangsadresser eller enhedsadresser i BBR, kaldes en webservice hos KMS med de ændrede adresser. Inputparametre: OIO adressestrukturerne (som defineret på digitaliser.dk): AddressAccessCreatedRequestStructure AddressAccessUpdatedRequestStructure AddressAccessDeletedRequestStructure AddressSpecificCreatedRequestStructure AddressSpecificUpdatedRequestStructure AddressSpecificDeletedRequestStructure Kapitel 6 version 7.0 Side 19 af 53

20 Outputparametre: OIO adressestrukturerne (som defineret på digitaliser.dk): AddressAccessCreatedResponseStructure AddressAccessUpdatedResponseStructure AddressAccessDeletedResponseStructure AddressSpecificCreatedResponseStructure AddressSpecificUpdatedResponseStructure AddressSpecificDeletedResponseStructure Entitet: AdgangsAdresse og EnhedsAdresse Attributter: Alle attributter på AdgangsAdresse og EnhedsAdresse Entitet: AdgangsAdresse og EnhedsAdresse Attributter: Alle attributter på AdgangsAdresse og EnhedsAdresse Status: Denne webservice sættes i drift 15/ Betingelse: Alle ændringer på endelige og nye foreløbige adgangsadresser og enhedsadresser overføres. Ændringer på sagsadresser overføres IKKE. Resultat: adgangsadressen eller enhedsadressen bliver oprettet, ændret eller slettet. Implementering: KMS udstiller en webservice. Sikkerhed: IP beskyttelse. Fejlhåndtering: Hvis kaldet går godt, returnerer serveren fejlkode 0. Alt andet opfattes af klienten (BBR) som en fejl, og klienten prøver at sende opdateringen af sted igen efter et aftalt mønster. Isolation/Uafhængighed: Hvis KMSs webservice er nede, prøver BBR at sende hændelsen af sted igen efter et aftalt mønster. Opdateringen af adressen i BBR går godt. On-line tilgængelighed: Operationen er tidstro bortset fra, hvis der opstår fejl og hændelser må gensendes. Svartider: Kaldet mod KMS webservicen er afkoblet fra opdateringen af adressen i BBR, så det vil ikke påvirke svartiderne i BBR. Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftalt med KMS Overholdelse af Kontrakten: Krav Kommentarer: 3. Hentning af matrikelkoordinater Klient Nyt BBR Server KMS Beskrivelse: Leverer koordinaterne til en matrikel Inputparametre: Kommunenummer, Matrikelbetegnelse Outputparametre: Matrikelkoordinater, adressekoordinaterne samt angivelse af nøjagtighedsklasse ( B ), Teknisk standard ( UF ), kilde til geometri ( 2 ), revisionsdato ( dagsdato ), retning ( 200 ) og placering ( 5 ). Entitet: Matrikel, Adgangsadresser, Bygning Entitet: Matrikel Kapitel 6 version 7.0 Side 20 af 53

21 Attributter: Matrikelkoordinater Attributter: Matrikelkoordinater Betingelse: Matriklen skal eksistere Resultat: Adgangsadresse eller bygning får opdateret koordinater med værdierne fra KMS. Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis KMSs webservice er nede kan ajourføringen kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMS Overholdelse af Kontrakten: Krav 5.1.4, 2. punkt Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans (idet koordinater kan opdateres via oioxml-snitfladerne). Status: Webservice er implementeret. Ingen udestående. 4. Søgning af matrikel i KMS på basis af adressekoordinater Klient NYT BBR Server KMS Beskrivelse: Henter matrikel i KMS på basis af adressekoordinater Inputparametre: Kommunenummer, adressekoordinater Outputparametre: Liste af matrikler indenfor koordinaterne Entitet: Attributter: Entitet: Matrikler Attributter: Matrikel Betingelse: Adressekoordinater skal eksistere Resultat: Matrikeloplysninger er hentet Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis KMSs webservice er nede kan forespørgslen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med nyt BBR Overholdelse af Kontrakten: Krav 5.1.4, 2. punkt Kapitel 6 version 7.0 Side 21 af 53

22 Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans. Status: Webservice er implementeret. Ingen udestående. Kapitel 6 version 7.0 Side 22 af 53

23 5. Søgning på matrikel i KMS ud fra bygningskoordinater Klient Nyt BBR Server KMS Beskrivelse: Henter matrikel i KMS på basis af bygningskoordinater Inputparametre: Kommunenummer, bygningskoordinater Outputparametre: Liste af matrikler indenfor koordinaterne Entitet: Bygninger Attributter: Entitet: Matrikel Attributter: Matrikelbetegnelsen Betingelse: Bygningskoordinater skal eksistere Resultat: Matrikeloplysninger er hentet Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis nyt BBR er nede kan forespørgslen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med nyt BBR Overholdelse af Kontrakten: Krav Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. 6. Vedligeholdelse af matrikulære data i BBR Matrikulære data i Nyt BBR vedligeholdes både ved hjælp af ESR og KMS s matrikelsystem minimaks. I det følgende beskrives den implementerede model: Kapitel 6 version 7.0 Side 23 af 53

24 En sletning af et matrikelnummer resulterer i fjernelse af matrikelnummeret fra dens grund i BBR og grunden slettes hvis den ikke har andre matrikelnumre tilminimaks 1 5 ESR Nyt BBR 4 6 1) Matrikulære ændringer sendes til ESR fra minimaks. 2) Der foretages sagsbehandling i ESR. ESR tilføjer bl.a. ejendomsnummer; alle matrikler har et ejendomsnummer tilknyttet i ESR. 3) ESR gemmer matrikulære ændringer i en hændelsestabel, hvor de bliver læst af BBR (snitflade 4 til 10 i afsnit ). 4) BBR behandler den modtagne hændelse. 5) Nogle hændelser fra ESR, fx oprettelse af en ny matrikel eller ændring af SFEnummer initierer et kald til minimaks for at hente den geografiske sammenhæng for den modtagne eller ændrede matrikel. 6) BBR opdaterer matrikulære data på baggrund af den modtagne hændelse og information. Fx resulterer en oprettelse af en ny matrikel i ESR i, at matrikelnummeret tilføjes til en eksisterende grund som denne matrikel hører til eller i en oprettelse af en ny grund. Opdateringen i BBR afhænger af, om der i forvejen ligger en grund, som denne matrikel skal knyttes til. Kapitel 6 version 7.0 Side 24 af 53

25 knyttet. ESR sikrer, at der ikke er bygninger på grunden. Eventuelle adresser på matriklen flyttes til UMAT (uden matrikel). Ud over opret- og slet-matrikel-hændelser findes der flere ESR-hændelser som initierer en opdatering af matrikulære data i Nyt BBR. De mulige hændelser som modtages fra ESR er beskrevet i kapitel Kapitel 6 version 7.0 Side 25 af 53

26 BBR - ESR Der kommunikeres med ESR på 3 forskellige måder: Online opslag som henter hændelser fra ESR (snitflade 1 til 10). Når der sker opdateringer i ESR, som har betydning for BBR, stiller ESR disse opdateringer til rådighed via en hændelsestabel, som BBR kan læse i via en webservice. BBR sørger for, at BBR s data opdateres med disse ændringer. Som eksempel kan nævnes, at der oprettes eller opdateres grunde i BBR som konsekvens af oprettelse eller sletning af matrikler i ESR. Et andet eksempel er bestilling af BBR-Meddelelser ved ejerskifte i ESR. Disse hændelser/snitflader er beskrevet i afsnit Online opslag som henter oplysninger fra ESR (snitflade 11 til 16) I forbindelse med sagsbehandling i BBR hentes der online ESR-oplysninger. Som eksempel kan nævnes, at der hentes BBR oplysninger i forbindelse med skærmbilledet Ejendomsoversigten. Disse kald er beskrevet i afsnit Online opslag som sender oplysninger til ESR (snitflade 17) Adresseopdateringer i BBR har betydning for ESR. Derfor sendes disse opdateringer til ESR. Dette kald er beskrevet i afsnit Online opslag, som henter hændelser fra ESR 1. Opdatering af ejerforholdskoden i ESR Klient Nyt BBR Server ESR Beskrivelse: Opdatering af oplysninger om opdaterede ejerforholdskoder i ESR. Når der ændres i ejerforholdskoden på en ejendom skal ESR gøre oplysningerne tilgængelige for Nyt BBR. Der er 3 hændelsestyper inden for opdatering af ejerforholdskoden i ESR: 001: ret ejerforholdskode i forbindelse med opret ejer 002: ret ejerforholdskode i forbindelse med historisk ejer 003: ret ejerforholdskode i forbindelse med ret ejer Inputparametre: - Outputparametre: (det er de samme outputparametre ved de 3 hændelsestyper) MessageType Kommunenummer Ejendomsnr EjerlejlighedsEjdnr EjendomsRef Entitet: Grund, Bygning, Teknisk anlæg, enhed Attributter: Ejerforholdskode Entitet: Ejer Attributter: Kommunenummer, Ejerforholdskode, Ejendomsnummer, Ejendomsreference, Betingelse: Resultat: Oplysninger giver mulighed for at op- Kapitel 6 version 7.0 Side 26 af 53

27 datere Nyt BBR, således at grunden opdateres med den nye ejerforholdskode. Er der tale om en moderejendom for ejerlejligheder skal ejerforholdet registreres for de pågældende ejerlejligheder (jf. krav 5.4.2) Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerforholdskoden ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 2. Ejerskifte i ESR Klient Nyt BBR Server ESR Beskrivelse: Ejerskifte i ESR Når der foretages ejerskifte i ESR, skal ESR gøre oplysningerne tilgængelig for Nyt BBR, da det skal medføre en udskrivning af en BBR-Meddelelse. Der er 2 hændelsestyper inden for opdatering af ejerskifte i ESR: 501: ejerskifte 502: ejerskifte i forbindelse med historisk ejer Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr EjendomsRef Dcprcir Entitet: Ejendom, Grund, Bygning (ejerlejlighed), Enhed (ejerlejlighed) Attributter: Entitet: Ejendom (ejerlejlighed) Attributter: Kommunenummer, Ejendomsnummer, Ejendomsreference Betingelse: Ejerskab skal eksistere Resultat: Nyt BBR skal gøre klar til udskrivning Kapitel 6 version 7.0 Side 27 af 53

28 af en BBR-Meddelelse (med årsag ejerskifte ) Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerforholdskoden ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav 7.1, 7.7 Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 3. Opdatering af etagemeter (tinglyst areal) i ESR Klient Nyt BBR Server ESR Beskrivelse: Opdatering af oplysninger om etagemeter i ESR. Når der opdateres i etagemeter (som svarer til feltet tinglyst areal i Nyt BBR) skal ESR gøre oplysningen tilgængelig for Nyt BBR. Der er 1 hændelsestype inden for opdatering af etagemeter (tinglyst areal) i ESR: 101: ret etagemeter Inputparametre: - Outputparametre: MessageType Kommunenummer EjerlejlighedsEjdnr Artskode EjendomsRef Etagemeter Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Ejendom (Ejerlejlighed) Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etagemeter Betingelse: Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter Kapitel 6 version 7.0 Side 28 af 53

29 Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR. 4. Oprettelse af matrikel i ESR Klient Nyt BBR Server ESR Beskrivelse: ESR opretter en matrikel. Dette skal Nyt BBR har besked om så tilsvarende matrikel automatisk oprettes i Nyt BBR. Der er 1 hændelsestype inden for opret matrikel i ESR: 201: opret matrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Grund, matrikel Entitet: Ejendom, matrikel Kapitel 6 version 7.0 Side 29 af 53

30 Resultat: Oplysninger giver mulighed for at opdatere Nyt BBR med nye matrikler Attributter: Fuld matrikelbetegnelse Betingelse: Ejendommen skal eksistere Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og matriklen ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: en følge af brug af ESR-matriklen (krav 5.1.1, 51.2, allonge 1, ændringsbilag 32 og 37, se beskrivelse i afsnit 6.1.2) Kommentarer: Hvis oplysningerne ikke sendes fra ESR når de opstår, vil det på ejendomme/grunde som allerede er oprettet i Nyt BBR, ikke være muligt at placere bygninger på disse matrikler, da matriklerne ikke vil komme til Nyt BBR s kendskab. Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 5. Sletning af matrikel i ESR Klient Nyt BBR Server ESR Beskrivelse: ESR sletter en matrikel. Dette skal Nyt BBR have besked om så evt. tilsvarende matrikel kan slettes i Nyt BBR. ESR tjekker i KRR om der er bygninger på matriklen (senere skal der tjekkes op mod Nyt BBR). Hvis der er bygninger på matriklen kan sletningen ikke gennemføres. Hvis der ikke er bygninger på matriklen gennemføres sletningen og der lægges en hændelse i hændelsesregisteret. Der er 1 hændelsestype inden for slet matrikel i ESR: 301: slet matrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Kapitel 6 version 7.0 Side 30 af 53

31 Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Entitet: Grund, matrikel Entitet: Ejendom, matrikel Attributter: Fuld matrikelbetegnelse Betingelse: Ejendommen skal eksistere Resultat: Oplysninger giver mulighed for at slette matrikler i Nyt BBR Resultat: Readonly Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og matriklen ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: en følge af brug af ESR-matriklen (krav 5.1.1, 51.2, allonge 1, ændringsbilag 32 og 37, se beskrivelse i afsnit 6.1.2) Kommentarer: Nyt BBR skal have faciliteter til at flytte en bygning fra en matrikel til en anden. Denne facilitet skal implementeres i Nyt BBR under alle omstændigheder. Bygningens placering skal synkroniseres til KRR. Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 6. Flytning af matrikler i ESR Klient Nyt BBR Server ESR Beskrivelse: Der flyttes matrikler mellem to ejendomme i ESR. Det laves mod Nyt BBR som opret og slet af matrikel, se pkt. 5 Sletning af matrikler i ESR. Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Kapitel 6 version 7.0 Side 31 af 53

32 7. Approbationer i ESR Klient Nyt BBR Server ESR Beskrivelse: De foreløbige matrikler oprettes i Nyt BBR på linje med almindelige matrikler. Se opretning af ny matrikel. Når approbationen er gennemført laves en opretning af matriklen, og en sletning af den foreløbige matrikel. Se pkt. 4 Oprettelse af matrikel i ESR og pkt. 5 Sletning af matrikler i ESR. Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. 8. Opdatering af ejerlavskoder og tekster i ESR Klient Nyt BBR Server ESR Beskrivelse: ESR opdaterer i ejerlavskoder og tekster. Følgende skal gøres tilgængelig for Nyt BBR: Oprettelse af eller ændring i landsejerlavskode Oprettelse af eller ændring i landsejerlavstekst Oprettelse af eller ændring i kommunal ejerlavskode Der er 3 hændelsestyper inden for opdatering af ejerlavskoder og tekster i ESR: 401: ret ejerlavskode og tekster 402: opret ejerlavskode og tekster 403: slet ejerlavskode og -tekster Inputparametre: - Outputparametre: MessageType Gl_Kommunenummer Gl_Landsejerlavskode Gl_Landsejerlavstekst Gl_KomEjerlavskode Gl_KomEjerlavstekst Ny_kommunenummer Ny_landsejerlavskode Ny_landsejerlavstekst Ny_ejerlavskode Ny_ejerlavstekst Resultat: Oplysninger giver mulighed for at opdatere Nyt BBR med landsejerlavskode, landsejerlavstekst og kommunale ejerlav Entitet: Landsejerlav, kommunalt ejerlav Attributter: Landsejerlavskode, landsejerlavstekst, kommunal ejerlavskode Betingelse: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Kapitel 6 version 7.0 Side 32 af 53

33 Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerlavet ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Første gangs indlæsning i Nyt BBR skal ske via konverteringen. Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 9. Ret udskrivningsmatrikel i ESR Klient Nyt BBR Server ESR Beskrivelse: Opdaterer oplysninger om udskrivningsmatriklen i ESR. Der er 1 hændelsestype inden for ret udskrivningsmatrikel i ESR: 102: ret udskrivningsmatrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Matrikel Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etagemeter Betingelse: Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter Kapitel 6 version 7.0 Side 33 af 53

34 Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR. 10. Ret KMS_SFENR i ESR Klient Nyt BBR Server ESR Beskrivelse: Opdaterer oplysninger om KMS_SFENR i ESR. Der er 1 hændelsestype inden for ret KMS_SFENR i ESR: 103: ret KMS_SFENR Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Matrikel Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etageme- Kapitel 6 version 7.0 Side 34 af 53

35 Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter ter Betingelse: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR On-line opslag, som henter oplysninger fra ESR 11. Hent ejerforholdskode i ESR Klient Nyt BBR Server ESR Beskrivelse: Henter oplysninger om ejerforholdskode i ESR. Når Nyt BBR opretter en grund skal ejerforholdskoden hentes i ESR. Når Nyt BBR opretter en enhed, bygning eller teknisk anlæg som er en ejerlejlighed, skal ejerforholdskoden hentes i ESR. Inputparametre: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer (udfyldes ved artskode 02 og 32), Ejendomsreference Outputparametre: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer (udfyldes ved artskode 02 og 32), Ejendomsreference, Ejerforholdskode Entitet: Grund, Bygning, Teknisk anlæg, Enhed (ejerlejlighed) Attributter: Entitet: Ejendom Attributter: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer, Ejendomsreference, Ejerforholdskode Betingelse: Ejendommen skal eksistere Resultat: De hentede oplysninger giver mulig- Kapitel 6 version 7.0 Side 35 af 53

36 hed for at opdatere Nyt BBR med oplysningerne, således at grunden opdateres med ejerforholdskode. Er der tale om en moderejendom for ejerlejligheder skal ejerforholdet registreres for de pågældende ejerlejligheder (jf. krav 5.4.2) Implementering: ESR udstiller en service til hentning af ejerforholdskoden Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelsen af entiteten kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe. Status: Webservice er implementeret. Ingen udestående. 12. Hent CPRnr/CVRnr/løbenr og alternativ adresse Klient Nyt BBR Server ESR Beskrivelse: Henter ejers CPRnr/CVRnr/løbenr i forbindelse med udskrivning af fx BBR-Meddelelse. I forbindelse med udlejningsforhold dannes der desuden et udtræk, der skal sammenholdes med udtræk fra CPR. Inputparametre: Kommunenummer, Ejendomsnummer, Ejertype (altid a ) Outputparametre: Liste af Ejeres CPR-numre eller CVR-numre eller løbenr samt alternativ adresse. Samt om adressen er adressebeskyttet. Markering for administrator eller ejer. Ejertype (kun for ejere). Administratorkode (kun for adminstratorer) Entitet: Bygning, enhed Attributter: Entitet: Ejer, ejendom Attributter: CPRnr eller CVRnr eller løbenr og alternativ adresse Betingelse: Ejendommen skal eksistere Resultat: Liste af ejere. Der kan kaldes videre til OIS for at få navn og adresse til adressering af fx BBR-Meddelelser. Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Udskrivningen af ejermeddelelse kan ikke gennemføres/ajourføringen af Udlejningskode kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Kapitel 6 version 7.0 Side 36 af 53

37 Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: krav 7.2, EBST nota med ændringer til krav 5.3 Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. Kapitel 6 version 7.0 Side 37 af 53

38 13) Hent matrikelsammenhæng (Kbh & Frederiksberg) Klient Nyt BBR Server ESR Beskrivelse: Webservicen skal ud fra en matrikelidentifikation returnere en liste med samtlige matrikelidentifikationer, som hører til den samme faste ejendom som den kaldende matrikelidentifikation. For København udledes matrikelsammenhænget ud fra feltet SamletFastEjendom. For Frederiksberg udledes matrikelsammenhænget ud fra feltet Noteringskode. Inputparametre: Landsejerlavskode, Matrikelnummer Outputparametre: En liste af nedenstående data for samtlige leverede matrikler: Landsejerlavskode Matrikelnummer (nr og bogstav) SFE nummer Noteringskode Entitet: Grund, matrikel Attributter: Betingelse: Matrikel skal eksistere Resultat: Implementering: ESR udstiller en webservice Sikkerhed: Fejlhåndtering: Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. 14) Hent ejerlejligheds-oplysninger Klient Nyt BBR Server ESR Beskrivelse: Ved oprettelse af en ejerlejlighed hentes ejerlejlighedsoplysninger fra ESR. Samtidig kontrolleres det at ejerlejligheden eksisterer i ESR Inputparametre: Kommunenummer, matrikelnummer, ejerlejlighedsejendomsnr. Outputparametre: Ejerlejlighedsnr., etagemeter, ejerforholdskode, liste af matrikelbetegnelser Entitet: Enhed, Bygning, Teknisk Anlæg Entitet: Ejendom, matrikel Attributter: Fuld matrikelbetegnelse, etagemeter, ejerforholdskode Betingelse: Ejendommen skal eksistere Resultat: Enheden (ejerlejligheden) kan opdateres med aktuelle ejerlejlighedsoplysninger. Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Kapitel 6 version 7.0 Side 38 af 53

39 Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Matrikelbetegnelsen skal ikke benyttes direkte i Nyt BBR, men videre i synkroniseringen med KMD-BBR (og KKR). Hvis der i Nyt BBR flyttes en bygning indeholdende ejerlejligheder - fra en matrikel til en anden matrikel skal der på ny hentes oplysninger om ejerlejligheden. Kommentarer: Håndtering af redundante data vs. opdaterede data: Publish/Subscribe Status: Webservice er implementeret. Ingen udestående. 15) Hent ejendomsoplysninger fra ESR til Ejendomsoversigten i NYT BBR Klient Nyt BBR Server ESR Beskrivelse: Ved dannelse af Ejendomsoversigten hentes matrikel- og planoplysninger i ESR. Inputparametre: Kommunenummer Ejendomsnr. Landsejerlavskode Ejerlavskode Matrikelnr Matrikelbogstav Delnr Opdelingsnr Artskode Outputparametre: Returkode Systemkode Tekst Ejerlavskode Matrikelnr Matrikelbogstav Delnr Opdelingsnr Artskode Zonestatus Cnote (noteringskode) Udskrivningsmatr Fmatar (matrikelareal) Fvej (Heraf vejareal) Fdivar (Diverse areal) Plantype Plantypetekst Plannr Kapitel 6 version 7.0 Side 39 af 53

40 Plannavn Entitet: Grund Entitet: Matrikel Attributter: Betingelse: Ejendommen skal eksistere Resultat: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Appendiks 1 i Allonge 1 - Ekstra krav og Ejendomsoplysninger. Kommentarer: Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. 16) Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Klient Nyt BBR Server ESR Beskrivelse: Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Inputparametre: Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Outputparametre: Matrikelmarkering Returkode Systemkode Tekst Entitet: Grund Entitet: Matrikel Attributter: Betingelse: Ejendommen skal eksistere Kapitel 6 version 7.0 Side 40 af 53

41 Resultat: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Appendiks 1 i Allonge 1 - Ekstra krav og Ejendomsoplysninger. Kommentarer: Kommentarer: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående On-line opslag, som sender oplysninger til ESR 17) Ajourføring af adressedata ESR Klient Nyt BBR Server ESR Beskrivelse: Overfører adressedata til ESR ved oprettelse af, eller ændring af adgangs- eller enhedsadresse Inputparametre: Kommunenummer, Matrikelnummer, Ejendomsnummer, adresse (adgangs- eller enhedsadresse) Outputparametre: OK Entitet: Attributter: Entitet: Adgangs- og Enhedsadresse Attributter: Betingelse: Resultat: ESR adressedata opdateres Implementering: ESR udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis ESRs webservice er nede kan ajourføringen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Kapitel 6 version 7.0 Side 41 af 53

42 Logistik: Aftales med ESR Overholdelse af Kontrakten: Krav Kommentarer: Håndtering af redundante data vs. opdaterede data: Opdatering fra databærende system Status: Webservice er implementeret. Ingen udestående. Kapitel 6 version 7.0 Side 42 af 53

43 BBR Bossinf-STB Overførsel af kode for offentlig støtte til Nyt BBR Klient Nyt BBR Server Bossinf Beskrivelse: Opdatering af kode for offentlig støtte i Nyt BBR Inputparametre: Outputparametre: Offentlig støtte (ja/nej) Entitet: Enhed Attributter: offentlig støtte Entitet: Ejendom Attributter: Offentlig støtte Betingelse: Enheden skal eksistere Resultat: Enheden opdateres med den angivne kode Implementering: Bossinf udstiller en hændelsestabel som Nyt BBR tilgår via en webservice. Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om Bossinf er nede og offentlig støtte ikke er opdateret. Bossinf kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er ikke nødvendigvis tidstro, afhængig af implementering Synkronisering: Der kan være synkroniseringsproblemer, hvis opdateringen ikke er tidstro Kompleksitet: Simpel Overholdelse af Kontrakten: Krav Kommentarer: Koden overføres ikke til KMD- BBR i dag. To Do: Ingen udeståender. Webservicen foreligger i form af de generelle oioxml-snitflader, som BOSSINF også kan bruge. Kapitel 6 version 7.0 Side 43 af 53

44 BBR CPR 1. Hentning af navn og adresse ud fra CPR-nummer Klient Nyt BBR Server CPR Beskrivelse: I forbindelse med adressering af bl.a. BBR-Meddelelse skal man bruge ejerens navn og adresse. Inputparametre: CPR-nummer Outputparametre: Navn og Adresse Entitet: Flere Attributter: Entitet: Flere Attributter: Navn og Adresse Betingelse: Resultat: Mulighed for at påtrykke navn og adresse på bl.a. BBR-Meddelelse. Sikkerhed: Autorisation ud fra brugernavn og password. Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis man ikke kan foretage opslaget, så er det ikke muligt at få oversat CPRnr og dermed ikke muligt at adressere bl.a. BBR-Meddelelse. On-line tilgængelighed: Ikke nødvendigvis tidstro. Svartider: I forbindelse med masseudskrivninger er svartiden kritisk. Synkronisering: Nej Kompleksitet: Nej Logistik: KOMBIT stiller snitfladerne til rådighed. Overholdelse af Kontrakten: Kommentarer: Servicen benyttes kun hvis der er adressebeskyttelse (da navn og adresse da ikke kan leveres fra OIS) eller det ikke er ejeren man skal adressere til. To Do: To Do: KOMBIT aftaler med CPR. Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. Kapitel 6 version 7.0 Side 44 af 53

45 2. Opslag fra CPR af adresse i Nyt BBR Klient CPR Server Nyt BBR Beskrivelse: I forbindelse med flytningen af boligregisteret til Nyt BBR skal CPR fremover have adgang til hvilke adresser der er oprettet i Nyt BBR via en snitflade. Inputparametre: Adresse Outputparametre: Oplysning om, om adressen findes Entitet: Adgangs- og enhedsadresse Attributter: Entitet: Adgangs- og enhedsadresse Attributter: To Do: Status: Betingelse: Resultat: Sikkerhed: Krypteret forbindelse med autorisation via certifikat. Fejlhåndtering: Fejl logges på klienten. Isolation/Uafhængighed: Der kan opstå inkonsistens, hvis CPR ikke oplyses om at en given adresse ikke findes i Nyt BBR. On-line tilgængelighed: Systemet bruges til her og nu opslag ved CPR. Svartider: Forsinkelser i svartider opleves hos CPR. Synkronisering: Den er ønskværdig, men ikke kritisk. Kompleksitet: Lav Logistik: Nyt BBR stiller WebService til rådighed for CPR. Overholdelse af Kontrakten: Kommentarer: Data leveres i OIOXML. To Do: Det er aftalt, at folkeregisteret skal tilgå BBR-data via de generelle OIOXML-snitflader. Kapitel 6 version 7.0 Side 45 af 53

46 3. Opdatering af Udlejningsforhold ved samkøring af ESR, CPR og Nyt BBR Klient Nyt BBR Server CPR, ESR Beskrivelse: I forbindelse med opdatering af udlejningsforhold sammenkøres udtræk fra CPR og ESR med data fra Nyt BBR. Inputparametre: Outputparametre: Udtræk af alle ejere og lejere i CPR. Entitet: Attributter: Entitet: Attributter: Udlejningsforhold Betingelse: Resultat: Opdatering af udlejningsforhold i Nyt BBR. Sikkerhed: Overførsel af data sker via FTPS. Fejlhåndtering: I forbindelse med kørslen udskrives en fejlliste. Isolation/Uafhængighed: Alle systemer er nødvendige. On-line tilgængelighed: Dette er en batch-kørsel. Svartider: Nej Synkronisering: Nej Kompleksitet: Middel Logistik: Data overføres fra ESR og CPR i flade filer til Nyt BBR. Her læses de ind i Nyt BBR i tilknyttede tabeller. Efter indlæsningen køres der en stored procedure der opdaterer udlejningsforhold. Overholdelse af Kontrakten: Kommentarer: To Do: To Do: Håndtering af redundante data vs. opdaterede data: Ingen dataredundans Status: Webservice er implementeret. Ingen udestående. Opdatering af udlejningsforhold sker ved samkøring af ESR, BBR og CPR. I opdatering af udlejningsforhold indgår 3 datasæt: Udtræk fra ESR som indeholder kommunenr, ejendomsnr, ejerlejlighedsnr og CPRnr. Dette hentes via FTPS på en FTP-server hos KMD. Udtræk fra CPR som indeholder oplysninger om CPRnr. og adresse. Dette hentes via FTPS på en FTP-server hos CSC. Udtræk fra Nyt BBR som indeholder kommunenr, ejendomsnr, ejerlejlighedsnr, adresse, boligtypekode og anvendelseskode. Kapitel 6 version 7.0 Side 46 af 53

47 Når ESR-udtrækket er hentet, læses det ind i tabel ESR_Ejer i database JR5000PD i Nyt BBR via et SSIS job. Når udtrækket fra CPR er hentet, læses det ind i tabel CPR_Adresse i database JR5010PD i Nyt BBR via det job, som indlæser og opdaterer data fra CPR. Jobbet hedder OpdaterCPRData.exe. Når data er indlæst køres stored procedure bbr_domain.usp_enhedupdatebatchudlejningsforhold2, som herefter opdaterer kolonnen Udlejningsforhold2 i tabellen Enhed. Proceduren opdaterer udlejningsforhold med én af følgende værdier: 1. Udlejet 2. Benyttet af ejer 3. Ikke benyttet Først opsættes kode 3. Hvis BBR-enheden ikke er i CPR_Adresse tabellen. Derefter opsættes kode 2, hvis et CPR nummer fra CPR_Adresse, der bebor en enhed, matcher tabellen ESR_ejer på den pågældende ejendom. De resterende sættes til kode 1. Tabellerne ESR_ejer, BBR_Adresse og CPR_Adresse er arbejdstabeller og indgår derfor ikke i den logiske datamodel. Kørslen vil ske 3 gange årligt (april, september og december). Kapitel 6 version 7.0 Side 47 af 53

48 Kapitel 6 version 7.0 Side 48 af 53