Integration SF1590_B_02_V3 Overfør debitorregistrering til Debitor Integrationsbeskrivelse - version 3.7.0

Transkript

1 Integration Integrationsbeskrivelse - version Kommunernes Data- og Infrastrukturfællesskab - KDI

2 Versionshistorik Dato Relevans Initialer Version Kommentarer Samlet KDI Ny baseline Udgivet KDI Opdateret med referencer og præciseringer Udgivet KDI Version 3.5 findes ikke. Der er foretaget flg. yderligere rettelser og tilføjelser: Rettelse af versioneringsværdi i Hovedoplysninger Præcisering af anvendelse af reference klasser, Sortiment Rettelse af skabelon til brug for overvågning af SFTP-mapper Struktur for de enkelte operationer er blev gennemgået for at sikre konsistens ift. SF1590_B_01_V3. Der er foretaget forenkling i den enkelte strukturer, så de kan anvendes med mindst mulig regelbeskrivelse under operationen. Detaljeret beskrivelse findes i [Servicestrukturrapport]. Informationsmodellen er blevet suppleret med en aktiv html-version. Udgivet KDI Skemaer tilrettet så kortere lokalstrukturnavne benyttes. Dette for at tilgodese udviklingsværktøjers forudsætninger for automatisk kodegenerering. Objekt DebitorSpecifikation renavngivet til DebitorkontoSpecifikation. Objekt OpkrævningOplysninger renavngivet til Opkrævning. Element DebitorkontoDebitorkontoType rettet til Debitorkonto- Type. Transiente elementer AntalDebitorkonti, AntalFordringer, Antal- Delfordringer fjernet. KOMBIT A/S Halfdansgade København S CVR Side 2 af 58

3 Referencer Ref. Titel Kommentarer [GVF] Integration Generelle vilkår og forudsætninger Findes her: Generelle vilkår og forudsætninger.pdf. Teknisk vejledning Serviceplatformen Generelle vilkår og forudsætninger, der skal være på plads før Snitflader kan anvendes Den anbefales, at leverandører af fagsystemer og kildesystemer tager et kik her. [SFTP] [SFTPnoter] [SFTP FS] [SFTP DS] [Hovedoplysninger] Findes her: Vejledning til Serviceplatformens SFTP Service Findes her: Vejledning til Serviceplatformens SFTP Service.pdf. SFTP - Anvendelsesnoter med relation til ØiR v.1.0 Findes her: Anvendelsesnoter med relation til ØiR v.1.0.pdf. Template for debitorregistreringer - Fagsystem Findes her: [Bilag] NOT0746 Oprydningskonfiguartion til SFTP Server - SF1590_A_02_V3 FS.docx NOT0746 Oprydningskonfiguration til SFTP Server - SF7001 FS.docx NOT0746 Oprydningskonfiguration til SFTP Server - SF7002 FS.docx Template for debitorregistreringer - Debitorsystem Findes her: [Bilag] NOT0746 Oprydningskonfiguartion til SFTP Server - SF1590_A_02_V3 DS.docx NOT0746 Oprydningskonfiguration til SFTP Server - SF7001 DS.docx NOT0746 Oprydningskonfiguration til SFTP Server - SF7002 DS.docx Transaktionsspor og Fejlbehandling ved servicekald Tekniskbeskrivelse af SFTP service på Serviceplatformen ØiR specifikke krav ifm. anvendelse af Serviceplatformens SFTP-se Forudfyldt template til brug for fagsystemets overvågning af sin SFTP-dataleverance. Input til oprettelse hos Serviceplatformens Help Desk Forudfyldt template til brug for debitorsystemets overvågning af sin SFTP-dataleverance. Input til oprettelse hos Serviceplatformens Help Desk Fælles datastruktur for services udstillet på Serviceplatformen. Indgår i servicens input og output payload KOMBIT A/S Halfdansgade København S CVR Side 3 af 58

4 Ref. Titel Kommentarer [Bilag] Findes her: Transaktionsspor og Fejlbehandling ved servicekald.pdf. Bilagssamling til integrationsbeskrivelsen Samler bilag, som knytter sig til integrationen. [Informationsmodel] Samlet informationsmodel for håndtering af dataudveksling med debitor, dvs. debitorsystemer. [Servicestrukturrapport] [ØiR Klassifikation] Findes her: under området Økonomi eller direkte med reference til SF1590_B_02_V3, SF1590_B_02_V3 Overfør debitorregistrering til Debitor Bilag zip. ØiR Debitor Informationsmodel Findes her: [Bilag] SF1590_B_V3 - ØiR Debitor - Informationsmodel pdf Overfør Debitorregistrering til Debitor Servicestrukturrapport Findes her: [Bilag] SF1590_B_01_V3 Overfør Debitorregistrering til Debitor - Servicestrukturrapport pdf ØiR Klassifikationssystemet Findes her: i mappen STS Klassifikationer/Økonomi Beskriver datastrukturen for servicen. Indeholder reference til relevant WSDL mv. Indeholder ØiR domæne klassifikationer og sortimenter, samt en række fælles referenceklassifikationer. KOMBIT A/S Halfdansgade København S CVR Side 4 af 58

5 Indholdsfortegnelse 1 Overordnet beskrivelse Integrationens formål Overordnet forretningsflow i integrationen Servicebetingelser for den samlede integration Teststrategi Håndtering af legacy registreringer Forudsætninger for produktionssætning Kontekst for integrationsparter Kontekst fælles for fagsystem Kontekst fælles for kildesystem - debitorsystem Kontekst for KY, KSD [!@KY@!][!@KSD@!] Kontekst for Ejendsomskat og Ejendomsbidrag System [!@EogE@!] Kontekst for Social Pension Kommune [!@SPK@!] Kontekst for Debitorsystem - EG ØS Indsigt Kontekst for Debitorsystem - Fujitsu Prisme Kontekst for Debitorsystem - KMD Opus Debitor Specifikation for integrationsparter Specifikation af endpoints for Fagsystem [!@KY@!][!@KSD@!][!@EogE@!][!@SPK@!] Specifikation af endpoints for SP [!@SP@!] Specifikation af endpoints for Debitorsystem [!@DS@!] Beskrivelse for integrationsplatforme Beskrivelse for Serviceplatformen [!@SP@!] Tilslutning til integrationspart: Serviceplatformen KOMBIT A/S Halfdansgade København S CVR Side 5 af 58

6 1 Overordnet beskrivelse 1.1 Integrationens formål ØiR Økonomi i Rammearkitekturen omfatter services til brug for dataudveksling mellem fagsystemet og ERP-systemer indenfor områderne finans, kreditor, ordre og fakturering samt debitor og betalinger. Integration dækker debitorregistrering, dvs. fagsystemets aflevering af og opdatering af debitorregistrering i myndighedens debitorsystem. Integrationen giver endvidere fagsystemet mulighed for at hente mange debitorkontis status for betalingsservice samt indbetalinger på krav. Debitorregistreringer er samlet om en debitorkonto eller en indbetaling. Debitorkontoen er formålsangivet med en debitorkontotype. Debitorkontotyper er fastlagt i en fælleskommunal klassifikation. Det enkelte fagsystem fastlægger sine delfordringstyper for de specifikke krav. Tilsvarende gør debitorsystemet for de krav, som alene håndteres af debitorsystemet. 1.2 Overordnet forretningsflow i integrationen Integrationen understøtter for det første dataoverdragelse af debitorregistreringer fra et fagsystem til det af kommunen valgte debitorsystem (ERP). Dataoverdragelsen kræver, at debitorsystemet skal sende kvittering med accept eller afvisning af dataoverdragelsen. Kvitteringen kan indeholde forretningssvar fx ifm. søgning af information. Integrationen, dvs. servicen på Serviceplatformen, ændrer ikke på de debitorregistreringer, som overdrages. For det andet understøtter integrationen, at fagsystemet kan få dataoverdraget (hente og søge) information om debitorregistreringer i debitorsystemet, egne og andres debitorregistreringer. Leverancen af debitorregistreringer begynder, når et fagsystem har en leverance til eller behov for data i myndighedens debitorsystem. Leverancerne kan deles op i tre typer: Opret, Opdater og Forespørg. Med undtagelse af enkelte operationer af typen forespørg, er objektet for alle leverancer af debitorregistreringer knyttet til en debitorkonto. I debitorsystemet valideres data for, om de overholder det aftalte format og indeholder valide data. Debitorsystemet skal herved sikre sig, at det kan viderebehandle leverancen og dermed overtage dataansvaret herfor. Ved oprettelse og ajourføring af debitorregistreringer er resultatet af valideringen debitorsystemets accept eller afvisning af leverancen. Det sker ved, at debitorsystemet danner et forretningssvar per leverance med kvitteringsstatus for debitorregistreringen. Ved forespørgsel på debitorregistreringer vil resultatet af validering og eksekvering af forespørgslen være et forretningssvar. Integrationen understøtter kommunikationen mellem et fagsystem og et debitorsystem. Kommunikationen foregår typisk inden for samme myndighed, men understøtter også at den dataafgivende myndighed er forskellig fra den myndighed, som har dataansvaret for debitorsystemet Integrationens begreber Integrationen er begrebsmodelleret ud fra den overordnede ØiR Debitor domæne model. De anvendte forretningsmæssige begreber i integrationen fremgår af integrationens informationsmodel [Informationsmodel]. KOMBIT A/S Halfdansgade København S CVR Side 6 af 58

7 Integrationen benytter sig af en teknisk datastruktur kaldet hovedoplysninger. Dens begreber og anvendelse er angivet her [Hovedoplysninger]. Nedenfor er angivet enkelte begreber, som er nyttige for læsningen af integrationsbeskrivelsen. AfsenderItSystemInstans Det system, som overfører debitorregistreringer til et debitorsystem eller henter debitorsystemets debitorregistreringer. Typisk vil det være et fagsystem, fx KY. Det kan også være et andet debitorsystem. Der er tale om den enkelte fysiske instans af et it-system, heraf navnet. I STS Administration anvendes begrebet it-system. Indgår i HovedOplysning, AfsenderItSystemInstans. Alias: Fagsystem, Anvendersystem Teknisk repræsentation: UUID AfsenderOrganisation Den myndighed, som har dataansvar for datavideregivelse eller dataforespørgsel fra AfsenderItSystemInstans. Defineret i STS Organisation, som myndighed. Indgår i HovedOplysning, AfsenderOrganisation. Alias: Kommune, AfgivendeMyndighed Teknisk repræsentation: oio:cvr:cvr-nummer:xxxxxxxx ModtagerItSystemInstans Debitorsystemet som er modtager af debitorregistreringer, eller som svarer på forespørgsel om debitorregistreringer. Der er tale om den enkelte fysiske instans af et debitorsystem, heraf navnet. I STS Administrationsmodul anvendes begrebet it-system. Indgår i HovedOplysning, AfsenderOrganisation. Alias: Debitorsystem, ERP-løsning, ERP-system, Kildesystem Teknisk repræsentation: UUID ModtagerOrganisation Den myndighed, som har dataansvar for datamodtagelse i ModtagerItSystemInstans. Defineret i STS Organisation, som myndighed. Indgår i HovedOplysning, ModtagerOrganisation. Alias: Kommune, Debitoransvarlig myndighed Teknisk repræsentation: urn:oio:cvr:cvr-nummer:xxxxxxxx KOMBIT A/S Halfdansgade København S CVR Side 7 af 58

8 1.2.2 Diagrammer for forretningsflow Debitorregistrering Flow Masseleverance Serviceplatform Fagsystem Overfør Anmodning Opbevar filer (SFTP Service) Fordel til SFTPbruger Hent Forretningssvar Opbevar filer (SFTP Service) Fordel til SFTP-bruger Opbevar filer (SFTP Service) Opbevar filer (SFTP Service) Debitorsystem Hent Anmodning Valider / Fremsøg Overfør Forretningssvar Figur 1 Debitorregistrering flow - Masseleverance Valg af integrationsmønster Masseleverance af debitorregistreringer foregår filbaseret via Serviceplatformens SFTP-service. Der er tale om et asynkront integrationsmønster, hvor serviceforespørgsel sendes af fagsystemet i en fil til debitorsystemet. Senere, når debitorsystemet har behandlet serviceforespørgslen, sender debitorsystemet sit svar i en ny fil til fagsystemet. Det giver mulighed for at håndtere store datavolumener. Forretningsmæssigt er det en forudsætning, at fagsystemet ikke har behov for her og nu svar, dvs. synkrone svare ifm. forespørgsel. Som alternativ til masseleverance kan der vælges straksleverance. Denne leveranceform foregår som webservice kald, og er synkron. Straksleverance understøtter flere forretningsmæssige operationer end det er tilfældet under masseleverance. Afsend (Straksleverance) Overfør (Masseleverance) : SF1590_B_01_V3 : SF1590_B_02_V3 KOMBIT A/S Halfdansgade København S CVR Side 8 af 58

9 1.2.4 Håndtering af accept og afvisning af dataoverdragelse af debitorregistrering Når fagsystemet kalder debitorservicen på Serviceplatformen, vil Serviceplatformen foretage en simpel skemavalidering af den indkomne serviceforespørgsel. Debitorsystemet skal validere indkomne data, herunder om data kan mappes, hvis der er opsat mapningsregler mellem de fælles referencedata (jf. afsnit 1.2.9) og debitorsystemets egne referencedata, masterdata. Resultatet af valideringsprocessen er debitorsystemets accept eller afvisning af dataoverdragelsen. Dette er angivet som forretningssvar i Figur 1. Debitorsystemet skal indledningsvist foretage en validering af dataleverancen, dvs. om dataleverancen kan og må håndteres af debitorsystemet. Giver valideringen et negativt resultat vil forretningssvaret være en DebitorLeveranceAfvisning, som vil indeholde en detaljeret begrundelse for afvisning. Ved en positiv dataleverancevalidering vil forretningssvaret være afhængig af typen af operation. For operationer, der fremsøger eller henter, vil forretningssvaret være debitorregistreringer. For operationer, som opretter eller ajourfører, vil der gennemføres en validering om handlingen er mulig for den enkelte debitorregistrering. Denne validering resulterer i et forretningssvar pr. debitorregistrering, DebitorregistreringKvittering. Ved en positiv validering svares med DebitorAccept. Ved negativ vil det være DebitorAfvisning. Forretningssvaret vil være samlingen af DebitorAccept og DebitorAfvisning dækkende alle debitorregistreringer i dataleverancen. Omfatter en debitorregistrering oprettelse af en debitorkonto med tilhørende fordringer og delfordringer og fejler blot en af disse afvises debitorregistreringen som sådan. Det gælder her, at debitorsystemet skal gennemføre validering af samtlige elementer i debitorregistreringen uanset, at et tidligere element fejler. Der skal svares samlet for hele debitorregistreringen Angivelse og håndtering af Personfølsomhed Integrationen forudsætter, at fagsystemet angiver niveau af personfølsomhed for den enkelte debitorregistrering, som den forestår oprettelse af. Herved informerer fagsystemet debitorsystemet om sin fastlæggelse af personfølsomheden af de informationer, som dataoverdrages i integrationen. Det er op til debitorsystemet at håndtere denne klassificering ud fra egne regler, fx databehandleraftale, registerforskrifter mv. Debitorsystemet kan vælge et andet niveau af personfølsomhed ift. sin behandling af de overdragne data i debitorsystemet Håndtering af Administrator for en debitorkonto Som hovedregel er det den juridisk ansvarlige part, som har ansvaret for håndtering af forhold omkring debitorkontoen herunder kommunikationen med myndigheden, kommunen. Denne opgave og ansvar kan overdrages til en. En kan være en indsat værge, et dødsbo mv. Når et fagsystem via denne snitflade opretter en debitorkonto, skal fagsystemet tage stilling til, om det er fagsystemet eller debitorsystemet, som forestår tilknytning og vedligehold af information om KOMBIT A/S Halfdansgade København S CVR Side 9 af 58

10 . Fagsystemet vil altid ifm. oprettelse af selve debitorkontoen kunne angive en uagtet, at fagsystemet har markeret for, at denne ajourføring efterfølgende er debitorsystemets ansvar. Har fagsystemet ansvaret for at vedligeholde information om, så er det ikke tilladt for debitorsystemet at ændre fagsystemets angivelse af. Eneste undtagelser er ifm. oprettelse af dødsbo som. Fagsystemet vil via integrationen kunne hente de aktuelle informationer i debitorsystemet om Håndtering af en parts Gældende Adresse Adressen for den part fx borger, som indtræder i en partsrolle i snitfladen, fx juridisk ansvarlig part, vil som hovedregel være en officiel adresse, fx hentet fra CPR-registret. Debitorsystemer og snitfladen rummer mulighed for, at en parts adresse kan ændres i en periode. Dette kaldes gældende adresse. Denne mulighed anvendes også, hvor der oprettes en part, som ikke findes i et fællesoffentligt register, fx et erstatningscpr-nummer. Snitfladen giver mulighed for, at fagsystemet ifm. oprettelse af en debitorkonto samt efterfølgende løbende vedligeholder og afslutter gældende adresse. Samme mulighed ligger i debitorsystemet, som er master for den gældende adresse. Dvs. debitorsystemet kan afvise en adresseændring modtaget af fagsystemet. Det betyder, at der kan være forskellig information om gældende adresse i hhv. fagsystem og debitorsystem. Integrationen understøtter ikke en automatisk synkronisering af gældende adresse. Fagsystemet vil via integrationen kunne hente de aktuelt gældende adresser i debitorsystemet Bogføring Fagsystemet har ansvar for at danne det fornødne bogføringsgrundlag til brug for sin driftskontering. Reglerne herfor er opsat i fagsystemet. Tilsvarende skal debitorsystemet danne bogføringsgrundlag ift. restance-, opkrævning- og indbetalingskontering. Reglerne for denne kontering er opsat i debitorsystemet. Opsætningerne i hhv. fagsystem og debitorsystem skal koordineres ift. anvendelse af mellemregningskonti. Koordineringen vil typisk kunne foregå ved anvendelse af den mapningsfunktionalitet i bogføringssystemet, som er implementeret ifm. SF1590_A Afsend økonomiposteringer til Finans (ØiR) Anvendelse af referencedata En vigtig del af en debitorregistrering er angivelse af debitorkontotype, delfordringstype m.v. Hver angivelse referer til en klassifikation over mulige værdier. Klassifikationer er fastlagt i fælles klassifikationssystemer for ØiR [ØiR Klassifikationssystem] samt fælles klassifikationer så som Indenrigsministeriets kontoplan. KOMBIT A/S Halfdansgade København S CVR Side 10 af 58

11 Der er ikke krav om, at myndighedens debitorsystem benytter præcis de samme værdisæt. I debitorsystemet vedligeholdes en omsætningstabel, hvor debitormedarbejderen mapper et fagsystems sortiment til de lokale værdilister fx betalingsarter i debitorsystemet. Det er debitorsystemets opgave og ansvar med udgangspunkt i omsætningstabellen at forestå konvertering af de modtagne debitorregistreringer, herunder logning af denne konvertering. Tilsvarende skal debitorsystemet ifm. et fagsystemets fremsøgning af debitorregistreringer tilbagekonvertere til værdilister jf. [ØiR Klassifikation]. Under ØiR Klassifikationssystemet findes der fælles klassifikationer og sortimenter. Klassifikationerne indeholder brutto-mængden over tilladte værdier. Et sortiment er netto-mængden af værdier, som et fagsystem (anvendersystem) har valgt at benytte abonnerer på. Det betyder, at der for hvert fagsystem vil være et sortiment over dette systems valg af tilladte værdier. Klassifikationer og dermed også sortimenter indeholder både fælles værdier og kommune-/myndighedsspecifikke værdier. Det tilladte værdisæt for et fagsystems debitorregistreringer er således givet af klassifikationssystemet ØiR Klassifikationssystem. Fagsystemet vil skulle indeholde regler og procesunderstøttelse for korrekt benyttelse af sin del af klassifikationssystemet. Fagsystemet har tilsvarende ansvar og fuld råderet over opbygningen af denne del. Det er en forudsætning, at fagsystemet importerer sit sortiment fra [ØiR Klassifikationssystemet] ift. den myndighed, som er dataansvarlig for fagsystemet. Debitorsystemet skal tilsvarende importere sortimenter fra tilsluttede fagsystemer. Sortimentet skal både gælde sortimenter ift. de myndigheder, som benyttet et tilsluttet fagsystem, samt debitorsystemets eget sortiment for den debitoransvarlige myndighed, såfremt et sådant sortiment findes. Sortimenter modtages via servicen SF7002 Eksport Sortiment. En række af servicens operationer vil forudsætte, at både fagsystem og debitorsystem kan have behov for adgang til andre it-systemers anvendelse af ØiR Klassifikationssystemet. Det håndteres ved at abonnere på de overliggende klassifikationer. Klassifikationer modtages via servicen SF7001 Eksport Klassifikation. 1.3 Servicebetingelser for den samlede integration Servicemål Parameter Tidsrum Svartid Debitorregistreringsflow Værdi Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Kvitteringsflow Værdi Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. KOMBIT A/S Halfdansgade København S CVR Side 11 af 58

12 Tilgængelighed Spidsbelastningsperiode Servicevinduer Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen. Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen Service Management Eventuelle tilretninger og præciseringer i integrationens beskrivelse og specifikation, vil indtil integrationen ligger på Serviceplatformens eksterne testmiljø, blive håndteret af Kommunernes Data Fællesskab (KDI). Spørgsmål vedr. specifikation sendes til SPTest@kombit.dk. KDF sørger for at involverede parter i integrationen oplyses om tilretningerne og præciseringerne. Se oversigten over hvornår de enkelte integrationer forventes at være tilgængelige i eksternt testmiljø her: Når servicen er tilgængelig i det eksterne testmiljø på Serviceplatformen, vil den overgå til Serviceplatformens governanceproces. Adgangen hertil fremgår af Teststrategi Overordnet Det generelle udgangspunkt for KOMBITs teststrategi er, at alle involverede parter, dvs. fagsystemerne, debitorsystemerne og Serviceplatformen har gennemført en robust systemtest af egen løsning, før der gennemføres test parterne imellem. Pga. integrationens omfattende funktionalitet, samt da der er tale om flere parter både på anvendersiden og kildesystemsiden er den generelle teststrategi modificeret på flg. punkter: Da intet fagsystem benytter den fulde funktionalitet, som integrationen indeholder, gennemfører KDI en kildesystemintegrationstest med hver leverandørs debitorsystem. Pga. integrationens omfattende funktionalitet er Serviceplatformens systemtest begrænset til en robust test af kernefunktionalitet som fx routing, sikkerhed og tilsvarende. Den funktionelle test af servicens forskellige operationer og deres mulige anvendelser håndteres ifm. den første kildesystemintegrationstest, som gennemføres. Den test vil have den nødvendige dækning af det funktionelle indhold. Hvis dette enten pga. kommercielle forhold eller vurdering af manglende robusthed af Serviceplatform eller Kildesystem, da kan der etableres en kildesystemtest med anvendelse af teststubbe. KOMBIT A/S Halfdansgade København S CVR Side 12 af 58

13 Når første kildesystemintegrationstest er succesfuldt gennemført kan resterende test gennemføres, fx fagsystemernes integrationstest og end-to-end-test. Fagsystemet har mulighed for at gennemføre fagsystemintegrationstest, hvor der benyttes teststubbe til simulering af debitorsystemet. Behovet kan opstå, hvis servicen endnu ikke er udstillet på Serviceplatformen eller hvor kommercielle forhold gør en sådan integrationstest med kildesystemet uattraktiv. Fagsystemet skal særskilt bestille denne test hos KDI, Fagsystemet fastlægger omfanget af sin end-to-end test med kildesystemet. Ovennævnte test er gennemført med kildesystemernes centrale udviklings-/testmiljøer. Da en række af debitorløsningerne er i decentraldrift tilbydes, at myndighederne her, at der gennemføres en Tilslutningstest. Denne test gennemføres ift. testinstanser under den decentrale drift. Tilslutningstesten skal bestilles af myndigheden. Ifm. Serviceplatformens tilslutning af servicen og opkobling til det enkelte kildesystem aktiverer Serviceplatformen sin overvågning af kildesystemets SFTP-bruger. Der foretages ikke test af denne overvågning. For at risiko-mitigere det enkelte fagsystem produktionssætning af en myndigheds anvendelse er det anbefalingen, at fagsystemet i produktion aktiverer en verifikationstransaktion, nul-sums-postering. Dvs. en postering/registrering, som efterfølgende er uden forretningsmæssig konsekvens. Omfanget af sådanne verifikationstransaktioner vil afhænge af fagsystemets forretningsmæssige anvendelse af integrationen. Denne test kaldes Produktionsverifikationstest Test i forbindelse med udvikling på Serviceplatformen Integrationen indeholder ikke udvikling på Serviceplatformen. Standard SFTP-servicen anvendes. Denne test gennemføres derfor ikke Testfaciliteter og testmiljø Nil Testdata Nil Test i forbindelse med udvikling af kildesystemets serviceudstilling Der foretages en robust integrationstest af hver enkelt kildesystems serviceudstilling. Denne test kaldes kildesystemintegrationstest. Testen omfatter alle operationer i servicen. Omfatter både positive og negative testscenarier og alle væsentlige valideringer i integrationen. Kildesystemintegrationstesten kan gennemføres på en af to måder: 1. Via Serviceplatformen KOMBIT A/S Halfdansgade København S CVR Side 13 af 58

14 2. Indledningsvist/delvist direkte mod kildesystemet efterfuldt af en fuldstændig kildesystemintegrationstest via Serviceplatformen Valget afhænger dels af, om services er til rådighed på Serviceplatformen samt en fælles vurdering af stabiliteten af kildesystemets service. Det forudsættes, at kildesystemet har foretaget en intern og tilsvarende robust systemtest af sine services. Kildesystemet har adgang til testcases og testdata, som anvendes ifm. kildesystemintegrationstesten Testfaciliteter og testmiljø Testen gennemføres fra Exttest og SVOT-miljøet under Serviceplatformen. Parasoft anvendes som det tekniske testværktøj Testdata KDI etablerer testcases samt testdata herunder nødvendige referencedata [ØiR Klassifikation]. Kildesystemet foretager den nødvendige opsætning mv for kildesystemtestens gennemførelse Test i forbindelse med fagsystemets serviceanvendelse Fagsystemets primære test er en forretningsmæssig end-to-end-test. Fagsystemet fastlægger scope for denne test. Testen gennemføres ift. hver leverandørens centrale test-it-systeminstans. Testen aftales kommercielt med leverandøren via KDI. Det er en forudsætning, at fagsystemet succesfuldt har gennemført en robust systemtest af sine services. Det forudsættes videre, at debitorsystemet succesfuldt har gennemført kildesystemintegrationstest Testfaciliteter og testmiljø Testen gennemføres i Exttest. Fagsystemet bestiller de nødvendige routingskonfigurationer samt etablere relevante serviceaftaler Testdata Fagsystemet leverer testcases og testdata, som aftales med leverandørerne. KDI leverer efter bestilling fra fagsystemet sortiment til brug for test. KOMBIT A/S Halfdansgade København S CVR Side 14 af 58

15 1.4.5 Kildesystem - Tilslutningstest For de debitorløsninger, som har decentral drift, tilbydes en implementeringstest. Testens formål er at verificere, at den løsning, som er testet i kildesystemintegrationstesten, er blevet succesfuldt installeret i det decentrale driftsmiljø. Der er tale om en simpel test. Testen forudsætter, at myndigheden har et testmiljø under den decentrale drift Testfaciliteter og testmiljø Testen gennemføres fra Exttest og SVOT-miljøet under Serviceplatformen. Parasoft anvendes som det tekniske testværktøj Testdata KDI leverer 2-3 testcases og testdata, samt sortiment til brug for test Produktionsverifikationstest Testen har til formål at verificere at fagsystemet kan sende data til kildesystemet og få disse data valideret korrekt. Testen forudsætter, at fagsystemet har etableret funktionalitet til etablering og afsendelse af en nul-sums postering/registrering Testfaciliteter og testmiljø Testen gennemføres i Produktion Testdata Testcase og testdata er fastlagt af fagsystemet. Der anvendes fagsystemets produktionssortiment. 1.5 Håndtering af legacy registreringer Håndtering vedrører de debitorregistreringer, som er etableret før ibrugtagning af denne integration eller debitorregistreringer, som etableres løbende via legacy integrationer. Debitorsystemet kan håndtere dette ved en af to metoder. Hvilken metode, som debitorsystemet anvender er op til debitorsystemet, da de set fra et fagsystemets perspektiv har samme resultat. On the fly Debitorregistreringerne opgraderes til integrationens krav, når de aktiveres af et fagsystem. KOMBIT A/S Halfdansgade København S CVR Side 15 af 58

16 Fx før Debitorkontoen tilføjet UUID for DebitorkontoType, når den fremsøges i et søgeresultat. Eller fx når Kommunernes Ydelsessystem (KY) vil ajourføre en registrering fra det tidligere fagsystem KMD Aktiv, så oversætter debitorsystemet og overdrager ejerskabet fra KMD Aktiv til KY. Metode: Just in time Konvertering Alle relevante debitorregistreringer opgraderes til integrationens krav via en konverteringskørsel. Den vil sandsynligvis skulle køre løbende, fx ifm. fagsystemskifte. Metode: Just in case Debitorsystemet kan vælge et miks af de to metoder, hvis det findes hensigtsmæssigt Konvertering ifm. fagsystemskifte Det nye fagsystem har behov for at overtage det fulde ejerskab for debitorregistreringer, som har tilhørt et fagsystem, som erstattes. Konverteringen foregår ved, at det ny fagsystem modtager en oversigt over debitorregistreringer fra det fagsystem, som erstattes. Det ny fagsystem danner en mapningstabel, som sendes til debitorsystemet for konvertering. Specifikationen af denne konverteringsopgave ligger uden for integrationsbeskrivelsen. 1.6 Forudsætninger for produktionssætning For at kunne anvende snitfladen er der en række vilkår og forudsætninger, som skal være opfyldt af en tilslutningspart, der skal tilsluttes. Ved tilslutningspart skal forstås fagsystemer, kildesystem osv. Disse vilkår og forudsætninger er opdelt i generelle vilkår og forudsætning, som gælder på tværs af snitfladerne, og i specifikke vilkår og forudsætninger for tilslutning til selve snitfladen. De generelle vilkår og forudsætninger er beskrevet i et samlet dokument [GVF], mens de specifikke aktiviteter, der skal udføres som forudsætning for tilslutning af en tilslutningspart, er beskrevet for hver enkelt tilslutningspart i kapitel Køreplan for Implementering Nedenstående diagram viser den køreplan for udrulningen, som fagsystem inden for KOMBITs rammearkitektur følger. Det væsentlige i køreplanen er faserne, mens en egentlig tidsplan vil følge af den faktiske implementeringsplan. Aktiviteter, som er forudsætninger og betingelser i forbindelse med ibrugtagning af en snitflade, som følge af en udrulning af et fagsystem, vil referere til den fase, den hensigtsmæssigt kan udføres i. Serviceplatformen: Ved idriftsættelse af en snitflade er alle aktiviteter afsluttet, og snitfladen er klar til anvendelse KOMBIT A/S Halfdansgade København S CVR Side 16 af 58

17 Kildesystem: Alle aktiviteter i forhold til serviceplatformen er afsluttet, men der kan være yderligere aktiviteter i forbindelse med tilslutning af et fagsystem eller en kommune. Fagsystem og myndigheder: Ved tilslutning af et fagsystem og/eller en myndighed, er der en række aktiviteter op til idriftsættelsen, dels af aftalemæssig karakter, og dels også af konfigurationsmæssig karakter Særlige vilkår Der er ingen kendte særlige vilkår Supplerende information om tilslutning Integrationen forudsætter som minimum, at både fagsystemet og debitorsystemet benytter fagsystemet sortiment fra [ØiR Klassifikation]. Afhængig af serviceanvendelsen kan både fagsystem og debitorsystemet have behov for de overliggende fælles klassifikationer fra [ØiR Klassifikation]. Det skal afklares konkret gennem en forretningsmæssig anvendelsesanalyse. KOMBIT A/S Halfdansgade København S CVR Side 17 af 58

18 2 Kontekst for integrationsparter 2.1 Kontekst fælles for fagsystem Implementeringsopgaver Faserne følger afsnit 1.6. ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar TS100 Afklaring af dataudveksling. Dataansvarlig myndighed for fagsystemet og Debitoransvarlig myndig skal aftale, at der skal foregå dataudveksling. Afklaring/Aftale Dataansvarlig myndighed for fagsystemet Dataansvarlig myndighed for fagsystemet Fase 2.1 Kun såfremt det ikke ser samme myndighed. Aftalen indgås i TS111 TS101 Fagsystemet skal være oprettet i STS Administrationsmodul ift. anvendelse af SFTP-Servicen Konfiguration STS Administrationsmodul Leverandør af fagsystem Leverandør af fagsystem Fase 2.1 TS102 Dataansvarlig myndighed for fagsystemet skal oplyse den modtagne it-system-instans Koordinering Fagprojektet/Central Fagprojektet/ Central Fase 2.1 Forudsætter, at den debitorsystemet er oprettet i STS Administration, TS202 TS103 Udarbejd et fælles fagspecifikke datagrundlag for anvendelse af [ØiR Klassifikation] Koordinering ØiR Klassifikation Fagprojektet/Central Fagprojektet/ Central Fase 2.1 TS104 Udarbejd myndighedsspecifikt datagrundlag for anvendelse af [ØiR Klassifikation] Koordinering ØiR Klassifikation Myndighed /Lokal fagsystem Myndighed /Lokal fagsystem Fase 2.1 Skal ses ift. implementeringsplan for den enkelte kommune KOMBIT A/S Halfdansgade København S CVR Side 18 af 58

19 ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar TS105 Opret fagsystemets sortiment i [ØiR Klassifikation] Konfiguration ØiR Klassifikation Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS103 skal være gennemført, da fagsystemets ItSystemInstans UUID skal anvendes. TS106 Tilføj myndighedsspecifikt datagrundlag til fagsystemets sortiment i [ØiR Klassifikation] Konfiguration ØiR Klassifikation Myndighed /Lokal fagsystem Myndighed /Lokal fagsystem Fase 2.2 TS104 skal være gennemført TS107 Anmodning om Serviceaftaler for dataansvarlig myndighed i fagsystemet Konfiguration STS Administrationsmodul Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS108 Dataansvarlig myndighed for fagsystemet skal godkende serviceaftale for integrationen Konfiguration STS Administrationsmodul Fagprojektet/Central Dataansvarlig myndighed for fagsystemet Fase 2.2 TS109 Debitoransvarlig myndighed skal godkende serviceaftale for integrationen Konfiguration STS Administrationsmodul Fagprojektet/Central Debitoransvarlig myndighed Fase 2.2 Kun såfremt debitoransvarlig myndighed ikke er den samme som dataansvarlig for fagsystemet. Forudsætter TS100 TS110 Bestil SFTProuting fra fagsystem til debitorsystem Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 Skal gennemføres pr. dataansvarlig myndig- KOMBIT A/S Halfdansgade København S CVR Side 19 af 58

20 ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar hed, som benytter fagsystemet. TS111 Bestil overvågning af fagsystemets SFTPbruger ift. debitorregistreringsfiler. Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS112 Bestil abonnement på sortiment til fagsystemet Konfiguration ØiR Klassifikation Fagprojektet/Central Fagprojektet/Central Fase 2.2 Forudsætter TS105 TS113 Bestil SFTProuting af sortimentet til fagsystem Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 Forudsætter TS105 TS114 Bestil overvågning af fagsystemets SFTPbruger ift. sortimentsmodtagelse Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS115 Gennemførelse af Produktionsverifikationstest Drift Fagsystem Fagprojektet/Central Fagprojektet/Central Fase 3 Optionelt TS100 - Såfremt dataansvarlig myndighed for fagsystemet og Debitoransvarlig myndig ikke er samme myndighed, skal dataudvekslingens formål og grundlag afklares og aftales parterne imellem med formål om, at der senere kan indgås en serviceaftale i STS Administrationsmodul under dobbeltmyndighedsgodkendelse. TS101 - Fagsystemet skal være oprettet i STS Administrationsmodul. Der skal være angivet anvendelse af Simpel Filtransport, Dynamic Routing. SFTP-bruger skal være oprettet inklusiv SSH-nøgle. KOMBIT A/S Halfdansgade København S CVR Side 20 af 58

21 TS102 - Dataansvarlig myndighed for fagsystemet skal oplyse det modtagne it-system-instans. Informationen skal bruges, så der senere kan etableres serviceaftale og routing ift. hertil. KDI vil typisk allerede have denne information, så der kan være tale om en verifikation af eksisterende information. TS103 - Fagsystemet skal fastlægge sit behov for værdilister for klassificerede elementer i integrationen, sit ØiR Sortiment. Fagsystemet kan abonnere på fælles klassifikationer samt få etableret specifikke klasser for eget brug. [ØiR Klassifikation] Løsningen giver mulighed for, at fagsystemet løbende kan tilføje klasser til sit abonnement, ØiR Sortiment. TS104 - Såfremt fagsystemet giver mulighed for at benytte myndighedsspecifikke værdilister i sin brugergrænseflade/forretningsregler, da skal myndigheden afklares sit behov for sådanne herunder genbrug af sine allerede etablerede myndighedsspecifikke klasser. [ØiR Klassifikation] Løsningen giver mulighed for, at myndigheden løbende kan tilføje klasser til sit abonnement, ØiR Sortiment. TS105 - Bestilling af det fagsystem specifikke sortiment. Ajourføring af sortiment med de fælles værdilister, som gælder for alle myndigheders brug af fagsystemet TS106 - Ajourføring af sortiment med de myndighedsspecifikke værdilister. TS107 - I STS Administration skal der oprettes en anmodning om indgåelse af serviceaftale for dataansvarlig myndighed for fagsystemets brug af integrationen, SF1590_B_02_V3 Send- Anmodning. Anmodningen skal indeholde angivelse af Debitoransvarlig myndighed. TS108 - Dataansvarlig myndighed for fagsystemet skal godkende anmodning (TS107) om serviceaftale for snitflade jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. TS109 - Debitoransvarlig myndighed skal godkende serviceaftale for integrationen (TS107), hvis dataansvarlig myndighed for fagsystemet er forskellig fra Debitoransvarlig myndighed. TS110 - Integrationen skal konfigureres med SFTP-routingsinformations fra fagsystemet til debitorsystem ud fra information om dataansvarlige myndigheder for hhv. fagsystem og debitorsystem. Der anvendes implicit-routing. Det sker som en bestilling til Serviceplatformens Help Desk. TS111 - Der skal bestilles overvågning af fagsystemets SFTP-bruger ift. debitorregistreringsfiler. Det sker med brug af skabelonen [SFTP-FS]. Det sker som en bestilling til Serviceplatformens Help Desk. KOMBIT A/S Halfdansgade København S CVR Side 21 af 58

22 TS112 - Bestil abonnement på sortiment til fagsystemet. Det sker via KDI, TS113 - Bestil routing af sortimentet fra ØiR Klassifikationssystemet til fagsystem. Explicit routing. Det sker som en bestilling til Serviceplatformens Help Desk. TS114 - Der skal bestilles overvågning af fagsystemets SFTP-bruger ift. sortimentsfiler. Det sker med brug af skabelonen [SFTP-FS]. Det sker som en bestilling til Serviceplatformens Help Desk. TS115 - I fagsystemet aktivers en funktion, som igangsætter Produktionsverifikationstest. Resultatet heraf kan ses som en registrering i debitorsystemet og i forretningssvaret, som fagsystemet modtager fra debitorsystemet. KOMBIT A/S Halfdansgade København S CVR Side 22 af 58

23 2.2 Kontekst fælles for kildesystem - debitorsystem Implementeringsopgaver Faserne følger afsnit 1.6. ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS200 TS201 Aftale /Verifikation Konfiguration Debitoransvarlig myndighed skal indgå aftale om anvendelse af den snitflade i debitorsystemet, som integrationen anvender Debitor skal være oprettet i STS Administrationsmodul ift. anvendelse af SFTP-Servicen Debitorsystem Debitor ansvarlig myndighed Debitor ansvarlig myndighed STS Administrationsmodul Leverandør af debitorsystemet Leverandør af debitorsystemet Fase 1 Fase 1 TS202 Opdatering af instruks for databehandling, der angiver modtagelse af data for et givent fagsystem Aftale /Verifikation Debitorsystem Debitor ansvarlig myndighed Debitor ansvarlig myndighed Fase 2.1 Om der skal etableres aftale for hvert fagsystem afhænger af den overliggende databehandleraftale TS203 Anmodning om Serviceaftaler for dataansvarlig myndighed i debitorsystemet Konfiguration STS Administrationsmodul Debitorsystem Central Administrator eller Lokal Debitorsystem Central Administrator eller Lokal Fase 2.2 TS204 Dataansvarlig myndighed for debitorsystemet skal godkende serviceaftale for integrationen Konfiguration STS Administrationsmodul Debitor ansvarlig myndighed Debitor ansvarlig myndighed Fase 2.2 KOMBIT A/S Halfdansgade København S CVR Side 23 af 58

24 ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS205 Dataansvarlig myndighed for fagsystemet skal godkende serviceaftale for integrationen Konfiguration STS Administrationsmodul Debitorsystem Central Administrator eller Lokal Dataansvarlig myndighed for fagsystemet Fase 2.2 Kun såfremt debitoransvarlig myndighed ikke er den samme som dataansvarlig for fagsystemet. Forudsætter TS200 TS206 Bestil SFTProuting fra debitorsystem til fagsystem Konfiguration Serviceplatformen Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Skal gennemføres for hvert tilsluttet fagsystem for respektive myndigheder. TS207 Bestil overvågning af debitorsystemets SFTP-bruger ift. debitorregistreringsfiler. Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS208 Bestil abonnement på fagsystemets sortiment til debitorsystemet Konfiguration ØiR Klassifikation Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Forudsætter TS105 TS209 Bestil abonnement på klassifikationer og debitorsystem specifikke sortimenter til debitorsystemet Konfiguration ØiR Klassifikation Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Optionelt KOMBIT A/S Halfdansgade København S CVR Side 24 af 58

25 ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS210 Bestil SFTProuting af sortimentet til debitorsystemet Konfiguration Serviceplatformen Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Forudsætter TS105 TS211 Bestil overvågning af debitorsystemets SFTP-bruger ift. sortimentsmodtagelse Konfiguration Serviceplatformen Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 TS212 Etablere omsætningstabeller i debitorsystemet Konfiguration Debitorsystem Debitor ansvarlig myndighed Debitorsystem Lokal Fase 2.2 TS213 Drift Gennemførelse af Produktionsverifikationstest Debitorsystem Fagsystemet: Fagprojektet/Central Debitorsystem Lokal Fase 3 Optionelt TS200 - Debitoransvarlig myndighed skal indgå aftale om anvendelse af den snitflade i debitorsystemet, som integrationen anvender TS201 - Debitorsystemet skal være oprettet i STS Administrationsmodul. Der skal være angivet anvendelse af Simpel Filtransport, Dynamic Routing. SFTP-bruger skal være oprettet inklusiv SSH-nøgle. TS202 - Opdatering af instruks for databehandling, der angiver modtagelse af data for et givent fagsystem. Det kan evt. resulterer i en opsætning i debitorsystemet. TS203 - I STS Administration skal der oprettes en anmodning om indgåelse af serviceaftale for debitoransvarlig myndigheds brug af integrationen, SF1590_B_02_V3 SendSvar. KOMBIT A/S Halfdansgade København S CVR Side 25 af 58

26 Anmodningen skal indeholde angivelse af dataansvarlige myndighed for fagsystemet. TS204 - Debitoransvarlig myndighed skal godkende anmodning (TS203) om serviceaftale for snitflade jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. TS205 - Dataansvarlig myndighed for fagsystemet skal godkende serviceaftale for integrationen (TS203), hvis debitoransvarlig myndighed for dataansvarlig myndighed for fagsystemet. TS206 - Integrationen skal konfigureres med SFTP-routingsinformations fra debitorsystemet til fagsystemet ud fra information om debitoransvarlig myndighed, debitorsystemet, dataansvarlig myndighed for fagsystem samt fagsystemet. Der anvendes explicit-routing. Det sker som en bestilling til Serviceplatformens Help Desk. TS207 - Der skal bestilles overvågning af debitorsystemets SFTP-bruger ift. debitorregistreringsfiler. Det sker med brug af skabelonen [SFTP-DS]. Det sker som en bestilling til Serviceplatformens Help Desk. TS208 - Der skal bestilles debitorsystemets abonnement på sortiment for det specifikke fagsystem. Det sker via KDI, TS209 - Bestil debitorsystemets abonnement på klassifikationer og debitorsystem specifikke sortimenter til debitorsystemet. Det sker typisk ifm. første anvendelse af integrationen. Det sker via KDI, TS210 - Bestil SFTP-routing af sortimentet til debitorsystemet. Explicit routing. Det sker som en bestilling til Serviceplatformens Help Desk. TS211 - Bestil overvågning af debitorsystemets SFTP-bruger ift. sortimentsmodtagelse. Det sker med brug af skabelonen [SFTP-DS]. Det sker som en bestilling til Serviceplatformens Help Desk. TS212 - Det er debitorsystemet opgave at konfigurere regler for mapning mellem debitorsystemets egen klassifikation for kommunen og de modtagne klassifikationer og sortimenter fra ØiR klassifikation. Der vil altid være mapning/omsætning ift. fagsystemets sortiment. Der kan være yderligere omsætning ift. klassifikationer og specifikke sortimenter for debitorsystemet selv. Der henvises til debitorsystemleverandørens vejledning. TS213 - I fagsystemet aktivers en funktion, som igangsætter Produktionsverifikationstest. KOMBIT A/S Halfdansgade København S CVR Side 26 af 58

27 Resultatet heraf kan ses som en registrering i debitorsystemet og i forretningssvaret, som fagsystemet modtager fra debitorsystemet. KOMBIT A/S Halfdansgade København S CVR Side 27 af 58

28 2.3 Kontekst for KY, KSD Lovhjemmel og forvaltningsmæssigt formål Kommunens datavideregivelse af Debitorforhold til kommunens ERP-/Finansløsning via ØiR SF1590B følger lov nr. 429 af 6. juni 2005 om opkrævning og inddrivelse af visse fordringer, som ændret ved _i lov nr. 307 af 19. april 2006, i lov nr. 404 af 8. maj 2006 og _i lov nr. 516 af 7. juni 2006, og 2. lov om kommunens styrelse - kommunens økonomiske forvaltning, jf. jf. lovbekendtgørelse nr. 971 af 25. juli 2013, med de ændringer, der følger af 9 i lov nr. 639 af 12. juni 2013 og 1 i lov nr af 17. december Især kap. 1 og 5. Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på bestillingstidspunktet. Det er fastsat på baggrund af en rimelig og dækkende analyse. Henvisningen til hjemmelsgrundlaget bliver ikke vedligeholdt, hvorfor KOMBIT naturligvis ikke kan indestå for, at denne henvisnings indehold og retsvirkning til alle tider vil være korrekt. KOMBIT skal derfor understrege, at læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en orientering Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart Forventet volumen til snitfladen er overførsler om måneden Forudsætninger for produktionssætning af integration systemspecifikt Intet Forudsætninger for drift systemspecifikt Intet KOMBIT A/S Halfdansgade København S CVR Side 28 af 58

29 2.4 Kontekst for Ejendsomskat og Ejendomsbidrag System Lovhjemmel og forvaltningsmæssigt formål [afventer] Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart [afventer] Forudsætninger for produktionssætning af integration systemspecifikt [afventer] Forudsætninger for drift systemspecifikt [afventer] KOMBIT A/S Halfdansgade København S CVR Side 29 af 58

30 2.5 Kontekst for Social Pension Kommune Lovhjemmel og forvaltningsmæssigt formål [afventer] Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart [afventer] Forudsætninger for produktionssætning af integration systemspecifikt [afventer] Forudsætninger for drift systemspecifikt [afventer] KOMBIT A/S Halfdansgade København S CVR Side 30 af 58

31 2.6 Kontekst for Debitorsystem - EG ØS Indsigt Lovhjemmel og forvaltningsmæssigt formål [afventer] Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart [afventer] Forudsætninger for produktionssætning af integration systemspecifikt [afventer] Forudsætninger for drift systemspecifikt [afventer] Øvrige forhold Håndtering tekstfelter Jf. afsnit indeholder snitfladen en række tekstfelter, hvor der er fastlagt en teknisk maksimal længde. Nærværende debitorsystem kan hhv. lagre og vise følgende tekstlængder: Dataelement Max antal tegn fra tekststregen, som debitorsystemet kan: Ved ændring i lagring angives besked herom i Forretningssvar, Information- Årsag Note (X) Lagre i sin database Vise i brugerdialog Medtage på udskrift AdministratorGLNNummer [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] AdresselinjeTekst [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] BilagFilnavn [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DebitorFinansInfoFinanskontonummer [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DebitorFinansInfoFinanskontonummerkode [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DebitorkontoDebitorkontoIdentifikation [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DebitorSpecifikationVærdi [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DelfordringReguleringÆndringÅrsagTekst [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] DelfordringSpecifikationVærdi [Debitor] [Debitor] [Debitor] [Debitor] [Debitor] KOMBIT A/S Halfdansgade København S CVR Side 31 af 58