Integration SF1590_B_01_V3 Afsend debitorregistrering til Debitor Integrationsbeskrivelse - version 3.8.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 SPver KDI WSDL SOAP-action fejl rettet. Udgivet KDI Version er en intern version, omfattende fejlrettelse af SOAP-action. Den er lagt ind i den eksterne version 3.6.0, Der er foretaget flg. yderligere rettelser og tilføjelser: Rettelse af versioneringsværdi i Hovedoplysninger Præcisering af anvendelse af reference klasser, Sortiment Udvidelse af forretningssvaret ifm. operationen ForetagIndbetaling samt definition af restance. Afledt rettelse til operationen SøgDelfordringTilIndbetaling Struktur for de enkelte operationer er blevet gennemgået for at sikre konsistens ift. SF1590_B_02_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. Udgivet KDI [Bilag], [Servicestrukturrapport]: SOAPAction i WSDL er rettet til kun at benytte US-ASCII tegnsæt. KOMBIT A/S Halfdansgade København S CVR Side 2 af 57

3 Referencer Ref. Titel Kommentarer [GVF] Integration Generelle vilkår og forudsætninger Generelle vilkår og forudsætninger.pdf Findes her: 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. [Hovedoplysninger] [Bilag] Samler bilag, som knytter sig til integrationen. [Informationsmodel] Samlet informationsmodel for håndtering af dataudveksling med debitor, dvs. debitorsystemer. [Servicestrukturrapport] [ØiR Klassifikation] Findes her: Transaktionsspor og Fejlbehandling ved servicekald Transaktionsspor og Fejlbehandling ved servicekald.pdf Findes her: Bilagssamling til integrationsbeskrivelsen Bilag zip Findes her: under området Økonomi eller direkte med reference til SF1590_B_01_V3 ØiR Debitor Informationsmodel SF1590_B_V3 - ØiR Debitor - Informationsmodel pdf Findes her: [Bilag] Afsend Debitorregistrering til Debitor Servicestrukturrapport SF1590_B_01_V3 Afsend Debitorregistrering til Debitor - Servicestrukturrapport pdf Findes her: [Bilag] ØiR Klassifikationssystemet Findes her: i mappen STS Klassifikationer/Økonomi Fælles datastruktur for services udstillet på Serviceplatformen. Indgår i servicens input og output payload 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 3 af 57

4 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 anvendersystem 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 4 af 57

5 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 søge og hente debitorregistreringer, foretage indbetalinger, gennemføre ejerskifte m.m. 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 svarer med en kvittering med accept eller afvisning af dataoverdragelsen. 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, både 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. Integrationen håndter tre typer af debitorregistreringer: Debitorkonti, Indbetalinger og Parameteropsætning i debitorsystemet. Debitorsystemet autoriserer om fagsystemet har tilladelse til at foretage oprettelse eller fremsøgning af debitorregistreringer. Dernæst valideres data af debitorsystemet for, om data overholder det aftalte format og indeholder valide informationer. Debitorsystemet skal herved sikre sig, at det kan viderebehandle leverancen og dermed overtage dataansvaret herfor. 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]. 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. KOMBIT A/S Halfdansgade København S CVR Side 5 af 57

6 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: urn: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 6 af 57

7 Debitorsystem Serviceplatfom ØiR-service Fagsystem Integrationsbeskrivelse Diagrammer for forretningsflow Debitorregistrering flow Straksleverance Afsend Anmodning Modtag svar Modtag Anmodning Afsend svar Valider serviceanmodning Fejl Dan negativt svar HovedOplysningSvar Modtag forretningssvar Ok Gennemstil Anmodning Modtag Anmodning Valider/ fremsøg Send forretningssvar Figur 1 Debitorregistrering flow - Straksleverance Valg af integrationsmønster Straksleverance af debitorregistreringer foregår med synkrone webservicekald. Kaldet er begrænset ift. den datavolumen, som kan overføres mellem fagsystem og debitorsystem. Begrænsningen er gjort for at sikre den nødvendige performance og driftsstabilitet i fagsystem, debitorsystem samt på Serviceplatformen. KOMBIT A/S Halfdansgade København S CVR Side 7 af 57

8 Som alternativ til straksleverance kan der vælges integrationen for masseleverance. Denne leveranceform foregår via filtransport (Serviceplatformens SFTP-service) og er asynkron i sin natur. Det er ikke alle operationer, som er tilgængelig under masseleverance. Afsend (Straksleverance) Overfør (Masseleverance) : SF1590_B_01_V3 : SF1590_B_02_V 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 ) 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. KOMBIT A/S Halfdansgade København S CVR Side 8 af 57

9 1.2.6 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. 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 Indbetaling på krav Integrationen giver mulighed for, at der fra et fagsystem kan foretages en indbetaling på krav, som er registreret i kommunens debitorsystem. Krav kan omfatte både fordringer og rater på betalingsaftaler. Debitorsystemet udstiller de krav, som der kan foretages indbetaling på. Fagsystemet, det betalende it-system, vurderer ud fra egen faglovgivning, om der er hjemmel til at foretage en betaling fx med et tilhørende træk i en ydelse. Indbetaling kan ske på tværs af ejerskab til debitorkonti og mellem myndigheder. KOMBIT A/S Halfdansgade København S CVR Side 9 af 57

10 Ifm. indbetaling skal der foretages bogføring fra både fagsystemet og debitorsystemet. Integrationen understøtter, at fagsystemet kan fremsøge mulige krav til indbetaling. Da der er tale om en online operation, vil den være uhensigtsmæssig at anvende den ifm. gennemgang af mange mulige betalere under en kort tidshorisont, som fx en månedskørsel. I stedet bør der benyttes adviseringsmuligheden beskrevet i SF1590_H Adviser om krav til ekstern indbetaling. Et fagsystem vil kunne bruge følgende tilgang: 1) I forbindelse med oprettelse af en sag i fagsystemet benytter fagsystemet fremsøgningsoperationen under nærværende integration i processen oplysning af sagen. 2) Samtidig opdaterer fagsystemet sit beskedabonnement om advisering om krav til ekstern betaling med denne borger/sag. Fagsystemet har herved etableret en baseline med tilhørende løbende opdatering 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) Dog gælder ifm. anvendelse af indbetalingsoperationen, at fagsystemet særskilt kan angive den registreringskonto, som skal debiteres indbetalingen 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. 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 (fagsystem) har valgt at benytte abonnerer på. Det betyder, at der for hvert KOMBIT A/S Halfdansgade København S CVR Side 10 af 57

11 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. Sortimenter dækker både sortimenter ift. de myndigheder, som benyttet et tilsluttet fagsystem, samt debitorsystemets eget sortiment for den debitoransvarlige myndighed, såfremt et sådant sidstnævnt 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 Tilgængelighed Spidsbelastningsperiode Servicevinduer 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. 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 KOMBIT A/S Halfdansgade København S CVR Side 11 af 57

12 og Infrastruktur (KDI). Spørgsmål vedr. specifikation sendes til KDI 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. 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 service 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, kdi@kombit.dk. Omfang af fagsystemets end-to-end test fastlægges af fagsystemet. 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. KOMBIT A/S Halfdansgade København S CVR Side 12 af 57

13 Ifm. Serviceplatformens tilslutning af servicen til det enkelte kildesystem aktiverer Serviceplatformen sin overvågning af servicen via dennes overvågningsoperation. Et succesfuldt resultat her angiver, at der er hul-igennem. For at risiko-mitigere det enkelte fagsystem produktionssætning af en myndigheds anvendelse er det anbefalingen, at fagsystemet i produktion aktiverer en verifikationstransaktion, nul-sumspostering. 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 Den planlagte test af services til installation på Serviceplatformen omfatter pt., at der udfører automatiserede tests af services og unittests. Der er tale om en robust test af sikkerhed, routing og anden kernefunktionalitet i integrationen, samt mere en simpel test af, om de enkelte operationer kan benyttes, stikprøvekontrol. Testen omfatter ikke samtlige dataelementer i operationerne. Leverandøren af Serviceplatformen er ansvarlig for denne test Testfaciliteter og testmiljø Der er etableret simple testdrivere og teststubbe for simulering af fagsystem og kildesystem Testdata Tekniske testdata, som ikke nødvendigvis reflekterer en konkret forretningsmæssig anvendelse 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 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. KOMBIT A/S Halfdansgade København S CVR Side 13 af 57

14 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 (se afsnit for yderligere information) til brug for test Kildesystem - Tilslutningstest For de debitorløsninger, som har decentral drift, tilbyder KDI 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. KOMBIT A/S Halfdansgade København S CVR Side 14 af 57

15 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 fagsystems perspektiv har samme resultat. On the fly Debitorregistreringerne opgraderes til integrationens krav, når de aktiveres af et fagsystem. 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 fagsystemer 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. KOMBIT A/S Halfdansgade København S CVR Side 15 af 57

16 1.5.1 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 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 (anvendersystem) 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. KOMBIT A/S Halfdansgade København S CVR Side 16 af 57

17 1.6.2 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 57

18 2 Kontekst for integrationsparter 2.1 Kontekst fælles for anvendersystem 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 Dataansvarlig myndighed for fagsystemet skal oplyse det modtagne it-system-instans Koordinering Fagprojektet/Central Fagprojektet/ Central Fase 2.1 TS102 TS103 Fagsystemet skal være oprettet i STS Administrationsmodul Udarbejd et fælles fagspecifikke datagrundlag for anvendelse af [ØiR Klassifikation] Konfiguration Koordinering STS Administration Leverandør af fagsystem Leverandør af fagsystem ØiR Klassifikation Fagprojektet/Central Fagprojektet/ Central Fase 2.1 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 TS105 Opret fagsystemets sortiment i [ØiR Klassifikation] Konfiguration ØiR Klassifikation Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS103 skal være gennemført, da fagsyste- KOMBIT A/S Halfdansgade København S CVR Side 18 af 57

19 ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar mets 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 Fagsystemet skal have etablere til STS Token Service. Konfiguration STS Administration Leverandør af fagsystem Leverandør af fagsystem Fase 2.2 Når fagsystemet følger standarden om Tokenbaseret sikkerhed TS108 Fagsystemet skal have registreret certifikat, som benyttes ifm. autorisationen af fagsystemets servicekald Konfiguration STS Administration Leverandør af fagsystem Leverandør af anvendersystem Fase 2.2 Kun såfremt fagsystemet benytter certifikat baseret sikkerhed TS109 Anmodning om Serviceaftale for dataansvarlig myndighed i fagsystemet Konfiguration STS Administration Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS110 Dataansvarlig myndighed for fagsystemet skal godkende serviceaftale for integrationen Konfiguration STS Administration Fagprojektet/Central Dataansvarlig myndighed for fagsystemet Fase 2.2 TS111 Debitoransvarlig myndighed skal godkende serviceaftale f integrationen Konfiguration STS Administration Fagprojektet/Central Debitoransvarlig myndighed Fase 2.2 Kun såfremt debitoransvarlig myndighed ikke er den samme som KOMBIT A/S Halfdansgade København S CVR Side 19 af 57

20 ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar dataansvarlig for fagsystemet. Forudsætter TS100 TS112 Bestil routing af fagsystemet servicekald til det relevante debitorsystem Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 Skal gennemføres pr. dataansvarlig myndighed, som benytter fagsystemet. TS113 Bestil abonnement på sortiment til fagsystemet Konfiguration ØiR Klassifikation Fagprojektet/Central Fagprojektet/Central Fase 2.2 Forudsætter TS105 TS114 Bestil SFTProuting af sortimentet til fagsystem Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 Forudsætter TS105 TS115 Bestil overvågning af fagsystemets SFTPbruger ift. sortimentsmodtagelse Konfiguration Serviceplatformen Fagprojektet/Central Fagprojektet/Central Fase 2.2 TS116 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 Administration under dobbeltmyndighedsgodkendelse. KOMBIT A/S Halfdansgade København S CVR Side 20 af 57

21 TS101 - 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. TS102 - Fagsystemet skal være oprettet i STS Administration. 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 - Fagsystemet skal have etableret federation til STS Sikkerhed ifm. standarden Token-baseret sikkerhed. TS108 - Fagsystemet skal have registreret certifikat, som benyttes ifm. autorisationen af fagsystemets servicekald ifm. certifikatbaseret sikkerhed. Som det er nu, så vil alle fagsystemer skulle gøre det ifm. deres registrerings på STS Administrationsmodul. TS109 - I STS Administration skal der oprettes en anmodning om indgåelse af serviceaftale for myndighedens brug af integrationen, SF1590_B_01_V3. Anmodningen skal indeholde angivelse af Debitoransvarlig myndighed. TS110 - Dataansvarlig myndighed for fagsystemet skal godkende anmodning (TS109) om serviceaftale for snitflade jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. TS111 - Debitoransvarlig myndighed skal godkende serviceaftale for integrationen (TS109), hvis dataansvarlig myndighed for fagsystemet er forskellig fra Debitoransvarlig myndighed. KOMBIT A/S Halfdansgade København S CVR Side 21 af 57

22 TS112 - Integrationen skal konfigureres med routingsinformations mellem fagsystemet og myndighedens debitorsystem. Det sker som en bestilling til Serviceplatformens Help Desk. TS113 - Bestil abonnement på sortiment til fagsystemet. Det sker via KDI, TS114 - Bestil routing af sortimentet fra ØiR Klassifikationssystemet til fagsystem. Det sker som en bestilling til Serviceplatformens Help Desk. TS115 - Der skal bestilles overvågning af fagsystemets SFTP-bruger ift. modtagelse af sortimenter og klassifikationer fra ØiR Klassifikationssystemet. Det sker med brug af skabelonen [SFTP-FS]. Det sker som en bestilling til Serviceplatformens Help Desk. TS116 - 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 57

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 Debitorsystem Debitor ansvarlig myndighed Debitor ansvarlig myndighed STS Administration 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 Tilslutning af Serviceplatformens adgang til debitorsystemets services Konfiguration Debitorsystem Leverandør af debitorsystemet Leverandør af debitorsystemet Fase 2.1 TS204 Opsætning af tilladelse til modtagelse af data fra et givent fagsystem Konfiguration Debitorsystem Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Udførende afhænger af den aftale arbejdsdeling mellem leverandøren af debitorsystemet og myndigheden KOMBIT A/S Halfdansgade København S CVR Side 23 af 57

24 ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS205 Bestil abonnement på fagsystemets sortiment til debitorsystemet Konfiguration ØiR Klassifikation Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Forudsætter TS105 TS206 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 TS207 Bestil SFTProuting af sortimentet til debitorsystemet Konfiguration Serviceplatformen Debitor ansvarlig myndighed Debitorsystem Central Administrator eller Lokal Fase 2.2 Forudsætter TS105 TS208 TS209 Bestil overvågning af debitorsystemets SFTP-bruger ift. sortimentsmodtagelse Etablere omsætningstabeller i debitorsystemet Konfiguration Serviceplatformen Konfiguration Debitorsystem Debitor ansvarlig myndighed Debitorsystem Lokal Debitor ansvarlig myndighed Debitorsystem Lokal Fase 2.2 Fase 2.2 TS210 Drift Gennemførelse af Produktionsverifikationstest Debitorsystem Fagsystemet: Fagprojektet/Central Debitorsystem Lokal Fase 3 Optionelt KOMBIT A/S Halfdansgade København S CVR Side 24 af 57

25 TS200 - Debitoransvarlig myndighed skal indgå aftale om anvendelse af den snitflade i debitorsystemet, som integrationen anvender TS201 - Debitorsystemet med relevante endpoints skal oprettes i STS Administration, herunder skal der angives den anvendte sikkerhedsmodel (Token- eller certifikatbaseret sikkerhed). Der skal endvidere angives kontaktoplysninger ift. support mv. TS202 - Opdatering af instruks for databehandling, der angiver modtagelse af data for et givent fagsystem TS203 - Serviceplatformen skal foretage den tekniske konfiguration af Serviceplatformens adgang til debitorsystemets services, herunder verificere hul-igennem gennem opsætning og ibrugtagning af operation Ping. TS204 - I debitorsystemet skal det angivelse, at der er givet tilladelse til modtagelse af data fra et givent fagsystem pva. af en bestemt myndighed. Disse informationer indgår i den initiale leverancekontrol, om dataudveksling er tilladt. TS205 - Der skal bestilles debitorsystemets abonnement på sortiment for det specifikke fagsystem. Det sker via KDI, TS206 - Bestil debitorsystemets abonnement på klassifikationer og debitorsystem specifikke sortimenter til debitorsystemet. Det sker typisk ifm. første anvendelse af integrationen. Det sker via KDI, TS207 - Bestil routing af sortimentet og evt. klassifikationer fra ØiR Klassifikationssystemet til fagsystem. Det sker som en bestilling til Serviceplatformens Help Desk. TS208 - Der skal bestilles overvågning af debitorsystemets SFTP-bruger ift. modtagelse af sortimenter og klassifikationer. Det sker med brug af skabelonen [SFTP-DS]. Det sker som en bestilling til Serviceplatformens Help Desk. TS209 - 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. TS210 - 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 25 af 57

26 KOMBIT A/S Halfdansgade København S CVR Side 26 af 57

27 2.3 Kontekst for KY, KSD Faserne følger afsnit 1.6. 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 27 af 57

28 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 28 af 57

29 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 29 af 57

30 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 30 af 57