Personer, organisationer og adresser. Standard. IT- og Telestyrelsen København den 25. november FESD standardisering Datamodel Version 0.2.

Størrelse: px
Starte visningen fra side:

Download "Personer, organisationer og adresser. Standard. IT- og Telestyrelsen København den 25. november FESD standardisering Datamodel Version 0.2."

Transkript

1 Personer, organisationer og adresser Standard IT- og Telestyrelsen København den 25. november 2005 FESD standardisering Datamodel Version 0.2.2

2 Kolofon: FESD datamodel. Personer, organisationer og adresser. FESD standardisering. Datamodel Version 0.2 Denne standard kan frit anvendes af alle. Citeres fra standarden i andre publikationer til offentligheden skal angives korrekt kildehenvisning. Forslag til FESD standarder udarbejdes af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen i samarbejde med de tre FESD leverandører Software Innovation A/S, Accenture I/S og CSC Danmark A/S. Kontaktperson i FESD standardisering: Projektleder Tom Bøgeskov, Mail-adresse Telefon (direkte) Accenture I/S Lautrupsgade København Ø Telefon: Web-adresse: CSC Danmark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade 10 DK-2850 Nærum Telefon: Web-adresse: Ministeriet for Videnskab, teknologi og Udvikling IT- og Telestyrelsen IT- strategisk kontor Holsteinsgade 63 DK-2100 København Ø Telf Fax / 56

3 Del A. Baggrund 1. Indledning Som en del af FESD-datamodellen skal der standardiseres dataelementer, der omhandler adresse-området. Adressemodellen, der således er en delmængde af FESD-standardiseringens komplette datamodel, har til formål at beskrive de kontakt- og lokationsinformationer der er nødvendige for at et FESD-system kan varetage: Håndtering af stedrelaterede sagstyper; eksempelvis miljø-, ejendoms- og matrikelsager. Håndtering af sagstyper hvor en person, en organisation eller en virksomhed er sagens hovedemne. Håndtering af kontaktinformationer for sagsparter. Desuden skal adressemodellen give grundlaget for maskinel kommunikation med eksterne registre der indeholder de ovenfor nævnte data, eksempelvis CPR (Centrale personregister), CVR (Centrale virksomhedsregister), BBR (Bygnings- og Boligregister); hvilket er specificeret som en forudsætning for FESD-standardiseringsarbejdet. 2. Afgrænsning Det skal indledningsvist nævnes, at FESD-datamodellen for adresse-området ikke baserer sig på eller tager udgangspunkt i den norske NOARK, som det øvrige FESD-datamodel arbejde. Grunden til dette er, at det er anset for vigtigt at ESDH-systemer er kompatible med de store registre på netop dette område af hensyn til genbrug af data, som alligevel opsamles i Danmark. Det er dog anset for hensigtsmæssigt, at de forskellige FESD standardiseringsaktiviteter, når relevant, skal give indblik i NOARK s behandling af emnet. Dvs. når der fx skal udarbejdes datamodel for adresse-området skal indledningsvist kortfattet redegøres for hvorledes NOARK behandler området. Det skal således her anføres, at NOARK-4 har et antal tabeller, der styrer adresser samt person og organisationsdata. Det er primært tabellerne eller klasserne - som vist i det efterfølgende diagram, hvor enkelte klasser kan være udeladt. De væsentligste klasser for adresseområdet er dog de på diagrammet nævnte. 3 / 56

4 cd Noarks adressemodel Adresser::POSTNR + PO_KOMMUNE: + PO_KOMNR: + PO_NEDLDATO: + PO_OPRDATO: + PO_POSTNR: + PO_POSTSTED: Journalpost::AVSMOT Adresser::ADRTYPE + AT_BETEGN: + AT_KODE: Adresser::ADRESSEKP + AK_ADRGRUPPE: + AK_ADRID: + AK_BASEID: + AK_EPOST: + AK_FAKS: + AK_KORTNAVN: + AK_MOBIL: + AK_NAVN: + AK_OPDGRUPPE: + AK_ORGNR: + AK_OVERORD: + AK_PERSOK: + AK_POSTADR: + AK_POSTNR: + AK_POSTSTED: + AK_REGEPOST: + AK_TGGRUPPE: + AK_TILDATO: + AK_TLF: + AK_TYPE: + AK_UTLAND: Organisasjon:: ADRADMENH + AA_ADMID: + AA_ADRID: Tilgangstyring:: ADRPERSON + PA_ADRID: + PA_PEID: + AM_ADMID: + AM_ADRESSE: + AM_AVSKAV: + AM_AVSKDATO: + AM_AVSKM: + AM_BEHANSV: + AM_BESVAR: + AM_EPOSTADR: + AM_FORSEND: + AM_FRIST: + AM_FSSTATUS: + AM_GRUPPE: + AM_GRUPPEMOT: + AM_ID: + AM_IHTYPE: + AM_JENHET: + AM_JPID: + AM_KOPIMOT: + AM_KORTNAVN: + AM_NAVN: + AM_POSTNR: + AM_POSTSTED: + AM_REF: + AM_SBHID: + AM_U1: + AM_UTLAND: Sakshåndtering:: SAKSPART Adresser:: MEDLADRGR + MG_GRID: + MG_MEDLID: Adresser:: KPFORMAT + KF_ADRID: + KF_FORMAT: Adresser::DIGISERT + SE_ADRID: + SE_EPOST: + SE_FRADATO: + SE_ID: + SE_NAVN: + SE_SERT: + SE_SIGNTEKST: + SE_TILDATO: + SE_TTPEPOST: + SE_VERAV: + SE_VERDATO: Adresser:: KPAUTORIS + KA_ADRID: + KA_AUTAV: + KA_AUTDATO: + KA_FRADATO: + KA_TGKODE: + KA_TILDATO: + SP_ADRESSE: + SP_EPOSTADR: + SP_FAKS: + SP_KONTAKT: + SP_KORTNAVN: + SP_MERKNAD: + SP_NAVN: + SP_POSTNR: + SP_POSTSTED: + SP_ROLLE: + SP_SAID: + SP_TLF: + SP_U1: + SP_UTLAND: NOARK 4 på adresseområdet. UML-diagram over de mest centrale klasser/tabeller Det bemærkes som nævnt ovenfor, at NOARK ikke er skønnet særlig relevant for FESDstandardiseringarbejdet på adresse-området på grund af særlige danske forhold; dvs. de store registre CPR, CVR, BBR etc. som kan give mulighed for genbrug af data. 4 / 56

5 Del B. Forretningen vedrørende adressedata og ESDH 1. Indledning Inden der kan konstrueres den nødvendige del-datamodel og de nødvendige grænsesnit er det nødvendigt at beskrive det forretningsområde hvori model og grænsesnit indgår; eller med andre ord hvad de omhandlede data bruges til i ESDH-systemer. Efter gennemgang af fx NOARK-4 ses, at i forhold til ESDH har person/organisation og adresseoplysninger ikke nogen væsentligt selvstændig unik forretning. Person/organisation- og adresseoplysninger indgår som meget nødvendige hjælpeoplysninger i forbindelse med forretningen sagsbehandling men er i den forbindelse samlet set mindre vigtige i forhold til andre typer af dataelementer, der vedrører sager og dokumenter. Den forretning, der beskrives i det følgende, omhandler derfor først og fremmest helt praktiske forhold knyttet til funktionalitet ved håndtering af adresse-data. Beskrivelsen kan opdeles i to overordnet forskellige dele: 1. Oprettelse og vedligeholdelse af person/organisation- og adresseoplysninger i et ESDH-system 2. Brug og behandling af person/organisation- og adresseoplysninger i forbindelse med brug af ESDH 2. Oprettelse og vedligeholdelse af person/organisation- og adresseoplysninger i et ESDH-system Oprettelse af registre Der er i princippet to muligheder for at oprette registre: Automatisk eller ved inddatering. I det følgende forudsættes automatisk inddatering, hvilket dog ikke må afskære et system muligheden for manuel inddatering. En automatisk oprettelse kan i princippet foregå ved en batch-overførsel af de nødvendige oplysninger eller ved en online overførsel af de nødvendige oplysninger. FESDstandardiseringen tager ikke stilling til hvordan et ESDH-system således ajourføres med person/organisation og adresseoplysninger, men forudsætter blot at disse eksisterer i ESDH-systemet. Det må forventes, at data i videst muligt omfang hentes fra centrale registre og lagres lokalt i ESDH-systemets adressedatabase som redundante data, bl.a. for at sikre at benyttede adresseoplysninger lagres i ESDH-systemet til brug for senere visning af sagers og sagsparters tilknyttede adressedata. Det må formodes, at en fremtid med en fuldt udbygget service orienteret arkitektur (SOA) kan overflødiggøre lokale redundante registre, men det må samtidig konstateres, at den nødvendige infrastruktur endnu ikke er opbygget - og at det ikke vides, hvornår SOA vedrørende fx adresse-data er en realitet. Planlægningen vedrørende adresse-data må således tage højde for at fremtiden bliver SOA orienteret, men må samtidig indstille sig på, at fortidens metoder stadig vil fungere i en overgangsperiode af ukendt længde. 5 / 56

6 Vedligehold af registre Vedligehold kan foregå forskelligt, både automatisk og manuelt. Det følgende centrerer om automatisk understøttet vedligehold, men det skal nævnes, at manuel vedligehold stadig bør være mulig. Registre skal opdateres, når der foreligger ændringer og den mest hensigtsmæssige måde at opdatere på er ved alene at opdatere nyt, dvs. ændringer og tilføjelser. I det følgende centreres således om brug af web-service til sådanne opdateringsformål. På de relevante områder findes CPR (Centrale personregister), CVR (Centrale virksomhedsregister), BBR BBR (Bygnings- og Boligregister) / OIS (den Offentlige Informations Server) og senere FOA (Fælles Offentlig Adressebase p.t. under opbygning i ITST) som store autoritative registre, der er relevante for person/organisation- og adresseoplysninger knyttet til ESDH. Af disse tilbyder CVR allerede web-service til overførsel af data, og de øvrige må forventes også at kunne tilbyde web-service på et tidspunkt. Men uanset muligheden for web-service, er disse registre at opfatte som autoritative dataleverandører, hvorfor person/organisation- og adresseoplysninger i ESDH-systemer bør indrettes således at ESDH-systemets lokale registre på disse områder altid kan udnytte de store autoritative registre. Endvidere skal nævnes, at KMD vedligeholder en kopi af CPR-registret, kaldet P-data, der anvendes på tværs af de kommunale løsninger. P-data står til rådighed for alle kommuner, og dataadgang kan opnås gennem web-services.den fremtidige funktionalitet/forretning for ESDH-systemer er således, at vedligehold på de relevante områder sker via udnyttelse af disse registre. ESDHsystemet skal således have mulighed for at importere data fra disse registre og helst uden forudgående mapninger og/eller konverteringer. 3. Brug og behandling af person/organsation- og adresseoplysninger i forbindelse med brug af ESDH Oprettelse af sag principiel hovedfunktionalitet: Ved oprettelse af sag skal tilknyttes en sagsbehandler typisk fra egen organisation, dvs. fx fra register over ansatte. ESDH-systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til sag Fremsøgning, visning samt efterfølgende tilknytning til sag Modtagelse af dokumenter principiel hovedfuntionalitet: Ved modtagelse af dokumenter registreres typisk person/organisation som har afsendt dokumenterne, hvilket kan gøres ved enten indtastning af oplysningerne eller ved fremsøgning af de nødvendige oplysninger i ESDH-systemets lokale persons/organisationog adresseoplysnings registre. ESDH-systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til dokumenter Fremsøgning, visning samt efterfølgende tilknytning til dokument Afsendelse af dokumenter principiel hovedfunktionalitet Ved afsendelse af dokumenter registreres typisk at det er afsendt dokument samt modtager af dokumentet 6 / 56

7 ESDH systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til dokumenter Fremsøgning, visning samt efterfølgende tilknytning til dokument De tre nævnte overordnede funktioner - oprettelse af sag, modtagelse af dokument, afsendelse af dokument - kræver alle samme typer af funktionalitet i forbindelse med person/organisation og adresseoplysninger. Den væsentligste forskel er, at det er data fra forskellige registre, der skal benyttes. Der er således i ESDH-systemet behov for data fra følgende typer af registre: Register over ansatte i egen organisation Register over personer der kan blive sagsparter (i princippet alle) Register over organisationer der kan blive sagsparter (i princippet alle både offentlige og private) De væsentligste krav der således stilles er at, Den daglige brug af og funktion af adresseoplysninger i sagsbehandlingen skal være mulig ESDH-systemers datamodel på person/organisation- og adresseoplysninger skal indrettes således, at de beskrevne dataoverførsler og opdateringer bliver mulig. Det betyder, at det foreliggende arbejde skal skitsere de samlede dataelementer på person/organisations og adresseområdet også under hensyn til hvilke data der kan overføres fra CVR (Centrale virksomhedsregister), CPR (Centrale personregister), BBR (Bygningsog Boligregister) / OIS (den Offentlige Informations Server) samt FOA (Fælles offentlig adressebase). 7 / 56

8 Del C. Data og adresseområdet m.v. 1. Model for dataflow -adressedata Dataflow et skal understøtte de ønskede funktioner i et ESDH-system i relation til udarbejdelse af integrationer til de store stamregistre (CPR, CVR etc.) I princippet skal følgende logik kunne håndteres af et ESDH-system: CPR Inddate ring CVR BBR FOA Stamregistre i eller online overførsel til ESDH-system. Baseret på import Dynamisk Partskartotek i ESDH-system. Tilvækst med tilvækst af Journalposter. Hver part/adresse er knyttet til mindst én Journalpost Statisk Det er således data fra det ovenfor nævnte dynamiske stamregistre, der knyttes til ESDH-specifikke data. Det deraf afledede Partskartotek er statisk, hvilket betyder, at fx en person med to adresser på forskellige tidspunkter kan optræde to gange i Partskartotek. Dette er nødvendigt, da journalisering af fx et brev hvortil der knyttes en afsender, skal benytte personens aktuelle adresse for tidspunktet for brevets oprettelse. En yderligere binding til dette dataflow er et ønske om at web-service knyttet til de store registre skal være mulig. Bemærk dog, at skitsen alene afspejler hvad der skal være et muligt logisk dataflow og er ikke udtryk for eller forslag til faktiske implementeringer. 2. FESD adressedatamodel Introduktion og afgrænsning FESD-standarden på adresseområdet skal således åbne mulighed for at adresseregistre m.v. i ESDH-systemer kan opdatere data via web-services (integrationer) knyttet til de store registre, dvs. CPR, CVR, BBR og også FOA. I det følgende gives en introduktion til FESD-adressedatamodellen og afgrænsning af relationerne til et antal "hoved-adressekilder". Formålet er at udveksle adressedata mellem adressesystemer og ESDH-systemer som overholder FESD-standarden. Disse adressedata vil 8 / 56

9 2.1 CPR-systemet 2.2 BBR-systemet 2.3 CVR-systemet primært være baseret på adresser fra CPR-, BBR- og CVR-systemerne. Desuden omtales koblinger til adressedata i FOA-systemet samt til adresse-datamodeller i EPJ-systemer, og OIOXML Adresseguide beskrives som den samlende standard for visse af de relevante data i denne sammenhæng. CPR-personadressedata hentes typisk ind i et ESDH-system som "read-only" og lagres som en del af sagen. Teknisk set vil det ligeledes kunne lade sig gøre, at et fagsystem i forbindelse med et standardiseret ESDH-system kan anvende CPR-systemets interfaces til ajourføring af en persons CPR-adresse. Typisk ajourføres CPR-systemets data om borgere af medarbejdere i folkeregistrene, der anvender Java-klienter. Et system, der ligeledes ajourfører CPR-systemets venteregister er KMD s P-data-system. Via dette system har borgeren mulighed for at indberette oplysning om flytning til CPR s venteregister. Borgerens oplysninger overføres først fra venteregistret til selve CPR-registeret, når en kommunal myndighed har valideret borgerens indberetning. Såfremt der identificeres andre behov for opdatering af CPR-adressedata, fx i forbindelse med FESD, så skal CPR-kontoret inddrages for at vurdere, om det er tilladeligt. I forbindelse med kommunikation mellem BBR og et ESDH-system forudsættes, at BBRdata for bygninger og ejendomme hentes ind i ESDH-systemet fra OIS, og at ESDHsystemet ikke kommunikerer direkte med KMD's forskellige centraler, herunder Århus's og Københavns kommunes EDB-centraler. Det forudsættes, at procedurer og krav til sikkerhed omkring anvendelse og opdatering af BBR-data er tilsvarende de, der gælder for andre store systemer med personhenførbare data, som fx ToldSkat - blot gældende på kommuneniveau. Anvendelse og opdatering af BBR-data finder således sted under et bruger- og autorisationssystem, som ligger i KMDregi. Og opdatering af en kommunes BBR-oplysninger kan kun finde sted af autoriserede BBR-sagsbehandlere i den pågældende kommune. Anvendelsen (forespørgselsadgang) er kun mulig - landsdækkende - enten gennem BBR i SVUR eller i OIS, der drives af KMD. Virksomhedsdata i CVR-systemet ajourføres af de ansvarlige dataleverandører ToldSkat, E&S (Erhvervs- og Selskabsstyrelsen), DSt (Danmarks Statistik) og ABT (Arbejdstilsynet). Det er i regler fastlagt, hvem der har kompetence over hvilke data og for hvilke virksomhedsformer. E&S har fx selskaber som ansvarsområde. Og ToldSkat har enkeltmandsvirksomheder - stadigvæk - selv om den praktiske vedligeholdelse foretages via et system hos E&S. DSt har ansvar for vedligehold af de offentlige myndigheder. Vedligeholdsansvaret gælder for navn, adresse, virksomhedsform og livsforløb. For brancher ligger ansvaret formelt hos DSt, men 'alle' kan ajourføre. Til de enkelte virksomheder hører en eller flere produktionsenheder, der har 'samme slags data' med samme format - fx ensartet opbygning af adresser - som virksomheden, men hvor ansvaret formelt ligger hos DSt - dog 'hjælper' ABT til med at ajourføre. For virksomhederne gælder i praksis, at de ansvarlige dataleverandørers egne systemer 'fanger' og kontrollerer data, fx adresser, og sender dem videre til CVR, hvis de er i orden. CVR-systemet indeholder ikke ret meget kontrol af data, idet det er lagt an på at de ansvarlige leverandører også er de rette ansvarlige for datakvaliteten. Dette forventes også at være gældende for produktionsenhederne. CVR-systemet tilbyder desuden en browsergrænseflade, der er tænkt anvendt af myndigheder, som ikke selv har et eget 'datafangst- og registreringssystem', fx til brug for ABT. 9 / 56

10 2.4 Konklusioner vedr. CPR, BBR og CVR Det anbefales, at adressedata i første omgang alene modtages ind i FESD-systemerne fra "hoved-adressekilderne", CPR-, BBR(OIS)- og CVR-systemerne dvs. envejskommunikation. Opdatering af adressedata bør ske direkte i de centrale registre. Senere - når færdigudbygget - forventes anvendelse af adressedata fra FOA-systemet også komme på tale. 2.5 Kobling til FOA-systemet Det fælles offentlige adressesystem, FOA, har til formål at vedligeholde adresseoplysninger blandt andet for myndigheder og personer, som er tilknyttet den offentlige forvaltning i statslig regi. FOA-systemet indeholder en offentlig portal. Samt en redigeringsportal, som benyttes til at vedligholde entitetstyper, fx myndigheder og personer, samt postnumre, stillingsbetegnelser, partier, ordener osv. Både for personer og til myndigheder kan oprettes felter til bl.a. navn, adresselinier, postnummer, by, land, telefonnumre, faxnumre, mailadresser, hjemmesider samt CVR/CPR numre. Udover felterne til navn, adresse og øvrige kontaktoplysninger kan både for myndigheder og personer angives en værdi indenfor en række klassificeringer, det kunne f.eks. være parti, lønramme m.v. Det er også muligt at vedligeholde myndighedseller ordenshierarkierne. Desuden findes en administrationsportal, som blandt andet benyttes til brugeradministration. Brugergrænsefladen til redigeringsportalen er webbaseret. Det overordnede formål for redigeringsportal er at tilbyde funktionalitet til at kunne søge og administrere diverse entiteter i systemet. FOA omfatter blandt andet følgende entiteter: Myndigheder, personer, funktioner (beskriver en persons tilknytning til en myndighed), titler (beskriver de titler en person kan have), partier (beskriver sammenhængen mellem partibetegnelser og partinavne), ordner (beskriver sammenhængen mellem ordenskoder og ordensnavne og kan tilknyttes personer). FOA-systemet består primært af en myndighedsdatabase og en persondatabase. Myndighedsdatabasen Indeholder p.t aktive enheder. Persondatabasen indeholder ca personer. Alle personer i databasen er relateret til en eller flere enheder/myndigheder og/eller en eller flere ordener. FOA-systemet er stadig i færd med at blive udbygget og adressedata fra FOA-systemet forventes at blive inddraget i FESD-standardiseringsarbejdet på et senere tidspunkt. 2.6 OIOXML adresseguide For at skabe sammenhæng til anden dataudveksling i det offentlige skal FESD-standarden på adresseområdet også rette ind efter den adresse standardisering der sker i XML-projektet, dvs. den eksisterende OIOXML adresseguide, som er en del af det standardiseringsarbejde, som finder sted under den fælles offentlige XML-komité i regi af Nøgledatagruppen. Nøgledatagruppens primære opgave er at tilvejebringe XML-beskrivelser af data i de tre nøglebaser: CVR - Det Centrale Virksomhedsregister, CPR - Det Centrale Personregister, BBR - Bygnings- og Boligregistret samt Told & Skats databaser. Formålet er at identificere og standardisere informationsobjekter, som er fælles for mange af de offentlige IT-systemer. En adresse er et sådant fælles informationsobjekt. I OIOXML adresseguide anbefales endvidere de adressetyper som Nøgledatagruppen finder bedst egnet som udvekslingsformat i forskellige situationer. OIOXML adresseguide standarden omfatter således data fra flere af de samme hovedkilder, som er relevante for ESDH-systemer, hvorfor FESD standardiseringen anvender denne hvad angår udvalg af data og beskrivelser af disse til udveksling i forbindelse med grænsesnit. 10 / 56

11 2.7 Kobling til adressedata i andre systemer: EPJ-systemer På sigt kan det være relevant og muligt at etablere en integration mellem ESDH-systemer og EPJ (Elektronisk Patient Journal)-systemer, da disse to typer systemer begge er baseret på CPR-informationer om personer i dette tilfælde patienter. De fleste EPJ-systemer og PAS (Patient Administrative)-systemer benytter (i princippet) samme adresse-datamodel, som benyttes i CPR-systemet. EPJ/PAS-systemer fx GS (Grønt System) indeholder egne adressedatabaser for at sikre, at disse for samfundet kritiske systemer om nødvendigt kan køre uafhængigt af andre adressedata-kilder. Nye eller ændrede adressedata for personer (patienter) og ændrede vejregister-data overføres fra CPR-registret via batch-opdatering til de (centrale) EPJ/PAS-systemer, som abonnerer på CPR-systemets personadresse- og vejregisterdata. Det er desuden muligt at oprette egne person-adressedata i EPJ-systemet, men disse personadressedata vil blive overskrevet af eventuelle CPR-adressedata, som modtages fra CPR-registret for samme CPR-nummer. Det tilstræbes, at adressedata i EPJ-systemer så vidt muligt er synkroniseret med på personadresse- og vejregisterdata fra CPR-systemet. Der sker ingen eller kun begrænset transformation/mapning af adressedata, som modtages fra CPR-systemet. Tilsvarende sker der ingen eller kun begrænset berigelse af person (patient) adressedata i EPJ-systemerne. Et eksempel er dog den entydige personidentifikation, som oftest vil være det officielle CPR-nummer, som fås fra CPRregistret, men personidentifikationen kan i nødstilfælde udgøres af et midlertidigt erstatnings-cpr-nummer, som fx kan tildeles en patient, der ankommer bevidstløs til et sygehus. FESD-datamodellen på adresseområdet kobler ikke til EPJ-systemer, men da både EPJ- og FESD-datamodellen vedrørende personer og adresser relaterer sig til CPR-data, burde der kunne opnås kompatibilitet vedrørende disse data. 11 / 56

12 Del D. FESD-adressemodel Modellen er beskrevet ved anvendelse af UML 2.0. Den model der beskrives i det efterfølgende skal, som tidligere nævnt, kunne anvendes i forbindelse med: 1. håndtering af sagstyper hvor en person, en organisation eller en virksomhed er sagens hovedemne. 2. håndtering af stedrelaterede sagstyper; eksempelvis miljø-, ejendoms- og matrikelsager. 3. håndtering af kontaktinformationer for sagsparter. For at dække punkt 1 skal modellen kunne indeholde data om: Individuelle personer Råd, nævn og udvalg inklusiv tværorganisatoriske. Organisationer og virksomheder Organisatoriske enhedstyper som afdeling, styrelse, kontor og lignende. Til det formål indgår klasserne Person, Gruppe, Organisation og OrganisatoriskEnhed i modellen. Da disse fire klasser alle kan have samme type af kontaktinformationer tilknyttet og alle kan have samme association til klassen Sag, kan de med fordel betragtes som havende samme superklasse eller generalization. I modellen repræsenteres denne af en abstrakt klasse, kaldet Kontakt. cd K ontakt Person Gruppe OrganisatoriskEnhed Organisation Bemærk at Kontakt ikke kan have instanser. Klassen vil med andre ord ikke kunne optræde som objekter af denne type. Alle associationer og attributter der tilknyttes Kontakt tilknyttes altså til hver og en af klassens underklasser. For at dække punkt 2 skal modellen kunne indeholde data om: Matrikel Ejendomme Bygninger Klasserne MatrikelOplysning, Ejendom og Bygning indgår i modellen. MatrikelOplysning Ejendom Bygning 12 / 56

13 Data der dækker kravet under punkt 3 vil være de almindeligt tilgængelige former for kontaktmetoder, som: E-post Telefon og telefax Almindelig (papir) post Som led i modelleringen af ovenstående behov indgår klasserne ElektroniskPostAdresse, Telefon, Adresse og UdlandsAdresse. ElektroniskPostAdresse Telefon Adresse UdlandsAdresse Ud over disse centrale klasser indgår der en række andre klasser hvis primære formål er at kvalificere de ovenfor nævnte klasser. Alle klasser beskrives i de efterfølgende afsnit. Sammenhængen mellem FESD-modellens sags- og dokumentkerne og adressemodellen skabes med associationer med kerneklasserne JournalPost og Sag som illustreret i nedenstående diagram. Sag- og dokumentstyring::journalpost Sag- og dokumentstyring::sag +modtager +afsender 0..* +sagspart +sagsgenstand +sagsgenstand Bygning 0..* Kontakt +sagsgenstand Ej endom Person Gruppe OrganisatoriskEnhed Organisation +sagsgenstand MatrikelOplysning Et separat dokument indeholder et diagram over den samlede UML-model jf. bilag Samlet UML-model for adresseområdet (publiceret særskildt). I nærværende dokument beskrives de enkelte klasser og disses associationer. Strukturreformen og adressemodellen På nuværende tidspunkt er det erkendt at den kommende strukturreform kan medføre ændringer for vejkode og ejendomsnummer. Disse to datatyper er dags dato entydige indenfor den enkelte kommune. For at sikre en tilsvarende entydighed efter kommunesammenlægning, er en revision af datatypernes format nødvendigt. Adressemodellen vil blive tilpasset de ændringer der måtte komme som følge af det igangværende arbejde med strukturreformen, så snart disse ændringer er bekendtgjort. 13 / 56

14 Objekteksempel Til brug til illustrering af adressemodellen anvendelighed er nedenfor vist et simpelt eksempel, hvor et meget lille udsnit af KL s formand Ejgil W. Rasmussens offentligt tilgængelige data er anvendt. Selvom dette eksempel ikke dækker alle klasser i modellen, kan den forhåbenligt med fordel bruges til at lette forståelsen af hele modellen. Læseren opfordres til dels at vende tilbage til denne beskrivelse under gennemgangen af modellen, dels til selv at finde lignende eksempler fra den virkelige verden og afprøve dem mod modellen. Obj ekteksempler :Telefon tlfnr = privattelefon = true fax = false :Person fornavn = Ejgil mellemnavn = Winther efternavn = Rasmussen adresseringsnavn = Ejgil W. Rasmussen foedselsdato = foedselsdatousikker = false koen = M navnadressebeskyttelse = false unikid = reklamebeskyttelse = false :RolleRelation rolleforumid = 789 rolleforumtype = Gruppe rollestartdato = RolleRelation.rolleForumID = Kommune.unikID :RolleRelation rolleforumid = 6543 rolleforumtype = Kommune rollestartdato = 1986 :Rolle rollenavn = Formand rollebeskrivelse = Formand for en bestyrelse, et udvalg el. lign. :Rolle rollenavn = Borgmester rollebeskrivelse = Øverste myndighedsperson i en kommune. RolleRelation.rolleForumID = Gruppe.unikID :Gruppe gruppenavn = KL's bestyrelse unikid = 789 reklamebeskyttelse = false :Kommune kommunenr = 609 organisationsnavn = Gedved Kommune cvrnr = branchekode = virksomhedsform = 250 orgstart = unikid = 6543 reklamebeskyttelse = false :VirksomhedsType :VirksomhedsType virksomhedsform = 110 typenavn = Forening :Organisation organisationsnavn = KL cvrnr = branchekode = virksomhedsform = 110 orgstart = unikid = 5678 reklamebeskyttelse = false :Adresse unikid = 2345 landkodealfa2 = DK kommunenr = 101 vejkode = 8122 bynavn = København postboks = 3370 postnr = 2300 lokalitetsnavn = KL Huset virksomhedsform = 250 typenavn = Primærkommune :PostDistrikt postnr = 2300 postdistrikt = København S :Telefon tlfnr = privattelefon = false fax = false :Telefon tlfnr = privattelefon = false fax = true :ElektroniskPostAdresse epostadresse = privatepost = false :Vej kommunenr = 101 vejkode = 8122 vejnavn = Weidekampsgade vejadresseringsnavn = Weidekampsgade 14 / 56

15 Beskrivelse af klasser Kontakt Klassen er en abstrakt klasse der ikke implementeres med instanser. Klassen indeholder de attributter og associationer der er fælles for klassens underklasser, Person, Gruppe, Organisation og OrganisatoriskEnhed. Klassen (og dens underklasser) kan antage rollen som sagspart og rollen som sagsgenstand i forhold til klassen Sag. I rollen som sagsgenstand er Kontakt emne for sagen. cd Sags- og dokumentstyring::sag Sags- og dokumentstyring::journalpost +sagsgenstand +sagspart +afsender 0..1 K ontakt + unikid : int + reklamebeskyttelse: boolean = false +modtager 0..* I relation til JournalPost kan Kontakt antage enten en modtager - eller en afsender -rolle. Attribute Type Kardinalitet Beskrivelse unikid int 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Attributten reflekterer den tilsvarende oplysning i CPR- og CVRregistrene. Person Person-klassen afspejler at kun følgende attributter kan forventes kendt for hver instans af Person: fornavn efternavn koen Alle øvige attributter kan altså ikke forventes at eksistere i hver enkelt instans. cd Adressemodel +careof * Person + forn avn: char(50) + mellemnavn: char(40) [0..1] + eftern avn: char(40) + adressering snavn: char(34) [0..1] + foedselsdato: date [0..1] + foedselsdatousikker: boolean = true + koen: char(1) + cprn r: int(10) [0..1] + cprn rstatus: int(2) [0..1] + navnadressebeskyttelse: boolean = false + beskyttelseslutdato: date [0..1] ::Kontakt + unikid : int + reklamebeskyttelse: boolean = false 15 / 56

16 Associationen careof Denne association udtrykker at en person har c/o adresse hos en anden person. Attribute Type Kardinalitet Beskrivelse fornavn char(50) 1 Den samlede længde af fornavn må ikke overskride 50 karakterers længde mellemnavn char(40) 0-1 Den samlede længde af mellemnavn må ikke overskride 40 karakterers længde efternavn char(40) 1 Feltets indhold kan bestå af flere navne adskilt af en blank position eller af en bindestreg. Feltet kan være blank for børn, hvis disse endnu ikke er navngivet. adresseringsnavn char(34) 0-1 Jf. 5 i Indenrigsministeriets bekendtgørelse nr. 842 af 13. oktober 2003 foedselsdato date 0-1 Dato angivet som DDMMAA foedselsdatousikker boolean 1 Sættes til true når angivelsen af fødselsdatoen er behæftet med usikkerhed. Sættes altid til true når foedselsdato ingen værdi har. koen char(1) 1 'koen' kan sættes til værdierne 'K' (for kvinde) eller 'M' (for mand), cprnr int(10) 0-1 Entydig identifikation på en person. Noter at cprnr ikke fungerer som entydig identifikator for klassen, da cprnr ikke kan forventes kendt for alle instanser. cprnrstatus int(2) 0-1 Angiver om et personnummer er aktiv, inaktiv eller en række andre oplysninger. navnadressebeskytt else boolean 1 Markering der viser om personen har navne-/adressebeskyttelse beskyttelseslutdato date 0-1 Angiver datoen for adressebeskyttelsens ophør. Normalt et år efter beskyttelsens oprettelse. Arvet fra Kontakt unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Gruppe Klassens instanser omfatter alle former for udvalg, råd og nævn, såvel indenfor en organisation som tværorganisatorisk. Angivelse af en gruppes medlemmer angives ved brug af klassen RolleRelation der beskrives efterfølgende. En instans af Gruppe kan være tilknyttet en organisation eller en organisatoriskenhed. cd Kontakt Gruppe + g ruppenavn: char(50) + g ruppefrad ato: date + g ruppetildato: date [0..1] ::Kontakt + unikid : int + reklamebeskyttelse: boolean = false 0..* +foraeldregruppe * * 0..1 Organisation OrganisatoriskEnhed +foraeldreenhed 0..1 Kontakt Kontakt 0..* organisatoriskstruktur Attribute Type Kardinalitet Beskrivelse gruppenavn char(50) 1 Navn på gruppen. gruppefradato date 1 Angiver oprettelsesdatoen. For alle PersonGruppe-instanser kendes oprettelsesdatoen. 16 / 56

17 gruppetildato date 0-1 Angiver den dato instansen ophørte med at fungere. Arvet fra Kontakt unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Organisation Klassen beskriver organisationer og virksomheder. Klassens instanser kan hver bestå af et antal instanser af OrganisatoriskEnhed. Denne sammenhæng beskrives via en compositeassociation. cd Adressemodel Organisation + organisationsnavn: char(50) + cvrnr: int(8) [0..1] + branchekode: int(6) [0..1] + orgstart: date [0..1] + orgophoer: date [0..1] ::Kontakt + unikid: int + reklamebeskyttelse: boolean = false Attribute Type Kardinalit et Beskrivelse organisationsnavn char(50) 1 Navnet på organisationen eller virksomheden cvrnr int(8) 0-1 Det tildelte CVR-nummer. branchekode int(6) 0-1 Organisationens primære branche. Branchebetegnelserne er harmoniseret i EU, og gengivet i "Dansk Branchekode 1993, 2. udg." (DB93). Enhederne tildeles en branche ud fra de 810 brancher i DB93, efter en konkret analyse eller efter bedste skøn. orgstart date 0-1 Dato for starten på organisationen. Startdatoen afhænger af den juridiske enheds virksomhedsform. For enheder der er registreret hos Erhvervs- og Selskabsstyrelsen er startdato som udgangspunkt stiftelsestidspunktet. For ToldSkats enheder vil startdatoen være datoen for pligternes ikrafttræden. Offentlige enheder har andre startdatoer (kommuner fx ved kommunalreformen ). Danmarks Statistik registrerer disse datoer i CVR. orgophoer date 0-1 Dato for ophør for organisation Arvet fra Kontakt unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Det skal bemærkes at attributten branchekode kan anvendes til ikke blot at angive branche i almindelig forstand, men også til at vise foreningstyper. Foreninger oprettes som instanser af klassen Organisation og påføres den branchekode der er relevant for foreningen. Nedenstående eksempel viser hvordan branchekoden benyttes til at vise hvilken type organisation eller hvilken foreningstype der er tale om. 17 / 56

18 cd Objekteksempler :Organisat ion org anisationsnavn = Amnesty International dansk afd cvrn r = branchekode = : Org an isatio n org anisationsnavn = Danske Ølentusiaster branchekode = = Andre politiske og ideologiske org anisationer = Selskabelig e foreninger, loger mv. Eksempel på angivelse af foreninger via branchekode VirksomhedsType Klassen er oprettet for at indeholde CVRs definitioner af virksomhedsformer VirksomhedsType + virksomhedsform: int(3) + typenavn: char(110) Attribute Type Kardinalitet Beskrivelse virksomhedsform int(3) 1 Virksomhedsformen (fx A/S, ApS) er den juridiske form, under hvilken den juridiske enhed drives. typenavn char(110) 1 Navn på virksomhedsformen. OrganisatoriskEnhed En instans af OrganisatoriskEnhed kan ikke eksistere uden en associeret instans af Organisation. For hver instans af Organisation kan der eksistere ingen eller en instans af OrganisatoriskEnhed der har rollen juridiskenhed. For hver instans af Organisation kan der eksistere ingen eller mange instanser af OrganisatoriskEnhed der har rollen produktionsenhed. Rollerne juridiskenhed og produktionsenhed anvendes i overensstemmelse med CVRs beskrivelser af henholdsvis juridisk- og produktionsenhed. Associationen organisatoriskstruktur kan benyttes til at angive hierarkisk sammenhæng mellem enheder. 18 / 56

19 cd eks OrganisatoriskEnhed + orgenhedn avn: char(50) + pn r: int(10) [0..1] + branchekode: int(6) [0..1] + bibranchekode: int(6) [0..3] + enhedsstart: date [0..1] + enhedophoer: date [0..1] ::Kontakt + unikid : int + reklamebeskyttelse: boolean = false +foraeldreenhed 0..1 Kontakt 0..* +enhed 0..* +juridiskenhed produktionsenhed 0..* 1 1 Organisation + organisationsnavn: char(50) + cvrn r: int(8) [0..1] + branchekode: int(6) [0..1] + virksomhedsform: int(3) [0..1] + orgstart: date [0..1] + orgophoer: date [0..1] ::Kontakt + unikid : int + reklamebeskyttelse: boolean = false Kontakt constraints {self.enhed-> includesall(self.juridiskenhed)} {self.enhed-> includesall(self.produktionsenhed)} organisatoriskstruktur Attribute Type Kardinalite t Beskrivelse orgenhednavn char(50) 1 Navn på den organisatoriske enhed. pnr int(10) 1 P-nummeret er det entydige identifikationsnummer for en p-enhed i CVR. I modsætning til CVR-nummeret er offentlige myndigheder ikke forpligtet til at anvende p-nummeret i kommunikationen med og om p-enheder. branchekode int(6) 0-1 Den organisatoriske enheds primære branche. Branchebetegnelserne er harmoniseret i EU, og gengivet i "Dansk Branchekode 1993, 2. udg." (DB93). Enhederne tildeles en branche ud fra de 810 brancher i DB93, efter en konkret analyse eller efter bedste skøn. bibranchekode int(6) 0-1 Eventuelt andre brancher end den i branchekode angivne. Anvender samme værdimængde som branchekode. enhedstart date 0-1 Startdatoen for en organisatoriskenhed. Startdatoen er den første dag enheden er aktiv. Efter evt. genstart angiver startdatoen første dag produktionsenheden igen er aktiv. enhedophoer date 0-1 Ophørsdatoen for en p-enhed angiver første dag p-enheden er inaktiv efter en aktiv periode. Arvet fra Kontakt unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Rolle Klassen benyttes i sammenhæng med RolleRelation til beskrivelse af roller mellem instanser af Kontakts underklasser. cd R olle + rollen avn: char(50) + rollebeskrivelse: char(255) Attribute Type Kardinalitet Beskrivelse rollenavn char(50) 1 rollenavn angiver funktionen. Kan eventuelt være stillingsbetegnelse. rollebeskrivelse char(255) 1 Kort, men dækkende beskrivelse af rollen. 19 / 56

20 RolleRelation Klassen er en associativ klasse eller associeringsklasse. Det betyder at RolleRelation har egenskaberne fra UML-typerne association og klasse. Dette er her anvendt til at beskrive de data der alene er relevante ved associationen mellem en specifik instans af Rolle og en specifik instans af Kontakt. Instanser eksisterer alene når en instans af en Kontakt-type har en rolle og derfor danner en link til en instans af Rolle. cd Rolle + rollen avn: char(50) + rollebeskrivelse: char(255) +rollehaver 0..* 0..* K ontakt + unikid : int + reklamebeskyttelse: boolean = false RolleRelation + rolleforumid : int + rolleforumtype: string + varetag esforid : int [0..1] + varetag esfortype: string [0..1] + rollestartd ato: date [0..1] + rolleslutd ato: date [0..1] Attribute Type Kardinalitet Beskrivelse rolleforumid Int 1 Henvisning til id en for den person, gruppe, organisation eller lignende som rollen udføres i forbindelse med. rolleforumtype string 1 Attributten beskriver hvilken objekttype rolleforumid skal være knyttet til. Klassens constraint beskriver dette som: self.rolleforumtype.ocliskindof(kontakt) = true varetagesforid int 0-1 Hvis rollen ikke udføres på egne vegne, men varetages for anden person, organisation eller lignende, angives dennes unikke ID her som henvisning. varetagesfortype string 0 1 Attributten beskriver hvilken objekttype varetagesfortypeid skal være knyttet til. Klassens constraint beskriver dette som: rollestartdato date 0 1 Start dato for rollen. rolleslutdato date 0-1 Slutdato for rollen. self.varetagesfortype.ocliskindof(kontakt) = true Nedenstående tænkte objekteksempel viser hvordan klassen kan benyttes. Personen Anker Boye skal i en periode fra 31/ til 28/ afløse Ejgil W. Rasmussen midlertidigt på formandsposten for KL s bestyrelse. Med rolleforumid og rolleforumtype henvises til gruppen KL s bestyrelse. Med varetagesforid og varetagesfortype henvises til personen Ejgil W. Rasmussen. Med rollestartdato og rolleslutdato angives perioden. 20 / 56

21 cd Obj ekteksempler :Person fornavn = Anker efter Navn = Boye foedselsdatousikker = true unikid = reklamebeskyttelse = false :RolleRelation r olleforumid = 789 rolleforumtype = Gruppe varetagesforid = varetagesfortype = Person r ollestar tdato = r olleslutdato = :Rolle rollenavn = Formand r ollebes krivels e = For mand for en bestyr els e, et udvalg el. lign. :Person fornavn = Ejgil mellemnavn = Winther efternavn = Rasmuss en adresseringsnavn = Ejgil W. Rasmussen foedselsdato = foedselsdatousikker = false koen = M navnadr essebeskyttelse = false unikid = reklamebeskyttelse = fals e RolleRelation.var etagesforid = Pers on.unikid RolleRelation.r olleforumid = Gruppe.unikID :Gruppe gruppenavn = KL' s bestyrelse unikid = 789 reklamebeskyttelse = fals e Adresse Klassen Adresse har set fra Kontakt to roller: beliggenhedadresse og postadresse. En række organisationer og virksomheder har en adresse for den officielle beliggenhed og en eller flere adresser hvortil post tilsendes. Adresse-klassen er direkte afhængig af klasserne Land, Kommune, PostDistrikt og Vej til yderligere kvalificering af klassens attributter. Attribute Type Kardinalitet Beskrivelse unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til landkodealfa2 char(2) 1 ISO-betegnelse for land. Refererer til klassen Land. Herfra kan landnavn hentes. Alle instanser har default = DK da denne klasse primært benyttes til danske adresser. kommunekode char(4) 1 Det af Indenrigsministeriet fastsatte nummer for kommunen. Refererer til klassen Kommune. Herfra kan kommunenavn hentes. vejkode char(4) 1 Vejkoden består af fire cifre i intervallet Intervallet kaldes 'højvejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i Danmark. Refererer til klassen Vej. Herfra kan udledes såvel vejnavn som vejadresseringsnavn husnr char(4) 1 Nummerbetegnelse inkl. et evt. stort bogstav, som identificerer en bestemt adgang til en bygning, en grund eller et teknisk anlæg og lign. med udgangspunkt i dén navngivne vej som giver adgang hertil. 21 / 56

22 Ved Husnummer forstås i Danmark altid husnummer inkl. evt. bogstav. Indgår et bogstav i adressen, er dette en nødvendig del af den fuldstændige og korrekte adresse. Et husnummer består af et tal i intervallet Husnummeret kan have tilknyttet et bogstav fra A til Z. bynavn char(34) 1 Det fastsatte bynavn præciserer beliggenheden inden for en kommune eller postdistrikt. Et evt. bynavn er en nødvendig del af den fuldstændige og korrekte adresse. Et bynavn skal fastsættes når der findes ens eller enslydende vejnavne i postdistriktet eller kommunen. bynavn kan bestå af indtil 34 tegn. postboks char(4) 0-1 Nummer eller anden identi-fikation af postboks jvf. Post Danmark. postnr char(4) Et postnummer består af fire cifre. Refererer til klassen PostDistrikt. Herfra kan postdistrikt hentes (tekstbetegnelse for distriktet) lokalitetsnavn char(34) 0-1 Ikke entydigt navn for lokalitet. lokalitetsnavn (gårdnavn, bygningsnavn e.l.) kan knyttes til en enkelt eller flere adresser i en bygning eller et bygningskompleks lokalitetsnavn består af indtil 34 tegn som indgår i den officielle adressebetegnelse, f.eks. fra CPR Reglerne herom findes i 17, stk. 3, i Cirkulære om ajourføring af CPRs vej- og boligregister (Cirkulære nr. 130 af 25. november 2002). etage char(2) 0-1 Etagen, hvor enheden er beliggende. Etagen kan antage følgende værdier: Den etage hvis gulvplan ligger i eller umiddelbart over gadeniveau benævnes ST De følgende etager herover benævnes nedefra og opefter 1, 2, 3, til 99 Kældre (etagerne under gadeniveau) benævnes KL K2 K3 til K9 i retning ovenfra og nedefter Etagen angives ikke, hvis der kun er en enhed i bygningen. doerbetegnelse char(4) 0-1 Identifikation som beskriver beliggenheden af en bestemt indgangsdør på en etage (trappeafsats) i den pågældende opgang. Betegnelserne tv, mf og th bruges når der er indtil tre døre på trappeafsatsen. Hvis der er flere døre anvendes tallene 1, 2, 3, 4 osv. Andre betegnelser på indil 4 tegn kan dog også fastsættes. På etager med fire enheder kan betegnelserne TV, MFTV, MFTH og TH anvendes. PostDistrikt Klassens instanser beskriver danske postdistrikter. PostDistrikt + postnr: int(4) + postdistrikt: char(20) Attribute Type Kardinalitet Beskrivelse postnr char(4) 1 Id defineret af Post Danmark. 22 / 56

23 postdistrikt char(20) 1 Tekstbetegnelse for postdistriktet. Vej Klassen beskriver veje i Danmark. I adressemodellen benyttes vejkode som reference til en instans af klassen Vej. Klassens attributter kan yderligere beskrive vejen. cd Adressemodel Vej + kommunenr: int(4) + vejkode: int(4) + vejnavn: char(40) + vejadressering sn avn: char(20) Attribute Type Kardinalitet Beskrivelse kommunekode char(4) 1 kommunekode der anvendes til at sikre entydigheden. Se efterfølgende beskrivelse. vejkode char(4) 1 Vejkoden består af fire cifre i intervallet Intervallet kaldes 'høj vejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i Danmark. vejnavn char(40) 1 Det fuldstændige og korrekte vejnavn. Et vejnavn angiver en bestemt fysisk vej, plads, torv, sti o.l. efter reglerne i adressecirkulærets 7. Et vejnavn kan sammensættes af indtil 40 tegn. For veje med vejkoder i intervallet må vejnavn kun indeholde en af følgende angivelser: 1) Kommunenavnet samt evt. et nummer. 2) Teksten KOMMUNEKONTORET samt evt. et nummer. 3) Teksten FOLKEREGISTRET samt evt. et nummer. 4) Teksten UDEN FAST BOPÆL samt evt. et nummer. 5) Teksten UKENDT ADRESSE samt evt. et nummer. vejadresseringsnavn char(20) 1 Eventuel forkortet udgave af vejnavn på indtil 20 tegn. Hvis vejnavn ikke overstiger 20 tegn skal de to navne være ens. For veje med vejkoder i intervallet må vejadresseringsnavn kun indeholde en af følgende angivelser: 1) Kommunenavnet samt evt. et nummer. 2) Teksten KOMMUNEKONTORET samt evt. et nummer. 3) Teksten FOLKEREGISTRET samt evt. et nummer. 4) Teksten UDEN FAST BOPÆL samt evt. et nummer. 5) Teksten UKENDT ADRESSE samt evt. et nummer. Kommune Klassen beskriver danske kommuner. 23 / 56

24 Attribute Type Kardinalitet Beskrivelse kommunekode char(4) 1 Det af Indenrigsministeriet fastsatte nummer for kommunen Arvet fra Organisation organisationsnavn char(50) 1 Det af Indenrigsministeriet fastsatte navn for kommunen cvrnr int(8) 0-1 Det tildelte CVR-nummer. branchekode int(6) 0-1 Organisationens primære branche. Branchebetegnelserne er harmoniseret i EU, og gengivet i "Dansk Branchekode 1993, 2. udg." (DB93). Enhederne tildeles en branche ud fra de 810 brancher i DB93, efter en konkret analyse eller efter bedste skøn. orgstart date 0-1 Dato for starten på organisationen. Startdatoen afhænger af den juridiske enheds virksomhedsform. For enheder der er registreret hos Erhvervs- og Selskabsstyrelsen er startdato som udgangspunkt stiftelsestidspunktet. For ToldSkats enheder vil startdatoen være datoen for pligternes ikrafttræden. Offentlige enheder har andre startdatoer (kommuner fx ved kommunalreformen ). Danmarks Statistik registrerer disse datoer i CVR. orgophoer date 0-1 Dato for ophør for organisation. Arvet fra Kontakt unikid int(10) 1 Unik identifikation. Positivt heltal fra 1 til reklamebeskyttelse boolean 1 Angiver om der er reklamebeskyttelse for instansen. Land Klassen beskriver lande ved navn plus op til fire koder for landet: Landeidentifikations kode - 2 eller 3 karakterer eller 3 cifre - som beskrevet i ISO 3166 standarden eller 4 cifre som beskrevet i MyndighedsKode fra Indenrigs- og Sundhedsministeriet. Eks. 'DK', 'DNK', '208' er koderne for Danmark i ISO 3166 standarden og '5100' er koden for Danmark i MyndighedsKode fra Indenrigs- og Sundhedsministeriet. Land + landnavn: char(40) + landkodealfa2: char(2) + landkodealfa3: char(3) + landkodenumerisk: int(3) + myndighedskode: int(4) [0..1] 24 / 56

25 Attribute Type Kardinalitet Beskrivelse landnavn char(40) 1 Landets navn landkodealfa2 char(2) 1 ISO-3166 standardens alpha2-kode betegnelse for land. landkodealfa3 char(3) 1 ISO-3166 standardens alpha3-kode landkodenumerisk int(3) 1 ISO-3166 standardens numeric-kode myndighedskode int(4) 0-1 MyndighedsKode fra Indenrigs- og Sundhedsministeriet AdressePunkt Adressepunktet er et geografisk punkt som kan høre til instanser af Adresse. Kommunen placerer adressepunktet indenfor den bygning eller det matrikelnummer som adressen hører til. Adressekoordinaterne er de geografiske koordinater (X,Y) som viser adressepunktets præcise beliggenhed. cd Adressemodel AdressePunkt + koordinatx: flow + koordinaty: flow + koordinatsystem: KoordinatSystem Attribute Type Kardin alitet Beskrivelse koordinatx flow 1 X-koordinaten for punktet. Beskrives med det i koordinatsystem angivne system. koordinaty flow 1 Y-koordinaten for punktet. Beskrives med det i koordinatsystem angivne system. koordinatsystem KoordinatSystem 1 Koordinatsystemet vælges fra Klassen KoordinatSystem. KoordinatSystem Klassen er af typen enumeration og indeholder de systemangivelser der er valide til beskrivelse af koordinatsystem i adressemodellen. cd Adressemodel «enumeration» K oordinatsystem + system34: + system45: + KP2000: + utmed50: + utmeuref89: MatrikkelOplysning cd Adressemodel MatrikelOplysning + matrikelid: string + landsejerlavnr: int + kommunekode: char(4) + delnr: char(3) 25 / 56

26 Attribute Type Kardinalitet Beskrivelse matrikelid String 1 MatrikelID er et nummer plus bogstaver, der identificerer matriklen (jordstykket). En ejendom kan bestå af flere matrikelnumre. matrikelid kan antage værdier fra 1 til 9999 plus fra 1 til 3 bogstaver. Kun små bogstaver er tilladte. Alle bogstaver bortset fra 'j', 'w' og 'å' er tilladte. landsejerlavnr int 1 Reference til Ejerlav. kommunekode char(4) 1 Reference til Kommune. delnr int(3) 0-1 Oplysning fra ESR. Anvendes af kommunen som midlertidig betegnelse. Ejendom cd Adressemodel Ej endom + ejendomsn r: int(6) + kommunen r: int(4) Attributer Type Kardinalitet Beskrivelse ejendomsnr int(6) 1 Ejendomsnummeret identificerer den enkelte ejendom indenfor kommunen. Når ejendomsnummeret suppleres med kommunenummeret identificerer det entydigt den enkelte ejendom på landsplan. kommunekode char(4) 1 Reference til Kommune. Bygning Attribute Type Kardinalitet Beskrivelse bygningsnr int(4) 1 Bygningsnummeret er en entydig nummerering af ejendommens bygninger. ejendomsnr int(6) 1 Ejendomsnummeret identificerer den enkelte ejendom indenfor kommunen. kommunekode char(4) 1 Reference til Kommune. BBRidentifikator char(15) 1 Unik identifikator dannet af BBR. Unik for hver bygning i Danmark. Ejerlav 26 / 56

27 cd Adressemodel Ej erlav + landsejerlavsnr: int + landsejerlavsnavn: char(40) + kommunekode: char(4) + kommuneejerlavsnr: int(3) + kommuneejerlavsnavn: char(16) Attribute Type Kardin alitet Beskrivelse landsejerlavsnr int 1 Kode og betegnelse for det landsejerlav, hvor ejendommens matrikelnumre er beliggende. Et landsejerlav er et geografisk afgrænset område, der er en del af et sogn i et herred. Det er oprindelig et jordfællesskab. landsejerlavsnavn char(40) 1 Kode og betegnelse for det landsejerlav, hvor ejendommens matrikelnumre er beliggende. Et landsejerlav er et geografisk afgrænset område, der er en del af et sogn i et herred. Det er oprindelig et jordfællesskab. kommunekode char(4) 1 Også kaldet kommunekode. Reference til Kommune kommuneejerlavsnr int(3) 0 1 Kommuner definer ofte egne ejerlav. kommuneejerlavsnav n char(16) 0 1 Kommuner definer ofte egne ejerlav. ElektroniskPostAdresse Klassen indeholder data om en Kontakt epost-adresse. Erfaringen viser at der er behov for at kunne håndtere såvel arbejdsrelaterede som private epostadresser. Derfor attributten privatepost. cd Adressemodel ElektroniskPostAdresse + epostadresse: string + privatepost: boolean = false Attribute Type Kardinalitet Beskrivelse epostadresse uri:mailto 1 adresse i standard uri-form; privatepost boolean 1 Ved true er epostadresse relateret til JuridiskEntitet som dennes private, ikke-arbejdsrelaterede adresse. Telefon Klassen Telefon benyttes til alle telefontyper; fastnet, mobil og fax. Der er ikke konstateret et behov for at skelne mellem en telefon af typen fastnet og mobil. Der er konstateret et behov for at vide om et telefonnummer er arbejds- eller funktionsrelateret eller om det er et privatnummer. Derfor attributten privattelefon. cd Adressemodel Telefon + tlfn r: char(20) + lokaln r: char(5) [0..1] + privattelefon: boolean = false + fax: boolean = false 27 / 56

28 Attribute Type Kardinalitet Beskrivelse tlfnr char(20) 1 Tekststreng for telefonnummer. Dækker både danske og udenlandske telefonnumre. lokalnr char(5) 0-1 Eventuelt lokalnummer. (Valget af 20 karakterer til at beskrive et telefonnummer er truffet ud fra hensynet til udenlandske telefonnumre). privattelefon boolean 1 Ved true er tlfnr relateret til JuridiskEntitet som dennes private, ikke-arbejdsrelaterede telefonnummer. fax boolean 1 Ved true er tlfnr et faxnummer. 28 / 56

29 UdlandsAdresse UdlandsAdresse + adresselinie1: char(34) + adresselinie2: char(34) + adresselinie3: char(34) + adresselinie4: char(34) [0..1] + adresselinie5: char(34) [0..1] + adresselinie6: char(34) [0..1] + landkodealfa2: char(2) + unikid: int Attribute Type Kardinalitet Beskrivelse unikid Int(10) 1 Unik identifikation. Positivt heltal fra 1 til landkode char(2) 1 ISO-betegnelse for land. Refererer til klassen Land. Herfra kan landnavn hentes. adresselinie1 char(34) 1 Første linie i adressebeskrivelse til udenlandsk adresse. adresselinie2 char(34) 1 Anden linie i adressebeskrivelse til udenlandsk adresse. adresselinie3 char(34) 1 Tredje linie i adressebeskrivelse til udenlandsk adresse. adresselinie4 char(34) 0-1 Fjerde linie i adressebeskrivelse til udenlandsk adresse. adresselinie5 char(34) 0-1 Femte linie i adressebeskrivelse til udenlandsk adresse. adresselinie6 char(34) 0-1 Sjette linie i adressebeskrivelse til udenlandsk adresse. Historik Varetager historikoplysninger for klasserne: PersonGruppe Person OrganisatoriskEnhed Organisation Kommune Adresse UdlandsAdresse Klassen er oprettet til brug for sikring af historikoplysninger på udvalgte klassers instanser. Instanser af Adresse og UdlandsAdresse samt alle klasser nedarvet fra Kontakt, kan alle benytte Historik til registrering af tidspunkt for ændring, hvem der foretog ændring og eventuelt hvilket datagrundlag der lå til grund. 29 / 56

30 cd Adressemodel + historikforid : int + historikforid Type: string + opdateretd ato: datetime + opdateretaf: string + datakilde: string [0..1] Historik constraints {self.historikforidtype.ocliskindof(kontakt) = true} {self.rolleforumtype.ocliskindof(adresse) = true} {self.rolleforumtype.ocliskindof(udlandsadresse) = true} Attribute Type Kardinalitet Beskrivelse historikforid int(10) 1 Unik identifikation. Positivt heltal fra 1 til Henviser til id en for den instans historikken gælder. historikfortype string 1 Attributten beskriver hvilken objekttype historikforid skal være knyttet til. Klassens constraint beskriver dette som: self.historikforidtype.ocliskindof(kontakt) = true self.rolleforumtype.ocliskindof(adresse) = true self.rolleforumtype.ocliskindof(udlandsadresse) = true opdateretdato datetime 1 Dato og tidspunkt for opdateringen. opdateretaf string 1 Identificerende tekststreng for den person eller det system der foretog opdateringen. datakilde string 0 1 Identificerende tekststreng for kilde til opdateringen. 30 / 56

31 Del E. XML-schema for adressemodellens indhold På baggrund af UML-modellen er der dannet et xml-schema for adressemodellen. Følgende præfiks er anvendt: fesd kms cvr xs xkom xkom2 bbr Itst Itst2 dkcc dkcc2 dkcc3 cpr cpr Kun elementer og attributter i namespace fesd: er dokumenteret i det efterfølgende. For øvrige elementer og attributter henvises til ISB. 31 / 56

32 Attributten UnikID <xs:element name="uniqueidentifier" type="fesd:uniqueidentifiertype"/> <xs:simpletype name="uniqueidentifiertype"> <xs:restriction base="xs:nonnegativeinteger"> <xs:maxinclusive value=" "/> </xs:restriction> </xs:simpletype> Klassen Adresse og rollerne BeliggenhedsAdresse, PostAdresse, BygningsAdresse og EjendomsAdresse <xs:element name="addressstructure" type="fesd:addressstructuretype"/> <xs:element name="situationaddressstructure" type="fesd:addressstructuretype"/> <xs:element name="maildeliveryaddressstructure" type="fesd:addressstructuretype"/> <xs:element name="buildingaddress" type="fesd:addressstructuretype"/> <xs:element name="realpropertyaddress" type="fesd:addressstructuretype"/> <xs:complextype name="addressstructuretype"> <xs:complexcontent> <xs:extension base="xkom2:addresscompletetype"> <xs:sequence> <xs:element ref="fesd:uniqueidentifier"/> <xs:element ref="fesd:addresslocation" minoccurs="0"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> 32 / 56

33 Klassen AdressePunkt <xs:element name="addresslocation" type="fesd:addresslocationtype"/> <xs:complextype name="addresslocationtype"> <xs:sequence> <xs:element ref="fesd:xcoordinate"/> <xs:element ref="fesd:ycoordinate"/> </xs:sequence> <xs:attribute name="coordinatesystemcode" type="fesd:coordinatesystemcodetype"/> </xs:complextype> <xs:element name="xcoordinate" type="xs:decimal"/> <xs:element name="ycoordinate" type="xs:decimal"/> <xs:simpletype name="coordinatesystemcodetype"> <xs:restriction base="xs:string"> <xs:enumeration value="system34"/> <xs:enumeration value="system45"/> <xs:enumeration value="kp2000"/> <xs:enumeration value="utmed50"/> <xs:enumeration value="utmeuref89"/> </xs:restriction> </xs:simpletype> Klassen Telefon <xs:element name="telephonestructure" type="fesd:telephonestructuretype"/> 33 / 56

34 <xs:complextype name="telephonestructuretype"> <xs:sequence> <xs:element ref="itst2:telephonenumberstructure"/> <xs:element ref="fesd:privatetelephoneindicator"/> <xs:element ref="fesd:faxindicator"/> </xs:sequence> </xs:complextype> <xs:element name="privatetelephoneindicator" type="xs:boolean"/> <xs:element name="faxindicator" type="xs:boolean"/> Klassen ElektroniskPostAdresse <xs:element name=" addressstructrure" type="fesd: addressstructruretype"/> <xs:complextype name=" addressstructruretype"> <xs:sequence> <xs:element ref="xkom: addressidentifier"/> <xs:element ref="fesd:private indicator"/> </xs:sequence> </xs:complextype> <xs:element name="private indicator" type="xs:boolean" default="false"/> 34 / 56

35 Klassen UdlandsAdresse <xs:element name="foreignaddressstructure" type="fesd:foreignaddressstructuretype"/> <xs:complextype name="foreignaddressstructuretype"> <xs:sequence> <xs:element ref="fesd:uniqueidentifier"/> <xs:element ref="dkcc:countryidentificationcode"/> <xs:element ref="cpr2:secondaryaddresslabel"/> </xs:sequence> </xs:complextype> 35 / 56

36 Klassen Rolle <xs:element name="role" type="fesd:roletype"/> <xs:complextype name="roletype"> <xs:sequence> <xs:element ref="fesd:rolename"/> <xs:element ref="fesd:roledescriptiontext"/> <xs:element ref="fesd:roleowner" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:rolerelation"/> </xs:sequence> </xs:complextype> <xs:element name="roleowner" type="fesd:roleownertype"/> <xs:complextype name="roleownertype"> <xs:choice> <xs:element ref="fesd:person"/> <xs:element ref="fesd:group"/> <xs:element ref="fesd:organizationalunit"/> <xs:element ref="fesd:organization"/> </xs:choice> </xs:complextype> <xs:element name="rolename" type="xs:string"/> <xs:element name="roledescriptiontext" type="xs:string"/> 36 / 56

37 Klassen RolleRelation <xs:element name="rolerelation" type="fesd:rolerelationtype"/> <xs:complextype name="rolerelationtype"> <xs:sequence> <xs:element ref="fesd:roleforumreference"/> <xs:element ref="fesd:roleforumclasscode"/> <xs:element ref="fesd:representingreference" minoccurs="0"/> <xs:element ref="fesd:representingclasscode" minoccurs="0"/> <xs:element ref="fesd:rolestartdate" minoccurs="0"/> <xs:element ref="fesd:roleenddate" minoccurs="0"/> <xs:element ref="fesd: addressstructure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:telephonestructure" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="representingreference" type="fesd:uniqueidentifiertype"/> <xs:element name="roleforumreference" type="fesd:uniqueidentifiertype"/> <xs:element name="roleforumclasscode" type="xs:string"/> <xs:element name="representingclasscode" type="xs:string"/> <xs:element name="rolestartdate" type="xs:date"/> <xs:element name="roleenddate" type="xs:date"/> 37 / 56

38 Klassen Kontakt ContactType er en abstrakt typedefinition og anvendes ikke direkte til dannelse af elementer. Anvendes i afledt form af Person, Group, OrganizationalUnit og Organization. <xs:complextype name="contacttype" abstract="true"> <xs:sequence> <xs:element ref="fesd:uniqueidentifier"/> <xs:element ref="fesd:advertisementprotectionindicator"/> <xs:element ref="fesd:situationaddressstructure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:telephonestructure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd: addressstructrure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:foreignaddressstructure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:maildeliveryaddressstructure" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:role" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:element name="advertisementprotectionindicator" type="xs:boolean" default="false"/> 38 / 56

39 Klassen Gruppe og rollen ForaeldreGruppe <xs:element name="group" type="fesd:grouptype"/> <xs:element name="parentgroup" type="fesd:grouptype"/> <xs:complextype name="grouptype"> <xs:complexcontent> <xs:extension base="fesd:contacttype"> <xs:sequence> <xs:element ref="fesd:groupname"/> <xs:element ref="fesd:groupstartdate"/> <xs:element ref="fesd:groupenddate" minoccurs="0"/> <xs:element ref="fesd:parentgroup" minoccurs="0"/> <xs:element ref="fesd:organizationalunit" minoccurs="0"/> <xs:element ref="fesd:organization" minoccurs="0"/> <xs:element ref="fesd:groupmember" minoccurs="0"/> 39 / 56

40 </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:element name="groupstartdate" type="xs:date"/> <xs:element name="groupenddate" type="xs:date"/> 40 / 56

41 Klassen Person og rollerne Gruppemedlem og CareOf 41 / 56

42 <xs:element name="person" type="fesd:persontype"/> <xs:complextype name="persontype"> <xs:complexcontent> <xs:extension base="fesd:contacttype"> <xs:sequence> <xs:element ref="itst:personnamestructure"/> <xs:element ref="itst:personnameforaddressingname" minoccurs="0"/> <xs:element ref="dkcc2:birthdate" minoccurs="0"/> <xs:element ref="fesd:birthdateuncertaintyindicator"/> <xs:element ref="dkcc:persongendercode"/> <xs:element ref="cpr:personcivilregistrationidentifier" minoccurs="0"/> <xs:element ref="fesd:personcivilregistrationidentifierstatuscode" minoccurs="0"/> <xs:element ref="fesd:nameaddressprotectionindicator"/> <xs:element ref="fesd:nameaddressprotectionenddate" minoccurs="0"/> <xs:element ref="fesd:careof" minoccurs="0"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> 42 / 56

43 Klassen Organisation <xs:element name="organization" type="fesd:organizationtype"/> <xs:complextype name="organizationtype"> <xs:complexcontent> <xs:extension base="fesd:contacttype"> <xs:sequence> <xs:element ref="fesd:organizationname"/> <xs:element ref="cvr:cvrnumberidentifier" minoccurs="0"/> <xs:element ref="fesd:businessactivity" minoccurs="0"/> <xs:element ref="fesd:companycategory" minoccurs="0"/> <xs:element ref="fesd:organizationstartdate" minoccurs="0"/> 43 / 56

44 <xs:element ref="fesd:organizationenddate" minoccurs="0"/> <xs:element ref="fesd:organizationalunit" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:element name="organizationstartdate" type="xs:date"/> <xs:element name="organizationenddate" type="xs:date"/> 44 / 56

45 Klassen OrganisatoriskEnhed og rollen ForaeldreEnhed <xs:element name="organizationalunit" type="fesd:organizationalunittype"/> <xs:element name="parentunit" type="fesd:organizationalunittype"/> <xs:complextype name="organizationalunittype"> <xs:complexcontent> <xs:extension base="fesd:contacttype"> <xs:sequence> <xs:element ref="fesd:organizationalunitname"/> <xs:element ref="cvr:productionunitidentifier" minoccurs="0"/> <xs:element ref="fesd:businessactivity" minoccurs="0"/> 45 / 56

46 <xs:element ref="fesd:businesssideactivity" minoccurs="0" maxoccurs="3"/> <xs:element ref="fesd:unitstartdate" minoccurs="0"/> <xs:element ref="fesd:unitenddate" minoccurs="0"/> <xs:element ref="fesd:parentunit" minoccurs="0"/> </xs:sequence> <xs:attribute name="unittypecode" use="optional"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="legalunit"/> <xs:enumeration value="productionunit"/> </xs:restriction> </xs:simpletype> </xs:attribute> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:element name="unitstartdate" type="xs:date"/> <xs:element name="unitenddate" type="xs:date"/> Attributten unittypecode For at sikre at en OrganizationalUnit eller en ParentUnit kan være en af typerne legalunit eller productionunit er OrganizationalUnit tildelt attributten unittypecode. Attributten kan antage værdierne legalunit og productionunit. Klassen VirksomhedsType <xs:element name="companycategory" type="fesd:companycategorytype"/> <xs:complextype name="companycategorytype"> <xs:sequence> <xs:element ref="fesd:companycategorycode"/> <xs:element ref="fesd:companycategoryname"/> </xs:sequence> </xs:complextype> <xs:element name="companycategorycode" type="fesd:companycategorycodetype"/> <xs:simpletype name="companycategorycodetype"> 46 / 56

47 <xs:restriction base="xs:nonnegativeinteger"> <xs:maxinclusive value="999"/> </xs:restriction> </xs:simpletype> <xs:element name="companycategoryname" type="fesd:companycategorynametype"/> <xs:simpletype name="companycategorynametype"> <xs:restriction base="xs:string"> <xs:length value="110"/> </xs:restriction> </xs:simpletype> Klassen Branche <xs:element name="businessactivity" type="fesd:businessactivitytype"/> <xs:element name="businesssideactivity" type="fesd:businessactivitytype"/> <xs:complextype name="businessactivitytype"> <xs:sequence> <xs:element ref="fesd:businessactivitycode"/> <xs:element ref="fesd:businessactivityname"/> </xs:sequence> </xs:complextype> <xs:element name="businessactivitycode" type="fesd:businessactivitycodetype"/> <xs:simpletype name="businessactivitycodetype"> <xs:restriction base="xs:nonnegativeinteger"> <xs:maxinclusive value="999999"/> </xs:restriction> </xs:simpletype> <xs:element name="businessactivityname" type="fesd:businessactivitynametype"/> <xs:simpletype name="businessactivitynametype"> <xs:restriction base="xs:string"> <xs:maxlength value="255"/> </xs:restriction> </xs:simpletype> 47 / 56

48 Klassen Land <xs:element name="countrystructure" type="fesd:countrystructuretype"/> <xs:complextype name="countrystructuretype"> <xs:sequence> <xs:element ref="fesd:countryname"/> <xs:element ref="dkcc:countryidentificationcode" maxoccurs="4"/> </xs:sequence> </xs:complextype> <xs:element name="countryname" type="fesd:countrynametype"/> <xs:simpletype name="countrynametype"> <xs:restriction base="xs:string"> <xs:length value="40"/> </xs:restriction> </xs:simpletype> dkcc:countryidentificationcode har attributten scheme der benyttes til at afgøre hvilken af de fire UML-attributter der indeholdes i elementet. Værdierne er: iso3166-alpha2 iso3166-alpha3 un-numeric3 imk 48 / 56

49 Klassen PostDistrikt <xs:element name="postdistrictstructure" type="fesd:postdistrictstructuretype"/> <xs:complextype name="postdistrictstructuretype"> <xs:sequence> <xs:element ref="dkcc2:postcodeidentifier"/> <xs:element ref="dkcc2:districtname"/> </xs:sequence> </xs:complextype> 49 / 56

50 Klassen Vej <xs:element name="streetstructure" type="fesd:streetstructuretype"/> <xs:complextype name="streetstructuretype"> <xs:sequence> <xs:element ref="cpr:municipalitycode"/> <xs:element ref="cpr:streetcode"/> <xs:element ref="dkcc2:streetname"/> <xs:element ref="cpr:streetnameforaddressingname"/> </xs:sequence> </xs:complextype> 50 / 56

51 Klassen Kommune <xs:element name="municipality" type="fesd:municipalitytype"/> <xs:complextype name="municipalitytype"> <xs:complexcontent> <xs:extension base="fesd:organizationtype"> <xs:sequence> <xs:element ref="cpr:municipalitycode"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> 51 / 56

52 Klassen Ejerlav <xs:element name="cadastraldistrictstructure" type="fesd:cadastraldistrictstructuretype"/> <xs:complextype name="cadastraldistrictstructuretype"> <xs:sequence> <xs:element ref="kms:cadastraldistrictidentifier"/> <xs:element ref="kms:cadastraldistrictname"/> <xs:element ref="cpr:municipalitycode"/> <xs:element ref="fesd:cadastraldistrictimunicipaldentifier"/> <xs:element ref="fesd:cadastraldistrictimunicipalname"/> </xs:sequence> </xs:complextype> <xs:element name="cadastraldistrictmunicipaldentifier" type="fesd:municipalcadastraldistrictidentifiertype"/> <xs:simpletype name="cadastraldistrictmunicipalidentifiertype"> <xs:restriction base="xs:nonnegativeinteger"> <xs:maxinclusive value="999"/> </xs:restriction> </xs:simpletype> <xs:element name="cadastraldistrictmunicipalname" type="fesd:cadastraldistrictmunicipalnametype"/> <xs:simpletype name="cadastraldistrictmunicipalnametype"> <xs:restriction base="xs:string"> <xs:length value="16"/> </xs:restriction> </xs:simpletype> 52 / 56

53 Klassen MatrikelOplysning <xs:element name="landparcelstructure" type="fesd:landparcelstructuretype"/> <xs:complextype name="landparcelstructuretype"> <xs:sequence> <xs:element ref="kms:landparcelidentifier"/> <xs:element ref="kms:cadastraldistrictidentifier"/> <xs:element ref="cpr:municipalitycode"/> <xs:element ref="fesd:landparcelmunicipalpartnumber"/> <xs:element ref="fesd:realpropertystructure"/> </xs:sequence> </xs:complextype> <xs:element name="landparcelmunicipalpartnumber" type="fesd:landparcelmunicipalpartnumbertype"/> 53 / 56

54 Klassen Ejendom <xs:element name="realpropertystructure" type="fesd:realpropertystructuretype"/> <xs:complextype name="realpropertystructuretype"> <xs:sequence> <xs:element ref="bbr:municipalrealpropertyidentifier"/> <xs:element ref="cpr:municipalitycode"/> <xs:element ref="fesd:building" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="fesd:realpropertyaddress"/> </xs:sequence> </xs:complextype> 54 / 56

55 Klassen Bygning <xs:element name="building" type="fesd:buildingtype"/> <xs:complextype name="buildingtype"> <xs:sequence> <xs:element ref="dkcc3:buildingidentifier"/> <xs:element ref="bbr:municipalrealpropertyidentifier"/> <xs:element ref="cpr:municipalitycode"/> <xs:element ref="fesd:bbridentifier"/> <xs:element ref="fesd:buildingaddress" minoccurs="0"/> </xs:sequence> </xs:complextype> 55 / 56

56 Klassen Historik <xs:element name="audittrail" type="fesd:audittrailtype"/> <xs:complextype name="audittrailtype"> <xs:sequence> <xs:element ref="fesd:audittrailsubjectreference"/> <xs:element ref="fesd:audittrailsubjectclasscode"/> <xs:element ref="fesd:updatedate"/> <xs:element ref="fesd:updatedbyreference"/> <xs:element ref="fesd:updatesourcereference" minoccurs="0"/> </xs:sequence> </xs:complextype> <xs:element name="audittrailsubjectreference" type="fesd:uniqueidentifiertype"/> <xs:element name="audittrailsubjectclasscode" type="xs:string"/> <xs:element name="updatedate" type="xs:datetime"/> <xs:element name="updatedbyreference" type="xs:string"/> <xs:element name="updatesourcereference" type="xs:string"/> 56 / 56

FESD Navn- og Adressemodel

FESD Navn- og Adressemodel FESD Navn- og Adressemodel Standard IT- og Telestyrelsen København den 10. december 2008 FESD-standardisering Navn- og adressemodel. Datamodel Version 1.1 Kolofon: FESD-standardisering. Navn- og adressemodel.

Læs mere

Aktør-adresse. Konceptuel model. Fællesoffentligt modeludkast. 7. december 2005. Version 1.1

Aktør-adresse. Konceptuel model. Fællesoffentligt modeludkast. 7. december 2005. Version 1.1 Aktør-adresse Konceptuel model Fællesoffentligt modeludkast 7. december 2005 Version 1.1 Indholdsfortegnelse 1 INDLEDNING... 3 1.1 ARBEJDSMETODE... 3 1.2 FORUDSÆTNINGER... 3 1.3 AFGRÆNSNINGER... 4 1.4

Læs mere

OIOXML Adresseguide. 1. Baggrund. 2. Formål

OIOXML Adresseguide. 1. Baggrund. 2. Formål OIOXML Adresseguide Denne guide er udarbejdet af en arbejdsgruppe under den såkaldte Nøgledatagruppe under XML-projektet i Ministeriet for Videnskab, Teknologi og Udvikling. Arbejdsgruppen består af: Morten

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Stamoplysninger for en person CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk

Læs mere

CVR i DPR. Database- og feltbeskrivelse

CVR i DPR. Database- og feltbeskrivelse CVR i DPR Database- og feltbeskrivelse 20. november 2013 CSC Danmark Copyright ll Rights Reserved. Side 2 af 25 Indholdsfortegnelse 1. Indledning... 3 2. Introduktion... 3 3. Databasebeskrivelse... 4 3.1

Læs mere

Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering

Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering 28. oktober 2009 Rev. 6./11. november 2009 Svar på spørgsmål om Nyt BBRs adresser og adressekonvertering Sag 07/ mli 1. Indledning Dette notat skal søge at svare på en række spørgsmål som KL har modtaget,

Læs mere

CVR i DPR. CVR Database- og feltbeskrivelse

CVR i DPR. CVR Database- og feltbeskrivelse CVR i DPR CVR Database- og feltbeskrivelse 15. marts 2011 CSC Danmark Copyright ll Rights Reserved. Side 2 af 8 Indholdsfortegnelse 1. Indledning... 3 2. Introduktion... 3 3. Databasebeskrivelse... 4 3.1

Læs mere

Personnummerregister / CPR Importer

Personnummerregister / CPR Importer Personnummerregister / CPR Importer 1 Indbakke Forventer biblioteker i sin indbakke indeholdende filer kodet i tegnsættet ISO-8859-1 der overholder følgende navngivningsmønster: D.{6}\.L4311.* Filerne

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Værgeoplysninger CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Håndbog

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services CPR-kontoret Finsensvej 15, 2000 Frederiksberg E-post: cpr@cpr.dk. Tlf.: 72269735 - Fax: 72269742. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse 1. Indledning... 3 2.

Læs mere

Personnummerregister / CPR Importer

Personnummerregister / CPR Importer Personnummerregister / CPR Importer 1 Indbakke Forventer biblioteker i sin indbakke indeholdende filer kodet i tegnsættet ISO-8859-1 der overholder følgende navngivningsmønster: D.{6}\.L4311.* Filerne

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Adresser UBL 2.0 Address G36 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Adresser Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2 DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...

Læs mere

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG Side 1 af 15 Navision Stat 7.0 30. april 2015 ØS/ØSY/MAG CVR Integration Overblik Introduktion I denne vejledning kan du læse om, hvordan du validerer dine debitorers og kreditorers data op imod Det Centrale

Læs mere

Bekendtgørelse om vejnavne og adresser

Bekendtgørelse om vejnavne og adresser Bekendtgørelse om vejnavne og adresser I medfør af 3c og 3f i lov om bygnings- og boligregistrering, jf. lovbekendtgørelse nr. 767 af 12. september 2002, som ændret ved 1 i lov nr. 601 af 24. juni 2005

Læs mere

OIOXML dokumentationsguide Person

OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person . Ejerskab Indenrigs og Sundhedsministeriets CPR-kontor i medfør af Bekendtgørelse af lov om Det Centrale Personregister, jf. lov nr.

Læs mere

Vejnavne og adresser i kommunalreformen

Vejnavne og adresser i kommunalreformen ORIENTERING Til sammenlægningsudvalgene 3. januar 2006 Sag: D-4236-4 /lgl/mli Vejnavne og adresser i kommunalreformen Orientering om kommunernes opgaver som adressemyndighed forud for kommunesammenlægningen

Læs mere

CPR Centrale Personregister Side 2 af 50

CPR Centrale Personregister Side 2 af 50 CPR Centrale Personregister Side 1 af 50 UDTRÆKSBESKRIVELSE ----- Kunde OFFENTLIG M. VALGFRIE RECORDTYPE Opgavenr. Journal nr. 001403 Udtrækstype Oprettet Ændret STATUS UDTRÆK (EKSTERN NØGLE) 06.01.2009

Læs mere

CPR Centrale Personregister Side 1 af 53

CPR Centrale Personregister Side 1 af 53 CPR Centrale Personregister Side 1 af 53 UDTRÆKSBESKRIVELSE ----- Kunde OFFENTLIG M. VALGFRIE RECORDTYPE Opgavenr. Journal nr. 001402 Udtrækstype Oprettet Ændret ÆNDRINGSUDTRÆK 12.11.2008 27.01.2011 Udtrækskriterier/formål:

Læs mere

Faktaark for DAR 1.0

Faktaark for DAR 1.0 1. december 2014 HEGK Faktaark for DAR 1.0 Overordnet beskrivelse og baggrund for DAR 1.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 DAR i dag... 3 Fremtidige DAR 1.0... 4 3. Teknik...

Læs mere

BBR OIOXML. Vejledning til snitfladen: Address.wsdl

BBR OIOXML. Vejledning til snitfladen: Address.wsdl OIOXML Vejledning til snitfladen: En vejledning rettet mod 3. part. Ændringer i forhold til forrige versioner Version 1.0 Første version, 15.01.2010 Version 1.1.0 5.2.2010: Opdateret med de tilbagemeldinger

Læs mere

Vejledning i opdatering af vandindvindingsanlægsoplysninger

Vejledning i opdatering af vandindvindingsanlægsoplysninger Vejledning i opdatering af vandindvindingsanlægsoplysninger Denne vejledning beskriver hvordan data trækkes ud af Jupiter når der skal sendes data til SKAT i forbindelse med indkrævningen af afgiften for

Læs mere

OIOXML dokumentationsguide Adressepunkt

OIOXML dokumentationsguide Adressepunkt OIOXML dokumentationsguide Adressepunkt OIOXML dokumentationsguide Adressepunkt . Ejerskab Økonomi- og Erhvervsministeriet, Erhvervs- og Byggestyrelsen i medfør af lov om bygnings- og boligregistrering

Læs mere

Nordic Address Forum 3.-4. June 2010 Odense. Country Report Denmark

Nordic Address Forum 3.-4. June 2010 Odense. Country Report Denmark Nordic Address Forum 3.-4. June 2010 Odense Country Report Denmark by Katrine Langballe Danish Enterprise and Construction Authority (EBST) kla@ebst.dk Ændringer i lovgivningen Since last meeting Nem Oplysning

Læs mere

Specifikation af serviceinterface for organisation. Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13.

Specifikation af serviceinterface for organisation. Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13. Specifikation af serviceinterface for organisation Dette udkast til standard er i offentlig høring i perioden 12. oktober til 13. november 2009 Specifikation af forretningsservice for Organisation Denne

Læs mere

ADR Adresseklient version 0.9.2. Kom godt i gang. Adresseklient ADK Version 0.9.2 Maj 2015

ADR Adresseklient version 0.9.2. Kom godt i gang. Adresseklient ADK Version 0.9.2 Maj 2015 Kom godt i gang Adresseklient ADK Version 0.9.2 Maj 2015 Side 1 af 69 sider INDHOLDSFORTEGNELSE Indholdsfortegnelse... 2 Indledning... 5 Begreber... 6 Adgangspunkter, husnumre og adresser... 6 Status af

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Bopælssamling CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Håndbog til

Læs mere

Beskrivelse af de 10 faste rapporter

Beskrivelse af de 10 faste rapporter Beskrivelse af de 10 faste rapporter Dette bilag indeholder en mere detaljeret gennemgang af indholdet af de 10 fast definerede rapporter. Som beskrevet i kapitel 10 Rapporter drejer det sig om disse 10

Læs mere

Dokumentlog. Dato Version Beskrivelse Applikation version Ny godkendelsesproces. Reference Forfatter Godkender.

Dokumentlog. Dato Version Beskrivelse Applikation version Ny godkendelsesproces. Reference Forfatter Godkender. Dokumentlog Dato Version Beskrivelse Applikation version 2015.11.30 4.0 Ny MDS 4.1 godkendelsesproces Reference Forfatter Godkender K15 Transition Oprydning CPRDOK Godkendt af leverandør ifb. med Transition

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17-06-2014 MST Oprettelse af krav 0.2 18-05-2014 MST Tilretning af tabeller 0.3 18.06.2014 PKR

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Navnesøgning - udvidet CPR-kontoret Christianslund 48, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 94 03 07. Hjemmeside: www.cpr.dk

Læs mere

Høringssvar vedrørende Specifikation af serviceinterface for person (part)

Høringssvar vedrørende Specifikation af serviceinterface for person (part) IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Høringssvar vedrørende Specifikation af serviceinterface for person (part) Dette er KLs høringssvar på den offentlige høring om specifikation af serviceinterface

Læs mere

Appendix C - Databeskrivelse

Appendix C - Databeskrivelse Appendix C - Databeskrivelse D1: Entitet: Person En Person repræsenterer en borger, som anvender systemet. En Person har ved oprettelsen ingen Barselsforløb og orlovsperioder, men kan generelt have flere

Læs mere

CPR Centrale Personregister Side 1 af 20

CPR Centrale Personregister Side 1 af 20 CPR Centrale Personregister Side 1 af 20 UDTRÆKSBESKRIVELSE ----- Kunde INDENRIGSMINISTERIET Opgavenr. Journal nr. 370715 EJ-HJEMMESID Udtrækstype Oprettet Ændret STATUS UDTRÆK (UDEN NØGLE) 19.07.2007

Læs mere

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister februar 2014

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister februar 2014 NOTAT VERSION 0.5 Dato: 17. februar 2014 Kontor: By/Land/Ejendomsdata Sagsnr.: Sagsbehandler: MLI Dok id: Adresseprogrammet Vejledning til adressemyndigheden om opgavelister februar 2014 1. Indledning

Læs mere

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister november-december 2013

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister november-december 2013 NOTAT VERSION 0.4 Dato: 19. december 2013 Kontor: By/Land/Ejendomsdata Sagsnr.: Sagsbehandler: MLI Dok id: Adresseprogrammet Vejledning til adressemyndigheden om opgavelister november-december 2013 1.

Læs mere

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister april 2014

Adresseprogrammet Vejledning til adressemyndigheden om opgavelister april 2014 NOTAT VERSION 0.6 Dato: 31. marts 2014 Kontor: By/Land/Ejendomsdata Sagsnr.: Sagsbehandler: MLI Dok id: Adresseprogrammet Vejledning til adressemyndigheden om opgavelister april 2014 1. Indledning I forbindelse

Læs mere

Faktaark for BBR 2.0

Faktaark for BBR 2.0 1. december 2014 HEGK Faktaark for BBR 2.0 Overordnet beskrivelse og baggrund for BBR 2.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 BBR i dag... 3 Fremtidige BBR 2.0... 4 3. Teknik...

Læs mere

Lovtidende A 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) 16. november 2010.

Lovtidende A 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) 16. november 2010. Lovtidende A 2010 16. november 2010. Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) I medfør af 4, stk. 4, og 8, stk. 2, i lov om bygnings- og boligregistrering,

Læs mere

CPR 2. CPR udtræk fra CPR kontoret

CPR 2. CPR udtræk fra CPR kontoret CPR 2 Dette dokument er et ekstrakt af det grundlag der blev udarbejdet i NSI i oktober 2013, som baggrund for udvidelse af CPR datasamlingen også kaldet CPR 2. --------- NSP CPR datagrundlaget er udvidet

Læs mere

Hyppige brugsscenarier

Hyppige brugsscenarier Hyppige brugsscenarier Indhold 1. Virksomhed som ønsker at henvende sig til nye potentielle kunder 2. Bruger som ønsker at abonnere på hele CVR databasen og modtage opdateringer 3. Bruger som kun er interesseret

Læs mere

Postnummerkort.dk, version 1.0 officielt postnummerkort

Postnummerkort.dk, version 1.0 officielt postnummerkort Postnummerkort.dk, version 1.0 officielt postnummerkort 1. december 2006 Sag D-4236-6 /mli Version 1.0a 1. Indledning I forbindelse med forberedelsen af kommunalreformen vedtog folketinget i juni 2005

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Fødselsdato-søgning CPR-kontoret Christianslund 48, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 94 03 07. Hjemmeside: www.cpr.dk

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Tidligere navne CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Håndbog

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

BBR OIOXML. Vejledning til snitfladen: AddressGeometryService

BBR OIOXML. Vejledning til snitfladen: AddressGeometryService BBR OIOXML Vejledning til snitfladen: En vejledning rettet mod 3. part. Ændringer i forhold til forrige versioner Version 1.0 Første version, 17.2.2009 Version 1.1 Opdateret i forhold til _- 20090930.

Læs mere

Bilag 3: Dataelementer, som frit må videreformidles mhp andre formål end markedsføring

Bilag 3: Dataelementer, som frit må videreformidles mhp andre formål end markedsføring Bilag 3: Dataelementer, som frit må videreformidles mhp andre formål end markedsføring Side 2 af 8 Dataelementer, som fremgår af nedenstående tabel, kan anvendes frit. Dette gælder dog ikke brug til markedsføring

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Att: Mads Ellehammer:

Att: Mads Ellehammer: KL Att: Mads Ellehammer: 27. august 2008 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 22. marts 2008 til 23. maj 2008, og ønsker med dette brev at

Læs mere

FIE brugervejledning

FIE brugervejledning FIE brugervejledning Hvad er FIE?... 2 Hvordan bruger jeg FIE?... 2 Hvor finder jeg FIE?... 2 Hvordan logger jeg ind?... 3 Hvordan uploader jeg data?... 4 Hvad sker, når mine data er behandlet?... 4 Efter

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17.06.2014 PKR Første udkast 0.2 18.06.2014 MBS Tilføjet afsnit om Søgeresultater 0.3 26.06.2014

Læs mere

Beskrivelse af de 12 faste rapporter

Beskrivelse af de 12 faste rapporter Beskrivelse af de 12 faste rapporter Dette bilag indeholder en mere detaljeret gennemgang af indholdet af de 12 fast definerede rapporter. Som beskrevet i kapitel 10 Rapporter drejer det sig om disse 12

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

Læs mere

Håndbog Til CPR services

Håndbog Til CPR services Håndbog Til CPR services Søgeservices - Servicespecifikation Fødselsdatosøgning - udvidet CPR-kontoret Christianslund 48, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 94 03 07. Hjemmeside:

Læs mere

Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor. Version 1.0,

Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor. Version 1.0, Af Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor Version 1.0, 05.09.2012 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version...

Læs mere

Specifikation af serviceinterface for organisation. Denne standard er godkendt af OIO-komiteen december 2009

Specifikation af serviceinterface for organisation. Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for organisation Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for Organisation Denne standard kan frit anvendes af alle.

Læs mere

Notat. Introdansk beskrivelse af fastlagte krav til indberetning af statistikoplysninger fra udbydere 27.06.2012 JL

Notat. Introdansk beskrivelse af fastlagte krav til indberetning af statistikoplysninger fra udbydere 27.06.2012 JL Notat Vedrørende: Skrevet af: Introdansk beskrivelse af fastlagte krav til indberetning af statistikoplysninger fra udbydere Jesper Lund Version: 1.4: rev. af Ankestyrelsen, januar 2014 27.06.2012 JL I

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Hvilken version af MS-SQL Server forventes løsningen idriftsat på? Hvilken version af MS SQL Server kører Aarhus kommune?

Hvilken version af MS-SQL Server forventes løsningen idriftsat på? Hvilken version af MS SQL Server kører Aarhus kommune? Notat Den 13. december 2011 Udbud vedr. etablering af en decentral persondata database spørgsmål og svar Introduktion I forbindelse med udbuddet vedr. etablering af en decentral persondata database er

Læs mere

Emne Sidst opdateret 23-08-2010/version 1. 1/Steen Eske Christensen

Emne Sidst opdateret 23-08-2010/version 1. 1/Steen Eske Christensen Emne Sidst opdateret 23-08-2010/version 1. 1/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Behandlede emner Vejledningen består af 3 dele, som kan læses hver for sig. Du kan derfor

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Bekendtgørelse om videregivelse af data fra Bygnings- og Boligregistret (BBR) og øvrige ejendomsdata (OIS-Bekendtgørelsen)

Bekendtgørelse om videregivelse af data fra Bygnings- og Boligregistret (BBR) og øvrige ejendomsdata (OIS-Bekendtgørelsen) BEK nr 195 af 07/03/2008 (Gældende) Udskriftsdato: 2. juli 2016 Ministerium: Ministeriet for By, Bolig og Landdistrikter Journalnummer: Økonomi- og Erhvervsmin., Erhvervs- og Byggestyrelsen j. nr. 07/08217

Læs mere

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 FESD standardisering FESD-modul. Skanningsmodul Version 1.0 Kolofon: FESD moduler. Skanningsmodul. FESD standardisering. Skanningsmodul

Læs mere

Krav til dataformat ved indberetning

Krav til dataformat ved indberetning Bilag 1 Krav til dataformat ved indberetning Dette bilag beskriver data struktur og format for de data som energileverandørerne skal indberette. Formatet på filen er en csv eller xls fil som består af

Læs mere

1 KY-person. 1.1 Skattekort 26.11.2013

1 KY-person. 1.1 Skattekort 26.11.2013 1 KY-person... 2 1.1 Skattekort... 2 1.1.1 Attributter... 3 1.2 Person... 3 1.2.1 Attributter... 3 1.3 Ægteskab... 5 1.3.1 Attributter... 5 1.4 Adresse... 5 1.5 Dansk adresse... 5 1.5.1 Attributter...

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Faktaark for BBR 2.0

Faktaark for BBR 2.0 4. april 2014 SRS Faktaark for BBR 2.0 Overordnet beskrivelse og baggrund for BBR 2.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 BBR i dag... 3 Fremtidige BBR 2.0... 4 3. Teknik...

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

BBR-Kommune Inddataboks

BBR-Kommune Inddataboks BBR-Kommune Inddataboks Brugervejledning Version 1.0 Indholdsfortegnelse 1.1. Forord... 3 1.2. Formål... 3 1.3. Adgang... 3 1.4. Opbygning af vejledningen... 4 2. Inddataboksen set i sammenhæng... 5 2.1.

Læs mere

Affaldsdatasystem Vejledning i manuel indberetning

Affaldsdatasystem Vejledning i manuel indberetning Affaldsdatasystem Vejledning i manuel indberetning Dokument version: 1.3 ADS version: 1.0 Henvendelse vedrørende affald: Miljøstyrelsen Roskilde, Affaldsekretariatet Ny Østergade 7-11 4000 Roskilde Tlf.

Læs mere

CAMPridge Medlemssystemet kan udbygges med en række ekstra funktioner og faciliteter, kaldet tilvalg.

CAMPridge Medlemssystemet kan udbygges med en række ekstra funktioner og faciliteter, kaldet tilvalg. CAMPridge for Dynamics AX - Tilvalg Landeuafhængige tilvalg til CAMPridge Medlems-system CAMPridge Medlemssystemet kan udbygges med en række ekstra funktioner og faciliteter, kaldet tilvalg. Persondata,

Læs mere

Brugerguide Integration af erhvervsdata fra NN Markedsata til Microsoft Dynamics CRM 2013

Brugerguide Integration af erhvervsdata fra NN Markedsata til Microsoft Dynamics CRM 2013 Brugerguide Integration af erhvervsdata fra NN Markedsata til Microsoft Dynamics CRM 2013 Indledning Løsningen Navne & Numre Erhverv Webservice til Microsoft Dynamics muliggør integration til Microsoft

Læs mere

SÆRLIGT SUNDHEDSKORT. NOTUS Kommunal. Den 07.09 2009

SÆRLIGT SUNDHEDSKORT. NOTUS Kommunal. Den 07.09 2009 SÆRLIGT SUNDHEDSKORT NOTUS Kommunal Den 07.09 2009 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.com, scandihealth@csc.com CVR-nr.

Læs mere

Integration mellem webcrm og NN Markedsdata

Integration mellem webcrm og NN Markedsdata Integration mellem webcrm og NN Markedsdata I samarbejde med NN Markedsdata (NNM) tilbyder webcrm følgende 3 tillægsmoduler, der giver mulighed for direkte integration mellem webcrm og NN Markedsdatabasen,

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Blanketdokumentation LÆ 231 & 235 v1.0 Februar 2011

Blanketdokumentation LÆ 231 & 235 v1.0 Februar 2011 Blanketdokumentation LÆ 231 & 235 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

Erhvervs- og Boligstyrelsen

Erhvervs- og Boligstyrelsen Erhvervs- og Boligstyrelsen Analyse af vejnavnesammenfald Undersøgelse af problemer mht. flere forekomster af samme vejnavn i kommunen - efter en kommunesammenlægning Februar 2004 www.carlbro.com INDHOLDSFORTEGNELSE

Læs mere

Vejledning til indberetning af oplysninger om handicappede og udsatte voksne til Danmarks Statistik via Webløsning

Vejledning til indberetning af oplysninger om handicappede og udsatte voksne til Danmarks Statistik via Webløsning Vejledning til indberetning af oplysninger om handicappede og udsatte voksne til Danmarks Statistik via Webløsning Version 6 side 1 Indhold Indledning... 3 Baggrund... 3 Start indberetninger... 4 Kontaktoplysninger...

Læs mere

Blanketdokumentation LÆ 221 & 225 v1.0 Februar 2011

Blanketdokumentation LÆ 221 & 225 v1.0 Februar 2011 Blanketdokumentation LÆ 221 & 225 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge.

Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge. Danmarks Statistik, Velfærd 22. januar 203 Børn og Unge, Udsatte børn Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge. Indhold Baggrund...2 2 Formål...2

Læs mere

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011

Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Blanketdokumentation LÆ 121 & 125 v1.0 Februar 2011 Indholdsfortegnelse 1. Indledning... 3 1.1 Baggrund... 3 1.2 Blanketternes anvendelse... 4 1.3 Den papirbaserede arbejdsgang... 5 1.4 Den fremtidige

Læs mere

Indberetningsstruktur for Elevplanindberetning

Indberetningsstruktur for Elevplanindberetning Indberetningsstruktur for Elevplanindberetning Dato 20-01-2016 Version Status 0.9 Foreløbig udgave Ansvarlig Egon Thor Hansen Side 2 af 15 Ændringshistorik Version Kapitel/afsnit Beskrivelse 0.9 Dokumentet.

Læs mere

Vejledning til leverandører ifm. CPR-abonnement

Vejledning til leverandører ifm. CPR-abonnement Vejledning til leverandører ifm. CPR-abonnement Dette notat beskriver de forhold som man som leverandør og kommune skal være opmærksom på når man ønsker at modtage CPR-data i abonnement fra Serviceplatformen.

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Integration mellem Acadre og GeoEnviron

Integration mellem Acadre og GeoEnviron 1. MÅLSÆTNING... 1 2. OPSÆTNING AF STAMDATA... 2 2.1 KL journalplan... 2 2.2 Parametre til GeoEnvirons mappe-struktur... 3 3. FUNKTIONALITET I GE BYGGESAG... 4 3.1 Oprettelse af ejendomme... 4 3.2 Søgning

Læs mere

Det Gode CPR-opslag MedCom, version 1.0.2

Det Gode CPR-opslag MedCom, version 1.0.2 Det Gode CPR-opslag MedCom, version 1.0.2 1 Indholdsfortegnelse Indholdsfortegnelse... 2 Formål... 3 Introduktion... 3 Adgangskrav... 3 Sikkerhedslog... 3 Løsningsmodel... 4 Funktionalitet... 5 getpersoninformation...

Læs mere

Leverancebeskrivelse - Bilag 1

Leverancebeskrivelse - Bilag 1 Leverancebeskrivelse - Bilag 1 Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 17-07-2008 Kontor: Udviklingsenhed J.nr.: I4148 Sagsbeh.: CHS Fil-navn: Leverancebeskrivelse bilag

Læs mere

Integrationer. Praktikportal projektet Oktober 2014 Version 1.1

Integrationer. Praktikportal projektet Oktober 2014 Version 1.1 Integrationer Praktikportal projektet Oktober 2014 Version 1.1 Revisionshistorie Version Dato Ansvarlig Beskrivelse 1.0 23-10-2014 Lars Christensen Dokument oprettet 1.1 24-3-2015 Kasper Hansen Yderligere

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

ENERGIBESPARELSE I STATEN.

ENERGIBESPARELSE I STATEN. ENERGIBESPARELSE I STATEN. 24-09- 2010 Vejledning til indberetning af målerdata. Ministeriums niveau. Denne vejledning er et supplement til 8 i Vejledning til cirkulære nr. 9787 af 1. oktober 2009 om energieffektivisering

Læs mere

Kvik-guide: Sådan opretter du en bruger

Kvik-guide: Sådan opretter du en bruger Kvik-guide: Sådan opretter du en bruger Denne guide henvender sig til brugere, der er oprettet med en administrator- eller superbrugeradgang, og som har brug for at oprette andre brugere med tilknytning

Læs mere

Erfaringer med CPR-replikering

Erfaringer med CPR-replikering Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs

Læs mere

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata NOTAT MINISTERIET FOR BY, BOLIG OG LANDDISTRIKTER Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata 18. juli 2012 Sag: /mli-mbbl Baggrund Initiativet Genbrug af

Læs mere

Rapport dannet den: 5. oktober 2010 1 Spil kontrol

Rapport dannet den: 5. oktober 2010 1 Spil kontrol 1 Spil kontrol kan vindes af 1 Jackpot - Identifikation - Gevinst - TotalGevinst - DatoTid - KommissionRake Spil - Identifikation - KøbDatoTid - Salgskanal - ForventetSlutDatoTid - FaktiskSlutDatoTid -

Læs mere

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014

Fordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014 Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,

Læs mere

Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR)

Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) Bekendtgørelse om energiforsyningsselskabernes indberetningspligt til Bygnings- og Boligregistret (BBR) I medfør af 4, stk. 4, i lov om bygnings- og boligregistrering, jf. lovbekendtgørelse nr. 160 af

Læs mere

Høringssvar vedr. Serviceinterface for Person

Høringssvar vedr. Serviceinterface for Person Høringssvar vedr. Serviceinterface for Person 1. Indledning... 3 1.1 Arkitekturmæssige overvejelser... 3 2. Konkrete ændringsforslag... 5 2.1 Variable attributnavne... 5 2.2 Registeroplysninger fra akkreditiv...

Læs mere

Guideline. EAN-systemet

Guideline. EAN-systemet Guideline Hammershusgade 17 DK-2100 København Ø Tel: 39 27 85 27 Fax: 39 27 85 10 www.ean.dk for anvendelsen af EAN-systemet til entydig identifikation af målepunkter i EL-forsyningssektoren samt EAN-13

Læs mere

Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet.

Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet. Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet. Version: 1.0, maj 2003 Indholdsfortegnelse: 1. Baggrund... 2 2. Mål... 2 3. Definition

Læs mere

Registrering i Patientadministrativt system - OPUS

Registrering i Patientadministrativt system - OPUS Sygehus: Oprettet af: Gælder for: Oprettet dato: August 2011 Side 1 af 11 ANVENDELSE AF CPR-KOMPONENT ved generering af Erstatnings CPR-numre Formål: At sikre, at der oprettes éntydige erstatnings CPR-numre

Læs mere