Bilag 3A.6 Integrationer

Bilag 3A.6 Integrationer Version 0.5 23-02-2015

Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 2.1 BILAGETS FORMÅL OG OPBYGNING... 4 2.2 RELATION TIL ØVRIGT MATERIALE... 4 3 INTEGRATIONSBESKRIVELSER... 5 3.1 ATP ERP... 7 3.2 ATP AFSTEMNING... 7 3.3 ATP DATAWAREHOUSE... 8 3.4 ATP IDM & IDP... 9 3.5 POSTHÅNDTERING... 12 3.6 BERIGET GRUNDDATA... 14 3.7 NEMKONTO... 15 3.8 FAGSYSTEMER (YDELSER)... 16 3.9 MODREGNINGSFORDELER... 19 3.10 KMD INDKOMST... 20 3.11 SKAT... 22 3.12 NETS... 25 3.13 OPKRÆVNING VIA EFAKTURERING... 27 3.14 BOGFØRINGSCENTRAL... 28 3.15 SAGS- OG DOKUMENTINDEKS... 28 3.16 YDELSESINDEKS... 30 3.17 FJERNPRINT... 31 3.18 SIKKER POST... 33 4 OPTIONER... 35 Bilag 3A.6 Integrationer Side 1 af 38 1

4.1 NEMLOG-IN... 35 4.2 DIGITAL FULDMAGT... 35 4.3 BORGER.DK... 37 Bilag 3A.6 Integrationer Side 2 af 38 2

1 Vejledning til Tilbudsgiver Bilaget skal ikke ændres af Tilbudsgiver Tabel 1 Vejledning til Tilbudsgiver Bilag 3A.6 Integrationer Side 3 af 38 3

2 Indledning 2.1 Bilagets formål og opbygning I dette bilag leveres uddybende information om de integrationer, som Leverandøren skal etablere fra. I bilaget fremgår integrationsr for alle de integrationer, der er præsenteret på systemkonteksten i bilag 3A (Behovsopgørelse). 2.2 Relation til øvrigt materiale Bilaget er en del af Behovsopgørelsen og skal ses i sammenhæng med bilag 3, 3A og øvrige underbilag til 3A. Bilag 3A.6 Integrationer Side 4 af 38 4

3 Integrationsr Dette afsnit indeholder integrationsr for alle de integrationer, som skal etableres fra, jf. Systemkonteksten i figur 1. I det følgende vil hver integration blive beskrevet ud fra en fast struktur indeholdende nedenstående informationer: Integrationsnavn/ID Formål med integrationen Hvilke data flyder over integrationen Forventet volumen (frekvens, datamængder) angivet ud fra forretningsmæssige behov Reference til løsningsflows som indeholder integrationen Reference til produkt-/snitflade Integrationerne vil blive beskrevet på et logisk niveau, og der vil således ikke nødvendigvis være en 1-1 relation mellem integrationsrne i det følgende og de faktiske metoder/services, som skal anvendes. I flere tilfælde vil en integration således dække over kald af flere forskellige services, f.eks. vil en integration til SKAT EFI kunne dække over både fordringer, som sendes til inddrivelse og modregning. Det vil være op til leverandøren at oversætte de forretningsmæssige krav til integrationerne til en konkret anvendelse af konkrete tekniske snitflader, ud fra hvad der er mest hensigtsmæssigt i. De mulige tekniske snitflader på de tilstødende systemer vil være beskrevet i separate underbilag eller via referencer til eksterne r. Systemkonteksten er illustreret på Figur 1. Bilag 3A.6 Integrationer Side 5 af 38 5

Figur 1: Systemkonteksten for. Diagrammet viser alle de systemer, som skal integrere til. Figuren viser ikke infrastruktur-komponenter men udelukkende applikationer på logisk niveau. Bilag 3A.6 Integrationer Side 6 af 38 6

3.1 ATP ERP DERP1 Posteringer til ERP Formål med integrationen Kommunikationsmønster Data fra til Data fra til Snitflade DERP1 ATP ERP ATP ERP er et Business support system, hvori ATP håndterer områderne økonomi og HR. På økonomiområdet håndteres internt og eksternt regnskab, og hertil modtages løbende posteringsinformationer fra alle fagsystemer, inkl. Debitorsystemet. ATP ERP er baseret på SAP FI/CO. ATP ERP driftes og vedligeholdes af ATP IT. Vedligehold af regnskab i ATP ERP. overfører bogføringsposter til ATP ERP. Posteringsinformationer også på enkeltposteringsniveau. Kontoplan, dog ikke via en direkte integration til overførsel af kontoplaner. Kontoplanen skal kunne konfigureres af Udbetaling Danmark direkte i Debitorsystemet. skal dagligt sende bogføringsdata til ATP ERP system. LF Debitor Håndter udbetaling 3.5.1.1 Produkt: Underbilag 3A.6a - Produkt og snitflader/atp ERP - Produkt.pdf. Beskrivelse af snitflade til overførsel af posteringer: Underbilag 3A.6a - Produkt og snitflader/atp ERP - Snitflade - Krav til leverance-systemernes bogfoerings-records.pdf Debitorsystemet skal integrere til eksisterende snitflade. Der findes et integrationstestmiljø (eksternt testmiljø) for ATP ERP. 3.2 ATP afstemning DAAF1 Afstemningsdata til ATP DAAF1 ATP s afstemningsenhed Bilag 3A.6 Integrationer Side 7 af 38 7

DAAF1 Afstemningsdata til ATP ATP s enhed, der er ansvarlig for at sikre at regnskabsdata er korrekte og afstemt mellem systemerne. Enheden foretager afstemning af bogføringsdata for alle Udbetaling Danmarks systemer via egne værktøjer og systemer. ATP Formål med integrationen Levering af data til brug for den regnskabsmæssige kontrol og afstemning. Kommunikationsmønster udtrækker data og afleverer dem på et ATP file share via ATP's integrationsplatform EKKO (se Underbilag 3A.6a - Produkt- og snitflader/atp Integrationsplatform Produkt v1.0.pdf). Data fra til Udtræk af posteringsdata på alle relevante tilstande/steps i pengestrømmen. Data fra til Ingen Afstemningsdata udtrækkes og afleveres med faste tidsintervaller. Endvidere kan en ATP-medarbejder med særlige rettigheder igangsætte et udtræk af specifikke afstemningsdata. Alle enkeltposteringer i en given periode på forskellige tidspunkter/tilstande i pengestrømmen skal kunne udtrækkes. Posteringerne knytter sig til de enkelte krav, opkrævninger, ind- og udbetalinger m.v. Snitflade Debitorsystemet skal integrere til eksisterende snitflade. ATP s integrationsplatform findes i både et integrationstestmiljø (eksternt testmiljø) og et pilot- (præproduktions-) miljø. 3.3 ATP Datawarehouse DDWH1 Data til datawarehouse DDWH1 ATP s datawarehouse Bilag 3A.6 Integrationer Side 8 af 38 8

DDWH1 Data til datawarehouse ATP s datawarehouse indsamler relevante data fra øvrige systemer og stiller disse til rådighed for ledelsesrapportering, statistik og ad hoc analyser. For Udbetaling Danmark benyttes systemet til ledelsesrapportering. Endvidere holdes heri datagrundlaget for Udbetaling Danmarks arbejde med Helhedsorienteret Kontrol. ATP Formål med integrationen At stille data fra til rådighed for de dataanalyser og rapporteringer, der sker i ATP s datawarehouse. Kommunikationsmønster skubber data til ATP. Data fra til Alle data i. Ved hver dataaflevering skal der dog kun leveres de data, der er nye eller ændrede siden sidste dataaflevering. Data fra til Ingen Skal kunne varieres så data bliver leveret i realtid, ugentlig eller på daglig basis. Ved start gennemføres et fuldt dataload af den totale mængde, derefter gennemføres delta. Snitflade udtrækker data og afleverer dem på et ATP file share via ATP's integrationsplatform EKKO (se Underbilag 3A.6a - Produkt- og snitflader/atp Integrationsplatform Produkt v1.0.pdf). Snitflade: Datawarehouse har en snitflade mod Eksisterende Løsning. Denne integration skal erstatte den nuværende snitflade. N/A 3.4 ATP IdM & IdP DIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM Bilag 3A.6 Integrationer Side 9 af 38 9

DIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM DIDM1 ATP IdM og IdP (Identity Management og Identity Provider) En række systemer i ATP s sikkerhedsdomæne, som benyttes til administration af interne brugere og deres roller og rettigheder, samt autentifikation af de interne brugere. Fra systemerne gøres bruger- og rettighedsoplysninger tilgængelige for de øvrige it-systemer. Udbetaling Danmarks brugere, herunder kunderådgivere, administreres som en del af ATP s øvrige interne brugere, og de tildeles roller med rettigheder til fagsystemet via Identity Management-systemet. De interne brugere vil endvidere blive autentificeret via disse systemer. Som IdM-løsning anvendes produktet IBM Security Identity Manager (TIM). Derudover anvendes Windows AD, IBM TFIM og TAM. ATP Formål med integrationen får kendskab til de brugere og rolletildelinger, som vedligeholdes i ATP s IdM. Kommunikationsmønster ATP s IdM og IdP system understøtter forskellige metoder til udveksling af bruger- og rolle-/rettighedsoplysninger: a) ATP s IdM skubber oplysninger om alle brugere og deres rolletildelinger til s brugerdatabase. b) ATP s IdM og IdP leverer oplysninger om en brugers rolletildelinger i forbindelse med brugerens login. Der er forskellige teknologier i spil afhængigt af valgt metode se snitfladen. Data fra til s roller gøres tilgængelige for rolletildelingen i ATP s IdM i forbindelse med oprettelse og vedligehold af rollerne. Data fra til Brugere og deres tildeling af systemmæssige roller. Afhængigt af valgt kommunikationsmønster: a) Brugere og deres rolletildeling skubbes ud hver gang disse oprettes eller ændres i ATP s IdM. b) Rolletildeling leveres ved hvert login. Der forventes et relativt begrænset antal brugere, som skal have adgang til. Bilag 3A.6 Integrationer Side 10 af 38 1

DIDM1 Bruger- og rettighedsoplysninger fra ATP s IdM Snitflade Se n af ATP s sikkerhedsdomæne og de forskellige tilladte integrationsmuligheder i Underbilag 3A.6a - Produkt- og snitflader/atp Sikkerhed Produkt v1.0.pdf. ATP s IdM er et eksisterende produkt som tilbyder en række forskellige integrationsmekanismer, som også er implementeret mod en række andre systemer. Se Underbilag 3A.6a - Produkt- og snitflader/atp Sikkerhed Produkt v1.0.pdf. DIDP1 Login via ATP s IdP DIDP1 ATP IdM og IdP Se DIDM1. ATP Formål med integrationen ATP s interne brugere har single-sign on med deres ATP windows login. Kommunikationsmønster Afhænger af valgt teknologi. Der kan være tale om både client side og server side integration. Data fra til Ingen Data fra til Brugerens identitet. Hver gang en ATP-bruger har brug for at logge på systemet. Der forventes et relativt begrænset antal brugere, som skal have adgang til. Snitflade Se n af ATP s sikkerhedsdomæne og de forskellige integrationsmuligheder i Underbilag 3A.6a - Produkt- og snitflader/atp Sikkerhed Produkt v1.0.pdf. ATP s IdM og IdP har mekanismer for Single sign-on etableret mod flere andre systemer. Bilag 3A.6 Integrationer Side 11 af 38 1

DIDP1 Login via ATP s IdP Se Underbilag 3A.6a - Produkt- og snitflader/atp Sikkerhed Produkt v1.0.pdf. 3.5 Posthåndtering DPHL1 Modtag indgående post DPHL1 Posthåndteringsleverandør Posthånderingsleverandøren håndterer modtagelse, scanning, fordeling og præjournalisering af Udbetaling Danmarks indgående post. Posthåndteringsleverandøren modtager fysisk post, og indhenter digital post fra henholdsvis Sikkerpost og Digital Post. Data Scanning Formål med integrationen At kunne modtage al indgående post og automatisk placere de indgående dokumenter på en eksisterende sag eller en ny sag. Dokumenterne placeres ud fra de medfølgende metadata. Kommunikationsmønster Posthåndteringsleverandøren overfører posten med metadata til, som kvitterer for modtagelsen. Det skal fastlægges om post overføres enkeltvis eller i batch. Data fra til Kvittering Data fra til Indgående post med tilhørende metadata. Udvekslingsformatet på metadata baseret på OIO Sag og OIO Dokument. Debitorsystemet skal i realtid eller på realtidslignende basis modtage post. LF Debitor Håndter Automatisk generede hændelser 2.5.1.1 LF Debitor håndter Opkrævning 2.5.2.1 LF Debitor håndter Afdragsordning 2.5.2.2 LF Debitor Håndter udbetaling 3.5.1.1 Bilag 3A.6 Integrationer Side 12 af 38 1

DPHL1 Modtag indgående post Snitflade Snitflade tilgår ved PHL Milepæl 1 (tidsplan fastlægges i Afklaringsetapen). Snitfladespecifikation tilgår ved PHL Milepæl 2 (tidsplan fastlægges i Afklaringsetapen). Snitfladen er ikke etableret på (tidsplan fastlægges i Afklaringsetapen) PHL udstiller ikke testmiljøer. DPHL2 Send post til genjournalisering DPHL2 Posthåndteringsleverandøren Se DPHL1 Se DPHL1 Formål med At kunne returnere post til posthåndteringsleverandøren, integrationen enten fordi posten er journaliseret i et forkert system, eller fordi en kopi også skal journaliseres i et andet system. Kommunikationsmønster Fagsystemet overfører post med metadata til Posthåndteringsleverandøren, som kvitterer for modtagelsen. Data fra til Post med metadata, herunder om det er en kopi eller originalen som skal journaliseres i et andet fagsystem. Hvis posten skal journaliseres som en Kopi, så skal modtageren angives, ellers angives en fritekst til brug for journalmedarbejderen. Formatet fastlægges i Afklaringsetapen. Data fra Kvittering til Efter behov. Snitflade Se DPHL1 Se DPHL1 Se DPHL1 Bilag 3A.6 Integrationer Side 13 af 38 1

3.6 Beriget Grunddata DBGD1 Grunddata Formål med integrationen Kommunikationsmønster DBGD1 Beriget Grunddata Støttesystem, som indeholder og leverer oplysninger om personer, virksomheder og myndigheder, samt relationer imellem disse. Oplysningerne inkluderer bl.a. personoplysninger fra CPR og CVR. Beriget Grunddata tildeler alle personer og virksomheder et unikt ID, således at systemet også kan håndtere personer og virksomheder uden CPR eller CVR.nr (f.eks. udenlandske borgere). etableres af ATP. Levering af person- virksomheds- og myndighedsdata. Beriget Grunddata understøtter to forskellige kommunikationsmønstre: a) Replikering via abonnement: opsætter abonnement på de parter (personer, virksomheder og myndigheder), som det ønsker data for. Data replikeres derefter dagligt til systemet, enten ved oprettelse eller ved ændringer i data. b) Opslag: henter data fra Beriget Grunddata, når der er brug for det, f.eks. ved oprettelsen af et nyt abonnement. Data fra til Data fra til Abonnement i Beriget Grunddata oprettes for alle parter (personer, virksomheder og myndigheder), der ikke kendes af Debitorsystemet, når et krav modtages eller oprettes. Identifikation af den part, som der ønskes data for, samt oprettelse af abonnement ved a) Data for parten (person, virksomhed og myndighed), med angivelse af evt. ændring. Daglig replikering + ad hoc forespørgsler. forventes årligt at håndtere en bestand af debitorer på 600.000. LF - Debitor Opret krav 1.5.1.1 LF Debitor Håndter Automatisk generede hændelser 2.5.1.1 Bilag 3A.6 Integrationer Side 14 af 38 1

DBGD1 Grunddata Snitflade Informationsmodellen for Beriget Grunddata beskriver informationerne i Beriget Grunddata se bilag 3A.4 (Begrebs- og informationsmodeller). En foreløbig af snitfladen til replikering af data kan ses i: Underbilag 3A.6a (Produkt og snitflader)/beriget Grunddata Snitflade XML-struktur for replikeringen.pdf Endelig snitflade og -specifikation tilgår senere, jævnfør bilag 1 (Tidsplan). Beriget Grunddata er under etablering. Beriget Grunddata kommer til at udstille et testmiljø. 3.7 NemKonto DNEM1 Udbetaling Formål med integrationen Kommunikationsmønster Data fra til Data fra til DNEM1 NemKonto Et udbetalingssystem, som modtager udbetalingsanmodninger fra flere andre systemer og sikrer, at disse effektueres. Digitaliseringsstyrelsen er ansvarlig for systemet, og det driftes pt. af KMD. Debitorsystemet anvender NemKonto til alle udbetalinger. overfører udbetalinger til NemKonto. NemKonto kvitterer for modtagelsen heraf. NemKonto sender løbende retursvar om fejlede udbetalinger. Identifikation af beløbsmodtageren (CPR nr./ CVR nr. / SE nr.), beløb og dispositionsdato, samt specifikation af det udbetalte beløb. Kvittering og evt. fejlmeddelelse. Dagligt. Der forventes at være et relativt begrænset antal udbetalinger. LF Debitor Håndter udbetaling 3.5.1.1 Bilag 3A.6 Integrationer Side 15 af 38 1

DNEM1 Udbetaling Snitflade Produkt: Se http://www.nemkonto.dk/myndighed/ Beskrivelse af snitflade til overførsel af udbetalingsanmodninger: http://www.nemkonto.dk/myndighed/teknisk-info Debitorsystemet skal integrere til NemKontos eksisterende snitflade. NemKonto stiller et testmiljø til rådighed hvori der skal gennemføres en tilslutningsprøve. 3.8 Fagsystemer (ydelser) For Debitorsystemets integration til Udbetaling Danmark Fagsystemer, hvorfra der modtages krav, gælder, at en generel snitflade skal anvendes. Denne snitflade skal gøre det muligt at kunne tilføje eller fjerne Udbetaling Danmark Fagsystemer, uden at dette har en effekt på øvrige tilkoblede Udbetaling Danmark Fagsystemer. Integrationerne DFSY1-4 nedenfor indeholder derfor en generel henvisning til Fagsystemer og dette skal udtrykke, at der integreres til et eller flere systemer. DFSY1 Krav Formål med integrationen Kommunikationsmønster Data fra til Data fra til DFSY1 Fagsystem Udbetaling Danmark Fagsystem, som forvalter sager vedrørende Udbetaling Danmark ydelser. Udbetaling Danmark. Oprettelse af krav i Debitorsystemet. Et krav vil typisk føre til en opkrævning i Debitorsystemet. Krav sendes kontinuerligt og dagligt via snitfladen til Debitorsystemet. Kvittering og evt. fejlmeddelelse Fagsystemet sender et krav til Debitorsystemet. Kravene sendes fra Udbetaling Danmark Fagsystemer på kontinuerlig og på daglig basis. Der vil typisk være et månedligt peak mønster, således at krav sendes forud for en månedlig opkrævning. En større mængde krav kan også forekomme i et årligt mønster, f.eks. i forbindelse med årsreguleringer. Bilag 3A.6 Integrationer Side 16 af 38 1

DFSY1 Krav Snitflade LF - Debitor Opret Krav 1.5.1.1 Se DFSY1 Ny snitflade Se DFSY1 DFSY2 Kravstatus Formål med integrationen Kommunikationsmønster Data fra til Data fra til DFYS2 Fagsystem Udbetaling Danmark Fagsystem, som forvalter sager vedrørende Udbetaling Danmark ydelser. Udbetaling Danmark. Status på et tidligere modtaget krav. Når et krav afsluttes (f.eks. ved indbetaling, modregning eller afskrivning) i Debitorsystemet sendes status på kravet retur til det afgivende Udbetaling Danmark Fagsystem. Kravstatus sendes dagligt via snitfladen til Udbetaling Danmark Fagsystem. Debitorsystemet sender kravstatus til det afgivende Udbetaling Danmark Fagsystem. Ingen. Kravstatus sendes til Udbetaling Danmark Fagsystemer på daglig basis. LF Debitor Håndter indbetaling 2.5.2.3 LF Debitor Håndter Afskrivning 2.5.2.6 Snitflade Se DFSY2 Ny snitflade Se DFSY2 DFSY3 Modregningsanmodning DFSY3 Fagsystem Bilag 3A.6 Integrationer Side 17 af 38 1

DFSY3 Modregningsanmodning Udbetaling Danmark Fagsystem, som forvalter sager vedrørende Udbetaling Danmark ydelser. Udbetaling Danmark. Formål med integrationen Anmodning om modregning i en Udbetaling Danmark ydelse. Krav fra nogle Udbetaling Danmark ydelser kan modregnes i andre Udbetaling Danmark ydelser. Ifald Debitorsystemet vælger at lade et krav modregne i en anden Udbetaling Danmark ydelse, anmodes der herom via denne integration. Kommunikationsmønster Modregningsanmodning sendes dagligt via snitfladen til Udbetaling Danmark Fagsystem. Data fra til Debitorsystemet sender en modregningsanmodning til Udbetaling Danmark Fagsystem. Data fra til Kvittering. Kravene sendes til Udbetaling Danmark Fagsystemer på daglig basis. LF Debitor Håndter Afdragsordning 2.5.2.2 Snitflade Se DFSY3 Se DFSY3 Se DFSY3 DFSY4 Modregningsstatus DFSY4 Fagsystem Udbetaling Danmark Fagsystem, som forvalter sager vedrørende Udbetaling Danmark ydelser. Udbetaling Danmark. Formål med integrationen Status på en tidligere modtaget anmodning om modregning. Når en modregningsanmodning afsluttes (fuld, delvis eller ingen modregning) i Udbetaling Danmark Fagsystemet, sendes status på modregningsanmodningen retur til Debitorsystemet. Kommunikationsmønster Modregningsstatus sendes dagligt via snitfladen til Debitorsystemet. Bilag 3A.6 Integrationer Side 18 af 38 1

DFSY4 Modregningsstatus Data fra til Kvittering Data fra til Udbetaling Danmark Fagsystem sender Modregningsstatus på en modregningsanmodning til Debitorsystemet. Modregningsstatus sendes fra Udbetaling Danmark Fagsystemer til Debitorsystemet på daglig basis. Der vil typisk være et månedligt peak mønster, i de tilfælde, hvor modregning sker i en ydelse, der udbetales på månedlig basis. LF Debitor Håndter Afdragsordning 2.5.2.2 LF Debitor Håndter indbetaling 2.5.2.3 Snitflade Se DFSY4 Se DFSY4 Se DFSY4 3.9 Modregningsfordeler DMOD1 Modregningsanmodning DMOD1 Serviceplatform - Modregningsfordeler Serviceplatformen er et fælleskommunalt system til håndtering af dataudveksling på tværs af kommuner og myndigheder (herunder Udbetaling Danmark). Formål med integrationen Kommunikationsmønster KOMBIT Overførsel af modregningsanmodninger til kommunerne til modregning i Kontanthjælp. Dagligt. Data fra til Data fra til Debitorsystemet sender en modregningsanmodning til Modregningsfordeleren. Kvittering Dagligt Bilag 3A.6 Integrationer Side 19 af 38 1

DMOD1 Modregningsanmodning LF Debitor Håndter Afdragsordning 2.5.2.2 LF Debitor Håndter indbetaling 2.5.2.3 Snitflade Ny snitflade skal aftales med KOMBIT. Ny snitflade skal etableres skal aftales med KOMBIT. Test af dataafleveringen skal aftales med KOMBIT. DMOD2 Modregningsstatus DMOD2 Se DMOD1 Se DMOD1 Se DMOD1 Formål med integrationen Status på en tidligere modtaget anmodning om modregning. Når en modregningsanmodning afsluttes (fuld, delvis eller ingen modregning) i et kommunalt fagssytem, sendes status på modregningsanmodningen retur til Debitorsystemet via modregningsfordeleren. Kommunikationsmønster Dagligt. Data fra til Data fra til Snitflade Kvittering Modregningsfordeleren sender Modregningsstatus på en modregningsanmodning til Debitorsystemet. Dagligt LF Debitor Håndter Indbetaling 2.5.2.3. Ny snitflade Ny snitflade skal etableres Test af dataafleveringen skal aftales med leverandør. 3.10 KMD Indkomst DKIN1 Forskudsopgørelse Bilag 3A.6 Integrationer Side 20 af 38 2

DKIN1 Forskudsopgørelse Formål med integrationen Kommunikationsmønster DKIN1 Se DKIN1 Forespørgsel om forskudsopgørelse. Ad hoc, i forbindelse med betalingsevnevurdering. Data fra til Data fra til Snitflade Udsøgningskriterier. Forskudsopgørelse Ad hoc. Eksisterende standard snitflade for indhentning af indkomstoplysninger. Eksisterende snitflade. Test af dataafleveringen skal aftales med KMD. DKIN2 Årsopgørelse Formål med integrationen Kommunikationsmønster DKIN2 Se DKIN1 Se DKIN1 Se DKIN1 Forespørgsel om årsopgørelse. Ad hoc, i forbindelse med betalingsevnevurdering. Data fra til Data fra til Udsøgningskriterier. Årsopgørelsesoplysninger Ad hoc. Bilag 3A.6 Integrationer Side 21 af 38 2

DKIN2 Årsopgørelse Snitflade Eksisterende standard snitflade for indhentning af oplysninger vedr. årsopgørelse. Eksisterende snitflade. Test af dataafleveringen skal aftales med KMD. DKIN3 Formueoplysninger Formål med integrationen Kommunikationsmønster DKIN3 Se DKIN1 Se DKIN1 Se DKIN1 Forespørgsel om formue. Ad hoc, i forbindelse med dødsfald. Data fra til Data fra til Snitflade Udsøgningskriterier. Formueoplysninger Ad hoc. Eksisterende standard snitflade for indhentning af oplysninger vedr. årsopgørelse. Eksisterende snitflade. Test af dataafleveringen skal aftales med SKAT. 3.11 SKAT DSKA1 Renteoplysninger DSKA1 Bilag 3A.6 Integrationer Side 22 af 38 2

DSKA1 Renteoplysninger Formål med integrationen Kommunikationsmønster SKAT COR SKAT COR udstiller grænseflade til indberetning af renteudgifter. SKAT Overførsel af renteoplysninger til SKAT. Årligt, i forbindelse med årsopgørelse. Data fra til Data fra til Snitflade Renteoplysninger. Kvittering Årligt i forbindelse med årsopgørelse. Anslået ca. 5-10.000 personer. Eksisterende standard snitflade for indberetning af renteindtægter til SKAT anvendes. Eksisterende snitflade. Test af dataafleveringen skal aftales med SKAT. DEFI1 Fordringsindberetning DEFI1 EFI SKAT s EFI (Et Fælles Inddrivelsessystem) varetager Fordringer (krav), som skal modregnes, opkræves eller inddrives. SKAT Formål med integrationen Overførsel af fordringer (krav) til modregning i overskydende skat eller inddrivelse. Integrationen varetager nye fordringer, ændringer eller afmelding. Kommunikationsmønster Dagligt. Data fra til Krav som skal modregnes eller inddrives via EFI. Bilag 3A.6 Integrationer Side 23 af 38 2

DEFI1 Fordringsindberetning Data fra til Kvittering samt en status på den umiddelbare behandling af fordringen. Dagligt Debitor har ca. 5.500.000 fordringer i EFI LF - Debitor Opret Krav 1.5.1.1 LF Debitor Håndter Afdragsordning 2.5.2.2 LF Debitor Håndter indbetaling 2.5.2.3 LF Debitor håndter Rykker 2.5.2.4 LF - Debitor Håndter Restance 2.5.2.5 LF Debitor Håndter Afskrivning 2.5.2.6 Snitflade Eksisterende standard snitflade MFFordringIndberet og MFKvitteringHent forventes anvendt. Eksisterende snitflader. Kontakt SKAT. DEFI2 Fordringsstatus Formål med integrationen Kommunikationsmønster DEFI2 EFI SKAT s EFI (Et Fælles Inddrivelsessystem) varetager Fordringer (krav), som skal modregnes, opkræves eller inddrives. SKAT Forespørgsel på status af EFI fordringer. Dagligt. Data fra til Data fra til Debitorsystemet forespørger på alle udestående EFI fordringer på daglig basis. Forespørgsel med EFI fordringsstatus. "Underretning", indeholdende statusinformation om EFI sag fordring. Dagligt Bilag 3A.6 Integrationer Side 24 af 38 2

DEFI2 Fordringsstatus Snitflade LF Debitor Håndter Afdragsordning 2.5.2.2 LF Debitor Håndter indbetaling 2.5.2.3 LF - Debitor Håndter Restance 2.5.2.5 LF Debitor Håndter Afskrivning 2.5.2.6 Eksisterende standard snitflade MFUnderretSamlingHent forventes anvendt. Eksisterende snitflade. Kontakt SKAT. 3.12 NETS DNET1 Opkrævning Formål med integrationen Kommunikationsmønster DNET1 NETS Opkrævning af krav sker via service fra NETS. NETS Overførsel af opkrævninger til personer, virksomheder og myndigheder. Månedligt med hensyntagen til Nets kalender med opkrævningsfrister. Data fra til Data fra til Snitflade Opkrævningsdata, bl.a. beløb, ydelse, betalingsfrist m.v. Kvittering Månedligt i forbindelse med, at alle krav er modtaget i Debitorsystemer fra Fagsystemer. NETS fastlægger desuden selv en månedlig frist for modtagelse af opkrævninger, som Debitorsystemet skal tage hensyn til NETS fastlægger de månedlige afleveringsfrister på årlig basis. LF Debitor håndter Opkrævning 2.5.2.1 Eksisterende standard snitflade til NETS anvendes. Bilag 3A.6 Integrationer Side 25 af 38 2

DNET1 Opkrævning Eksisterende snitflade. Kontakt NETS. DNET2 Indbetaling Formål med integrationen Kommunikationsmønster DNET2 NETS Opkrævning af krav sker via service fra NETS. NETS Tilbagemelding fra NETS til Debitorsystemet med indbetalinger og fejlmeddelelser vedr. opkrævninger til personer, virksomheder og myndigheder, som tidligere er sendt fra Debitorsystemet til NETS. Dagligt via batch. Data fra til Data fra til Snitflade Kvittering Information om indbetalinger eller fejl i forbindelse med effektuering af tidligere modtagne opkrævninger. Dagligt. Se DNET1 (samme volumen) Eksisterende standard snitflade til NETS anvendes. Eksisterende snitflade. Kontakt NETS. DNET3 BS-aftale DNET3 NETS Opkrævning af krav sker via service fra NETS. I forbindelse med dette kan Betalings Service (BS) aftaler til- eller frameldes. NETS Bilag 3A.6 Integrationer Side 26 af 38 2

DNET3 BS-aftale Formål med integrationen Kommunikationsmønster Overførsel af BS-aftaler mellem Debitorsystemet og NETS. Dagligt i batch. Data fra til Data fra til Snitflade BS-aftale informationer, samt indikation af til- eller afmelding. Kvittering Dagligt. LF Debitor Håndter Automatisk generede hændelser 2.5.1.1 Eksisterende standard snitflade til NETS anvendes. Eksisterende snitflade. Kontakt NETS. 3.13 Opkrævning via efakturering DEAN1 Opkrævning via efakturering DEAN1 Virksomheder med EAN.. Virksomheder, hvor der er aftalt opkrævning via efakturering Ukendt Formål med integrationen Overførsel af opkrævninger til virksomheder, hvor der er aftalt opkrævning via efakturering. Kommunikationsmønster Månedligt Data fra til Opkrævningsdata, bl.a. beløb, ydelse, betalingsfrist m.v. Data fra til Kvittering Månedligt. Ukendt volumen LF Debitor Håndter Håndter opkrævning 2.5.1.1 Snitflade Eksisterende standard snitflade antages anvendt. Bilag 3A.6 Integrationer Side 27 af 38 2

DEAN1 Opkrævning via efakturering Eksisterende snitflade. Ukendt. 3.14 Bogføringscentral DBFC1 Indbetaling Formål med integrationen Kommunikationsmønster DBFC1 Bogføringscentral Bogføringscentraler sørger for indbetalinger via banker. Informationer vedrørende indbetalinger i banker. Bemærk, at indbetalinger via banker kan mangle fyldestgørende reference til tidligere udsendt opkrævning, således at det ikke er muligt at afstemme indbetalingen med en tidligere udsendt opkrævning. Dagligt. Data fra til Data fra til Snitflade Teknisk kvittering Information om indbetalinger via banker. Dagligt LF Debitor Håndter udbetaling 3.5.1.1 LF Debitor Håndter indbetaling 2.5.2.3 Eksisterende standard snitflade anvendes Eksisterende snitflade. 3.15 Sags- og dokumentindeks DSDI1 Udstil oplysninger i Sags- og dokumentindeks DSDI1 Sags- og dokumentindeks Bilag 3A.6 Integrationer Side 28 af 38 2

DSDI1 Udstil oplysninger i Sags- og dokumentindeks Formål med integrationen Kommunikationsmønster Data fra til Data fra til Sags- og dokumentindeks er en del af den fælles kommunale rammearkitekturs støttesystemer(rasts). Sags- og dokumentindeks indeholder metadata om Sager og dokumenter. Indekset medvirker til at skabe et tværgående overblik indenfor en myndighed. Indekset understøtter også et overblik på tværs af myndigheder. KOMBIT Udstille metadata om sager i et fælles register, så der kan dannes et overblik på tværs af systemer. Sags- og dokumentindekset benyttes til at udstille data til følgende systemer: KMD Sag, for at kunne vedligeholde et sags- og dokumentoverblik i KMD Sag. Kommunale overbliksystemer som skal kunne vise et sags overblik med Udbetaling Danmarkssager. Udbetaling Danmarks øvrige fagsystemer, som skal kunne danne et tværgående overblik. sender metadata om sager og dokumenter til Sags- og dokumentindekset, som kvitterer med henholdsvis en transport- og forretningskvittering. Efterfølgende skal opdateringen publiceres som en hændelse på beskedfordeleren. Metadata om Sager, journalnotater og dokumenter Formatet er baseret på henholdsvis OIO Sag og OIO Dokument. Se underbilag 3A.6a (Produkt- og snitflader) \ RASTS integrationsvilkår \ Underbilag 6.A. Begrebs- og informationsmodel for Sags- og dokumentindeks Kvittering Ved sagsoprettelse, sagssletning og ændringer til metadata, som er udstillet i indekset, skal indekset opdateres. Bilag 3A.6 Integrationer Side 29 af 38 2

DSDI1 Udstil oplysninger i Sags- og dokumentindeks Snitflade Snitflade tilgår ved RASTS Milepæl 1, se bilag 1 (Tidsplan). Snitfladespecifikation tilgår ved RASTS Milepæl 2, se bilag 1 (Tidsplan). Vilkår for integration til systemet: Underbilag 3A.6a (Produktog snitflader) \ RASTS integrationsvilkår\bilag 7. Vilkår for integration til støttesystemet Sags- og Dokumentindeks Og Vilkår for integration til systemet: Underbilag 3A.6a (Produktog snitflader) \ RASTS integrationsvilkår \ Bilag 3. Vilkår for integration til støttesystemet Beskedfordeler Snitfladen er en del af KOMBIT s udbud af Rammearkitekturens støttesystemer (tidsplan fastlægges i Afklaringsetapen). KOMBIT udstiller teststubbe, og leverer kodeeksempler tilgængeligt efter RASTS Milepæl 3, se bilag 1 (Tidsplan). KOMBIT udstiller et testmiljø for sags- og dokumentindeks, testmiljøet vil være tilgængeligt efter RASTS Milepæl 4, se bilag 1 (Tidsplan). 3.16 Ydelsesindeks DYDI1 Hent oplysninger fra Ydelsesindeks DYDI1 Ydelsesindeks Ydelsesindeks er en del af den fælles kommunale rammearkitekturs støttesystemer. Ydelsesindeks indeholder metadata om Bevillinger, Ydelser og Udbetalinger. Indekset medvirker til at skabe et tværgående overblik indenfor en myndighed. Indekset understøtter også et overblik på tværs af myndigheder. KOMBIT Formål med integrationen Hente metadata om Udbetaling Danmark Ydelser. Kommunikationsmønster overfører søgekriterier til Ydelsesindekset, som returner metadata om Ydelser og Udbetalinger, der opfylder søgekriterierne. Data fra til Søgekriterier Bilag 3A.6 Integrationer Side 30 af 38 3

DYDI1 Hent oplysninger fra Ydelsesindeks Data fra til Metadata om Ydelser og Udbetalinger. Se underbilag 3A.6a (Produkt- og snitflader) \ RASTS integrationsvilkår \Underbilag 6.A. Begrebs- og informationsmodel for Ydelsesindeks Ved udførelse af betalingsevnekontrol. LF - Debitor Håndter Restance 2.5.2.5 Snitflade Snitflade tilgår ved RASTS Milepæl 1, se bilag 1 (Tidsplan). Snitfladespecifikation tilgår ved RASTS Milepæl 2, se bilag 1 (Tidsplan). Vilkår for integration til systemet: Underbilag 3A.6a (Produktog snitflader) \ RASTS integrationsvilkår\bilag 7. Vilkår for integration til støttesystemet Sags- og Dokumentindeks Og Vilkår for integration til systemet: Underbilag 3A.6a (Produktog snitflader) \ RASTS integrationsvilkår \ Bilag 3. Vilkår for integration til støttesystemet Beskedfordeler Snitflade er en del af KOMBIT s udbud af Rammearkitekturens støttesystemer (tidsplan fastlægges i Afklaringsetapen). KOMBIT udstiller teststubbe, og leverer kodeeksempler tilgængeligt efter RASTS Milepæl 3, se bilag 1 (Tidsplan). KOMBIT udstiller et testmiljø for sags- og dokumentindeks, testmiljøet vil være tilgængeligt efter RASTS Milepæl 4, se bilag 1 (Tidsplan). 3.17 Fjernprint DFPR1 Send besked DFPR1 Fjernprint Bilag 3A.6 Integrationer Side 31 af 38 3

DFPR1 Send besked Formål med integrationen Kommunikationsmønster Data fra til Den fællesoffentlige Fjernprintløsning, som er etableret af Digitaliseringsstyrelsen. Fjernprintløsningen er en output-management løsning, der automatisk sørger for forsendelse til digital post (hvis muligt) og ellers til fysisk post. For fysisk post håndteres også print, kuvertering og forsendelse. Fjernprint leveres pt. af Strålfors på vegne af Digitaliseringsstyrelsen. Afsendelse af beskeder til personer og virksomheder enten via digital post eller fysisk post. Forsendelse af beskeder følger nedenstående overordnede kommunikationsmønster: 1. Debitorsystemet afsender beskeder enten som masseforsendelse eller enkeltforsendelse. 2. Debitorsystemet henter forsendelseskanal og forsendelsesstatus via opslag i log. Beskeder i form af en PDF-fil og tilhørende metadata som muliggør forsendelse som både digital og fysisk post. Data fra til Beskederne skal indeholde identifikation af fagsystem og dokument dels som metadata og dels som QR-kode, således at det ved modtagelse af et tilhørende svar (enten via digital post eller en returneret blanket/brev) vil være muligt at identificere både fagsystem og tilknyttet sag. Oplysninger fra forsendelsesloggen herunder forsendelseskanal (fysisk/digital post) og forsendelsesstatus. Når der skal afsendes besked til borgere eller virksomheder. LF - Debitor Opret Krav 1.5.1.1 LF Debitor Håndter Automatisk generede hændelser 2.5.1.1 LF Debitor håndter Opkrævning 2.5.2.1 LF Debitor håndter Afdragsordning 2.5.2.2 LF Debitor Håndter indbetaling 2.5.2.3 LF Debitor håndter Rykker 2.5.2.4 LF - Debitor Håndter Restance 2.5.2.5 LF Debitor Håndter Afskrivning 2.5.2.6 LF Debitor Håndter udbetaling 3.5.1.1 Bilag 3A.6 Integrationer Side 32 af 38 3

DFPR1 Send besked Snitflade Information om den fællesoffentlige fjernprintløsning kan findes her: http://www.digst.dk/loesninger-oginfrastruktur/digital-post/loesninger-og-teknik/fjernprint API: http://www.digst.dk/loesninger-og-infrastruktur/digital- Post/Loesninger-ogteknik/Fjernprint/Vejledninger/Graenseflader-til-Fjernprint Snitfladen er i drift, og der er pt. ingen planlagte aktiviteter i forbindelse med denne snitflade. Der stilles testfunktionalitet til rådighed i snitfladen. 3.18 Sikker Post DSPT1 Send besked til myndighed DSPT1 ATPs Mail server (Exchange) Sikker Post er et system til kommunikation imellem offentlige myndigheder. Løsningen er baseret på at der er etableret en sikker forbindelse, mellem myndighedernes mailservere via en 3. part., så mail kan routes fra en myndighed til en anden over en sikker forbindelse (TLS/SSL eller VPN). ATP IT Formål med integrationen Afsendelse af besked til myndighed. Kommunikationsmønster sender beskeder (mails) enten som masseforsendelse eller enkeltforsendelse. Data fra til Data fra til Mails med vedhæftede dokumenter. Ingen. F.eks. hvis der skal adviseres, afsendes en besked (Advis) til kommunen. Bemærk at denne integration udelukkende anvendes for de kommuner, som i systemadministrationen er konfigureret til Sikker Post kanalen, et andet alternativt er kanalen fjernprint. Ikke afbildet på Løsningsflows. Bilag 3A.6 Integrationer Side 33 af 38 3

DSPT1 Send besked til myndighed Snitflade Der skal etableres en sikker kommunikationskanal, som muliggør afsendelse af Sikker Post (e-mails) fra Debitorsystemet til ATP mail server, hvorfra mailen routes videre til den respektive kommune. Bemærk denne kanal anvendes udelukkende til afsendelse altså envejs beskeder. Snitfladen er i drift og kan anvendes for de myndigheder, som er tilmeldt denne modtagelses form. Test af snitfladen skal aftales med ATP IT. Bilag 3A.6 Integrationer Side 34 af 38 3

4 Optioner 4.1 NemLog-in DNLO1 Login til selvbetjening via NemLog-in DNLO1 NemLog-in Det offentlige log-in-fællesskab som bl.a. understøtter single sign-on mellem offentlige it-løsninger. Digitaliseringsstyrelsen er ansvarlig for løsningen. Formål med integrationen Autentifikation af personer i forbindelse med selvbetjening. Kommunikationsmønster Når en person vil tilgå de dele af selvbetjeningsløsningen, som kræver, at brugeren er logget ind, sender brugeren til NemLog-in. NemLog-in autentificerer brugeren og sender brugeren og brugeroplysninger tilbage til selvbetjeningsløsningen. Data fra til Ingen Data fra til Oplysninger om hvem brugeren er. Hver gang en person vil logge ind på Selvbetjeningsløsningen. Information tilgår senere Information tilgår senere Snitflade Information om NemLog-in kan findes her: http://www.digst.dk/loesninger-og-infrastruktur/nemlogin Tekniske krav og politikker for NemLog-in, som skal overholdes af alle medlemmer af den fællesoffentlige føderation: http://www.digst.dk/loesninger-oginfrastruktur/nemlogin/tekniske-krav Eksisterende snitflade. NemLog-in har et integrationstestmiljø, hvori integrationstest skal foretages. 4.2 Digital Fuldmagt Nedenstående snitflade er alene for at hente de fuldmagtshavere som borgeren har givet fuldmagt til. Leverandøren er forpligtet til at efterleve samtlige Bilag 3A.6 Integrationer Side 35 af 38 3

retningslinjer fra Digitaliseringsstyrelsen, som er nævnt i relation til brugen- /implementeringen af den Digitale fuldmagt i et myndighedssystem. Digital fuldmagt er bygget ind i NemLog-in, som returnere en liste over fuldmagter som fuldmagtshaveren kan vælge at benytte. DDIF1 Hent digital fuldmagt DDIF1 Digital fuldmagt Mulighed for borgere at give fuldmagt til en repræsentant, således at repræsentanten kan agere på borgerens vegne i de offentlige selvbetjeningsløsninger, der er tilsluttet Digital Fuldmagt. Fuldmagter kan gives til andre borgere, en medarbejder i en virksomhed, eller en virksomhed (via CVR nummer) Ydermere udstilles en webservice grænseflade, hvor fuldmagtsprivilegier kan forespørges for en vilkårlig bruger (repræsentant). Dette betyder at en kunderådgiver via denne vej kan få at vide, om der foreligger en fuldmagt, uden at repræsentanten er logget på. Formål med integrationen Kommunikationsmønster Data fra til Data fra til NemLogin's Fuldmagtsløsning At give en borger mulighed for at overdrage fuldmagt til fx en ægtefælle eller barn. Når en kunderådgiver har behov for at forespørge om hvilke fuldmagtsprivilegier, der foreligger for en given borger, kaldes en webservice, der returnerer bruger/brugere som borgeren har givet fuldmagt og de dertil tilhørende fuldmagtsprivilegier/permissions der er tilknyttet det pågældende myndighedssystem. Fuldmagtsprivilegier, der svarer til de delegérbare adgange i. En list over fuldmagt haver, og de tilknyttede fuldmagtsprivilegier. Hver gang en Kunderådgiver får vist overbliksbillede. Information tilgår senere. Bilag 3A.6 Integrationer Side 36 af 38 3

DDIF1 Hent digital fuldmagt Information tilgår senere. Snitflade Basale fuldmagtsløsning: http://digitaliser.dk/resource/2292550 Teknisk guide: http://digitaliser.dk/resource/2456177 Snitfladen er udstillet af digitaliseringsstyrelsen, se snitflade n. NemLog-in's integrationstestmiljø 4.3 Borger.dk DBOR1 Visuel integration i Borger.dk DBOR1 Borger.dk Borger.dk er borgernes samlede digitale indgang til den offentlige sektor. Det er ATP s strategi at udstille selvbetjeningsløsninger igennem Borger.dk. Borger.dk bliver leveret af Digitaliseringsstyrelsen og drives i et samarbejde mellem Staten, KL og Danske Regioner. Formål med integrationen Udstilling af selvbetjeningsløsningen på Borger.dk Kommunikationsmønster Der er tale om en client-side integration, hvor selvbetjeningsløsningen via brugerens browser integreres i Borger.dk. Data fra til Ingen. Der sendes dog registreringer af sidebesøg fra browseren til statistikopsamling på borger.dk. Data fra til Ingen N/a N/a Information tilgår senere. Bilag 3A.6 Integrationer Side 37 af 38 3

DBOR1 Visuel integration i Borger.dk Snitflade Materiale vedrørende visuel integration i Borger.dk kan findes her: http://digitaliser.dk/group/2292671 HTML-guide: http://htmlguide.borger.dk/ Information vedrørende statistiksystem og tællerscript, kan findes her: https://www.borger.dk/formyndigheder/sider/statistiksystem.aspx https://www.borger.dk/sitecollectiondocuments/vejledning_ portalservices_v2%205_20130913.pdf Eksisterende standard snitflade. Se https://www.borger.dk/formyndigheder/sider/udviklere.aspx Bilag 3A.6 Integrationer Side 38 af 38 3