Standard IT- og Telestyrelsen København den 17. december 2007

Størrelse: px
Starte visningen fra side:

Download "Standard IT- og Telestyrelsen København den 17. december 2007"

Transkript

1 Standard IT- og Telestyrelsen København den 17. december 2007 FESD-standardisering FESD Datafølgeseddel. Protokol Version 1.0

2 Kolofon: FESD-standardisering. FESD Datafølgeseddel. Protekol. Version 1.0 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Datastandardiseringskontoret, FESDstandardiseringsgruppen i samarbejde med de tre FESD-leverandører Software Innovation A/S, Accenture I/S og CSC mark A/S. Kontaktperson i FESD-standardisering: Projektleder Palle Aagaard, Mailadresse Telefon (direkte) Accenture A/S Arne Jacobsens Allé København S Telefon: Web-adresse: CSC mark 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 Datastandardiseringskontoret National IT and Telecom Agency Ministry of Science, Technology and Innovation Holsteinsgade 63 DK-2100 København Ø Telf Fax / 28

3 Indholdsfortegnelse 1. Forord DEL A FESD Datafølgeseddel Indledning Sammenhæng med DOKFORM og FESD Packet standarderne Formål Afgrænsning Del B Forretningsarkitektur Datafølgesedlens anvendelse Ansvar Protokoller Web-Service til modtagelse af datafølgeseddel Transaktionshåndtering Gentagen oversendelse / opdatering Unik identifikator for sags- og dokumentobjekter Registrering af sags- og dokumentparter Datafølgesedlens struktur Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Elektronisk signering og kryptering af datafølgeseddel Del C Beskrivelse af skema Beskrivelse af klasser Elementet følgeseddel meta Elementet Sag meta Beskrivelse af elementet SagsPart meta Elementet JournalPost Beskrivelse af elementet JournalpostPart meta Beskrivelse af elementet Dokument meta Beskrivelse af elementet DokumentObjekt Elementet Følgeseddel Signatur Bilag A Anvendte typer i FESD-modellerne integer boolean Identifikationstyper char.27 3 / 28

4 1.2.5 date, datetime og time string float.28 4 / 28

5 1. Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både mellem ESDH-systemer og til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESD-standardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-Datastandardiseringskomiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telsestyrelsens OIO-Katalog, som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. 5 / 28

6 2. DEL A FESD Datafølgeseddel 1.1 Indledning Standarden FESD Datafølgeseddel i det følgende betegnet som datafølgesedlen - angiver struktur og indhold for en datafølgeseddel der kan benyttes til oversendelse af sags- og dokumentinformation mellem myndigheder, uden forudgående aftale. Datafølgesedlen kan sidestilles med en almindelig brevforsendelse mellem myndigheder, med den forskel at datafølgesedlen giver den modtagende part alle relevante oplysninger om sags, dokument og part i elektronisk form, som grundlag for registrering Datafølgesedlen er en videreudvikling af FESD Packet, som gav mulighed for at sende dokumenter mellem myndigheder, baseret på DOKFORM standarden i forhold til beskrivelse af dokumenterne. Datafølgesedlen giver også mulighed for at medsende information om sag og part, og udvider dermed anvendelsesmulighederne i forhold til FESD Packet. Datafølgesedlen tager indholdsmæssigt udgangspunkt i FESD Datamodel, og sags- og parts- og dokumentinformation er således umiddelbart sammenligneligt med FESD Datamodel. 1.2 Sammenhæng med DOKFORM og FESD Packet standarderne FESD Packet standarden specificerer hvorledes dokumenter sendes mellem myndigheder, baseret på DOK- FORM eller udvekslingskernen som den også kaldes. FESD Packet er begrænset til at sende dokumenter via e- post, og havde dermed en række begrænsninger i forhold til såvel det indholdsmæssige, som metoder til at sende. Datafølgesedlen giver mulighed for at benytte andre protokoller end SMTP ( ), og giver desuden mulighed for at sende information om sag og part i tilknytning til dokumenterne. Forsendelser med datafølgesedlen, beriger således forsendelsen i et større omfang end FESD Packet gav mulighed for. Datafølgesedlen afløser FESD Packet, og udgør det der i FESD Packet standarden betegnes som FASE 2. Der vil ikke ske yderligere revisioner af FESD Packet, ligesom der sandsynligvis heller ikke vil blive udarbejdet flere revisioner af DOKFORM (Udvekslingskernen) Formål Formåled med standarden FESD Datafølgeseddel, er at give et grundlag for fremsendelse af sager og dokumenter fra en myndighed til en anden, og dermed understøtte behovet for sagsbehandling på tværs af myndighederne i den offentlige forvaltning Afgrænsning Standarden for FESD Datafølgeseddel har sit udgangspunkt i FESD Packet standarden, og i FESD kontraktens krav om understøttelse af efølgeseddel såvel ved afsendelse som modtagelse af dokumenter i FESD systemet. Standarden baserer sig ikke på eller har sit udgangspunkt i den norske NOARK-4 standard, som det er tilfældet for andre FESD standarder. Standarden stiller ikke eksplicitte krav til implementering af forretningslogik, til understøttelse af udveksling baseret på datafølgesedlen, men FESD kontraktens krav om at FESD systemet skal kunne danne og afsende en e-følgeseddel baseret på udvekslingskernen, samt modtage og anvende samme som registreringsgrundlag, vil være gældende i forhold til datafølgesedlen. Anvendelse af de forskellige protokoller, beskrevet i Del B afsnit 1.5 vil variere fra leverandør til leverandør, og der kan kun forventes en understøttelse, svarende til den eksisterende, baseret på udvekslingskernen. 6 / 28

7 3. Del B Forretningsarkitektur 1.3 Datafølgesedlens anvendelse Datafølgesedlen giver mulighed for at en myndighed kan sende sager og dokumenter til en anden myndighed, i elektronisk form. Forsendelsen indeholder, udover de elektroniske dokumenter, de metadata den afsendende myndighed har registreret i sit FESD ESDH system, og giver således den modtagende myndighed et grundlag for registrering af tilsvarende metadata i sit FESD ESDH system. Dermed opnår den modtagende myndighed dels en større præcision i sin registrering, dels en effektivitetsgevinst idet en tidligere registrering genbruges. Det er vigtigt at bemærke, at der i forvaltningsmæssig forstand er tale om forskellige instanser af hhv. sager og dokumenter hos den afsendende og modtagende myndighed. Nedenstående figur illustrerer den forretningsgang, datafølgesedlen er tænkt anvendt: Fig. 1 Forretningsgang for oversendelse af datafølgeseddel En forbindelse med et sagsforløb, som indvolverer to myndigheder, udfører myndighed A sin sagsbehandling til et givent punkt, og sagen skal herefter behandles i myndighed B. Myndighed A danner en datafølgeseddel indeholdende information om sagen, sagens dokumenter og de elektroniske dokumenter, og sender denne via en af de mulige protokoller til myndighed B. Myndighed B anvender det fremsendte som grundlag for registrering af sagen/dokumenterne i sit FESD ESDH system. 1.4 Ansvar Det er den afsendende part som har ansvaret for oversendelsen, herunder modtagelsen, til den modtagende part. Det vil sige at det er den afsendende part der skal sikre at den oversendte information er modtaget og vil blive behandlet som ønsket. Standarden giver ikke mulighed for f.eks. anmodning om hvittering for modtagelse eller behandling. Den afsendende part må foretage en implementering af datafølgesedlen, som i nødvendigt omfang sikrer afsendelse/modtagelse i henhold til de krav der gælder for kommunikationen mellem de to parter. Dette kan ske gennem valg af protokol og evt. gennem særskilt aftale mellem afsender og modtager. 1.5 Protokoller Til forskel fra FESD Packet, som alene forholder sig til benyttelse af SMTP (e-post), kan man sende datafølgesedlen ved hjælp af flere protokoller: 7 / 28

8 SMTP FTP FILE HTTP Oversendelse via e-post. Denne protokol er i dag understøttet af FESD Packet standarden, og er den protokol der typisk anvendes. Protokollen er asynkron. Det vil sige at man ikke umiddelbart får en kvittering for modtagelse, og ikke har 100% sikkerhed for modtagelse. Oversendese via FTP protokollen kan anvendes i forbindelse med oversendelse af større data mængder. Herudover har protokollen den fordel at man får en teknisk kvittering på at oversendelse er gennemført. Ved oversendelse af større datamængder, eller oversendelse til en myndighed som ikke har åbnet for direkte kommunikation, kan protokollen FILE anvendes. I praksis vil oversendelsen skulle ske via et fysisk medie (CD, DVD, USB-memory stick, ell. lign.). Mediet transporteres fysisk fra afsender til modtager. Man kan opnå kvittering for modtagelse, gennem traditionelle forsendelsesmetoder (post / bud / fragt). I de tilfælde hvor man har hyppig oversendelse af data fra en myndighed til en anden, f.eks. i de tilfælde hvor to myndigeder i fællesskab forvalter et sagsområde, kan det være hensigtsmæssigt at pgl. myndigheder udvikler web-services som benyttes til oversendelsen. Ved valg af protokol, er der flere ting som bør overvejes: 1) Tekniske mulighede for kommunikation 2) Behovet for kvittering for oversendelse/modtagelse 3) Datamængder Selve datafølgesedlen er identisk, uanset valgt protokol, men omfanget i forbindelse med implementering, og den opnåede sikkerhed i forbindelse med overførsel vil variere meget. 1.6 Web-Service til modtagelse af datafølgeseddel Som en del af standarden defineres en webservice ved navn receivefesddeliverynote, som skal kunne modtage en datafølgeseddel og behandle denne med henblik på registrering i et ESDH system. Da en datafølgeseddel per definition kun kan fungere som et regitreringsgrundlag kan den interne funktionalitet i servicen ikke beskrives, og det vil være frit for den enkelte leverandør at afgøre graden af manuel sagsbehandling i forbindelse med en oversendelse. Servicen har således til formål at sikre, at det er muligt at sende datafølgesedlen problemfrit via http-protokollen, og kravet er således blot at servicen tager en datafølgeseddel som argument. 8 / 28

9 receivefesddeliverynote (Standard WebService) Fig. 2 Netværk af myndigheder der udstiller en dedikeret Web-Service til modtagelse af datafølgeseddel Webservicen bør implementeres via som en realisering af OWSA model T (OIO Web Service Arkitekur model Transportbaseret sikkerhed) referencemodellen. OWSA model T er baseret på punkt-tilpunkt kommuninkation over SSL 3.0. Dermed sikres fortroligheden i forbindselse med overførsel af data, og datafølgeseddelen behøver ikke særskilt kryptering. OWSA model T er endvidere relevant da denne standard realiserer både MOCES(medarbejdercertifikat) og VOCES(virksomhedscertifikat). Det er således muligt at som myndighed eksponere en webservice til modtagelse af datafølgesedler og samtidigt sætte konkrere regler for hvilke myndigheder eller sagsbehandlere der kan tilgå denne service, og sikre en pålidelig identifikation af samme. Dette personcertifikat skal ikke forveksles med den signering som foregår på selve datafølgeseddelen. Signering af datafølgeseddel har til formål at sikre uafviselighed af data på tværs af protokoller, hvorimod certifikatet som oversendes med webservicekaldet har til formål at bevise brugsretten af pågældende service. I takt med implementering af standarden i den offentlige sektor, vil de implementerede Web-Services udgøre et alternativt forsendelsesnet. Standarden indeholder ikke administrative retningslinier i forhold til lokalisering og anvendelse af en modtagelsesservice hos en specifik myndighed. Det forventes her at den eksisterende infrastruktur omkring OIO/ISB benyttes. Myndigedernes web-services vil dermed være udstillet i det centrale UDDI. 1.7 Transaktionshåndtering Datafølgesedlen er udviklet med henblik på effektiv oversendelse af sags- og dokumentinformation, herunder dokumentobjekter. Standarden indeholder ikke mulighed for f.eks. at afsender kan anmode om modtagelseskvittering af modtageren. Krav om pålidelighed, kvittering, mv. skal adresseres i forbindelse med valg af protokol, og evt. gennem bilaterale aftaler mellem afsender og modtager. 9 / 28

10 Høj pålidelighed i forbindelse med oversendelse opnås gennem anvendelse af http protokollen. Det vil sige gennem en dedikert webservice, som modtageren udstiller. Her vil man umiddelbart få en kvittering for transaktionen og dermed for teknisk modtagelse af den oversendte pakke. Tilsvarende vil man ved anvendelse af protokollen FTP kunne opnå en teknisk transmissionskvittering. I forhold til anvendelse af FILE og SMTP protokollerne, som begge er asynkrone protokoller, er der ikke umiddelbart mulighed for at opnå kvittering for modtagelse, og bør således ikke benyttes hvis det er et krav i forbindelse med oversendelsen Gentagen oversendelse / opdatering I forbindelse med hyppig kommunikation mellem to myndigheder, kan man forestille sig et behov for at den ene myndighed sender en sag med sagens dokumenter, og på et senere tidspunkt ønsker at sende samme sag, med opdaterede oplysninger samt yderligere dokumenter. Opdatering er ikke medtaget som en del af standarden, og de to oversendelser er i forhold til standarden selvstændige, uafhængige forsendelser.evt. semantik omkring opdatering af sagsinformation, tilføjede dokumenter siden sidste forsendelse, mv. skal aftales bilateralt mellem afsender og modtager. Til støtte for fastlæggele af semantik omkring gentagen oversendelse, indeholder standarden krav om entydig identifikation af sags- og dokumentobjekter se afsnit vedrørende unikke identifikatorer Unik identifikator for sags- og dokumentobjekter Oversendelse af sager mellem myndigheder kan ske på et vilkårligt tidspunkt i sagsforløbet, og kan i nogle tilfælde ske flere gange: SAG A SAG A SAG A Sagsbehandling Sagsbehandling Sagsbehandling TID. Fig. 3 Sagens udvikling over tid, med flere oversendelser. Ovenstående figur, illustrerer et sagsforløb, hvor den samme sag sendes fra en myndighed til en anden, flere gange indenfor det specifikke sagsforløb. Sagen vil udvikle sig over tid, det vil sige at der vil være flere dokumenter i sagen, sagens metadata vil muligvis ændre sig, osv. Standarden giver ikke mulighed for at DELE en sag mellem to myndigheder det vil sige at der ikke er elementer eller metoder som specifikt skal bidrage til at sikre synkronisering af sags- og dokumentinformation mellem to myndigheder. Imidlertid er der et krav om at den afsendende part opmærker afsendte sager og dokumenter med en unik identfikator, som skal benyttes ved en evt. senere oversendelse af samme sag/dokument eller ved oversendelse til en tredje myndighed. Referencens formål er primært at kunne identificere et sags- eller dokumentobjekt der oversendes mere en en gang, men kan også benyttes som reference i andre former for dialog mellem myndigheder. 10 / 28

11 Den unikke identifikator, anbefales konstrueret som en UUID (som vist på nedenstående figur). UUID benyttes generelt i FESD Datamodel og øvrige standarder i forbindelse med dannelse af entydige nøgler. Som følge af denne standard, vil FESD Datamodel blive konsekvesrettet, så et ophavs UUID vil blive tilføjet på sags- og dokumentklasserne. Fig. 4 Entydig nøgle for et sagsobjekt Registrering af sags- og dokumentparter I forbindelse med oversendelse af sager og dokumenter mellem to myndigheder, skal det oversendte som tidligere beskrevet opfattes som registreringsgrundlag ved modtagelse. Det er i denne forbindelse vigtigt at den modtagende myndighed fastlægger generelle principper for hvorledes den oversendte partsinformation benyttes og dermed registreres. Hvis man f.eks. forestiller sig at en myndighed har opretttet en sag, på baggrund af en skrivelse, modtaget fra en borger, vil denne skrivelse være registreret i myndighedens ESDH system som et indgående dokument, og borgeren vil være registreret som dokumentpart med egenskaben AFSENDER. Sagen og sagens dokumenter oversendes på et tidspunkt til en anden myndighed, som en del af det samlede sagsbehandlingsforløb. I den datafølgeseddel der dannes i forbindelse med oversendelsen, vil førnævnte dokument, inkl. partsregistrering være indeholdt. Den modtagende myndighed vælger at oprette en sag i eget ESDH system, på baggrund af det oversendte, og lade denne indeholde de dokumenter der er modtaget. I forbindelse med registreringen af dokumenterne i sagen, skal myndigheden tage stilling til om det førnævnte dokument, skal registreres med en dokumentpart med egenskaben AFSENDER, hvor afsenderen er borgeren, eller om den afsendende myndighed skal angives som afsender, og i givet fald, hvilken egenskab skal dokumentparten der indeholder information om borgeren have. Der vil formodentlig være forskel i praksis, fra myndighed til myndighed, og eventuelt også fra sagstype til sagstype, og standarden sætter derfor ingen restriktioner i forhold til praksis. Myndigheden må dermed fastlægge praksis i forbindelse med implementering af standarden Datafølgesedlens struktur Datafølgesedlen indeholder en sag og et eller flere dokumenter, samt parter på både sags- og dokumentniveau. Dokumenter skal i denne sammenhæng forstås som journalposter der kan indeholde flere dokumenter - både metadata om dokumenter og selve dokumentobjektet. I modsætning til standarderne DOKFORM/FESD-Packet, forudsætter datafølgesedlen et sagselement indeholdt. Denne forudsætning er baseret på at oversendelse af information mellem myndigheder er en forvaltningsmæssig handling som skal dokumenteres i en sagsmæssig sammenhæng. Datafølgesedlen kan således ikke benyttes til oversendelse af dokumenter uden sagsmæssigt tilhørsforhold. Strukturen følger strukturen i FESD Datamodel, med SAG-JOURNALPOST-DOKUMENT- DOKUMENTVERSION. Der er dog foretaget en sammenlægning af klasserne DOKUMENT og DOKU- MENTVERSION, idet datafølgesedlen ikke understøtter oversendelse af flere versioner af samme dokument. Det antages, at en myndighed ved oversendelse af et dokument, sender seneste officielle/godkendte version. 11 / 28

12 Følgeseddel Meta FØLGESEDDEL SAG Sag Meta 1.. Sagspart Meta Journalpost Meta JOURNALPOST JournalpostPart Meta Dokument Meta DOKUMENT Dokument Objekt Journalpost MetaExt Sag MetaExt Følgeseddel Signatur Fig. 5 FESD datafølgeseddel opbygning Dokumentobjekter (filer) inkluderes i datafølgesedlen, som kodede objekter, ved benyttelse af base64 encoding. Datafølgesedlen vil således kun bestå af ét filobjekt et XML-dokument, indeholdende såvel metadata som dokumentobjekter (filer). I forhold til dokumentformater, indeholder standarden ingen begrænsninger. I og med der benyttes Base64 encoding, neutraliseres det oprindelige format. Det betyder, at den enkelte myndighed må vurdere hvilke formater det er hensigtsmæssigt at anvende ved oversendelse til en anden myndighed. Man bør anvende formater der er generelt accepteret som produktionsog/eller arkiveringsformater, for at sikre at modtageren er i stand til at læse/benytte de oversendte dokumenter, herunder sikre at gældende standarder for anvendelse af dokumentformater i forbindelse med udveksling, overholdes. Standarden sætter ikke restriktioner i forhold til hvilke formater det er tilladt at medsende i en datafølgeseddel- Filobjektet betragtes som et binært objekt, og dette kodes efter Base64 kodningsstandarden. Elementet DOKUMENT giver mulighed for en simpel angivelse af hvilket format et givent dokument oversendes i. Angivelsen foretages ved at specificere ekstension samt en verbal beskrivelse af formatet. Det er således alene andre standarder/regler som kan sætte restriktioner for hvilke formater der kan/skal benyttes i forbindelse med en specifik oversendelse. 12 / 28

13 1.7.5 Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Datafølgesedlen indeholder generelle metadata for sager, dokumenter og parter. Normalt vil disse være dækkende i forhold til at beskrive de sager og dokumenter der oversendes, men der kan være behov for sektorspecifikke eller myndighedsspecifkke metadata, som vil kunne berige de oversendte sager/dokumenter og dermed potentielt berige en given sagsproces. Datafølgesedlen indeholder derfor en mulighed for udvidelse, som kan benyttes. Udvidelsesmuligheden kan benyttes med de nedenfor beskrevne restriktioner. Anvendelse af myndigheds- eller sektorspecifikke udvidelser af skemaet Overordnet kan den påtænkte udvidelsesmulighed illustreres på følgende måde: XML SCHEMA FESD DATAFØLGESEDDEL SAG-Meta META-Extension ISB JOURNALPOST-Meta META-Extension Udvidelser skal ske gennem særskilte, publiserede skemaer Fig. 6 Udvidelseselementer i datafølgesedlen De to udvidelsesformer dækker: 1) Beskrivende metadata om sagen Yderligere, beskrivende attributter om sagen 2) Beskrivende metadata om dokumentet Yderligere, beskrivende attributter om dokumentet Tilføjelse af de to typer af udvidelser, realiseres gennem et såkaldt ANY element, der som bekendt kan benyttes uden restriktioner i XML skemaet. En fri modellering af ANY elementet, vil svække standarden, og elementet vil således kun kunne benyttes indenfor standarden, såfremt en række betingelser er overholdt: 1) Udvidelser skal realiseres gennem særskilte skemaer, som er publiceret på ISB en 2) Skemaerne skal følge NDR reglerne i forhold til udformning, mv. 3) Skemaerne skal formålsbeskrives, og må ikke dække generelle forhold som rettelig skal adresseres i standarden og ikke som en udvidelse. 4) Der skal være reference til ansvarshavende for udvidelsen Kravet om publicering af udvidelserne betyder at modtageren vil være i stand til at validere de udvidelser der er foretaget. Det vil også betyde, at standardiseringsenheden vil kunne opsamle og vurdere de forskellige udvi- 13 / 28

14 delser der foretages, med henblik på at revidere standarden, og evt. tilføje yderligere, generelle metadata til standarden Elektronisk signering og kryptering af datafølgeseddel Et vigtigt element i FESD Datafølgeseddel, er muligheden for at signere følgesedlen, standardiseret og dermed uafhængigt af specifikke produkter, og uafhængig af hvilken protokol man benytter i forbindelse med oversendelse. I datafølgesedlen anvendes XML-Signature (xmldsig) til at påføre digitale signaturer. Den fulde beskrivelse af xmldsig ligger udenfor dette dokuments formål og kan findes på Datafølgesedlen tillader et ubegrænset antal personer at signere følgesedlen, og det vil således være muligt at implementere en procedure hvor en sagsbehandler forbereder og danner følgesedlen, signerer denne digitalt og fremsender til nærmeste leder for godkendelse, inden afsendelse. Tilsvarende vil en modtager af datafølgesedlen kunne signere denne, og dermed tilføje endnu en signatur til følgesedlen, hvorefter den kan videresendes indeholdende alle digitale underskrifter. Signatur kan påføres datafølgesedlen som helhed. Standarden giver ikke mulighed for at signere enkelte dele af følgesedlen. Signeringen foretages, som tidligere nævnt, uafhængig af den protokol der påtænkes anvendt. En signeret datafølgeseddel kan sålede oversendes via e-post, på en CD, via ftp, mv., i sogneret form. Anderledes forholder det sig med kryptering. Standarden ser kryotering som værende knyttet til transport. Det vil sige til de protokoller som er nævnt i afsnit 1.5 Protokoller. Fig. 7 Adskillelse af signering og kryptering af datafølgesedlen Ovenstående figur, illustrerer adskillelsen af signering og kryptering. Signeringen foretages på datafølgesedlen, og først når datafølgesedlen afsendes, krypteres den forsendelse som datafølgesedlen udgør. Det vil dermed være muligt at anvende krypteringsfaciliteterne i det e-post programmel man anvender, man kan vælge at benytte liniekryptering ved oversendelse via http (https), mv. 14 / 28

15 Del C Beskrivelse af skema 1.1 Beskrivelse af klasser Elementet følgeseddel meta Indeholder overordnet information om datafølgesedlen Type Kardinalitet Beskrivelse dfsafsendernavn dnsendername char(50) [1] Afsender myndighedsnavn dfsafsendercvr dfsafsenderpnr int(8) [1] Afsenders CVRnummer. dfseannummer dfseanreference Int(8) [1] Afsenders EAN nummer dfsafsenderkontaktpersonnavn dnsendercvrreference dnsenderpreference dnsendercontact- Name dfsafsendelsesdatotid dfssenderdatetime DateTime CCYYMMDD, Jf. ISO dfsdokumenthenvisningreference dfsdocumentreference int(8) [0..1] Afsenders P-nummer produktionsenhedsnummer under det anførte CVRnummer. char(50) [1] Personnavn på vedkommende der er ansvarlig for afsendelse af følgesedlen, og som dermed bør kontaktes i forhold til den specifikke oversendelse. anyuri [0..1] Der kan her indsættes en reference til et af de dokumenter der er indeholdt i datafølgesedlen. Dette kan benyttes til at angive et dokument som værende følgeskrivelse til datafølgesedlen og som dermed må forventes at indehole formål, mv. med oversendelsen Elementet Sag meta Indeholder information om sagen med hovedvægt på de traditionelle journaloplysninger. Type Kardinalitet Beskrivelse sagidentifikatir casefileidentifier UUID [1] Unik nummerering af samtlige sager for at sikre teknisk entydighed. Anvendes som teknisk reference for sagen, hvilket muliggør skabelse af referentiel integritet. UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). Anføres på formen: urn:uuid:<uuididentifier> 15 / 28

16 Type Kardinalitet Beskrivelse sagpapir paperstorageindicator Indicator [0..1] Angiver om sagen arkiveres på papirform eller elektronisk. Værdi der angiver, om sagen er på papir eller elektronisk. sagdato creationdate Date [1] Oprettelsdato for sagen. Bør tildeles automatisk. Anvendes som bl.a. afgrænsiningsparameter ved søgninger. Sagsoprettelsdato CCYYMMDD, Jf. ISO sagtitel titletext text [1] Feltet indeholder sagens titel, der er ingen krav om entydighed, blot at titlen afspejler sagens indhold. Feltet bidrager sammen med journalnummer/emneord og andre sagsinformationer til at sagsbehandleren/journalføreren kan vurdere sagens indhold og dermed relevans for den opgave, vedkommende skal løse. Felt indeholder sagens titel i klar tekst. sagtiteluofficiel TitleUnofficialIndicator Indicator [1] Værdi der markerer, om sagstitlen er officiel. Markerer om sagstitlen indeholder fortrolig information, eller af anden grund ikke er officiel. sagtitelalternativ TitleAlternativeText text [0..1] Hvis sagstitlen er uofficiel kan dette felt indeholde en alternativ officiel sagstitel, til postlister etc. Feltet indeholder en alternativ titel i klar tekst. sagsstatusbetegnelse StatusName Name [1] Sagsstatus betegnelse i klar tekst. Fri tekst. sagstypebetegnelse name text [1] Sagstypebetegnelsen i klar tekst. Anvendes til at beskrive en række sagstyper, der kan indgå i sagsbehandlingen. sagansvarligsagsbehandler managerreference char(50) [1] Feltet udfyldes med navn på ansvarlig sagsbehandler. Hentes fra Bruger.brugerNavn sagundtagetoffentlighed RestrictedFromPublicText name [0..1] Henvisning til den lovgivning under hvilken denne sag er undtaget offentlighedsloven. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage sagen fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. sagsenestejournalpost latestrecorddate Date [0..1] Udfyldes med dato for seneste registrerede journalpost. Angiver hvornår der senest har været tilføjet journalposter i sagen. Der er ikke sammenhæng til rækkefølgen af dokumenter. Bør være automatisk genereret dato af seneste tilføjelse af journalpost. sagsletningsfrist retentiontimeyear integer(2) [0..1] Antal år sagen skal bevares. Anvendes typisk i forbindelse med Kassationsbestemmelser fra Statens Arkiver og/eller sletningsfrister jf. Registerforeskriften fra Datatilsynet. Antal år CC. kassationskodebetegnelse name Name [1] KassationsKoden i klar tekst. Beskriver kassationskoden. 16 / 28

17 Type Kardinalitet Beskrivelse sagkassationdato DisposalDate Date [0..1] Angiver hvornår der skal foretages kassation eller anden arkivmæssig behandling af sagen. Kassation skal jf. Persondatabeskyttelsesloven foregå på et givent tidspunkt. Der skal eventuelt ske aflevering til Statens Arkiver inden. Denne dato angiver hvornår der skal foretages kassation. Kassationsdato CCYYMMDD, Jf. ISO sagnr NumberIdentifier char(40) [1] Frit sagsnr. Eventuelt sammenstillinger af andre felter. Indeholder ofte journalnummeret, der traditionelt er sammenstillinger af forskellige andre felter fra Sag og Registrering eksempelvis sagsår, saggruppe og sagloebenummer. Frit sagsnummer. Fri tekst. sagafsluttetdato casefilecloseddate Date [0..1] Udfyldes med den dato sagen opfattes som afsluttet CCYYMMDD, Jf. ISO 8601 sagnormtid casefileestimatedtime Integer(3) [0..1] Evt. fastsat normtid i dage for behandling af sagen sagnettosagsbehandlingstid CaseFileActualWork Integer(3) [0..1] Skønnet nettosagsbehandlingstid i dage. Dvs. antal kalenderdage brugt til egentlig behandling af sagen og dermed undtaget de dage hvor sagen behandles udenfor institutionen (er i høring, behandles af anden institution, afventer svar fra part etc.) emneidentifikator termidentifier char(34) [1] Dette er den entydige identifikator for emnet indenfor systematikken. Identifikatoren er en streng, hvor tilladte karakterer er alle alfanumeriske tegn plus tegnet punktum (. ). emnekvalificeretemneid termuniquetermidentifier URI [1] Dette er en generelt entydig identifikator for emnet. Identifikatoren er en URI dannet ved sammensætning af den URI-baserede identifikator for emnesystematikken + URI-fragmentsymbolet # + emneid. emnedeskriptortekst termdescriptortext Text [1] Kortfattet, præcis titel for emnet. Denne ID skal gøre det muligt for eksterne parter og systemer entydigt at genkende og identificere klassificering foretaget med emnesystematikken. I tilfælde, hvor der foretages lovlige udvidelser af en emnesystematik med ekstern forfatter, udvides identifikatoren for emnesystematikken med en organisationsreference. sagsikkerhedsklassifikation casefilesecurityclassifcation char(50) [0..1] Sikkerhedsklassifikationskode. Sikkehedsklassifikation er beskrevet i FES- Dstandarden for BrugerAdministration Beskrivelse af elementet SagsPart meta Indeholder information om sagens parter. Part skal her forståes bredt, som personer, organisationer, genstande, mv. Elementet er primært opbygget af elementer fra FESD adressemodel, som ikke beskrives her. Der henvises til beskrivelse af adressemodellen på oio.dk: 17 / 28

18 Type Kardinalitet Beskrivelse sagspartrolle casefilereferencerole ShortText [0..1] Den rolle (part, fuldmægtig advokat eller lign.) kontaktpersonen har i sagen. Fri tekst. Eventuelt hentet fra opslagstabel. sagspartuofficielindikator casefilereferenceunofficielindicator Indicator [0..1] Udfyldes hvis oplysninger om sagsparten er undtaget almindelig offentlighed. Hvis sagsparten er en person, må sagspartsoplysningrne ikke umiddelbart offentliggøres. Der kan også findes andre årsager til at sagspartsoplysningerne ikke umiddelbart må offentliggøres. Værdi, hvortil der bør anvendes følgende udfaldsrum: 1 hvis sagsparten ikke umiddelbart kan offentliggøres ellers 0. sagspartkommentar casefilereferencecomment Text [0..1] Kommentar der beskriver sagspartens forhold til sagen. Fri tekst Elementet JournalPost Type Indeholder grundoplysningerne om en Journalpost. Anvendes til at registrere grundoplysninger om hoveddokument, eventuelt med underdokumenter og/eller bilag. Kardinalitet 18 / 28 Beskrivelse journalpostidentifikator recordidentifier UUID [1] Unik nummerering af samtlige Journalposten for at sikre teknisk entydighed. Anvendes som teknisk reference for Journalposten, hvilket muliggør skabelse af referentiel integritet. journalpostdokumentnummer SequenceNumber Sequence- Number UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). ). Anføres på formen: urn:uuid:<uuid-identifier> [1] Dokumentnummeret indenfor sagen. Anvendes til at definerer dokumentets rækkefølge i sagen. I Noark 4 tildeles nummeret automatisk og kan kun ændres ved en flytning eller omregistrering af sagen. Entydigt maskingenereret løbenummer knyttet til dokument i sagen. journalpostregistreringsdato RegistrationDate date [1] Registreringsdato for journalposten. Anvendes til at registrere det tidspunkt, hvor journalposten er registreret i systemet. Retningslinierne for udfyldelsen af dette felt bør hænge sammen med processen for modtagelse af dokumenter. Registreringsdato CCYYMMDD, Jf. ISO dokumenttypebetegnelse name Name [1] Dokumenttypen i klar tekst. journalpostdokumentdato documentdate Date [1] Dokumentdato for dokumentet. Anvendes til at registrere den dato, der er påstemplet eller på anden måde registreret på dokumentet. Dokumentdato

19 journalpostudateret Kardinalitet documentdateunknownindicator Type Beskrivelse CCYYMMDD, Jf. ISO Indicator [1] Værdi der dokumenterer, om dokumentet er udateret. Et dokument betragtes som udateret, hvis det ikke er muligt at lokaliserer en dato af brevheaderen eller specifikt markeret som afsendelsesdato. journalpostindholdsbeskrivelse descriptiontext Text [1] Tekst der beskriver indholdet af journalposten. Anvendes til at beskrive indholdet af journalposten, der kan være tale om et hoveddokument med underdokumenter, eller bilag, eller enkeltstående dokumenter. Fri tekst. Om journalposten. journalpostindholdsbeskrivelseuofficiel journalpostindholdsbeskrivelsalternativ descriptionunofficialindicator Indicator [0..1] Udfyldes hvis oplysninger om Journalpostens indholdsbeskrivelse er undtaget almindelig offentlighed. Hvis beskrivelsen af journalpostens indhold indeholder personoplysninger, eller anden fortrolig information markeres det i dette felt. alternativedescriptiontext Text [0..1] Kan indeholde en alternativ beskrivelse. Hvis indholdsbeskrivelse af journalpost er uofficiel, kan dette felt indeholde en alternativ officiel journalpost beskrivelse til postlister etc. journalpostafskrivningsdato depricationdate date [0..1] Registrerer dato for hvornår dokumentet er færdigbehandlet. I den offentlige forvaltning skal det sikres, at alle henvendelser besvares, og at de besvares indenfor en given tidsramme. Feltet anvendes som basisinformation for denne type af opgaver. Færdigbehandletdato CCYYMMDD, Jf. ISO journalpostekspederetdato responsedate date [0..1] Registrerer dato for hvornår dokumentet er ekspederet. Knytter sig til sagsbehandlingsdelen af systemet. Ekspeditionsdato CCYYMMDD, Jf. ISO journalpostforfaldsdato responsedeadlinedate date [0..1] Forfaldsdato registrerer, hvornår dokumentet senest skal være ekspederet. Knytter sig til sagsbehandlingsdelen af systemet. Fristdato for ekspedition CCYYMMDD, Jf. ISO journalpostundtagetoffentlighed publicationindicator ShortText [0..1] Henvisning til den lovgivning under hvilken denne journalpost er undtaget offentlighedsloven. Udfyldes hvis journalposten er undtaget fra almindelig offentlighed. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage journalposten fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. journalpostoffentlighedsvurderet publicationevaluationdate Date [0..1] Dato for hvornår journalposten er blevet offentlighedsvurderet. Anvendes til at beskrive hvornår Journalposten er blevet offentlighedsvurderet. Kan anvendes i forbindelse med aktindsigtsregler og/eller åbne postlister. Offentlighedsvurderet dato CCYYMMDD, Jf. ISO journalpostpapir PaperStorageIndicator Indicator [1] Skal journalposten arkiveres i papirform eller elektronisk. Angiver om journalposten arkiveres på papirform eller elektronisk. 19 / 28

20 Type Beskrivelse journalstatusbetegnelse recordstatusname ShortText [1] Journalstatus i klar tekst. Beskriver Journalstatus. journalpostansvarligenhed casefilemanagerreference Char(50) [0..1] Udfyldes med information om hvem der er ansvarlig sagsbehandler. Kardinalitet journalpostansvarligsagsbehandler recordrecipientunitreference Hentes fra Bruger.brugerNavn char(50) [0..1] Udfyldes med information om ansvarlig organisation/afdeling for journalposten. Enhedsnavnet hentes fra OrgEnhed.enhedsNavn journalpostskandato recordscandate Date [0..1] Datoen hentes fra scandatatime efter evt. skanning. Formatet er CCYYDDMM, jf. ISO 8601 journalpostskantid recordscantime Time [0..1] Tidspunktet hentes fra scandatetime efter evt. skanning. Formatet er hh:mm:ss, jf. ISO 8601 journalpostsikkerhedsklassifikation recordsecurityclassifcation char(50) [0..1] Sikkerhedsklassifikationskode. Sikkehedsklassifikation er beskrevet i FES- Dstandarden for BrugerAdministration. journalpostkategorikode recordcategorycode Code [0..1] Kategori af Journalposten. Denne kan være indgående, udgående, notat. Udfyldes med I, U, N Beskrivelse af elementet JournalpostPart meta Type Indeholder information (navn adresse etc.) som beskriver den/de person, virksomhed, myndighed eller organisation, som er part i dokumentet (afsender/modtager). Kardinalitet 20 / 28 Beskrivelse personcprnr personcprnumber integer(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. Udfyldes såfremt personorganisationindikator angiver at der er tale om en person. personadresseringsnavn personaddressname Name 1 Fornavn, mellemnavn og efternavn, sammenstillet. Elementet er ikke nødvendigvis konstrueret af de selvstændige elementer fornavn, memmelnavn og efternavn, men kan i sin helhed være tolket eller indtastet i forbindelse med indskanningen. Udfyldes såfremt personorganisationindikator angiver at der er tale om en person. personfornavn personsurname char(50) 0..1 Den samlede længde af fornavn må ikke overskride 50 karakterers længde personmellemnavn personmiddlename char(40) 0-1 Den samlede længde af mellemnavn må ikke overskride 40 karakterers længde personefternavn personfamilyname char(40) 0..1 Feltets indhold kan bestå af flere navne adskilt af en blank position eller af en

21 Type Kardinalitet 21 / 28 Beskrivelse bindestreg. Feltet kan være blank for børn, hvis disse endnu ikke er navngivet. organisationcvrnr organizationcvrnumber integer(8) 0-1 Afsenderorganisationens CVR nummer. Udfyldes såfremt personorganisationindikator angiver at der er tale om en organisation. organisationorganisationsnavn organizationorganization- Name char(50) 0..1 Navnet på organisationen eller virksomheden. Udfyldes såfremt personorganisationindikator angiver at der er tale om en organisation. personorganisationindikator personorganizationindicator indicator 1 Angivelse af om part er en person eller en organisation, og således hvilke oplysninger der skal være tilstede. adressekommunekode addressmunicipalitycode char(4) 0..1 Det af Indenrigsministeriet fastsatte nummer for kommunen. Refererer til klassen Kommune. Herfra kan kommunenavn hentes. adresselandkodealfa2 addresscountrycodealpha2 Code 1 ISO-betegnelsen for land. adressevejkode addressroadcode char(4) 0..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 mark. Refererer til klassen Vej. Herfra kan udledes såvel vejnavn som vejadresseringsnavn adressehusnr addresshousenumvber char(4) 0..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. Ved Husnummer forstås i mark 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. adresseetage addressflorrefernce 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.

22 Type Kardinalitet Beskrivelse adressedoerbetegnelse addressdoorreference 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. adresselinie1 addressline1 char(50) 0-1 c/o reference. Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. adresselinie2 addressline2 char(50) 1 Gade, husnummer, etage. Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. adresselinie3 addressline3 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adresselinie4 addressline4 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adresselinie5 addressline5 char(50) 0-1 Såfremt landekodealfa2 er forskellig fra DK, indgår adresselinien uspecificeret i den udenlandske adresse. Anvendes ikke hvis landekodealfa2 er DK adressepostboks addresspostboxreference Char(4) 0-1 Nummer eller anden identifikation jf. Post mark adressepostnr addresszipcode char(4) 1 Et postnummer består af fire cifre. Refererer til klassen PostDistrikt. Herfra kan postdistrikt hentes (tekstbetegnelse for distriktet) adressebynavn addresscityname 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. adresselokalitetsnavn addresssitename 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 vejog boligregister (Cirkulære nr. 130 af 25. november 2002). epostadresse addressidentifier MailToURI adresse i standard uri-form; 22 / 28

23 Type Beskrivelse journalpostfaxnummer recordpartyfaxnumber char (20) 0..1 Faxnummeret på person, virksomhed, myndighed eller organisation der er part i sagen. Faxnummer, eventuelt foranstillet + journalpostparttlf recordpartyphonenumber char (20) 0..1 Telefonnummer på person, virksomhed, myndighed eller organisation der er part i sagen. Telefonnummer, eventuelt foranstillet + journalpostpartrolle recordpartyrole char (70) [0..1] Den rolle (part, fuldmægtig advokat eller lign.) kontaktpersonen har i sagen. Fri tekst. Eventuelt hentet fra opslagstabel. kontaktnavnadressebeskyttelse Kardinalitet contactnameaddressprotection boolean 1 Markering der viser om personen har navne-/adressebeskyttelse journalpostpartuofficiel recordpartyunofficial char (1) [0..1] Udfyldes hvis oplysninger om journalpostparten er undtaget almindelig offentlighed. Hvis journalpostparten er en person, må journalpostpartsoplysningrne ikke umiddelbart offentliggøres. Der kan også findes andre årsager til at journalpostpartsoplysningerne ikke umiddelbart må offentliggøres. Værdi, hvortil der bør anvendes følgende udfaldsrum: 1 hvis journalpostparten ikke umiddelbart kan offentliggøres ellers Beskrivelse af elementet Dokument meta Denne klasse indeholder information vedrørende dokumenter, der kan knyttes til en bestemt sag. Type Kardinalitet Beskrivelse dokumentidentifier documentidentifier UUID [1] Unik nummerering af samtlige dokumenter for at sikre teknisk entydighed. Anvendes som teknisk reference for dokumenter, hvilket muliggør skabelse af referentiel integritet. dokumentkategoribetegnelse description Name [1] Dokumenttilknytningstypen i klar tekst. Beskriver informationstypen. dokumenttitel titletext Text [1] Feltet indeholder dokumentets titel, der er ingen krav om entydighed, blot at titlen afspejler dokumentets Origin Dokument UUID (Universal Unique Identifier) anvendes (jf. ISO/IEC :2005 fra International Telecommunication Union). ). Anføres på formen: urn:uuid:<uuididentifier> DokumentKategori Dokument 23 / 28

24 Type Kardinalitet Beskrivelse indhold. Feltet bidrager sammen med andre dokumentinformationer til, at sagsbehandleren/journalføreren kan vurdere dokumentets indhold og dermed relevans for den opgave vedkommende skal løse. dokumentpapirplacering dokumentpaapapir paperstorageindicator Indicator [1] Angiver om sagen arkiveres på papirform eller elektronisk. documentpaperstoragelocation Text [0..1] Fri tekst der angiver papirets fysiske placering. Feltet anvendes til at beskrive, hvor papirdokumenter i form af tykke rapporter, publikationer, der ikke indskannes i deres fulde omfang, fysisk placeres. Origin Dokument Dokument dokumentstatusbetegnelse name name [1] Dokumentstatus i klar tekst. Beskriver dokumentstatus. DokumentStatus dokumentudarbejdetaf creatorreference Char(50) [0..n] Udfyldes med information om hvem der har udarbejdet dokumentet. Hentes fra Bruger.brugerNavn dokumentundtagetoffentlighed nondisclosurediscriptiontext char(16) [0..1] Henvisning til den lovgivning under hvilken dette dokument er undtaget offentlighedsloven. Udfyldes med henvisning til den lovgivning, hvis hjemmel anvendes for at undtage dokumentet fra almindelig offentlighed. Der vil ofte være tale om persondatabeskyttelseslovgivningen eller lign. Fri tekst. dokumentversionloebenummer number integer(5) [1] Indeholder dokumentets versionnummer indenfor dokumentet. Tildeles ofte automatisk. Entydigt maskingenereret løbenummer. varianttypebetegnelse name Name [1] Varianten i klar tekst. Beskriver varianten. VariantType lagringsformatfiltype DokumentVersion storageformatdefaultfiletype LongCode [0..1] Angiver standardformat filtyper eksempelvis DOC for Word. Tekst. dokumenttilknytningsbetegnelse documentlinktypename ShortText [1] dokumenttilknytningsbetegnelse i klar tekst. Beskriver informationstypen. 24 / 28

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

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

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008.

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

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

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

FESD Brugeradministration

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

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

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

Baggrundsinformation

Baggrundsinformation 1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres

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

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 1 Indholdsfortegnelse G.1 INTRODUKTION 4 G.1.1 OVERBLIK OVER HVORDAN DIGITAL POST KAN TILGÅS 4 G.1.2 FLOW SOM EN DIGITAL

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

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

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 Valutakurser og -koder UBL 2.0 Currency Exchange Rates G18 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Valutakurser og -koder Version

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 23. august 2006. FESD-standardisering Sikker epostløsning. Grænsesnit Version 1.0 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Kort og godt om test af arkiveringsversioner

Kort og godt om test af arkiveringsversioner Kort og godt om test af arkiveringsversioner Data og dokumenter fra den offentlige forvaltnings it-systemer, som skal bevares for eftertiden, skal afleveres til arkiv i form af arkiveringsversioner. Arkiveringsversioner

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

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere

Guide til Frivillige foreninger

Guide til Frivillige foreninger Brug Frivillige foreninger på Virk.dk til at oprette et CVR nr. til din frivillige forening. Det er også her, du retter i foreningens oplysninger, fornyer og lukker dens CVR nr.. Du kan tilgå løsningen

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

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

Vejledning om avanceret afhentning. i Digital Post på Virk.dk.

Vejledning om avanceret afhentning. i Digital Post på Virk.dk. Vejledning om avanceret afhentning og sortering i Digital Post på Virk.dk. Denne vejledning beskriver, hvordan virksomheder, foreninger m.v. med et CVR-nummer kan modtage Digital Post, herunder hvordan

Læs mere

IKT-teknisk kommunikationsspecifikation

IKT-teknisk kommunikationsspecifikation Bilag til IKT Ydelsesspecifikation Dato 2012-10-01, Revisionsdato: 2013-04-15 Samarbejdsdokument for byggesagens parter Projekt: Byggesag: Projektledelse: IKT Koordinator: Dato: Revision: Revision dato:

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 11. december 2008. FESD-standardisering Sikker epostløsning. Grænsesnit. Version 1.1 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Public 360. Hvordan understøtter Public 360 den offentlige digitaliseringsstrategi?

Public 360. Hvordan understøtter Public 360 den offentlige digitaliseringsstrategi? Public 360 Hvordan understøtter Public 360 den offentlige digitaliseringsstrategi? Realiser regeringens digitaliseringsstrategi i dag Hvordan understøtter Public 360 den offentlige digitaliseringsstrategi?

Læs mere

E-BOLIGHANDEL. Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel

E-BOLIGHANDEL. Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel Send sag til den finansielle sektor samt advokater tilmeldt e-bolighandel INDHOLD Indhold Indledning 3 Inden du går i gang 4 Tilslutnings aftale hos e-nettet 4 Opsætning af dine firmaoplysninger 4 Salgsopstilling

Læs mere

FESD Emnesystematik. Standard. FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1. IT- og Telestyrelsen København 10.

FESD Emnesystematik. Standard. FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1. IT- og Telestyrelsen København 10. FESD Emnesystematik Standard IT- og Telestyrelsen København 10. december 2008 FESD-standardisering FESD Emnesystematik. Datamodel Version 1.1 Kolofon: FESD-standardisering. Emnesystematik. Datamodel. Version

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

Rapport om snitflader til publiceringsagent i Gentofte Kommune

Rapport om snitflader til publiceringsagent i Gentofte Kommune Rapport om snitflader til publiceringsagent i Gentofte Kommune Connecting Business & Technology Devoteam Fischer & Lorenz A/S 2004 Dette dokument er udarbejdet for af Devoteam Fischer & Lorenz A/S. har

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

Vejledning til sagsbehandling af anmodninger om læseadgang til tredjemand i Digital Post

Vejledning til sagsbehandling af anmodninger om læseadgang til tredjemand i Digital Post Vejledning til sagsbehandling af anmodninger om læseadgang til tredjemand i Digital Post Denne vejledning beskriver proceduren for sagsbehandling i borgerservice af anmodninger om læseadgang til tredjemand

Læs mere

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. 1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale

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

Effektiv sagsbehandling og hurtig borgerservice

Effektiv sagsbehandling og hurtig borgerservice Effektiv sagsbehandling og hurtig borgerservice 360 Kommuneløsning Med udvidet borgerselvbetjening og tværgående digitale arbejdsgange er kommunen efterhånden blevet borgernes primære kontaktpunkt til

Læs mere

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister Side: 1 af 11 VEJDIREKTORATET DANBRO+ Modul 2.3 Indholdsfortegnelse 1. INDLEDNING 3 2. FORMÅL OG ANVENDELSE 4 3. TEKNISK BESKRIVELSE INPUT AF DATA 4 3.1 Generelt 4 3.2 Adresse- og telefonlisten 4 3.3 Maillister

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

Løntilskud- og fleksjobrefusion anmodninger fra NemRefusion

Løntilskud- og fleksjobrefusion anmodninger fra NemRefusion Løntilskud- og fleksjobrefusion anmodninger fra NemRefusion Vejledning til kommuner Indhold Arbejdsgiverens indberetning i NemRefusion... 2 Anmodningen sådan sendes den til kommunen... 3 Ændring af den

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

Lokale, danske betalinger - Business Online

Lokale, danske betalinger - Business Online Lokale, danske betalinger - Business Online Side 1 af 8 Dette dokument beskriver, hvorledes du skal opbygge filer med kommaseparerede betalingsrecords. Filen skal indeholde en linie for hver betaling.

Læs mere

KMA-oplysninger. 1 Introduktion

KMA-oplysninger. 1 Introduktion KMA-oplysninger MADS MENU: KODER SYSTEMET KMA-OPLYSNINGER (E.1.1.) Revideret 07-02-2011 1 Introduktion I programmet KMA-oplysninger sættes en række grundlæggende indstillinger for MADS i afdelingen, fx

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

Læs mere

Hvor mange Fi6670i og Fi6140Z har Silkeborg Kommune i dag? (Ajourføring af parameteropsætning (Versioner & Releases))

Hvor mange Fi6670i og Fi6140Z har Silkeborg Kommune i dag? (Ajourføring af parameteropsætning (Versioner & Releases)) Nr Reference Spørgsmål Svar 1 Bilag D, Afsnit B (Separatorark) Tværgående, Tekniske Krav Er det muligt at modtage eksempler på alle varianter af separatorark der benyttes i dag? I dag anvendes separatorark

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

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

Snitfladebeskrivelse for SR78685 KMD Aktiv Bevillingsoplysninger til Jobcenterløsninger. KMD Aktiv Version 7.6, 12.11.2013

Snitfladebeskrivelse for SR78685 KMD Aktiv Bevillingsoplysninger til Jobcenterløsninger. KMD Aktiv Version 7.6, 12.11.2013 6 Snitfladebeskrivelse for SR78685 KMD Aktiv Bevillingsoplysninger til Jobcenterløsninger KMD Aktiv Version 7.6, 12.11.2013 Snitfladebeskrivelse KMD Aktiv Bevillingsoplysninger til Jobcenterløsninger Indholdsfortegnelse

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

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

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Krav Beskrivelse Prioritet Krav opfyldt -krav til integration med fagsystemer 3.1.1 3.1.2 3.1.3 3.1.4 Ejendoms- og Miljødatabasen,

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

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

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang 29.04.2015 USS/XSTJ Version 1.3 1. Indledning... 2 2. Proces for kundestyret dataadgang... 2 2.1 Fuldmagtsgivning

Læs mere

Digital Tinglysning. Ikke opdateret. Vejledning til Servitut. Udgivet 1. september 2010 version 2.1

Digital Tinglysning. Ikke opdateret. Vejledning til Servitut. Udgivet 1. september 2010 version 2.1 Digital Tinglysning Vejledning til Servitut Udgivet 1. september 2010 version 2.1 Inden du starter Inden du går i gang med at ekspedere din anmeldelse, kan du benytte følgende tjekliste, for at sikre,

Læs mere

Studenterportalen. Registrering og upload af bacheloropgaver og andre afgangsprojekter. Professionshøjskolen Metropol, marts 2011

Studenterportalen. Registrering og upload af bacheloropgaver og andre afgangsprojekter. Professionshøjskolen Metropol, marts 2011 Studenterportalen Registrering og upload af bacheloropgaver og andre afgangsprojekter Professionshøjskolen Metropol, marts 2011 Forord Dette materiale har til formål at beskrive hvordan du registrerer

Læs mere

OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008

OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008 OPDATERINGSVEJLEDNING FOR AKC5 1.20 DECEMBER 2008 Denne vejledning beskriver installation af opdatering, nyheder og ændringer som skal bruges fra og med 1. januar 2009. Det er derfor meget vigtigt at du

Læs mere

Dansk Kvalitetssikringsgruppe Arkiv. - IT-advokatens syn på PDF/PDF-A med fokus på retsgyldighed

Dansk Kvalitetssikringsgruppe Arkiv. - IT-advokatens syn på PDF/PDF-A med fokus på retsgyldighed Advokat Per Mejer ActaAdvokater Dansk Kvalitetssikringsgruppe Arkiv - IT-advokatens syn på PDF/PDF-A med fokus på retsgyldighed 30. september 2013 NovoNordisk Bagsværd IT-Advokat Per Mejer pme@mejer.net

Læs mere

360 Digital Styringsreol

360 Digital Styringsreol 360 Digital Styringsreol OPNÅ BEDRE STYRING, OPFØLGNING, OVERBLIK SAMT DOKUMENTATION AF ORGANISATIONENS PROCESSER Mange organisationer oplever et voksende pres for på samme tid at skulle levere højere

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

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

Vejledning om e-arkivet - sagsområderne Teknik, Vej og Miljø

Vejledning om e-arkivet - sagsområderne Teknik, Vej og Miljø Vejledning om e-arkivet - sagsområderne Teknik, Vej og Miljø Hvordan fungerer e-arkivet - sagsområderne Teknik, Vej og Miljø i praksis? Hvordan anvendes funktionerne?. Dette og meget mere gives der svar

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

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

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

Specifikation af serviceinterface for dokument. Denne standard er godkendt af OIO-komiteen december 2009 Specifikation af serviceinterface for dokument Denne standard er godkendt af OIO-komiteen december 2009 > Specifikation af serviceinterface for dokument. Version 1.1.1 Denne standard kan frit anvendes

Læs mere

Særlig service vejvisning

Særlig service vejvisning Særlig service vejvisning Denne dokumentation er udarbejdet af Arbejdsgruppen for standardisering af vejdata (Vejportal) under en domæne-komité for vejsektoren i regi af XML-projektet i Ministeriet for

Læs mere

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database Kursusbeskrivelse Oprettelse af en Access-database Som eksempel på en Access-database oprettes en simpelt system til administration af kurser. Access-databasen skal indeholde: et instruktørkartotek et

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

E-MAILPOLITIK FOR NORDJYLLANDS AMT

E-MAILPOLITIK FOR NORDJYLLANDS AMT E-MAILPOLITIK FOR NORDJYLLANDS AMT 1 Indledning Nordjyllands Amt har som mål at skabe en åben og digital forvaltning, hvor borgere og erhvervsliv sættes i centrum med døgnåbne selvbetjeningstjenester på

Læs mere

GeoEnviron Web-løsninger

GeoEnviron Web-løsninger 2012 Troels Kreipke 01-01-2012 Indhold Generelt... 3 Web-løsninger... 3 XML-firewall... 4 GeoEnviron_WebService... 4 Installation af web-løsninger uden brug af GeoEnviron_WebService... 5 GeoEnviron_WebService...

Læs mere

Continia e faktura Brugermanual. Version 3.08 december 2014. Continia Software A/S Hjulmagervej 55 DK-9000 Aalborg Denmark

Continia e faktura Brugermanual. Version 3.08 december 2014. Continia Software A/S Hjulmagervej 55 DK-9000 Aalborg Denmark Version 3.08 december 2014 Continia Software A/S Hjulmagervej 55 DK-9000 Aalborg Denmark Tel. +45 82 30 50 00 Support mail: CEF@Continia.dk Hjemmeside: www.continia.dk 1 Indledning... 3 2 Opsætning...

Læs mere

Blanketdokumentation LÆ 141, 142 & 145 v1.0 Februar 2011

Blanketdokumentation LÆ 141, 142 & 145 v1.0 Februar 2011 Blanketdokumentation LÆ 141, 142 & 145 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

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig. Du kan derfor

Læs mere

Vejledning i brug af Foreningsportalen til brugere med adgangskode

Vejledning i brug af Foreningsportalen til brugere med adgangskode Holstebro Kommune Kultur og Fritid Vejledning i brug af Foreningsportalen til brugere med adgangskode Foreningsportalen kan benyttes både af borgere og foreninger til søgning af foreningsoplysninger og

Læs mere

1. Huskeseddel Sagsoprettelse

1. Huskeseddel Sagsoprettelse 1. Huskeseddel Sagsoprettelse Oprette en sag Vælg: Opret Sag i menuen Filer, eller brug genvejen Ctrl + N Når du opretter en sag, danner du som det første et sagsnummer. Der skal vælges en kategori, et

Læs mere

1 INTRODUKTION TIL DKAL SNITFLADER 3

1 INTRODUKTION TIL DKAL SNITFLADER 3 DKAL Snitflader 1 Indholdsfortegnelse 1 INTRODUKTION TIL DKAL SNITFLADER 3 1.1 ANVENDELSE AF OIOXML 3 2 SNITFLADEOVERSIGT 3 2.1 REST 5 2.1.1 HTTP RETURKODER OG FEJLKODER 6 2.1.2 WEBSERVICE 6 2.2 AFSENDELSE

Læs mere

PORTFOLIO Version 2.0

PORTFOLIO Version 2.0 Nikolaj Lisberg Hansen Løsningsarkitekt og partner nikolaj.hansen@empisto.dk Tlf. 22 90 91 22 PORTFOLIO Version 2.0 Kvalitetsstyring med sags og dokumenthåndtering Teknisk revision af energimærker Portfolio

Læs mere

Implementering af bips A104 hos DTU

Implementering af bips A104 hos DTU Implementering af bips A104 hos DTU Baseret på bips A104 dokumenthåndtering, udgivet juli 2012 Anita Dalgaard BIM koordinator DTU Campus Service anida@dtu.dk bips konference 16. september 2013 Implementering

Læs mere

Navision Stat 5.4.02. NS/Digital Post tilslutning: Trin for trin. Overblik. Side 1 af 22. ØSY/CPS Dato 27.10.14

Navision Stat 5.4.02. NS/Digital Post tilslutning: Trin for trin. Overblik. Side 1 af 22. ØSY/CPS Dato 27.10.14 Side 1 af 22 Navision Stat 5.4.02 ØSY/CPS Dato 27.10.14 NS/Digital Post tilslutning: Trin for trin. Overblik Introduktion For at man som afsendende myndighed kan benytte sig af integrationen, skal der

Læs mere

Finanstilsynets indberetningssystem. FAQ Ofte stillede spørgsmål

Finanstilsynets indberetningssystem. FAQ Ofte stillede spørgsmål Finanstilsynets indberetningssystem FAQ Ofte stillede spørgsmål Finanstilsynet - 1. udgave oktober 2009 Indholdsfortegnelse 1 HVAD ER FINANSTILSYNETS INDBERETNINGSSYSTEM?... 2 2 HVORDAN FÅR JEG DANNET

Læs mere

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne Finanstilsynets indberetningssystem Vejledning til Regnearksskabelonerne Finanstilsynet - 2. udgave oktober 2009 Indholdsfortegnelse 1 INDLEDNING... 2 2 FORUDSÆTNINGER... 3 3 TRIN FOR TRIN... 4 3.1 Hent

Læs mere

IKT-teknisk kommunikationsspecifikation

IKT-teknisk kommunikationsspecifikation Bilag til BYGST IKT Ydelsesspecifikation Dato 2013-12-19 Projekt: Byggesag: SDU, NATV2 Dato: 2014.03.25 Projektledelse: Version: Mads Koch, IKT Koordinator: Revision: Thomas Rasmussen, Revision dato: Modtaget:

Læs mere

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen Titel : Fælles ABM indholds- og transportformat Dato : 2009-08-28 Status : Gældende ABM-specifikation Sekretariat: Publicering: Kulturarvsstyrelsen

Læs mere

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 26. maj 2014 Side 1-11 Indholdsfortegnelse

Læs mere

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 NemKonto-betaling Side 1 af 13 Implementeringsvejledning Indholdsfortegnelse Indholdsfortegnelse... 2 Formål... 3 Målgruppe...

Læs mere

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system.

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. I dette notat gøres rede for Hvordan visning af dagsordener og referater teknisk set kører i dag, Valg af

Læs mere

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 3456.78 123456 TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 30. juli 2015 Indhold Indledning Side 3 Sådan kommer du i gang Side 4 Oprette nye varer Side 5 Ændre eksisterende

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje SelskabMasterKom Bemærkninger: Ny protokol (opr. Art 11) Generelt : 1. + 2. byte = RecordArt 3. byte = Transaktionskode 1 = Opret 2 = Ændring 3 = Slet Email og Hjemmeside reduceret til 30 kar. Samlet længde

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

Ungebasen. Løsningsbeskrivelse. Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer

Ungebasen. Løsningsbeskrivelse. Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer PUBLICPUBLICX Ungebasen Løsningsbeskrivelse Åbne interfaces mellem Datacontaineren/Tilbagemelding.dk og kommunale vejledningssystemer 14.09.2012 A414.44.4 [Status] Side 1 af 9 Indhold 1. Formål... 3 2.

Læs mere

Titel Nr. Udgave dato. Udarb. af Godkendt af Gyldighed Erstatter nr. Udgave dato

Titel Nr. Udgave dato. Udarb. af Godkendt af Gyldighed Erstatter nr. Udgave dato Kvalitetsstyringshåndbog for Natur området Styring af registreringer, herunder sagsakter T2 03.09.07 Formål Afgrænsning At sikre følgende: * At registreringer i sager styres, dvs. journaliseres systematisk,

Læs mere

Forsendelse af breve med Doc2Mail

Forsendelse af breve med Doc2Mail Forsendelse af breve med Doc2Mail Introduktion Med Doc2Mail kan du aflevere dokumenter fra dine alm. programmer direkte til modtageres digitale postkasse eller til KMD s printerservice. Printerservice

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

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere