Integration SF1590_B - ØiR - Afsend debitorregistrering til ØiR (Debitor) Integrationsbeskrivelse - version 2.8.0

Transkript

1 Integration SF1590_B - ØiR - Afsend debitorregistrering til ØiR (Debitor) Integrationsbeskrivelse - version Kommunernes Datafællesskab - KDF

2 Versionshistorik Relevans Dato Initialer Version Kommentarer pmu Første version mmt Opdateret wsdl mmt Leverance opdelt i tre former: Straks-, volumen-, masseleverance Tilpasninger ift. begrebsmodel. Suppleret med operationsmodel for straksleverancen. Ny beskrivelse, dertil også ny wsdl for Serviceplatform samt ERP-leverandør mmt SFTP-triggerfil model valg. Validering og fejlhåndtering ifm. masseog volumenleverancer præciseret Afsnit om triggerfil ændret. Oplæg til revideret udgave af triggerfil slettet. Det er afsnit 3.x mmt Beskrivelsen er blevet præciseret og korrigeret på en række områder. Fejlrettelser - Præciseringer, primært ift. kapitel 4, som omfatter interne krav til Serviceplatformen. - Begrebsmodel så juridisk ansvarlig forholdet ikke kan periodiseres. To begrebsnavne er præciseret. - Præciseret at masse- og volumenleverance alene understøtter opret-operationer. - Sikkerhedsafsnit for debitorsystemet er præciseret. - Beskedkurvet, tilføjet værdisæt herunder reference til myndighed til brug for revisionsspor. - Operation for SøgDelfordringTilIndbetaling er korrigeret ift. restanceopgørelse. - Tilføjelse af personfølsomhedsangivelse, så dataoverdragelse kan sikres ift. Persondataloven. - Håndtering af tekstfelter med teknisk maksimal længde. Hvor muligt er format af testfelter mv. præciseret yderligere. Ændring - Tilføjelse af reference på Delfordring til kreditorposterings kontonummer aht. Ydelsesrefusion Endvidere er den forretningsmæssige anvendelse af integrationen i hhv. anvender- og debitorsystem blevet præciseret uden ændring af de berørte snitflader. - Afsnit Beskrivelse af livscyklus og ejerskab af de forskellige debitorobjekter - Afsnit 3: Operationer er udvidet med funktionalitetsbeskrivelser [WSDL-SP] og [WSDL-EXT] er opdateret i overensstemmelse med ovennævnte SCH [Begrebsmodel] ændret versionsnummer til så den følger versionering af arbejdsversionerne. KOMBIT A/S Halfdansgade København S CVR Side 2 af 112

3 [WSDL-EXT]: i xsd og wsdl er namespaces ændret fra til når der er tale om elementer, der er specifikke for ØiR. XSD for forretningskvittering justeret (se også afsnit ). Rettet navn for alternativ adresse struktur i opret. Fjernet primær dimension på kontering ift. delfordring. Navngivning af leverance og kvittering er gjort specifik for debitor. Fjerne $ og ^ i enummerering Indsat reference [Valideringsflow] omhandler valideringsregler ifm. modtagelse af dataleverancer og forretningskvitteringer. Supplering af referencer under [ØiR Klassifikationssystem] Indsat reference [GVF] der omhandler generelle vilkår og forudsætninger. Afsnit 1.5 er skrevet om. Alle afsnit i forudsætninger for brug af snitfladen er udbygget, baseret på en standard skabelon, brugt i de andre integrationsbeskrivelser PSK [WSDL-EXT]: Afsnit og Triggerfil: Rettet så den følger seneste release på Serviceplatformen. Indholdsmæssig uændret. Den komplekse type Forretningskvittering er omdøbt til DebitorForretningskvittering og derved gjort unikt jho [WSDL-EXT], følgende fejlrettelser/præciseringer: LeverancedataAfgivendeITSystem ændret til UUID (var forkert i WSDL). Udvidelse af indbetaling. Indbetaling påføres ID (UUID) og reference (UUID) til anden indbetaling [Begrebsmodel] Udvidelse af indbetaling. Indbetaling påføres ID (UUID) og reference (UUID) til anden indbetaling Triggerfilens FileContentDescriptorType, der indeholder routing information er ændret, så RecipientIt-system er beskrevet. SenderIt-system er altid det system, som er afsender af en leverance RecipientIt-system er altid det system, som skal modtage en leverance Udfyldelse af FileContentDescriptorType er konsekvensrettet i beskrivelse af EP_FS3 og EP_DS3 Integrationsflow IF04: Forretningskvittering Volumenleverance er også konsekvensrettet. KOMBIT A/S Halfdansgade København S CVR Side 3 af 112

4 SFTP-bruger for modtager er rettet til [ØiR] i triggerfiler Brug af konfigurationstabel ifm. SFTP-routing er beskrevet. Routing baseres på konfigurationstabel og indhold i Triggerfil. Afvisning Tidligere modtaget indført som afvisning af leverance. Redaktionelle præciseringer jho [WSDL-EXT], følgende fejlrettelser / præciseringer: Nye felter Opkrævningsoplysniger med identifikation af Betalingsmåde, følger OIOUBL og erstatter Betalingsreference. Outputfiler på søg og hent service tilføjet forretningskvittering. Afslutningsdato på Ligestillingspartner er ikke længere mandatory. Feltet KontaktinformationPersonId bør er gjort mandatory, idet feltet skal udfyldes hvis man vil aflevere kontaktinformation til den elektroniske faktura hvilket stadig er optionelt. Namespaces er ændret til urn-model. Reference til Serviceplatformens namespaces for operationer er ændret til KDI s egne namespaces. WSDL leveres nu i to former én, der defineres SAML-baseret interaktion og én der definerer Certifikatbaseret interaktion. Den SAML-baserede interaktion er under afklaring og det må fortes at der kommer ændringer til denne. [Begrebsmodel] Nye felter Opkrævningsoplysniger med identifikation af Betalingsmåde, følger OIOUBL og erstatter Betalingsreference. Sikkerhedsmodel justeret så, FOCES certifikater kan anvendes SFTP filnavne ajourført i overensstemmelse med [SFTP] SFTP Routing ajourført i IF03 og IF04, så UC1 baseret SFTP dynamisk routing er afspejlet JJN Mindre ændringer til kapitler om Vilkår og forudsætninger: - Kapitel 2.1.3: Serviceaftale er tilrette til dobbelt myndighedes (TS110, TS111) og post konfiguration parameter for SFTP er slette, da de kommer implicit med SystemID (TS112) Kapitel 2.2.3: Serviceaftale for dobbelt myndighedsgodkendelse tilføjet (TS206, TS207), og aktivitet for mapning mellem fælles og lokal kontoplan (TS205). Kapitel 4.1.6: I post konfig trin er parameter for SFTP slettet, og parameter for rutning og serviceaftaler er slået sammen (TSP02 opdateret og TS208 slettet). Enkelte redaktionelle præciseringer angående datafil og triggerfil i IF03 og IF04 end points JJN Forudsætninger og vilkår er ændre for følgende aktiviteter: KOMBIT A/S Halfdansgade København S CVR Side 4 af 112

5 JHO [WSDL-SP]: - TS100 og TS209 er nye aktiviteter og omhandler henholdsvis kommunal bestilling af integration hos leverandør af debitorsystem, og debitorsystemets adgang til STS klassifikation. - Omformulering af TS103, TS104 og TS209 Reference til Serviceplatformens WSDL for version 2.7 er påført JHO [WSDL-EXT]. Som konsekvens af tilbagemelding fra leverandører er følgende mindre rettelser indkorporeret: Afvist Tidligere Modtaget er nu gyldigt Kvitteringsresultat i Debitorkvittering. PartID-felter er nu ikke længere en URN og er ikke omfattet af restriktioner. PartIDType indeholder den klassificerede type. MaterialemodtagerAlternativAdresseStruktur er nu krævet på MaterialemodtagerAlternativAdresse objekt. I operation SoegDebitorregistrering er Debitorkontoidentifikation gjort optionelt og tilføjet en Debitorkontoidentifikation.Type [SFTP] Opdateret reference til aktuelle version Rettelse af fil ekstensions jf. [SFTP] <any> felt i SFTP FileContentDescriptor erstattes af <SFTPDynamicRoutingInfo> felt i triggerfil. [Valideringsflow] Ny release [ØiR Klassifikationssystem] Ny release Referencer Ref Titel Kommentarer [SPref] [SFTP] [SF1460 _A] [SF1460 _C] [SF1460 _D] Se Note vedrørende servicemål for Serviceplatformen.pdf på følgende link: Modtag besked. Se integrationsbeskrivelse for SF1460_A, som er tilgængelig her: Aflever besked Se integrationsbeskrivelse for SF1460_C, som er tilgængelig her: Beskrivelse af SFTP service på Serviceplatformen Modtag besked via pull. Se integrationsbeskrivelse for SF1460_D, som er tilgængelig her: Beskrivelse for Beskedfordeleren Beskrivelse for Beskedfordeleren Beskrivelse for Beskedfordeleren KOMBIT A/S Halfdansgade København S CVR Side 5 af 112

6 Ref Titel Kommentarer [WSDL- SP] [WSDL- EXT] WSDL-fil for services udstillet af ERP-systemer. [Begrebsmodel] [ØiR Klassifikationssystem] [GVF] Generelle vilkår og forudsætninger, der skal være på plads før Snitflader kan anvendes: Generelle vilkår og forudsætninger [Valideringsflow] Reference [Valideringsflow] omhandler valideringsregler ifm. modtagelse af dataleverancer og forretningskvitteringer, herunder præcisering af forretningsregler for dataudvekslingen. [ROU- TING] SF1590_B Teknisk Spec ÅÅÅÅMMDD.zip placeret her: SF1590_B Bilag zip placeret her: [WSDL-EXT] i undermappen Begrebsmodel. Placeret her: [WSDL-EXT] i undermappen Klassifikationssystem. Placeret her: I datormådet for Økonomi i Rammearkitekturen findes klassifikationerne eksemplificeret i med brug af regneark ØiR Klassifikationssystem v rev zip : - ØiR Klassifikationssystem - ØiR Domain Finans - ØiR Domain Debitor - ØiR Domain Finans KY - ØiR Domain Debitor KSD - Indenrigsministeriets Kontoplan - STS - Følsomhed [Valideringsflow] findes i Dataområdet Økonomi i Rammearkitekturen. Placeret her: : ØiR Debitor Valideringsflow v pdf. zip-filen [WSDL-EXT] indeholder en SFTPDynamicRoutingInfo.xsd WSDL-fil for services udstillet på Serviceplatformen i denne forbindelse. Leveres senere af Serviceplatform Begrebsmodel for ØiR Debitorsnitfladen udarbejdet i Qualiware. Beskrivelse af del af ØiR Klassifikationssystemet, som fagsystemerne anvender til angivelse af værdier i Debitorsnitfladen. Indeholde en beskrivelse af, hvorledes debitorsystemet får adgang til hertil. Omtales også som Klassifikationssystemet ØiR Debitor. Schema til brug for dynamisk SFTP UC1 routing KOMBIT A/S Halfdansgade København S CVR Side 6 af 112

7 Indholdsfortegnelse 1 Overordnet beskrivelse Integrationens formål Overordnet forretningsflow i integrationen Servicebetingelser for den samlede integration Teststrategi Forudsætninger for produktionssætning Kontekst for integrationsparter Kontekst for KY, KSD [!@KY@!][!@KSD@!] Kontekst for Debitorsystem DS-X Kontekst for Debitorsystem DS-Y Kontekst for Debitorsystem DS-Z Specifikation for integrationsparter Specifikation af endpoints for Fagsystem [!@KY@!][!@KSD@!] Specifikation af endpoints for SP [!@SP@!] Specifikation af endpoints for Debitorsystem [!@DS@!] Beskrivelse for integrationsplatforme Beskrivelse for Serviceplatformen [!@SP@!] Noter vedr. beslutning, detaljer og andet Forudsætning Ændringer til SP SSE CCR - tilbud KOMBIT A/S Halfdansgade København S CVR Side 7 af 112

8 1 Overordnet beskrivelse 1.1 Integrationens formål ØiR Økonomi i Rammearkitekturen indeholder en række snitflader, som benyttes af fagsystemerne til at give en ensartet snitflade mod de bagvedliggende ERP-systemer til håndtering af finans-, debitor-, kreditorposteringer samt udbetalinger. Denne integration dækker debitorregistrering, dvs. fagsystemets aflevering af debitorregistrering til myndighedens debitorsystem. Debitorkontoen typificeres ved en fælles kommunal klassifikation. Det enkelte fagsystem fastlægger sine delfordringstyper. Tilsvarende gør sig gældende for 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 indebærer, at debitorsystemet skal sende forretningskvittering med accept eller afvisning heraf. Integrationen ændrer ikke på de debitorregistreringer, som overdrages. For det andet understøtter integrationen, at fagsystemet kan få dataoverdraget information om debitorregistrering i debitorsystemet, egne og andres debitorregistreringer. Debitorleveranceflowet begynder, når et fagsystem har en leverance til myndighedens debitorsystem. Leverancerne kan deles op i tre typer: Opret, Opdater og Forespørg. Med undtagelse af den ene søgeoperation af typen forespørg, er objektet for alle leverancer af debitorregistreringer knyttet til en debitorkonto. Fagsystemet kan levere data synkront, som straksleverance eller asynkront, volumenleverance og masseleverance. Fagsystemet kan vælge mellem straksleverance eller batch. I tilfælde af straksleverance skal debitorsystemet behandle forespørgslen vedrørende debitorregistreringen, medens fagsystemet venter på resultatet heraf (synkront). Ved batch håndterer debitorsystemet fagsystemets anmodning efter endt modtagelse af anmodning (asynkront). Der er to transportmodeller for batch, volumenleverance og masseleverance. Fagsystemet vælger transport model ud fra sine behov. Integrationen understøtter, at fagsystemet benytter alle tre transportmodeller. Antallet af debitorregistrering pr. kald vil af hensyn til performance være begrænset. Begrænsningen afhænger af, om der er tale om en straksleverance eller batch. Begrænsningen indgår som en del af integrationsaftalen og vil kunne ændres. I debitorsystemet valideres data for, om de overholder det aftalte format og indeholder valide data. Debitorsystemet skal herved sikre, 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 en forretningskvittering per leverance med kvitteringsstatus for debitorregistreringen. Ved forespørgsel på debitorregistreringer vil resultatet af validering og eksekvering af forespørgslen være et forretningssvar. KOMBIT A/S Halfdansgade København S CVR Side 8 af 112

9 Er der tale om straksleverance sker det som en gennemstilling af fagsystemets servicekald til en service udstillet af myndighedens debitorsystem. Debitorsystemet skal i sin respons angive om systemet kan acceptere dataoverdragelsen af debitorregistreringen. Dette kaldes her forretningskvittering, og fagsystemet vil således i responsen på servicekaldet modtage en sammensat transportog forretningskvittering. Hvis der er tale om en batch udstilles data til myndighedens debitorsystem på en SFTP-service i regi af Serviceplatformen. Debitorsystemet har herefter ansvar for at hente data. Fagsystemet vil her modtage en transportkvittering fra Serviceplatformen på leverancen af debitorregistreringer, Transportkvittering vil angive Serviceplatformens accept eller afvisning af modtagelse af debitorregistreringer til viderefremsendelse. Efterfølgende skal debitorsystemet afsende forretningskvittering for modtagne debitorregistreringer. Debitorsystemet afleverer sine forretningskvitteringer til SFTP-servicen i regi af Serviceplatformen. Fagsystemet kan her vælge enten at få levereret disse forretningsbeskeder via SFTP-servicen eller som beskeder via Beskedfordeleren. Sidstnævnte forudsætter, at fagsystemet har opsat et korresponderende beskedabonnement. Fagsystemet har ansvar for at sikre, at debitorregistreringer bliver overdraget til debitorsystemet. Dette ansvar ophører, når debitorsystemet positivt har accepteret dataovertagelsen af debitorregistreringen ved at fremsende en accepterende forretningskvittering til fagsystemet. Debitorservicen understøtter dataoverdragelse af supplerende posteringsinformation, så debitorsystemet kan foretage finansposteringen. Det skal konkret aftales for det enkelte omfang i hvilket omfang debitorsystemet skal foretage en sådan finanspostering, som om den foretages af fagsystemet selv. Samme debitorsystem skal kunne understøtte, at nogle fagsystemer vælger en tilgang medens andre fagsystemer en anden på denne opgave. Fagsystemet kan endvidere på den enkelte delfodring angive referencen til den primære konto, som den korresponderende kreditorpost er konteret under. Det skal blandt andet anvendes i forbindelse med Ydelsesrefusion, hvor debitorsystemet skal foretage indberetning med brug af denne reference til SKATs eindkomst Integrationens begreber Begrebsmodellen, der anvendes i integrationen, er dokumenteret i Qualiware, [Begrebsmodel]. Integrationen understøtter kommunikationen mellem et anvendersystem 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. AfgivendeIt-system Defineret i STS Organisation, som et it-system. Typisk vil det være et fagsystem, fx KY. Det kan også være en andet debitorsystem. Alias: Fagsystem, anvendersystem KOMBIT A/S Halfdansgade København S CVR Side 9 af 112

10 DebitorIt-system Defineret i STS Organisation, som et it-system. Typisk en del af en ERP-løsning. Alias: Debitorsystem, ERP-løsning, ERP-system AfgivendeMyndighed Defineret i STS Organisation, som myndighed. Den myndighed, som har dataansvar for datavideregivelse fra AfgivendeItsystem. Alias: kommune DebitoransvarligMyndighed Defineret i STS Organisation, som myndighed. Den myndighed, som har dataansvar for datamodtagelse i DebitorIt-system. Alias: kommune Forretningsmæssige begreber, livscyklus og ejerskab Der arbejdes med tre centrale begreber/objekter, derudover findes der en række andre begreber, som relaterer sig til de centrale begreber, som er angivet her: Debitorkonto o Parter Fordring o Opkrævningsoplysninger Delfordring o Indbetalinger o Hæftelse De forskellige objekter i debitor har egne livscyklus, som er vigtig at kende for at få den rigtige forståelse for, hvordan man arbejder med objekterne under de forskellige operationer. De forskellige objekter i debitor manipuleres med brug af serviceoperationer. En korrekt brug af integrationen forudsætter forståelse af serviceoperationerne i en forretningsmæssig kontekst. Det er ligeledes vigtigt at forstå, hvordan ejerforholdet til de forskellige objekter hænger sammen med operationernes virkemåde og begrænsninger her. I det følgende gennemgås livscyklus og ejerforhold for ovennævnte begreber. I afsnit 3 findes en uddybende beskrivelse af forhold for de enkelte operationer Livscyklus De tre hovedobjekter kan hver for sig være i forskellige tilstande gennem deres livscyklus. De underliggende relaterede objekter følger samme tilstand, som det hovedobjekt de tilhører. Som udgangspunkt er der tale om tre overordnede stadier. I følgende diagrammer er de sorte pile input fra snitfladen, de røde er tilstandsændringer foretaget af debitorsystemet. Såfremt en input eller tilstandsændring er understøttet af integrationens services, da vil der være angivet referencen til operationen. Services og operationer er nærmere beskrevet i afsnit 3. KOMBIT A/S Halfdansgade København S CVR Side 10 af 112

11 Aktiv Arkiveret Slettet Aktiv Alle objekter, som snitfladens operationer kan manipulere, skal være i denne tilstand. Tilstanden kan yderligere opdeles i undertilstande. Arkiveret Objekter, som er arkiveret, kan snitfladen ikke længere arbejde direkte med. Hvis snitfladen skal arbejde med et objekt, som er arkiveret, skal objektets tilstand ændres til aktiv. Slettet Objekter, som er slettet, kan ikke gøres aktivt, og kan derfor ikke håndteres af integrationens snitflader Debitorkonto Alle objekter i debitorsystemet afhænger af, at der er oprettet en Debitorkonto. Ingen andre objekter kan oprettes uden reference til en tilhørende Debitorkonto. Modsat kan en Debitorkonto godt eksistere uden, at der eksisterer tilknyttede Fordringer, Delfordringer mv. En debitorkonto oprettes i den aktive tilstand Oprettet. Debitorkontoen kan ikke have andre aktive tilstande. Hvis der efter et givet stykke tid ikke har været aktivitet, og debitorsystemet heller ikke forventer yderligere aktivitet på debitorkontoen, kan/vil den blive arkiveret eller slettet. Hvis en debitorkonto arkiveres eller slettes, gælder det også for alle andre objekter, som hører under Debitorkontoen. Hvis Debitorkontoen gøres aktiv efter at have været arkiveret, kan det gøres med eller uden fordringer. OP01 Opret Oprettet Arkiveret Slettet KOMBIT A/S Halfdansgade København S CVR Side 11 af 112

12 Fordring Fordringen samler Delfordringer med samme forfaldsdato. Fordringen holder også opkrævningsoplysningerne, som er fælles for Delfordringerne. Fordringen kan oprettes i en af tre aktive tilstande Afvent opkrævning, Klar til opkrævning og Opkrævet. For alle aktive tilstande gælder det, at hvis der efter et givent stykke tid ikke har været aktivitet og debitorsystemet heller ikke forventer yderligere aktivitet på en Fordring, så kan/vil den blive arkiveret eller slettet, såfremt alle delfordringer er dækket. Hvis en Fordring arkiveres eller slettes, gælder det også for alle andre objekter, som hører under Fordringen. Hvis Fordringen gøres aktiv efter at have været arkiveret, skal det gøres med alle Delfordringer. Afvent opkrævning Når en Fordring ikke er klar til opkrævning, er den blot oprettet i debitorsystemet og der gøres ingen tiltag til at opkræve udeståendet. Denne tilstand vil fx. blive brugt i forbindelse med tilbagebetalingspligtige ydelser, som ikke skal opkræves før ydelsen ophører. Klar til opkrævning Når en fordring er klar til opkrævning, påbegynder debitorsystemet dannelsen af opkrævningsmaterialet. Opkrævet Fordringen er opkrævet, når opkrævningen er udsendt. KOMBIT A/S Halfdansgade København S CVR Side 12 af 112

13 OP01 Opret OP06 RetTilstand OP01 Opret OP01 Opret Afvent opkrævning Klar til opkrævning Opkrævet Arkiveret Slettet Delfordring Der findes to slags Delfordringer. Den ene holder et krav, den anden er en negativ regulering af et krav. En negative regulering arver efter oprettelsen den samme tilstand som den Delfordring, som den regulerer. En Delfordring kan enten blive dækket eller sendt til inddrivelse. Indbetalinger fordeles på Delfordringer. OP01 Opret Oprettet Dækket Sendt til inddrivelse Arkiveret Slettet Oprettet KOMBIT A/S Halfdansgade København S CVR Side 13 af 112

14 Så længe en Delfordring er i tilstanden Oprettet, har kommunen et krav mod en debitor. Summen af negative reguleringer og indbetalinger overstiger ikke Delfordringens krav. Delfordringen ændrer ikke tilstand af, at der ikke betales til tiden. Sendt til inddrivelse Delfordringen er sendt til inddrivelse hos SKAT. Debitorsystemet tilskriver ikke yderligere renter eller gebyrer, og der gøres ingen yderligere tiltag for at opkræve kravet. Såfremt en Delfordring trækkes tilbage fra SKAT inddrivelse eller gælden er inddrevet af SKAT, da vil den skifte status til Oprettet. Dækket Når summen af indbetalinger og negative Delfordringer er lig beløbet på kravet, så er Delfordringen dækket. En Delfordring kan godt være delvist betalt uden at være dækket. Selvom en delfordring er dækket, kan der godt oprettes nye negative Delfordringer, som refererer til den oprindelige Delfordring. Derved vil summen af indbetalinger og negative Delfordringer overstige det oprindelige beløb. Dette vil resultere i en forretningsgang, som bestemmer, hvad der skal gøres med de overskydende penge, Delfordringen vil ikke skifte tilstand Ejerskab Registrering af ejerskab har to funktioner. For det første, så angiver det hvilket it-system, som er ansvarlig for et objekts informationsindhold og dermed en del af it-revisionsspor. For det andet indgår ejerskab som en del af autoriseringen af integrationens serviceoperationer, dvs. hvilke begrænsninger ejerskabet sætter for det videre arbejdet med objekterne. Hvis et objekt fejlagtigt er oprettet eller indeholder fejl, kan det ikke annulleres eller ændres. Der oprettes nye objekter, som kompenserer for fejlene. Debitorkonto Debitorkontoen er det øverste objekt i hierarkiet, derfor vil det altid være skabt af et anvendersystem, som kan være et fagsystem eller debitorsystemet selv. Parter Parter kan udelukkende redigeres af den, som ejer debitorkontoen. Fordring Fordringer kan oprettes af ejeren af debitorkontoen og debitorsystemet selv. Fordringer oprettet af debitorsystemet, hvor debitorsystemet ikke er ejer af debitorkontoen, vil oftest være renter og gebyrer. Opkrævningsoplysninger Opkrævningsoplysningerne oprettes som hovedregel af debitorsystemet. I enkelte tilfælde er opkrævningen allerede udskrevet ved oprettelse af fordringen (fx p-afgifter). Her vil opkrævningen være oprettet af anvendersystemet, p-afgift-systemet. KOMBIT A/S Halfdansgade København S CVR Side 14 af 112

15 Delfordring Debitorkontoens ejer kan oprette Delfordringer under Fordringer, som denne også ejer. Debitorsystemet kan oprette Delfordringer under Fordringer, som ejes af Debitorsystemet ejer, dvs. uden krav om ejerskab til Debitorkontoen. Debitorsystemet kan også oprette regulerende Delfordringer under Fordringer, de ikke ejer. Indbetalinger Indbetalinger vil altid være oprettet og ejet af debitorsystemet. De kan være foretaget på anmodning af et anvendersystem. Hæftelser Hæftelser er oprettet og ejet af ejeren af Debitorkontoen 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 jf. afsnit Resultatet af valideringsprocessen er debitorsystemet accept eller afvisning af dataoverdragelsen. Debitorsystemet accept eller afvisning er per debitorregistrering. Omfatter en debitorregistrering oprettelse af en debitorkonto med tilhørende fordringer og delfordringer og fejler blot en af disse afvises den samlede debitorregistrering. Debitorsystemet skal validere samtlige elementer i debitorregistreringen og give et samlet svar i forretningskvitteringen. En forretningskvittering omhandler altid én og kun én debitorregistrering. Svar på debitorregistreringer kan fordeles over flere forretningskvitteringer omhandlende samme leverance. Et svar på en debitorregistrering kan ikke splittes over flere forretningskvitteringer. I forbindelse med straksleverance skal valideringen gennemføres i selve forespørgselssessionen. I forbindelse med batch foretages valideringen asynkront. Debitorsystemet skal i videst muligt omfang undgå at foretage afvisninger, hvor årsagen ligger i debitorsystemet. Debitorsystemet skal have en tidsmæssig mulighed for at foretage korrigerende tiltag i egne data, opsætninger og eventuelle regler for mapning. Fagsystemet har behov for, inden for en kort tidsramme, at kende status på overdragelsen af debitorregistreringen. Der vil i servicemål for integrationsaftalen være fastlagt tidsrum for debitorsystemets fremsendelse af forretningskvittering. Indtil fagsystemet har modtaget accept på samtlige debitorregistrering er, skal fagsystemet kunne genfremsende debitorregistreringen. Der vil typisk være tale om en manuel supportproces. KOMBIT A/S Halfdansgade København S CVR Side 15 af 112

16 Fagsystemet kan vælge at genfremsende, såfremt det ikke har modtaget forretningskvittering efter tidsfristens udløb i antagelse af, at debitorsystemet ikke har modtaget debitorregistreringen. Der gælder følgende regler for debitorsystemets dannelse af forretningskvitteringer: En forretningskvittering dækker én debitorregistrering. o Vedrørende én myndighed og afsendt af ét fagsystem (AfgivendeIt-system) Forretningskvitteringen omfatter kvittering for samtlige elementer under debitorregistreringen. o Hvert element vil have sin statusangivelse Størrelsen på forretningskvittering er begrænset af hensyn til performance (fx mindre end 1 MB). Det betyder, at debitorsystemet kan være nødt til at opdele forretningskvittering for en debitorregistrering i flere forsendelser. Samlet set opfyldes herved krav om kvittering for samtlige elementer under et debitorregistrering Angivelse og håndtering af Personfølsomhed Integrationen understøtter, at anvendersystemet niveau af personfølsomhed på niveauerne Debitorkonto og Delfordring. Herved informerer anvendersystemet 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, registerforeskrifter mv. Tilsvarende informere debitorsystemet anvendersystemet om sin fastlæggelse af personfølsomhed, når debitorsystemet overdrager data til anvendersystemet ifm. forespørgseloperationer. Her vil det tilsvarende være anvendersystemet, som fastlægger sin håndtering ud fra den modtagne klassificering 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. I den fælleskommunale løsning STS Klassifikation, er der et klassifikationssystem for ØiR [ØiR Klassifikationssystem] samt fælles klassifikationer så som Indenrigsministeriets kontoplan. Under ØiR Klassifikationssystemet findes den overordnede klassifikation for nærværende integration, ØiR Domain Debitor. For hvert anvendende fagsystem findes en anvenderklassifikation, ØiR Domain Debitor anvenderløsning. De tilladte værdier, som fagsystemet kan benytte i sin angivelse af debitorregistreringen og tilsvarende debitorsystemets angivelse af fejlkoder under forretningskvitteringer vil enten fremgå af ØiR Domain Debitor eller ØiR Domain Debitor anvenderløsning. KOMBIT A/S Halfdansgade København S CVR Side 16 af 112

17 Klassifikationerne kan enten indeholde egne værdisæt eller referere til andre klassifikationer. Referencen kan enten være i form af et sortiment, dvs. udvalgt udsnit af den refererede klassifikation, eller det fulde værdisæt i den eksterne klassifikation. Følgende gælder for benyttelsen af værdisættet, dvs. registrering af UUID i dataobjekterne. Når der er tale om egne værdisæt, da benyttes UUID fra den relevante klasse. Er der tale om refererede klasser, så benyttes UUID for den klasse, som der referes til. Fx vil et fagsystemet i anvenderklassifikationen have et udsnit af koder/klasser fra STS Personfølsomhed. I registreringen skal benyttes UUID en fra STS Personfølsomheds klassen og ikke den klasse, som fremgår af anvendersystemets sortiment. For angivelse af kontoreferencen for kreditorregistreringen på en delfordring gælder det, at denne værdi tilhører ØiR Domain Debitor anvenderklassifikationen. Her benyttes angivelse af sekundær dimension med substitution. Substitutionen vil referere til klassifikationen ØiR Domain Finans. Der er ikke krav om, at myndighedens debitorsystem benytter præcis de samme værdisæt. Hvis der er forskel i anvendelse mellem fagsystemet og debitorsystemet er det debitorsystemets opgave og ansvar at forestå konvertering heraf, samt logning af denne konvertering. KOMBIT A/S Halfdansgade København S CVR Side 17 af 112

18 1.2.5 Digrammer for forretningsflow Debitorregistrering flow Straksleverance Fagsystem Afsend forespørgsel Modtag svar Modtag forespørgsel Afsend svar Serviceplatfom ØiR-service Valider serviceanmodning Ok Fejl Dan Transportkvitte ring Modtag forretningssvar Gennemstil forespørgsel Debitorsystem Modtag forespørgsel Valider/ fremsøg Send forretningssvar Figur 1 - Debitorregistrering - Straksleverance KOMBIT A/S Halfdansgade København S CVR Side 18 af 112

19 Debitorregistrering flow Batch - Volumenleverance Serviceplatform Beskedfordeler Fagsystem Afsend debitorregistrering Modtag debitorregistrering Dan datafil og triggerfil Fordel til SFTPbruger Modtag transportkvittering Afsend transportkvittering Dan transportkvittering Hent filer Opbevar filer (SFTP Service) Fordel til SFTP-bruger Filforsendelse Modtag besked Modtag og fordel besked Dan og send besked Beskedfordeling Vælg kanal for kvittering Hent filer Opbevar filer (SFTP Service) Opbevar filer (SFTP Service) Debitorsystem Hent filer Valider debitorregistrering Overfør forretningskvitteringsfil og triggerfil Figur 2 - Debitorregistrering - Batch Volumenleverance KOMBIT A/S Halfdansgade København S CVR Side 19 af 112

20 Debitorregistrering Flow Batch - Masseleverance Serviceplatform Beskedfordeler Fagsystem Afsend debitorregistrering Opbevar filer (SFTP Service) Fordel til SFTPbruger Hent filer Opbevar filer (SFTP Service) Fordel til SFTP-bruger Filforsendelse Modtag besked Modtag og fordel besked Dan og send besked Beskedfordeling Vælg kanal for kvittering Hent filer Opbevar filer (SFTP Service) Opbevar filer (SFTP Service) Debitorsystem Hent filer Valider debitorregistrering Overfør forretningskvitteringsfil og triggerfil Figur 3 - Batch - Masseleverance KOMBIT A/S Halfdansgade København S CVR Side 20 af 112

21 1.3 Servicebetingelser for den samlede integration Servicemål Parameter Debitorregistreringsflow Kvitteringsflow Tidsrum Svartid 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. 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 (KDF). 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. Beskrivelse af denne tilgår senere. 1.4 Teststrategi Test i forbindelse med udvikling Den planlagte test af services til installation på Serviceplatformen omfatter pt., at Systematic udfører automatiserede tests af services og unittests. Se [SPref] for detaljer Testfaciliteter og testmiljø [KDF: Udfyldes når behov fra bestiller er fastlagt] KOMBIT A/S Halfdansgade København S CVR Side 21 af 112

22 Testdata [KDF: Udfyldes når behov fra bestiller er fastlagt] Test i forbindelse med produktionssætning I forbindelse med produktionssætning er det omfattet af gældende aftale med Systematic, at der gennemføres følgende 3 prøver: Overtagelsesprøve Idriftsættelsesprøve Driftsprøve Se [SPref] for detaljer. 1.5 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 anvendersystemer, 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 anvendersystem inden for KOM- BITs rammearkitektur under monopolbrudsprojektet 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 anvendersystem, 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 anvendersystem eller en kommune. Anvendersystem og kommune: Ved tilslutning af et anvendersystem og/eller en kommune, er der en række aktiviteter op til idriftsættelsen, dels af aftalemæssig karakter, og dels også af konfigurationsmæssig karakter. Er der aktiviteter, som medføre konfiguration på Serviceplatformen, vil dette ske i forbindelse med oprettelse af myndighedens serviceaftalen for kommunen. KOMBIT A/S Halfdansgade København S CVR Side 22 af 112

23 1.5.2 Særlige vilkår [Til brug for servicekataloget på serviceplatformen er der behov for kort at beskrive vilkår der er specifikke for den pågældende integration. Det vil typisk være indgåelse af aftale mellem anvendersystem og kildesystem. Aftale inde for rammearkitekturen skal ikke beskrives. Er der ingen specifikke vilkår for integrationen anvendes nedenstående tekst. Vilkår for servicen Der er ingen specielle vilkår for brug af nærværende service ud over de generelle vilkår, der er beskrevet under vilkår for hhv. leverandører og kommuner.] Supplerende information om tilslutning Ingen KOMBIT A/S Halfdansgade København S CVR Side 23 af 112

24 2 Kontekst for integrationsparter 2.1 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 Serviceplatformen viderestiller kald fra anvender til forskellige debitorløsninger afhængigt af, hvilket kommunalt CVR nummer, der er anført i det AuthorityContext, der følger med i XML-payload. Første gang en kommune tilsluttes snitfladen, skal det anføres hvilket debitorsystem kommunen anvender. Dette gøres i forbindelse med oprettelsen af serviceaftalen i Serviceplatformens administrationsmodul. Er det ikke muligt at anføre debitorsystemet for kommunen, skal Serviceplatformen kontaktes. Se [GVF] for yderligere information om kontakt til serviceplatformen. Følgende opgaver skal gennemføres før et anvendersystem kan benytte snitfladen: ID Aktivitet Opgavekategori Ansvarlig Komponent Udførende Fase og afhængighed Kommentar TS100 TS101 Aftale Aftale Kommune skal indgå aftale om anvendelse af snitflader til Debitorsystem med leverandør Kommunen skal indgå eller opdatere databehandleraftale med leverandøren af debitorsy- Debitorsystem Kommunen Kommunen Debitorsystem Kommunen Kommunen Fase 2.1 Fase 2.1 KOMBIT A/S Halfdansgade København S CVR Side 24 af 112

25 TS102 TS103 TS104 Aftale stem om anvendelse af services Afsendelsesmyndighed og Debitoransvarlig myndig skal indgå dataudvekslingsaftale. Udarbejd fagspecifikke datagrundlag for ØiR kontoplan i STS Klassifikation for fagsystem Opret fagspecifikke datagrundlag for ØiR kontoplan i STS Klassifikation for fagsystem Koordinering Konfiguration Afsendelsesmyndighed Afsendelsesmyndighed Afsendelsesmyndighed STS Klassifikation Fagprojektet/Centraladministartor Fagprojektet/Centraladministartor STS Klassifikation Leverandør af Anvendersystem Leverandør af Anvendersystem Fase 2.1 Fase 1 Fase 1 Samme konfiguration som SF1590_A TS103 Forudsætter TS103 Samme konfiguration som SF1590_A TS104 TS105 Udarbejd kommunespecifikt datagrundlag for ØiR kontoplan i STS Klassifikation for fagsystem Koordinering STS Klassifikation Kommune /lokaladministrator Leverandør af Anvendersystem Fase 2.1 Forudsætter TS103 Kan være samme kontoplan som SF1590_A TS105 TS106 Opret kommunespecifikt datagrundlag for ØiR kontoplan i STS Klassifikation for fagsystem Konfiguration STS Klassifikation Leverandør af Anvendersystem Leverandør af Anvendersystem Fase 2.1 Forudsætter TS105 Kan være samme kontoplan som SF1590_A TS105 TS107 Verifikation af SFTP bruger for simpel SFTP er oprettet (se TBA08 i [GVF]) Verifikation Serviceplatformen Leverandør af Anvendersystem Leverandør af Anvendersystem Fase 2.2 TS108 Verifikation Verificer at SFTP for Anvendersystem Anvendersystem Leverandør af Anvendersystem Leverandør af Anvendersystem Fase 2.2 KOMBIT A/S Halfdansgade København S CVR Side 25 af 112

26 TS109 anvender korrekte parameter for triggerfil Kommune skal rekvirerer certifikat og konfigurerer dette til Serviceplatformen Konfiguration Administrationsmodul Kommune/Myndighed Leverandør af Anvendersystem Fase 2.2 Ifald der vælges certifikatbaseret adgang til Debitorsystem Certifikatet kan anvendes i andre snitflader. TS110 Anmodning om Serviceaftale for afsendende myndighed for SF1590_B Konfiguration Administrationsmodul Leverandør af Anvendersystem Leverandør af Anvendersystem Fase 2.2 TS111 Afsendende myndighed skal godkende serviceaftale for snitflade SF1590_B Konfiguration Administrationsmodul Leverandør af Anvendersystem Afsendende Myndighed/Kommune Fase 2.2 TS102, såfremt Afsendelsesmyndighed og debitoransvarlig myndig er forskellige TS112 Bestil ØIR parameterkonfiguration på serviceplatformen. Koordinering Serviceplatformen Afsendende Myndighed/Kommune Leverandør af Anvendersystem Fase 2.2 Ved forskellige myndigheder er der afhængighed til TS101 TS113 Verificer at basisopgaver for beskedfordeler er gennemført Verifikation Fase 2.2 Anvendersystem Leverandør af Anvendersystem Leverandør af Anvendersystem Gennemføres kun såfremt kvitteringer leveres via beskedfordeler (TS ) KOMBIT A/S Halfdansgade København S CVR Side 26 af 112

27 TS114 Fase 2.2 Oprettelse af serviceaftale for beskedtype ØiR Debitorregistrering Forretningskvittering Konfiguration Administrationsmodul Leverandør af Anvendersystem Leverandør af Anvendersystem Gennemføres kun såfremt kvitteringer leveres via beskedfordeler (TS ) TS115 Godkendelse af serviceaftale for besked. Fase 2.2 Konfiguration Administrationsmodul Kommune/Myndighed Kommune/Myndighed Gennemføres kun såfremt kvitteringer leveres via beskedfordeler (TS ) TS116 Fase 2.2 Oprettelse af abonnement på ØiR Debitorregistrering Forretningskvittering i beskedfordeler Konfiguration Beskedfordeler Leverandør af Anvendersystem Leverandør af Anvendersystem Gennemføres kun såfremt kvitteringer leveres via beskedfordeler (TS ) TS100 - Kommunen skal indgå aftale med leverandøren af debitorsystemet om anvendelse af integrationerne til Debitorsystemet, som er beskrevet i denne snitfladen. TS101 - Kommune skal indgå aftale om databehandling med leverandøren af Debitorsystemet. Aftalen skal yderligere dække anvendelsen af de udstillede services til Debitorsystemet. Disse services skal være i overensstemmelse med specifikationen i denne Snitfladebeskrivelse. TS102 - Såfremt Afsendelsesmyndighed og Debitorsansvarlig myndighed er forskellige myndigheder, skal der indgås en dataudvekslingsaftale mellem disse. TS103 - Forudsætningen for at et anvendersystem kan debitorregistrere i et debitorsystem er at der defineres en kontoplan, som kan konfigureres i klassifikation. Den generelle kontoplan dannes på basis af Indenrigsministeriet kontoplan (IM), men skal tilpasses fagsystemets behov. TS104 - Konfiguration af den generelle kontoplan fra TS103 i STS klassifikation TS105 - Såfremt kommune har egne udvidelser til kontoplanen, skal disse defineres som udvidelser til fagsystemets kontoplan og konfigureres i klassifikation. KOMBIT A/S Halfdansgade København S CVR Side 27 af 112

28 TS106 - Konfiguration af kommunespecifikke udvidelser til kontoplan fra TS105 i STS klassifikation TS107 - Anvendersystemet skal verificere, at der er oprettet en simpel SFTP bruger på serviceplatformen. Denne SFTP bruger skal benyttes til at overføre ØiR Debitordata i forbindelse med batch, samt modtage kvitteringer for kildesystemets behandling af data. Se TBA08 i [GVF] TS108 - Anvendersystemet skal verificerer at parameter for overførelse af økonomiposteringer via SFTP er korrekte. Følgende parameter skal være korrekte. Afsendermyndighed (CVR nr.) Afgivne anvendersystem (UUID for system) Modtagermyndighed (CVR nr.) Modtager Debitorsystem (UUID for system) Filtypen i SendersFieId ( Debitorregistrering Debitorkontering ) Filtypen i <InfRef> ( SF1590_B_IF02-03 ) TS109 - Benyttes certifikatbaseret adgangen til kommunes debitorsystem, skal der rekvireres et VOCES eller FOCES certifikat for kommune. Certifikatet skal uploades i Administrationsportalen, så der kan anvendes i Serviceaftalen i TS110. Samme certifikat kan anvendes for flere snitflader, og ikke alene bundet til SF1590_B. Det vil være oplagt at benytte samme certifikat for SF1590_A og SF1590_C TS110 - Leverandøren skal anmode om indgåelse af serviceaftale for kommunen, der skal bruge SF1590_B, i serviceplatformens administrationsmodul, og kommunen skal godkende denne anmodning jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. I forbindelse med tilslutning til SF1590_A skal korrekte endpoints for snitfladen angives. Serviceaftalen dækker alle services, beskrevet i denne integrationsbeskrivelse. Serviceaftalen kan oprettes med token eller certifikatadgang. Ved certifikatadgang skal serviceaftalen konfigureres med den afsendende myndigheds VOCES eller FOCES certifikat. Serviceaftalen indgår i en dobbelt myndighedes godkendelse, hvor både afsendende og debitoransvarlig myndighed skal indgå serviceaftale, som godkender udvekslingen af debiteringsdata. Dette skal også ske selv om debitoransvarlig- og afsendende myndighed er den samme myndighed. TS111 - Leverandøren af anvendersystemet skal for hver kommune bestille en opsætning på Serviceplatformen, som er dels er et supplement til serviceaftale og rutningsparameter for overførelse til valgte debitorsystem. Er Afsender-myndighed og Debitoransvarligmyndighed forskellige er parametrene for myndighed og system et udtryk for den dataudvekslingsaftale som er indgået i TS101. Følgende parameter registreres: Bilagstypen DEBITOR o SF1590_B_IF02-03 for afsend debitorregistrering KOMBIT A/S Halfdansgade København S CVR Side 28 af 112

29 o SF1590_B_IF04 for modtag kvittering Afsender o Afsender-myndighed/kommunes CVR-nr. o Afgivne anvendersystem (UUID for system) o Transportform for kvittering (SFTP/Beskedfordeler) o Afsendersystems SFTP bruger, såfremt der er valgt kvittering via SFTP Debitor o Debitoransvarligmyndighed CVR-nr. o Debitorsystem (UUID for system) o Debitorsystems SFTP bruger TS112 - Afsendendes-myndighed/-kommune skal godkende serviceaftalen. Herunder skal parameteropsætningen i TS111 godkendes. TS113 - Såfremt anvendersystemet vælger at få kvittering fra Debitorsystemet via Beskedfordeler, skal TS gennemføres. Det er en forudsætning for at kunne anvende beskedfordeler af TBA13 TBA15 i [GVF] er gennemført. Disse aktiviteter indeholder tilslutning til beskedfordeler, overvejelser om abonnements- og serviceaftale-struktur TS114 - Leverandøren skal for hver kommune oprette en serviceaftale, som indeholder en dataafgrænsning, der angiver beskedtypen ØiR Debitorregistrering Forretningskvittering, og en dataafgrænsning, der angiver, at der kan modtages forretningskvitteringer via beskedfordeler. TS115 - Kommunen skal godkende serviceaftale for beskedtypen ØiR Debitorregistrering Forretningskvittering i TS114 TS116 - For de enkelte kommuner skal der oprettes abonnementsudtrykket i beskedfordeler, som skal indeholdende ØiR Finans Forretningskvittering og kommunens CVR nummer. 2.2 Kontekst for Debitorsystem DS-X Lovhjemmel og forvaltningsmæssigt formål Der er ikke en specifik lovhjemmel for udlevering af data, men al udveksling af data sker i kontekst af den enkelte kommune, så et fagsystem for en bestemt kommune alene må modtage serviceudstillers data for den pågældende kommune. Debitorløsninger, der administrerer flere kommuners data, har ansvar for kun at returnere data for den kommune, der forespørges for Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart Den individuelle belastning for den enkelte debitorløsning kan ikke vurderes. KOMBIT A/S Halfdansgade København S CVR Side 29 af 112