Bilag 3A.6 Integrationer

Transkript

1 Bilag 3A.6 Integrationer Version

2 Indhold 1 VEJLEDNING TIL TILBUDSGIVER INDLEDNING BILAGETS FORMÅL OG OPBYGNING RELATION TIL ØVRIGT MATERIALE INTEGRATIONSBESKRIVELSER ATP ERP ATP AFSTEMNING ATP DATAWAREHOUSE ATP IDM & IDP POSTHÅNDTERING BERIGET GRUNDDATA NEMKONTO FAGSYSTEMER (YDELSER) MODREGNINGSFORDELER KMD INDKOMST SKAT NETS OPKRÆVNING VIA EFAKTURERING BOGFØRINGSCENTRAL SAGS- OG DOKUMENTINDEKS YDELSESINDEKS FJERNPRINT SIKKER POST OPTIONER Bilag 3A.6 Integrationer Side 1 af 38 1

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

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

5 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

6 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

7 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

8 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 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

9 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

10 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

11 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

12 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

13 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 LF Debitor håndter Opkrævning LF Debitor håndter Afdragsordning LF Debitor Håndter udbetaling Bilag 3A.6 Integrationer Side 12 af 38 1

14 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

15 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å LF - Debitor Opret krav LF Debitor Håndter Automatisk generede hændelser Bilag 3A.6 Integrationer Side 14 af 38 1

16 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 Bilag 3A.6 Integrationer Side 15 af 38 1

17 DNEM1 Udbetaling Snitflade Produkt: Se Beskrivelse af snitflade til overførsel af udbetalingsanmodninger: 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

18 DFSY1 Krav Snitflade LF - Debitor Opret Krav 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 LF Debitor Håndter Afskrivning Snitflade Se DFSY2 Ny snitflade Se DFSY2 DFSY3 Modregningsanmodning DFSY3 Fagsystem Bilag 3A.6 Integrationer Side 17 af 38 1

19 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 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

20 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 LF Debitor Håndter indbetaling 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

21 DMOD1 Modregningsanmodning LF Debitor Håndter Afdragsordning LF Debitor Håndter indbetaling 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 Ny snitflade Ny snitflade skal etableres Test af dataafleveringen skal aftales med leverandør KMD Indkomst DKIN1 Forskudsopgørelse Bilag 3A.6 Integrationer Side 20 af 38 2

22 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

23 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 SKAT DSKA1 Renteoplysninger DSKA1 Bilag 3A.6 Integrationer Side 22 af 38 2

24 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 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

25 DEFI1 Fordringsindberetning Data fra til Kvittering samt en status på den umiddelbare behandling af fordringen. Dagligt Debitor har ca fordringer i EFI LF - Debitor Opret Krav LF Debitor Håndter Afdragsordning LF Debitor Håndter indbetaling LF Debitor håndter Rykker LF - Debitor Håndter Restance LF Debitor Håndter Afskrivning 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

26 DEFI2 Fordringsstatus Snitflade LF Debitor Håndter Afdragsordning LF Debitor Håndter indbetaling LF - Debitor Håndter Restance LF Debitor Håndter Afskrivning Eksisterende standard snitflade MFUnderretSamlingHent forventes anvendt. Eksisterende snitflade. Kontakt SKAT 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 Eksisterende standard snitflade til NETS anvendes. Bilag 3A.6 Integrationer Side 25 af 38 2

27 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

28 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 Eksisterende standard snitflade til NETS anvendes. Eksisterende snitflade. Kontakt NETS 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 Snitflade Eksisterende standard snitflade antages anvendt. Bilag 3A.6 Integrationer Side 27 af 38 2

29 DEAN1 Opkrævning via efakturering Eksisterende snitflade. Ukendt 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 LF Debitor Håndter indbetaling Eksisterende standard snitflade anvendes Eksisterende snitflade Sags- og dokumentindeks DSDI1 Udstil oplysninger i Sags- og dokumentindeks DSDI1 Sags- og dokumentindeks Bilag 3A.6 Integrationer Side 28 af 38 2

30 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