Bilag 2: Kravspecifikation Kommunernes Ydelsessystem

Transkript

1 Bilag 2: Kravspecifikation Kommunernes Ydelsessystem

2 Indholdsfortegnelse Vejledning Indledning Leverancebeskrivelsens indhold... 4 Underbilag under nærværende bilag... 4 Klassifikation af krav... 5 Anvendelse af informations- og begrebsmodel... 6 Anvendelse af lov og regelfortolkning Baggrund, vision og målsætninger Baggrund... 7 Vision og målsætninger... 8 Succeskriterier Målgrupper Introduktion til områdets begreber, ydelser, processer og aktører Begreber Beriget konceptuel model (informationsmodel) Ydelsesarter Processer Aktører Overordnede krav Funktionelle krav Opgaver og sager Behandling af ydelsessager Administration af Persons økonomi Tværgående funktionalitet Visninger Håndter opgave vedrørende sag Systemadministration Rapporter og udtræk Selvbetjening Krav til dataudveksling Ikke-funktionelle krav Offentlige strategier og generelle arkitekturprincipper Arkitektur Rammearkitekturens støttesystemer Integrationer Brugervenlighed og Look n Feel Lovkrav Side 2 af 255

3 6.7 Sikkerhed Referencer Side 3 af 255

4 Vejledning Bilaget er færdigt og Tilbudsgiver må ikke ændre i det. Tilbudsgiver skal besvare bilaget gennem udfyldelse af underbilag 2.1(Løsningsbeskrivelse og kravmatrice) jf. de supplerende vejledninger. 1 Indledning Nærværende Bilag 2 (Kravspecifikation) udgør sammen med relaterede bilag samt underbilag og kontrakten som helhed - den samlede beskrivelse af Løsningen og relaterede ydelser. 1.1 Leverancebeskrivelsens indhold Leverancebeskrivelsen er struktureret i følgende afsnit: Nærværende kapitel 1 introducerer indholdet i leverancebeskrivelsen og relaterede underbilag. Herudover beskrives den anvendte kravklassificering og bl.a., hvordan begrebsmodel og informationsmodel anvendes i leverancebeskrivelsen. Kapitel 2 er et baggrundsafsnit, der kort introducerer KOMBITs og kommunernes behov for en fremtidig Løsning på kontanthjælpsområdet og tilgrænsende områder. Afsnittet tjener alene til det formål at give leverandøren formåls- og baggrundsviden i forhold til den Løsning, der skal leveres under Kontrakten. Kapitel 3 giver en kort introduktion til de forretningsprocesser, begreber, ydelser og aktører, som løsningen skal understøtte, med henvisninger til mere detaljerede beskrivelser i relevante underbilag. Kapitel 4 indeholder nogle få overordnede krav, som er generelle for hele Løsningen, og derfor gælder på tværs af de understøttede forretningsprocesser og de efterfølgende kapitler. Kapitel 5 indeholder de funktionelle krav, som skal sikre, at Løsningen understøtter behandlingen af ydelsessagerne. Kapitlet er struktureret ud fra sagsbehandlingsprocessens hovedtrin. For hver af sagsbehandlingsprocessens hovedtrin er der udarbejdet en række generelle krav, som gælder på tværs af de ydelser, som Løsningen understøtter. Hvor det er relevant, suppleres der med mere ydelsesspecifikke krav i underafsnit. Dertil kommer en række underafsnit med krav af mere tværgående karakter. Kapitel 6 indeholder ikke-funktionelle krav, herunder krav vedrørende brugervenlighed, sikkerhed, løsningsarkitektur, snitflader mv. Kapitel 7 indeholder referencer til dokumentation og anvenderkrav til Rammearkitekturens støttesystemer. 1.2 Underbilag under nærværende bilag Under nærværende bilag 2 findes følgende underbilag: Underbilag 2.1: Løsningsbeskrivelse og kravmatrice Underbilag 2.2: Oversigt over uforenelige ydelser Underbilag 2.3: Processer Underbilag 2.4: Begrebsmodel Underbilag 2.5: Informationsmodel Underbilag 2.6: Integrationer Underbilag 2.7: Lovgivning og beregningsregler Side 4 af 255

5 Underbilag 2.8: Lovgivning Underbilag 2.9: Eksempler på rapporter Underbilag 2.10: Eksempler på skærmbilleder Underbilag 2.11: Kommunale personas Underbilag 2.12: Eksempler på breve Underbilag 2.13: Oversigt over hændelser Underbilag 2.14: Beregninger og regler fleksydelse Underbilag 2.15: Oversigt over ydelsesarter Underbilag 2.16: Ydelser og målgruppe- målgruppestatus Underbilag 2.17: Borger personas Underbilag 2.18: Persona brugerrejser Underbilag 2.19: Målepunkter og succeskriterier Underbilag : Anvendes ikke Underbilag 2.24: Kundens it-miljø Underbilag : Anvendes ikke Underbilag 2.32: Eksempler på brugervenlighedstestopgaver Underbilag 2.33: Anvendes ikke Underbilag 2.34: Anvenderkrav til understøttelse af dialogintegration 1.3 Klassifikation af krav Alle krav er i Kravspecifikationen angivet ved et unikt fortløbende nummer og vil være angivet i tabeller som den følgende: Krav [#]: [Navn] Kategori: Beskrivelse: Type: Kravtabellen er opbygget som følger: Krav [#]: Angiver et fortløbende unikt nummer. [Navn]: Angiver kravets navn. Kategori: Angiver kravets kategori. Der anvendes følgende kravkategorier: Kategori Beskrivelse Mindstekrav Krav Mindstekrav er forbeholdt de elementer i Leverancen, som er fundamentalt afgørende for, om Leverancen kan anvendes af KOMBIT. Alle mindstekrav skal uforbeholdent opfyldes, for at Leverandørens leveranceforslag vil blive taget i betragtning. Mindstekrav er markeret med MK Krav er forbeholdt de elementer i Leverancen, som er nødvendige, for at Leverancen lever op til KOM- BITs krav. Alle krav skal dog ikke nødvendigvis opfyldes for, at KOMBIT vil tage Leverandørens leveranceforslag i betragtning, men graden af opfyldelse indgår jf. udbudsbetingelserne. Krav er markeret med K. Type: Typificering af krav i følgende områder: o Funktionelt krav (Hvad Løsningen skal gøre). o Ikke-funktionelt krav (Hvordan Løsningen skal opføre sig). Beskrivelse: En beskrivelse af kravet. Angiver eksempler på mulige løsningsmodeller samt referencer til tilgrænsende krav. Side 5 af 255

6 1.4 Anvendelse af informations- og begrebsmodel Begrebsmodellen beskriver de forretningsmæssige begreber, der omfattes af projektet. Begrebsmodellen fremgår i sin helhed af underbilag 2.4 (Begrebsmodel) og introduceres i afsnit 3.1. Informationsmodellen beskriver informationer, der skal håndteres indenfor systemets rammer. Fra de enkelte krav relateres der i nogle tilfælde til informationsmodellens bestanddele (i bemærkningsfeltet), således at Leverandøren får et indblik i hvilken information, der skal håndteres i en given funktion. Informationsmodellen fremgår i sin helhed af underbilag 2.5 (Informationsmodel) i form af en række UML klassediagrammer, og introduceres i afsnit 3.2. Der henvises fra funktionelle krav i kapitel 5 til informationsmodellen på følgende måde: Som udgangspunkt henvises til navnet på en delmodel eller til en eller flere pakker 1, som indeholder de informationer, som er relevante for kravet. Delmodeller er navngivet så navnet starter med KY-, fx KY-sag. En henvisning til en delmodel, kan eksempelvis se således ud: Se informationsmodellen (KY-sag) i underbilag 2.5 ) og en henvisning til en pakke kan se således ud: Se eventuelt informationsmodellen (Beregningsgrundlag) i underbilag 2.5. Denne henvisning vil som hovedregel være relevant for alle de ydelser, hvor pakken indgår. Alternativt henvises til specifikke klasser, attributter eller relationer, hvor der er behov for mere specifikke henvisninger, fx Se informationsmodellen (Økonomisk effektueringsplan) i underbilag 2.5 Endelig er der ved visse krav, der retter sig mod specifikke ydelser, henvisninger til den eller de ydelsesspecifikke modeller. Eksempelvis kan henvisningen gå til Beregningsgrundlag i Kontanthjælps-modellen, hvis der er tale om et krav, som kun vedrører uddannelseshjælp eller kontanthjælp: Se informationsmodellen (Beregningsgrundlag i KY-uddannelseshjælp eller kontanthjælp) i underbilag Anvendelse af lov og regelfortolkning I underbilag 2.7 (Lovgivning og beregningsregler) og underbilag 2.14 (Beregninger og regler vedrørende fleksydelse) er beskrevet eksempler på, hvordan lovgivning og beregningsregler kan fortolkes for en række af de ydelser, som Løsningen skal håndtere. Eksemplerne er af vejledende karakter og ikke udtømmende. Materialet giver Leverandøren en grundig indsigt i lov og regelfortolkning på området og det forventes, at Leverandøren orienterer sig i materialet. Krav# 1: Leverandørens lov- og regelfortolkninger Beskrivelse: Hvis Leverandørens lov- og regelfortolkninger er i modstrid med beskrivelserne i underbilag 2.7 og underbilag 2.14, bedes Leverandøren redegøre hvorfor og hvor der er uoverensstemmelser. - Dette krav er både relevant i afklarings-, design- såvel som udviklingsfasen 1 UML Packages Side 6 af 255

7 2 Baggrund, vision og målsætninger Dette kapitel indeholder en introduktion til baggrunden, visionen og målene for Kommunernes Ydelsessystem. Yderligere information kan findes på Baggrund Formålet med nærværende kravspecifikation er at sikre etableringen af en moderne, fælleskommunal it-løsning til understøttelse af sagsbehandling på kontanthjælpsområdet og tilgrænsende ydelsesområder 2, herunder tilvejebringe en afløser for kommunernes brug af "KMD Aktiv". Konkurrenceudsættelsen og etableringen af Kommunernes Ydelsessystem er et af flere projekter, som gennemføres som led i den fælleskommunale Udbudsplan (yderligere information kan findes på Planen er et centralt led i den fælleskommunale digitaliseringsstrategi, der blev vedtaget i november 2010, og som nu er under udmøntning. Figur 2: Oversigt over den fælleskommunale Udbudsplan I forbindelse med Udbudsplanen agerer KOMBIT indkøbscentral, og udbyder og indkøber de nye fælleskommunale løsninger på vegne af landets 98 kommuner. Alle kommuner vil således anvende Kommunernes Ydelsessystem, og betaler for anvendelsen via et årligt driftsbidrag til KOMBIT. Driftsbidraget anvendes til at finansiere behovsafdækning, udbudsomkostninger, markedsdialog, udfasning af eksisterende løsninger, informationskampagner og projektstyring, samt systemudvikling, -drift, -vedligehold og forbedring Kommunernes nuværende løsninger Den nuværende it-understøttelse af kontanthjælpsområdet sker i dag via beregningsunderstøttelse (via KMD Aktiv og EG BIS-Y), mens den egentlige understøttelse af selve sagsbehandlingen eksempelvis foregår i KMD Sag eller andre ESDH-systemer. KMD Aktiv, der anvendes i størstedelen 2 Der er tale om understøttelse af kommunernes sagsbehandling på ydelses-området og ikke jobcenter-området. På jobcenter-området eksisterer der flere konkurrerende it-løsninger og området er således ikke omfattet af Udbudsplanen for monopolområderne. Side 7 af 255

8 af landets kommuner, er mere end 10 år gammelt og baseret på 3270-teknologi, mens BIS-Y er et nyere system, der anvendes i en enkelt kommune. KMD Aktiv og KMD Sag er omfattet af transitionsaftalen indgået mellem KL og KMD A/S i forbindelse med salget af sidstnævnte, hvorfor bl.a. udfasning af systemerne (data-extract m.v.) er underlagt særlige betingelser. Yderligere information kan findes på [indhentet ] KMD Aktiv er driftssikkert og kendetegnet ved korte svartider, men flere kommuner rapporterer, at der er behov for hurtigere og billigere tilretninger i et kommende system Desuden skal sagsbehandlerne foretage en række dobbeltopslag og andre manuelle funktioner, som ikke virker tidssvarende, ligesom systemet ikke giver mulighed for automatisering og borger-vendt selvbetjening. Analyser forud for udarbejdelsen af Kontrakten har vist, at mange kommuner efterspørger en effektivisering af sagsbehandlingen gennem en væsentlig højere grad af beslutningsstøtte, automatisering og selvbetjening. For at sikre kommunerne de fulde gevinster ved Kommunernes Ydelsessystem er det således centralt, at der som del af projektet sker en gentænkning af it-understøttelsen af området, således at der ikke alene etableres en 1-til-1-kopi af den eksisterende it-understøttelse på området. 2.2 Vision og målsætninger Kontanthjælp, uddannelsesydelse og de øvrige beslægtede ydelsesområder er en central del af det danske velfærdssystem. De ydelser der beregnes og efterfølgende udbetales på baggrund af det kommende ydelsessystem udgør i mange tilfælde eksistensgrundlaget for de modtagende borgere. Løsningen vil blive anvendt i alle 98 kommuner, og samlet set udbetales der ydelser for ca. 25 mia. kr. årligt. Visionen for Løsningen er, at der etableres en moderne, brugervenlig sagsbehandlingsløsning, som ressourceeffektivt, tidssvarende og omkostningseffektivt understøtter den kommunale sagsbehandling på kontanthjælpsområdet og tilgrænsende ydelsesområder via beslutningsunderstøttelse, fuldautomatisering ( straight-through processing ) og sammenhæng til selvbetjening for borgere. Løsningen skal kunne understøtte behandlingen af ca ansøgninger og ca åbne sager svarende til ca beregninger og udbetalinger pr. måned. Løsningen forventes anvendt af ca samtidige brugere. Internt i kommunerne skal Løsningen bidrage til at muliggøre hurtigere oplæring af nye medarbejdere i Løsningen, fleksibelt samarbejde mellem faggrupper på tværs af faggrænser og organisatoriske enheder, samt skabe mulighed for en differentieret indsats over for borgerne. For borgerne skal Løsningen yderligere bidrage til øget med- og selvbetjening og øget adgang til egne oplysninger og kommunikation med kommunen. Kontrakten skal således bidrage til at sikre følgende kvalitative gevinster: Større understøttelse og kvalitetssikring af sagsbehandlingens enkelte skridt (strukturerede valg, vejledninger, genbrug af data, indhentning af oplysninger fra eksterne registre m.v.). Hurtig, let anvendelig og overbliksgivende sagsbehandlingsløsning for sagsbehandlere. Let anvendelig og overbliksgivende selvbetjeningsløsning for borgerne. Side 8 af 255

9 Øget retssikkerhed og støtte til borgere gennem forbedret udveksling og visning af data. Udvidede tilpasningsmuligheder i it-understøttelsen i forbindelse med breve, opgaver og proces-understøttelse. Fuld lovmedholdelighed gennem fælleskommunal kontrol med leverandørens implementering af lovændringer m.v. Stabil drift, som tilgodeser kontanthjælpsområdets væsentlighed for mange borgere. Fleksibilitet i forhold til justeringer af takster og mindre lovændringer (det er forventningen at større lovændringer vil kræve udvikling hos leverandøren). Løsningen skal være baseret på en moderne teknologisk platform, som med løbende vedligeholdelse og videreudvikling giver gode muligheder for levetid på år. Teknologi, rettigheder og dokumentation skal have en sådan form, at Løsningen løbende kan bringes i gen-udbud af KOM- BIT på kommunernes vegne med henblik på optimering af udbytte og kvalitet, og reduktion i omkostninger. For den fælleskommunale Udbudsplan er formuleret fire overordnede målsætninger, som konkurrenceudsættelsen af Kommunernes Ydelsessystem understøtter: 1. Højere grad af sagsunderstøttelse, via regelstyring, integrationer til andre systemer og selvbetjeningsdelen (lettelser for kommunale medarbejdere og for borgerne). 2. Prisfald på kommunernes samlede driftsudgift på minimum 25 %. 3. Forsyningssikkerhed sikker og stabil drift. 4. Fleksibel løsning, hvor små ændringer, fx ændringer af takster, kan foretages af kunden, og en løsning hvor en større grad af automatisering af sagsbehandlingen er mulig. I forlængelse heraf er der formuleret syv målsætninger med tilhørende succeskriterier for etableringen af Kommunernes Ydelsessystem. For at kontrakten og relaterede ydelser kan betegnes som vellykkede, skal ydelserne understøtte målsætningerne og succeskriterierne for projektet. Det forventes, at Leverandøren aktivt støtter KOMBIT i indfrielsen af målsætning A, B, C, D og F 3. Prioritet # Målsætninger 1 A 1 B Understøtte korrekte og rettidige udbetalinger af ydelser på kontanthjælpsområdet og tilgrænsende områder Sikre kommunerne min. 25 pct. lavere gennemsnitlige it-udgifter på kontanthjælpsområdet, samt afløfte kommunernes udbudspligt på området 2 C Sikre brugervenlig og effektiv it-understøttelse af de kommunale arbejdsgange på kontanthjælpsområdet og tilgrænsende områder gennem automatisering og beslutningsunderstøttelse 3 Målsætning B er primært relevant for leverandøren ift., at sende et konkurrencedygtigt tilbud, herunder en driftseffektivt løsning. Målsætningen E er ikke direkte relevante for Leverandøren, men er medtaget for at forstærke Leverandørens forståelse for KOMBITs interessenters behov. Side 9 af 255

10 2 D 3 E 3 F Muliggøre bedre it-mæssig sammenhæng til tilgrænsende kommunale opgaver gennem åbne snitflader, datastandardisering mv. Bidrage til at skabe momentum for KL s indsats for regelforenkling på beskæftigelsesområdet Oparbejde erfaringer, som smidiggør gennemførslen af øvrige projekter i KOMBITs og KL s udbudsplan Tabel 2: Overblik over projektets målsætninger (prioriteret rækkefølge). 2.3 Succeskriterier Succeskriterierne for denne kontrakt understøtter målsætningerne for udbudsplanen. For at kontrakten og relaterede ydelser kan betegnes som vellykkede, skal ydelserne understøtte målsætningerne og succeskriterierne for projektet. Det forventes, at Leverandøren aktivt støtter KOMBIT i indfrielsen af målsætninger og succeskriterier herunder også målsætninger og succeskriterier, som Leverandøren har begrænset indflydelse på, jf. bilag 2.19 Målepunkter og succeskriterier. 2.4 Målgrupper Løsningen vil primært blive anvendt af ydelsescentret, der er den del af den kommunale forvaltning, der arbejder med udbetaling af økonomiske ydelser på kontanthjælpsområdet. Sagsbehandlingen udføres i sammenhæng med jobcenterområdet, der varetager den opfølgningsmæssige opgave i forhold ydelsesmodtageren. Dertil kommer sagsbehandlere på tilgrænsende ydelsesområder, som anvender løsningen til udbetaling af ydelser på de tilgrænsende områder. Selvbetjeningsløsningen vil primært blive benyttet til ansøgning om uddannelseshjælp eller kontanthjælp og til at understøtte en del af kontakten mellem sagsbehandler og ansøger under sagsbehandlingen, fx ved behov for supplerende oplysninger. Brugerne af Kommunernes Ydelsessystem forventes at være følgende, jf. afsnit 3.5 (Aktører): Person (ansøger om forsørgelsesydelse via selvbetjeningsløsning) Sagsbehandler (Ydelsescentret) Sagsbehandler (Jobcentret) Sagsbehandler (anden forvaltning) Kommunal administrator Central administrator Kommunal/statslig tilsynsmyndighed Kommunal mellemleder Kommunalt kontrolteam Målgruppernes involvering Jf. Bilag 9 (KOMBITs medvirken) ønsker KOMBIT at agere som en aktiv, kompetent og ansvarlig kunde, som positivt og i anseeligt omfang bidrager til Leverandørens arbejde, herunder løbende bistår med at afklare forretningsmæssige spørgsmål og uddybe bestemmelserne i Kontrakten inkl. kravene i nærværende bilag. Side 10 af 255

11 Herudover lægger KOMBIT stor vægt på den løbende involvering af kommunerne. For at sikre forankring og input til specificering og udvikling af Kommunernes Ydelsessystem anvendes derfor to følgegrupper: Kommunal arbejdsgruppe: Samler ca. 10 erfarne kommunale medarbejdere på ydelsesområdet, som rådgiver KOMBIT med henblik på bl.a. arbejdsgange, fortolkning af lovgivning, udviklingstendenser, udrulning og funktionalitetsbehov. Arbejdsformen er primært fælles møder og workshops, hvor aktuelle emner afklares, ligesom gruppen også anvendes til skriftlig kvalitetssikring m.v. Medlemmer af arbejdsgruppen kan også udvælges med henblik på indstationering hos Leverandøren i kortere eller længere perioder. Kommunal referencegruppe: Samler ca. 10 kommunale ydelses- og borgerservicechefer eller ligende, som rådgiver KOMBIT med henblik på bl.a. arbejdsgange, prioritering og kvalitetssikring, udviklingstendenser, udrulning og gevinstrealisering. Arbejdsformen er primært fælles møder og workshops, hvor aktuelle emner afklares. Kommunal ekspertviden: I det omfang der er behov for særlig viden der ligger ud over kompetencerne i den kommunale arbejds- eller referencegruppe anvender KOMBIT andre kommunale medarbejdere og ledere til afklaring, fx på den kommunale økonomiproces. Grupperne har rådgivet KOMBIT i forbindelse med specificeringen af Løsningen, ligesom KOMBIT ønsker at anvende dem i forbindelse med design, udvikling og test af Kommunernes Ydelsessystem. Leverandøren kan således forvente i visse tilfælde at skulle samarbejde med de nævnte grupper under KOMBITs ledelse, jf. Bilag 9 (KOMBITs medvirken). Det forventes, at Leverandøren aktivt støtter KOMBIT i anvendelsen af grupperne og anden kommunal ekspertviden, herunder i væsentligt omfang planlægger dem anvendt i Leverandørens arbejde. 3 Introduktion til områdets begreber, ydelser, processer og aktører I dette kapitel beskrives de begreber, ydelser, processer og aktører, som enten indgår i Løsningen eller som skal anvende Løsningen. Formålet med kapitlet er dels at give Leverandøren et grundlag for at forstå det forretningsmæssige domæne, som Løsningen skal understøtte og dels at stille krav til Leverandørens brug af de beskrevne begreber og processer, som udgangspunkt for den videre modellering og udvikling af Løsningens datamodel og brugergrænseflade. Begrebsmodellen beskriver de forretningsbegreber, der er repræsenteret i domænet, og informationsmodellen viser de centrale informationer, som Løsningen indeholder. Processerne giver en sammenhængende fremstilling af aktiviteter for forskellige aktører og regler/forretningslogik udreder Løsningens lovgivning og regelsæt. 3.1 Begreber I dette afsnit præsenteres en begrebsmodel for Ydelsesområder samt en definition af de pågældende begreber. Modellerne og begreberne skal anvendes til at forstå forretningsområdet. I de- Side 11 af 255

12 signspecifikationsfasen skal Leverandøren anvende disse til datamodel, forståelige brugerflader, konsistente snitflader til systemaktørerne og andre relevante designopgaver. I underbilag 2.4 (Begrebsmodel) er begrebsmodellen med de centrale forretningsbegreber på et ikke-udtømmende niveau for Ydelsesområder beskrevet. Kunden forstår centrale forretningsbegreber som begreber, der er elementære i al kommunikation inden for dette område. Krav# 2: Begrebsmodel Beskrivelse: Leverandøren skal anvende de udarbejdede begrebsmodeller og tilknyttede definitioner som grundlag for udarbejdelse af Løsningens logiske datamodel. - Se underbilag 2.4 Begrebsmodel. De følgende definitioner er medtaget for at lette læsningen af leverancebeskrivelsen. Bemærk, at der i underbilag 2.4 (Begrebsmodel) fremgår en dybere beskrivelse af forretningsmæssige begreber. Begreb Advis Afmelding Afslag Afslagsbrev Aktivitet Alternativ modtager Ansøger Beløb til administration Beløb til udbetaling Besked Bevilget ydelse Beskrivelse I Løsningen benyttes ikke advis, som ellers er et anvendt begreb i mange kommunale fagsystemer. Advis opfattes som en form for nyhed, der ikke nødvendigvis skal reageres på i modsætning til en opgave, der er det anvendte begreb i Løsningen. Se opgave. Hvis en borger kommer i arbejde, undlader at tjekke sine jobopslag, eller der ikke bevilges ydelse, bliver borgeren afmeldt jobcentret. På grundlag af en afmelding foretager jobcentret en opfølgning eller afslutter borgerens kontaktforløb. Et afslag er resultat af en afgørelse, som falder negativt ud for ansøgeren Et brev med en negativ afgørelse med begrundelse, der indeholder henvisning til de retsregler, afgørelsen er truffet efter. Begrundelsen indeholder en kort redegørelse for sagens faktiske omstændigheder og relevante retsregler, som er tillagt betydning for afgørelsen, jf. FVL 24. Afslagsbrevet indeholder tillige en klagevejledning, jf. FVL 25. Jobcentret tilrettelægger en aktivitet for ledige, der skal bringe borgeren tættere på at komme i arbejde. Aktiviteten kan ligge indenfor områderne; Vejledning og opkvalificering, Virksomhedspraktik eller ansættelse med løntilskud. Borgeren skal tage imod rimeligt tilbud om aktivering for at beholde sin ydelse. En aktivitet kaldes også for en placering. En virksomhed, myndighed eller en anden person end bevillingsmodtageren, som modtager en udbetaling i en sag. Betalingen vedrører typisk en vare eller en tjeneste, som kommunen betaler for som led i sagsbehandlingen. Er i informationsmodellen (underbilag 2.5) repræsenteret som Ydelsesmodtager. En ansøger er den Person, som ansøger om en forsørgelsesydelse eller enkeltydelse mv. Ansøgeren kan ansøge både via selvbetjeningsløsningen og via papir. Beløb til administration: Det beløb, som overføres fra en bevilget ydelse til en administrationsordning. Beløbet anvendes til betaling af personens udgifter til fx husleje, el og varme og eventuelt til at udbetale den bevilgede ydelse til personen i rater frem for at udbetale den på én gang. Det beløb, som udbetales til modtageren af en bevilget ydelse. Beløbet beregnes med udgangspunkt i den bevilgede ydelsessats med eventuelle tillæg og fradrag (fx vedr. indtægter og sanktioner) samt fradrag af ATP og skat. En besked er oplysninger, der fremsendes fra et afsendersystem til Løsningen via Beskedfordeleren eller via en direkte snitflade mellem afsendersystemet og Løsningen. En besked oprettes på baggrund af en hændelse, der er registreret i afsendersystemet. Se også Hændelse og opgave En ydelse, som er bevilget til en specifik person efter afgørelse i vedkommendes sag, fx en Side 12 af 255

13 bevilling af en enkeltydelse efter LAS 81. Bevilget ydelsesbeløb Bevillingsskrivelse Bogføring Bruger Det beløb, som modsvarer den bevilgede ydelsessats (fx kontanthjælp eller revalideringsydelse) for en udbetalingsperiode, såfremt der udbetales for alle dage i perioden. Skrivelse med oplysning om den bevilgede ydelse med henvisning til de retsregler, som bevillingen er givet efter. Bevillingsskrivelsen oplyser ligeledes, hvornår første udbetaling sker. I denne sammenhæng bruges ordet bogføring om det, at et eksternt økonomisystem posterer i kommunens regnskab på baggrund af de oplysninger, der overføres fra løsningen. En person hos KOMBIT, en kommune eller andre, der skal anvende Systemets brugergrænseflader. Se brugeraktører i afsnit I afsnit , 5.8 og 5.10 vil en bruger typisk være en sagsbehandler I afsnit 5.7 vil en bruger typisk være en administrator I afsnit 5.9 vil en bruger typisk være en Person/Ansøger Efterlønsalder Forsørgelsesydelse Godtgørelse Hændelse Den alder, hvor en Person tidligst kan modtage efterløn, såfremt Personen i øvrigt er berettiget. I lov om arbejdsløshedsforsikring fremgår efterlønsalderen for et antal relevante fødselsårgange. Overkategori for ydelser omfattende kontant- og uddannelshjælp, revalideringsydelse, ledighedsydelse, forrevalidering og fleksjob. Jobcentret kan efter LAB 82 og 83 bevilge godtgørelse af udgifter forbundet med aktivering. Godtgørelsen kan bl.a. dække udgifter til buskort eller arbejdstøj. En hændelse kan være: 1) En begivenhed, der sker ude i verden som fx at en Person flytter, udvandrer, dør, bliver forælder etc. 2) En begivenhed, der registreres i en anden it-løsning, som er relevant for Løsningen. 3) En begivenhed, der indtræder i Løsningen forårsaget af en bruger- eller systemhandling. Se også beskeder og opgave. Ikke-sagshenførbar besked Indkomstgrundlag Jobcenterløsning KLE Kontaktforløb Kontering LAB LIS Lovgivning Monopolbrudsløsning Mundtlig afgørelse En besked, der modtages via jobcentersnitfladen, som ikke kan placeres på en sag, men som i stedet kan henføres til en Person. Den indkomst, der skal indgå i beregningen af beløbet til udbetaling. De beløb, som indgår i indkomstgrundlagt varierer mellem ydelsessarter. It-løsning til understøttelse af sagsbehandlingen i jobcentrene. Der findes pr. medio januar 2014 tre jobcenterløsninger: KMD Opera, Facit og WorkBase. KL Emnesystematik er en lovbaseret kommunal taksonomi (journaliseringsnøgle), der bruges til at registrere de kommunale opgaver (emner) og forvaltningshandlingen ift. opgaven (handlingsfacetterne) på den enkelte sag. Når en borger melder sig ledig, får han et kontaktforløb efter LAB kap. 7 i jobcentret. Kontaktforløbet består af en række aktiviteter, der alle sigter mod at få den ledige i job så hurtigt som muligt. Hvis det ikke er realistisk, at den ledige kommer i job på helt kort sigt, skal kontakten sigte mod at få planlagt jobrettede aktiviteter. Indføring af et beløb på en konto i kontoplanen i løsningen. Konteringen skaber grundlaget for, at Løsningen kan overføre oplysninger til et eksternt økonomisystem, hvor bogføringen i kommunens regnskab sker. Lov om en aktiv beskæftigelsesindsats. Ledelsesinformationssystem Når der henvises til lovgivningen i dokumentet, menes herunder både lovgivning, bekendtgørelser, vejledninger og ankeafgørelser mv. Dækker KOMBITs udbud af løsningerne Kommunernes Sygedagpengesystem, Kommunernes Ydelessystem og SAPA. En afgørelse kan meddeles mundtligt, men skal journalføres. FVL 23 giver personen ret til inden 14 dage, at få afgørelsen meddelt skriftligt. Side 13 af 255

14 Omregningssats Opgave Part Person Registerindsigt Samlever Sanktion SAPA Sats-register Strukturerede oplysninger Søgnehelligdag Tilbagebetalingspligt Tilmelding Udbetaling Danmark Benyttes til at beregne timetal jf. LAS 31.2, når timetal er ukendt. Offentliggøres årligt af AMS sammen med en række andre satser. En opgave er en notificering til brugeren omkring noget der skal løses. Opgaver kræver således, at brugeren foretager en eller anden form for handling. Er den Person, den virksomhed eller den adresse, en sag vedrører. Primær part er typisk den Person der modtager ydelsen, hvor sekundær part kan være den primære parts ægtefælle, barn osv. En Person, som indgår i behandling af en sag i løsningen. Person 1 (primær part) og Person 2 (sekundær part) anvendes i sager, hvor Ansøger (Person 1) og dennes ægtefælle/samlever (Person 2) begge er relevante for sagsbehandlingen, fx i sager vedr. kontanthjælp. Personer har ret til at få at vide, hvad der er anført om dem i offentlige registre, herunder også i Løsningen. Ved en Persons anmodning om indsigt i, hvad der er anført, som fx kan være rettet generelt til en kommune, håndteres anmodningen som en registerindsigt. Person som man bor sammen med i et ægteskabslignende forhold. To personer anses i forbindelse med sager om uddannelseshjælp og kontanthjælp for samlevende, hvis de opfylder betingelserne i LAS 2 b. Det er en konkret individuel vurdering, som foretages af kommunen. I disse sager indgår ansøgerens eventuelle ægtefælle eller samlever i sagsbehandlingen. En økonomisk konsekvens af Personens eller eventuelt ægtefællens manglende medvirken i aktivering mv., som udgør forudsætningen for at blive bevilget en ydelse., eksempelvis i form af nedsættelse af den bevilgede ydelse. Sagsoverblik/Partskontakt (SAPA). SAPA er en del af KOMBITs samlede udbudsplan for monopolområderne og skal sikre et alternativ til KMD Sag. Løsningen kan give kommunale sagsbehandlere hurtig adgang til centrale informationer og hændelser vedrørende borgeren på tværs af kommunens fagsystemer. Se mere på [indhentet ] Et register med satser og tilhørende beløb, kontanter mv., der anvendes i beregninger mv., fx Kontanthjælpssats og Omregningsfaktor. Beløb mv. fastsættes årligt i vejledning fra AMS. Data, som er indberettet af en bruger eller indhentet fra eksterne systemer, i form af strukturerede datafelter med faste formater, værdisæt mv.. Disse oplysninger kan typisk valideres og benyttes til beregninger og beslutninger i systemet. En helligdag, som falder på en hverdag undtagen lørdag. Benyttes fx ved ledighedsydelse. Det er 1. nytårsdag, Skærtorsdag, Langfredag, 2. påskedag, Store bededag, Kristi himmelfartsdag, 2. pinsedag, juledag og 2. juledag. Grundlovsdag behandles på samme måde. Visse ydelser kan bevilges med hel eller delvis tilbagebetalingspligt, hvilket vil sige, at Personen skal tilbagebetale et beløb efter kommunens nærmere bestemmelse. En ledig skal tilmeldes som ledig i jobcentret og registreres dermed i AMS fælles datagrundlag (DFDG). Tilmeldingen kan ske via Jobnet.dk eller via jobcentret. Borgen har pligt til at møde op i jobcentret. Hvis borgeren er berettiget til en ydelse, vil startdatoen for ydelsen i de fleste tilfælde være lig med tilmeldingsdatoen. Tilmeldingsdatoen kan ligge tidligere end startdatoen for kontaktforløbet. Borgeren registreres som kontanthjælpsansøger, og når ydelsescentret har truffet afgørelse, og der bevilges en ydelse, opdateres klientkategorien til kontanthjælpsmodtager i DFDG. Udbetaling Danmark (UDK) er en ny offentlig myndighed, der fra oktober 2012 begyndte at overtage en række opgaver fra kommunerne. Det er udbetaling af børneydelser, barselsdagpenge, pensioner og boligstøtte. Udbetalingsperiode Udbetaling Danmark blev dannet, da KL og regeringen i juni 2010 indgik en aftale om at samle dele af den objektive sagsbehandling i fem centre med virkning fra efteråret Den periode (typisk en kalendermåned), som en udbetaling vedrører. Der beregnes som hovedregel for én udbetalingsperiode af gangen. En udbetalingsperiode kan i visse tilfælde, fx ved 25 års fødselsdag i forbindelse med en sag om kontanthjælp, opdeles i delperioder, der beregnes separat. Udbetalingsperioden kan for en specifik sag være kortere fx pga., at Side 14 af 255

15 Personen kommer i arbejde midt i måneden. Ydelse Ydelsesart Ydelsesbeløb Ydelsessats Ægtefælle Se Ydelsesart Ydelsesart er en specifik type af ydelse. Det kan fx være kontanthjælp, revalideringsydelse osv. Se en oversigt over ydelsesarter i underbilag Det beløb, der er specificeret i ydelsessatsen den pågældende periode. Sats, der refererer til specifik paragraf, styk, punkt i loven, typisk Aktivloven (LAS). Kontanthjælpssats og Revalideringsydelsessats er eksempler på ydelsessatser. Til hver sats svarer et beløb, som gælder for en periode af en specificeret længde. Beløbet fastsættes årligt i vejledning fra AMS. Den person, som er gift med Ansøger. Hertil regnes også personer, der har indgået registreret partnerskab før medio Såfremt der er indgået separation eller skilsmisse, anses Personen for at være enlig. Tabel 2: Begrebsdefinitioner 3.2 Beriget konceptuel model (informationsmodel) Informationsmodellen viser Løsningens centrale informationer og deres attributter på et overordnet plan. De informationer, som anvendes i sagsbehandlingen er beskrevet på et ikke-udtømmende niveau i informationsmodellen i underbilag 2.5. Modellen er opdelt i et antal delmodeller, hvoraf nogle beskriver generelle begreber såsom Sag og Dokument, og andre beskriver de ydelsesspecifikke detaljer. Modellerne er udarbejdet, så de så vidt muligt følger et ensartet mønster med ensartede pakker i de enkelte delmodeller, såfremt pakken er relevant for den pågældende delmodel. Krav# 3: Informationsmodel Beskrivelse: Leverandøren skal anvende de udarbejdede informationsmodeller i Løsningen beskrevet i underbilag 2.5. som grundlag for udarbejdelse af Løsningens logiske datamodel. - Se underbilag 2.5 Informationsmodel. 3.3 Ydelsesarter Løsningen skal anvendes til kommunernes behandling af sager om bevilling og udbetaling af en række ydelser samt administrationssager. Disse introduceres kort nedenfor, og en samlet oversigt over ydelsesarter fremgår af underbilag Forsørgelsesydelser er de løbende ydelser efter Lov om aktiv socialpolitik: Uddannelseshjælp, kontanthjælp, revalideringsydelse, ressourceforløbsydelse og ledighedsydelse samt fleksløntilskud efter Lov om en aktiv beskæftigelsesindsats. Dertil kommer opkrævning af fleksydelsesbidrag (der ligner efterlønsbidrag) og beregning og udbetaling af fleksydelse (der ligner efterløn). Fælles for forsørgelsesydelserne er, at de i vidt omfang skal understøttes med et beregningsmodul i Løsningen. Modulet skal også foretage beregning og træk af ATP og skat. Side 15 af 255

16 Enkeltydelser er hjælp i særlige tilfælde efter Lov om aktiv socialpolitik kap. 10, og integrationslovens kap. 6. Det drejer sig om hjælp til rimeligt begrundede enkeltudgifter, hjælp til udsættelsestruede, hjælp til sygebehandling, hjælp til tandbehandling, hjælp til samværsudgifter, hjælp til forsørgelse af forældreløse børn og hjælp til flytning. Andre ydelser er en ydelsesart, der kan udbetales gennem Løsningen, men som hovedregel ikke understøttes beregningsmæssigt ud over skatteberegning. Det er fx helbredstillæg, udvidet helbredstillæg og personlige tillæg efter pensionslovene samt forskellige løbende økonomiske ydelser efter Lov om social service, fx merudgiftsydelse til børn med handicap, merudgifter til voksne og forskellige ydelser til forældre med børn. Dertil kommer en række ydelser efter Lov om en aktiv beskæftigelsesindsats, fx befordringsgodtgørelse efter 82 og godtgørelse til udgifter ved aktivering efter 83, tilskud til mentorordning og lign. mv. Administrationssager er sager, hvor kommunen har truffet afgørelse om hel eller delvis administration af en ydelsesmodtagers økonomi efter LAS 90 eller har indgået en frivillig aftale med personen. Dertil kommer et antal pensionister, hvor der efter pensionslovene er truffet beslutning om administration eller indgået frivillig aftale om administration af den pension, som beregnes og udbetales fra Udbetaling Danmark. Krav# 4: Understøttede ydelsesarter Kategori: (MK) Type: Funktionelt Beskrivelse: Løsningen skal ved idriftsættelse kunne håndtere behandlingen af de ydelsesarter, der er omfattet af Løsningen. Følgende ydelsesarter kan håndteres: Uddannelseshjælp, herunder særlig støtte Kontanthjælp, herunder særlig støtte Ledighedsydelse Revalideringsydelse Fleksydelse Fleksløntilskud Ressourceforløbsydelse Enkeltydelser Andre ydelser Administration af persons økonomi - Se specifikation af ydelsesarter i underbilag Ydelsesart / Aktivitet Opret sag Oplys sag Sagsog opgavefordeling Fastsæt ydelsessats og beregn Afslut og arkiver Træf afgørelse Effektuer Vedligeholdelse af sag Side 16 af 255

17 ydelse Kontanthjælp X X X X X X X X Uddannelseshjælp X X X X X X X X Ledighedsydelse X X X X X X X X X X X X X X X X Fleksydelse X X X X X X X X Fleksløntilskud X X X X X X X X Revalideringsydelse Ressourceforløbsydelse X X X X X X X X Enkeltydelser X X X X X X X Andre ydelser X* X X* X* X X X* Administration af persons økonomi X X X X X X X Tabel 3: Oversigt over systemunderstøttelse af ydelsesarter. *Se nedenstående beskrivelse For andre ydelser vil aktiviteter markeret med * kun være understøttet i og med, at funktionaliteten er tilvejebragt via de andre ydelsesarter, som fx kontanthjælp. Andre Ydelser kan eksempelvis benytte sags- og opgavefordelings-aktiviteten, da det vil give fin mening at modtage opgaver vedrørende fx flyttebeskeder fra CPR. Men det er ikke tænkt, at alle relevante beskeder på Andre Ydelser vil være en del af Løsningen. På samme måde vil der i udgangspunktet ikke være brevskabeloner specifikt til Andre Ydelser, men de brevskabeloner, der er lavet til de andre ydelsesarter, kan benyttes, hvor det er relevant. Andre Ydelser forventes således ikke at være fuldt understøttet på samme måde som de andre Ydelsesarter. 3.4 Processer I dette afsnit præsenteres de fremtidige processer (to be) hos Ydelsescentret, der fremover vil blive it-understøttede af Løsningen. Beskrivelsen af processerne har til formål at give en forretningsorienteret og sammenhængende præsentation af det fremtidige forløb af aktiviteter hos forskellige involverede aktører i forbindelse med behandlingen af ydelsessager. Dette skal sikre, at Leverandøren har forståelse for den forretningsmæssige virkelighed, som Løsningen skal anvendes i. De forretningsprocesser, som løsningen skal understøtte, er beskrevet i underbilag 2.3 med diagrammer og tilhørende procesbeskrivelser. Her er følgende processer beskrevet: Processen vedr. uddannelseshjælp eller kontanthjælp (inkluderer særlig støtte). Processen vedr. ledighedsydelse. Processen vedr. revalideringsydelse. Processen vedr. fleksydelse. Side 17 af 255

18 Processen vedr. ressourceforløbsydelse. Processen vedr. fleksløntilskud. Processen vedr. enkeltydelser. Processen vedr. udbetaling af andre ydelser. Processen vedr. administration af Persons økonomi. Krav# 5: Procesmodeller Beskrivelse: Leverandøren skal understøtte de ni udarbejdede procesmodeller i Løsningen beskrevet i underbilag 2.3. Se underbilag 2.3 Processer. 3.5 Aktører Løsningen indgår i et samspil med en række forskellige brugeraktører og systemaktører. De forskellige aktører gennemgås i den følgende beskrivelse Kontekstdiagram Aktørerne i Løsningen er opdelt i: Brugeraktører, dvs. brugere, som via brugergrænsefladen arbejder med Løsningen. Systemaktører, dvs. andre it-systemer eller services, som skal interagere med Løsningen. De forskellige brugeraktører er vist i nedenstående kontekstdiagram. Systemaktører er beskrevet i afsnit 6.4. Figur 2: Kontekstdiagram brugeraktører Side 18 af 255

19 3.5.2 Brugeraktører De forskellige brugeraktører er beskrevet herunder. Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Person En Person der søger om en ydelse og/eller eventuelt også modtager en ydelse (forsørgelsesydelse, enkeltydelse eller andre ydelser ) i kommunen Kan desuden være under administration af kommunen. Søger ydelsen og skal levere en mængde dokumentation for at modtage denne ydelse. Kan både søge ydelser via Selvbetjeningsløsningen eller via en papiransøgning. Er som udgangspunkt bosat i kommunen På landsplan var der i 2012 ca såkaldte helårsmodtagere af forsørgelsesydelser (svarende til ca berørte personer) på beskæftigelsesområdet. Hertil kommer personer, som modtager ydelser på øvrige delområder. Sagsbehandler (Ydelsescentret) Sagsbehandleren er den primære aktør i forhold til brugen af systemet. Benytter systemet til at udføre sin primære arbejdsopgave, som er behandling af ansøgninger og udbetaling af forsørgelses- eller enkeltydelser. Sagsbehandleren kan anvende selvbetjeningsløsningen med samtykke fra en Person, der har en sag i Løsningen, og har brug for hjælp til at anvende selvbetjeningsløsningen. Benytter Løsningen til at behandle ansøgninger samt udbetale ydelser. Vil som oftest være placeret i kommunens ydelsescenter eller evt. borgerservice. Nogle kommuner vil have opgaven opdelt i to, således at en gruppe håndterer borgerkontakt og ansøgninger, mens en anden gruppe håndterer selve udbetalingerne (inkl. løbende sagsopfølgning). I større kommuner kan det være opdelt i mange forvaltninger. På landsplan eksisterer der ca personer (estimeret). Sagsbehandler (Jobcenter) Der er et tæt samspil mellem jobcenter og ydelsescentret. Således kan der også være situationer, hvor jobcentersagsbehandleren har brug for at kigge i en Side 19 af 255

20 Navn Ansvar Org. og geografisk placering Antal/Kapacitet Sagsbehandler (Jobcenter) ydelsessag. Jobcentersagsbehandleren har ikke behov for at kunne arbejde i Løsningen men har behov for en læseadgang, så han/hun kan se, hvad der er sket i ydelsessagen. Benytter Løsningen til at slå ydelsessager op i forbindelse med behandling af en jobcentersag. Vil som oftest være placeret i kommunens jobcenter. Det vil være forskelligt i kommunerne, hvordan de vil give jobcentersagsbehandlerne adgang til ydelsessager, og adgangen vil ikke nødvendigvis ske via Løsningen. Det kan fx også ske via SAPA-løsningen. I det tilfælde vil Jobcentersagsbehandlerne ikke benytte Løsningen. På landsplan eksisterer der ca personer (estimeret). Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Sagsbehandler (Anden forvaltning) En sagsbehandler i en anden del af forvaltningen, der er interesseret i at vide noget om en sag i Løsningen (læse sager). Adgangen til sagen vil som hovedregel ske via SAPA, og dermed vil Løsningen ikke blive direkte påvirket. Enkelte kommuner kan dog vælge at give specifikke medarbejdere adgang til Løsningen. Dette kunne fx være relevant i forbindelse med andre ydelser. Benytter Løsningen til at slå ydelsessager op i forbindelse med behandling af en sag i en anden forvaltning i kommunen. Andre forvaltninger i kommunen. Det forventes, at antallet af sagsbehandlere fra andre forvaltninger, der har direkte adgang til Løsningen, vil være på et lavt niveau. Estimeret 300 personer. Kommunal administrator En medarbejder i kommunen der har adgang til det kommunale administrationsmodul i Løsningen. Benytter Løsningen til at foretage de lokale konfigurationer, så de svarer til kommunens behov. Kan være placeret i ydelsescentret, fx en erfaren sagsbehandler. Kan også være placeret centralt, som fx en kommunal systemejer. På landsplan eksisterer der ca personer (estimeret). Central administrator Side 20 af 255

21 Navn Central administrator Rolle Personen har adgang til det centrale administrationsmodul. Personen sørger for, at Løsningen er opsat og opdateret i forhold til nyeste lovgivning (fx opdatering af satser), jf. i øvrigt de omfattede krav til systemadministration. Ansvar Benytter Løsningen til at foretage de centrale konfigurationer. Org. og geografisk placering eller KL. Alternativt kan rollen placeres hos en eller Kan være centralt placeret, eksempelvis hos KOMBIT flere nærmere udvalgte kommuner. Antal/Kapacitet 1-10 Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Statslig/Kommunal tilsynsmyndighed Der vil både foretages intern kontrol (fx økonomiafdelingen) samt ekstern revision (v. revisor). Det er tilsynsmyndighedens ansvar at kontrollere korrekt/lovmedholdelig opgavehåndtering, -flow og dokumentation (herunder korrekt valg af refusionstype). Benytter Løsningen til at fremsøge sager, der skal foretages kontrol af. Kan være centralt placerede medarbejdere i Ydelsescentret (intern kontrol). Eksterne revisionsfirmaer (ekstern kontrol). Intern kontrol: 1-10 i hver kommune (estimeret). Ekstern kontrol: 2-5 i hver kommune (estimeret). Navn Kommunal mellemleder Rolle Kan være en teamleder i ydelsescentret eller borgerservice, der har ansvaret for en gruppe af sagsbehandlere. Ansvar Benytter Løsningen til at udtrække forskellige typer af ledelsesinformation via rapporter i Løsningen. Org. og geografisk placering Vil typisk være placeret i ydelsescentret. Antal/Kapacitet På landsplan eksisterer der Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Kommunalt kontrolteam Sagsbehandlere eller andre kommunale medarbejdere med erfaring fra området. Kontrollerer for socialt bedrageri i forbindelse med ydelsessager. Benytter Løsningen til at udsøge sager til kontrol. Vil typisk være placeret i ydelsescentret. På landsplan eksisterer der 1-4 i hver kommune (estimeret). Side 21 af 255

22 De følgende to aktører er en uddybning af aktøren Person, som benyttes i Selvbetjeningsafsnittet (jf. Afsnit 5.9) Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Navn Rolle Ansvar Org. og geografisk placering Antal/Kapacitet Digital Ansøger En Digital Ansøger er en person med NemID, der logger ind på Selvbetjeningsløsningen for at ansøge om en ydelse (jf. fx afsnit NemLog-in (Digital Fuldmagt)). En Digital Ansøger kan også tilgå Selvbetjeningsløsningen og udstede en fuldmagt til en Tilknyttet Ansøger, som herefter kan udarbejde hele eller dele af en ansøgning. Se borger/person. Se borger/person. Ca om året. Tilknyttet Ansøger En Tilknyttet Ansøger er en person, som logger ind på Selvbetjeningsløsningen og benytter Selvbetjeningsløsningen enten via en fuldmagt, der er givet af en Registreret Ansøger (fuldmagtsgiveren) eller via invitation fra ægtefælle eller samlever. Denne ansøger anvender ligeledes NemID. Se borger/person. Se borger/person. Se borger/person. Krav# 6: Brugeraktører som understøttes af Løsningen Beskrivelse: Løsningen skal understøtte følgende brugeraktører: Person Sagsbehandler (Ydelsescentret) Sagsbehandler (Jobcentret) Sagsbehandler (anden forvaltning) Kommunal administrator Central administrator Kommunal/statslig tilsynsmyndighed Kommunal mellemleder Kommunalt kontrolteam Side 22 af 255

23 4 Overordnede krav I dette kapitel angives helt overordnede krav, som gælder på tværs af de ydelser og processer, som Løsningen skal understøtte. Krav# 7: Løsningen skal overholde gældende lovgivning Kategori: (MK) Type: Funktionelt Beskrivelse: Løsningen skal ved overtagelsesprøven overholde gældende relevant lovgivning. Se underbilag 2.8 for en oversigt over relevant lovgivning. Bemærkning Kravet gælder generelt og med et særligt fokus på fastsættelse af ydelsessatser og beregninger samt behandling og opbevaring af sagsrelaterede informationer. Krav# 8: Gem alle oplysninger Beskrivelse: Alle oplysninger, der indberettes eller indhentes, beregnes mv., skal automatisk gemmes på sagen. a) Hvis der er indberettet eller indhentet data i Løsningen, er det gemt i databasen. b) Hvis der er beregnet beløb, er de gemt i databasen. Bemærkning - Se informationsmodellen i underbilag Funktionelle krav Dette kapitel indeholder KOMBITs krav til Løsningens funktionalitet. Figur nedenfor giver et overblik over, hvilke områder de funktionelle krav er inddelt i, hvor nummeret indikerer i hvilket afsnit i kravspecifikationen, de givne krav er beskrevet. Side 23 af 255

24 Opgaver og sager Behandling af ydelsessager Administration af Persons økonomi Tværgående funktionalitet Visninger Håndter opgave vedrørende sag Systemadministration Rapporter og udtræk Selvbetjening Krav til dataudveksling Figur 3: Overblik over funktionelle krav Hvert afsnit i de funktionelle krav bliver indledt med en beskrivelse af den forretningsmæssige kontekst og forretningsbehovet, samt eventuelle start- og slutbetingelser. Beskrivelsen er efterfulgt af en række tekstuelle krav. Kravene tager udgangspunkt i en eller flere af de kortlagte forretningsbehov og processer, hvor forretningsprocesserne er beskrevet nærmere i underbilag 2.3. Her følger en beskrivelse af indholdet i hvert afsnit: Afsnit 5.1 indeholder en beskrivelse af, hvordan der oprettes og fordeles opgaver. Hvordan sager oprettes, og hvordan sager og opgaver hænger sammen. Afsnittet indeholder også en beskrivelse af, hvordan en sagsbehandler læser og løser opgaven. Afsnit 5.2 indeholder meget af kernefunktionaliteten i Kommunernes Ydelsessystem; det at behandle en ydelsessag. Fra oplysning af sagen, beregning af ydelsen, afgørelsen, effektueringen, vedligeholdelse af sagen samt afslutningen af sagen. Nedenstående Figur giver indsigt i de aktiviteter, der typisk udføres i forbindelse med opgavehåndteringen samt behandlingen af en ydelsessag, illustreret i den hyppigst forekommende sekvens i en sagsbehandlers arbejde. Figuren skal således ikke ses som en udtømmende illustration, og der vil være afvigelser, men den giver et godt indblik i det normale flow. De øverste fem aktiviteter beskrevet i afsnit 5.1 og de nederste seks aktiviteter er beskrevet i afsnit 5.2. Nummeret i hver aktivitet henviser til det underafsnit, hvor aktiviteten samt krav er beskrevet. I underafsnittene i 5.1 og 5.2 vil dele af denne figur være indsat for at tydeliggøre, hvor i processen man befinder sig. Side 24 af 255

25 5.1.1 Fremsøg sag Opret opgave Fordel opgave 5.1 Opgaver og sager Opret sag Læs og løs opgave Oplys sag Fastsæt ydelsessats og beregn ydelse Træf afgørelse Effektuer Vedligeholdelse af sag Afslut sag 5.2 Behandling af ydelsessager Figur 4: Oversigt over underafsnit struktureret efter processen Afsnit 5.3 indeholder beskrivelse af håndtering af de sager, hvor kommunen administrerer Personens økonomi. Det er i de tilfælde, hvor Personen ikke er i stand til at administrere sin egen økonomi, fx betale husleje, el, vand osv. Afsnit 5.4 indeholder en beskrivelse af tværgående funktionalitet, som benyttes på tværs af de tre foregående afsnit. Fx benyttelse af breve og brevskabeloner, som både er relevante i afsnit 5.1, 5.2 og 5.3. Afsnit 5.5 indeholder en beskrivelse af forskellige visningskrav. Det vil sige funktionelle krav til brugergrænsefladen, således at brugernes arbejdsgange understøttes i så høj grad som muligt. Dette skal ikke forveksles med brugervenlighedskrav, som er beskrevet i afsnit 6.4. Afsnit 5.6 indeholder en beskrivelse af en række opgaver, der vedrørende sager, men ikke er den egentlige behandling af ydelsessager. Det er fx forskellige former for kontrol, samling af sager til aktindsigt mm. Afsnit 5.7 indeholder beskrivelse af systemadministrations-funktionaliteten. Det er både en central systemadministration, der gælder på tværs af alle kommunerne og en lokal systemadministration, hvor den enkelte kommune kan konfigurere forskellige dele af Løsningen. Afsnit 5.8 indeholder beskrivelse af rapport og udtræksfunktionaliteten. Her beskrives hvilke muligheder, der er for Ledelsesinformation og statistik i Løsningen. Afsnit 5.9 indeholder beskrivelse af de funktionelle krav til selvbetjeningsløsningen. Side 25 af 255

26 Afsnit 5.10 indeholder beskrivelse af, hvordan Løsningen udveksler data med andre myndigheder og organisationer. Afsnittet er et slags bindeled mellem nogle af de funktionelle krav og de nonfunktionelle integrationskrav. Et Typisk scenarie For at give en meget kort introduktion til omfanget af systemet kommer her en meget kort scenariebeskrivelse af et typisk forløb for brugen af Løsningen. Vær opmærksom på at scenariet ikke er et udtømmende billede, men en hurtig oversigt over den vigtigste funktionalitet. Tallet i parentesen henviser til det afsnit, hvor kravene er beskrevet. - En Person søger om kontanthjælp via selvbetjeningsløsningen (5.9). - Løsningen opretter automatisk sagen (5.1.4) o og alle de data, Personen har indtastet i selvbetjeningsløsningen, overføres automatisk til sagen. - Løsningen opretter en opgave vedrørende behandling af ansøgningen (5.1.2). - Løsningen fordeler automatisk opgaven til den rette sagsbehandler ud fra kommunens fordelingskriterier (5.1.3). - Løsningen slår op i en række eksterne registre for at indhente oplysninger, der er nødvendige for at behandle sagen (5.2.1). - Sagsbehandleren oplyser sagen i Løsningen (5.2.1). - Løsningen fastsætter ydelsessatsen og beregner den forventede ydelse (5.2.2). - Sagsbehandleren afgør sagen og benytter en brevskabelon til at skrive en bevillingsskrivelse til Personen (5.2.3 og 5.4.3). - Løsningen bestiller en udbetaling i udbetalingssystemet (der sætter pengene ind på Personens konto) (5.2.4). - De efterfølgende måneder sker udbetalingerne automatisk, og sagsbehandleren er ikke i kontakt med sagen (5.2.4). - Løsningen modtager en besked fra CPR, når Personen er fraflyttet kommunen (5.2.5). - Løsningen stopper automatisk den næste udbetaling og opretter en opgave til sagsbehandleren (5.2.5). - Sagsbehandleren behandler opgaven og træffer afgørelse om at lukke sagen (5.2.3). - Sagsbehandleren skriver et journalnotat og benytter brevskabelonen til at sende et afgørelsesbrev til Personen (5.4.4 og 5.4.3). - Løsningen ændrer sagens status til lukket (5.2.6). - Når kassationsfristen 5 år efter udløber, slettes sagen (5.2.6) 5.1 Opgaver og sager Sagsbehandleren løser dagligt en række forskellige arbejdsopgaver i forbindelse med behandlingen af ydelsessager. En sagsbehandler vil overordnet modtage disse arbejdsopgaver på to måder. (A) Enten som en integreret del af Løsningen i form af opgaver eller (B) ved henvendelser der genererer manuelle arbejdsopgaver. Det kan fx være et telefonopkald, en , eller at en borger henvender sig personligt. Dette er skitseret i Figur nedenfor. Side 26 af 255

27 A: Opgaver der er oprettet i Løsningen B: Henvendelser der generer manuelle arbejdsopgaver Telefonopkald Arbejdsopgaver Opgavelisten Arbejdsopgaver Sagsbehandler Arbejdsopgaver Arbejdsopgaver s Personlige henvendelser Figur 5: Kilder til arbejdsopgaver hos en sagsbehandler De manuelle arbejdsopgaver, der er genereret ved henvendelser, vil sagsbehandleren typisk behandle ved først at fremsøge den relevante sag, som henvendelsen drejer sig om. Sagsbehandleren vil, når hun har fremsøgt sagen, behandle arbejdsopgaven i Løsningen på samme måde som de opgaver, der er oprettet i Løsningen. Opgavelisten viser alle de opgaver, der er oprettet i Løsningen. Det kan fx være på baggrund af beskeder fra eksterne systemer eller interne systemregler. Opgaver vil blive oprettet løbende og kan både blive oprettet automatisk af Løsningen eller manuelt af en bruger. Opgavelisten har overordnet to formål: a) At give let mulighed for at fordele opgaver (afsnit 5.1.3). Hver enkelt opgave skal som udgangspunkt tilknyttes en sag (en eksisterende eller nyoprettet sag) samt fordeles til en sagsbehandler eller et team, før den kan behandles. b) At give den enkelte sagsbehandler overblik over de opgaver, denne skal løse (afsnit 5.1.5). Dette skal ses som sagsbehandlerens mulighed for at styre, prioritere sine opgaver og overholde deadlines etc. I Figur nedenfor har Kunden forestillet sig, hvordan en opgaveliste kunne se ud, blot for at give en visuel beskrivelse af konceptet. Opgavelisten kunne indeholde en lang liste med opgaver, hvor hver opgave indeholder en række relevante informationer, der understøtter de to ovenfor beskrevne formål. Det kunne fx være Opgavetitel, CPR nummer på den primære part i sagen, hvilken sagsbehandler opgaven er fordelt til osv. Der er filtrering og sorteringsmekanismer, som gør, at det er muligt hurtigt at fremfinde de opgaver, der er relevante for den enkelte sagsbehandler. Side 27 af 255

28 Opgaveliste Opgave Ydelsesart CPR blabla Sag Sagsbehandler Indkomst ændret Kontanthjælp AOH Dokument modtaget Opfølgning Kontanthjælp Ansøging Enkeltydelse AOH Tidsfrist partshøring Kontanthjælp SKI Figur 6: Konceptuel tegning af opgaveliste I de efterfølgende afsnit beskrives hvordan opgaverne oprettes, hvordan de fordeles og hvordan sagsbehandleren benytter opgavelisten som arbejdsredskab. Se desuden afsnit for krav til visninger vedrørende opgavelisten. Der beskrives også, hvordan opgaver hænger sammen med sager, og hvordan det ud over opgavefordeling også er muligt at fordele sager. Underafsnittene i afsnit 5.1 vil følge den tidligere beskrevne struktur fra Figur. Underafsnittene følger således den typiske proces ved håndtering af opgaver og sagsoprettelser. Nedenfor vises et udsnit af Figur, hvor afsnit 5.2 er foldet sammen, så det kun er aktiviteterne i afsnit 5.1, der vises. Nummeret i hver aktivitet henviser til de pågældende underafsnit, der beskriver aktiviteten. Side 28 af 255

29 5.1.1 Fremsøg sag Opret opgave Fordel opgave Opret sag Læs og løs opgave 5.1 Opgaver og sager 5.2 Behandling af ydelsessager Figur 7: Udsnit af " Oversigt over underafsnit struktureret efter processen" Fremsøg sag Som beskrevet tidligere skal sagsbehandleren hurtigt kunne fremsøge relevante sager ved forskellige typer af henvendelser. Ofte kan henvendelsen ske, mens sagsbehandleren er i gang med at behandle en anden opgave. Krav# 9: Fremsøgning af sager Beskrivelse: Brugeren har let adgang til søgefelt, hvor sager kan fremsøges. a) Brugeren kan ved maksimalt to klik/tastetryk få adgang til søgefeltet fra hvilket som helst skærmbillede i Løsningen. b) Ved søgning på sagsid vises den relevante sag. c) Ved søgning på CPR vises alle de sager, hvor det givne CPR nummer er part i sagen. d) Ved søgning på CPR nummer er det muligt at benytte CPR intervaller. e) Ved søgning på navn vises alle de sager, hvor navnet indgår som part i sagen. f) Ved søgning på adresse vises alle de sager, hvor en part i sagen bor på adressen. g) Ved søgning på fødselsdato og år vises alle de sager, hvor en part i sagen har fødselsdato og år h) Ved søgning på sagsbehandler/team vises alle de sager, hvor sagsbehandler/team er aktør på sagen. i) Ved søgning på sagsstatus vises alle de sager, der har den angivne status. De endelige søgemuligheder afklares af Kunden i samarbejde med Leverandøren i Designfasen. Side 29 af 255

30 Bemærkning Opret opgave Opgaver kan oprettes i Løsningen via fire overordnede kilder. De kan oprettes på baggrund af: - en besked/kald fra et eksternt system (fx en flyttebesked fra CPR) - en intern systemregel, der danner en opgave (fx i forbindelse med en tidsfrist) - en manuel brugeroprettet opgave - Modtagelsen af et dokument fra et eksternt system (fx et brev fra den kommunale postscanningsenhed) Alle disse forskellige typer af opgaver vil vises på opgavelisten. Dette er illustreret i Figur nedenfor. Kilder til oprettelse af opgaver Besked/ kald modtaget Dokument modtaget Opret opgave Opgave vises på opgavelisten Manuel opgave (påmindelse) Intern regel Figur 8: Kilder til oprettelse af opgaver Side 30 af 255

31 Krav# 10: Oprettelse af opgaver Beskrivelse: Løsningen kan oprette opgaver. a) Der kan oprettes opgaver manuelt af sagsbehandleren. b) Der kan oprettes opgaver automatisk af Løsningen på baggrund af interne regler. c) Der kan oprettes opgaver automatisk via beskeder/kald fra eksterne systemer. d) Der kan oprettes opgaver automatisk via indkomne dokumenter eller via ansøgning fra selvbetjeningsløsningen. e) Alle oprettede opgaver vises på en opgaveliste. f) Så mange informationer som muligt skal automatisk udfyldes ved opgaveoprettelse. - Se afsnit Vedligeholdelse af sag for en række krav og beskrivelser i forhold til oprettelse af opgaver. - Se afsnit for manuelt oprettede opgaver, jf. punkt a. - Se Krav# 93 vedrørende automatiske reaktioner på hændelser og interne regler, jf. punkt b og c. - Beskeder/integrationer kan fx være beskeder fra Beskedfordeleren eller fra den direkte integration fra Jobcentret, jf. punkt c. - Se afsnit vedrørende oprettelse af opgaver på baggrund af indkomne dokumenter, jf. punkt d. - Se afsnit vedrørende ansøgninger fra selvbetjeningsløsningen. - Se Krav# 190 vedrørende anmodninger om sagsoverførsler. - Se informationsmodellen KY-sag i underbilag 2.5. Krav# 11: Informationer på en opgave Beskrivelse: En opgave indeholder som minimum følgende informationer: - Opgavetype/titel - Ydelsesart (kontanthjælp, enkeltydelse, etc.) - Person opgaven omhandler (CPR + navn) - Sagen (Sagsnummer) - Sagsbehandler (navn eller team) - Dato for oprettelse af opgaven - Status for opgaven (ubehandlet, under behandling, afsluttet) - Deadline for løsning af opgave - Distrikt/område - Prioritet - Ydelse sat på hold - Opgavebeskrivelse - Frekvens ved tilbagevendende opgave Side 31 af 255

32 Opgavetypen skal kort og præcist afspejle den hændelse, der har udløst opgaven. Den endelige liste - med hvilke informationer en opgave indeholder - afklares med Leverandøren. Den endelige formulering af opgavetyper afklares med Leverandøren. - Ydelsesart er beskrevet i Krav# 4. - I bilag 2.13 findes en oversigt over de hændelser, der indtræffer, som brugeren skal reagere på. Dette vil være input til de forskellige opgavetyper. - Følgende er eksempler på opgavetyper o Ansøgning o Indstilling o Flyttemeddelelse o Indkomstændring Manuelt oprettede opgaver (påmindelser) I forbindelse med behandling af en sag, vil der være ofte være tilfælde, hvor brugeren bliver nødt til at lægge sagen til side for på et senere tidspunkt at genoptage sagen. I de tilfælde er der behov for, at brugeren bliver påmindet om sagen, så den ikke glemmes. Brugeren kan derfor oprette en opgave til sig selv og derigennem påmindes via en manuelt oprettet opgave på opgavelisten. Der kan også være andre situationer, hvor det kan være relevant at oprette manuelle opgaver. Krav# 12: Manuelt oprettet opgave Beskrivelse: Brugeren kan oprette en opgave. a) Brugeren kan oprette en opgave via sagen a. Der dannes i dette tilfælde automatisk en relation til sagen b) Brugeren kan oprette en opgave uden relation til en sag. c) Opgaven indeholder samme informationer som beskrevet i Krav# 11. d) Brugeren kan redigere alle data på opgaven. e) Ydelsesart, Person, sagsnummer og dato for oprettelse af opgaven er forudfyldt, hvis opgaven er oprettet via en sag. f) Det er muligt at oprette en opgave, der gentages. Det kan vælges med hvilken frekvens, opgaven gentages. Ofte vil en bruger benytte de samme opgaver mange gange. For at undgå at brugeren skal indtaste alle data på opgaven hver gang, kan brugeren vælge mellem en række forskellige standardopgaver, hvor den kommunale administrator har forudfyldt en række felter. Side 32 af 255

33 Krav# 13: Standardopgaver Beskrivelse: Ved oprettelse af en opgave er det muligt for brugeren at tage udgangspunkt i en række af standard-opgaver. - Se Krav# 12 om oprettelse af opgave. - Se Krav# 206 for konfigurering af standardopgaver Opgaver opretter på baggrund af indkomne dokumenter Løsningen kan modtage dokumenter via den udstillede service Dokumentservice, hvilket er beskrevet i afsnit Ved modtagelse af disse dokumenter skal Løsningen oprette en opgave, så sagsbehandleren kan behandle det indkomne dokument. Kunden forestiller sig, at det typisk vil være dokumenter fra kommunale ESDH systemer, den kommunale scanningsenhed (scannet papirpost) og andre kommunale fagsystemer. Men da det er eksterne systemer, der sender dokumenter til Dokumentservice, er det ikke muligt at vide, hvor mange og hvor præcise metadataene på dokumentet er. Ønsket er, at jo flere metadata der er på dokumentet, jo flere data kan opgaven oprettes med. Ved fx modtagelse af et indscannet dokument fra postscanningsenheden, vil det således være forskelligt, hvor mange metadata der er på dokumentet og dermed hvor mange data, der kan overføres til opgaven. Se desuden krav vedrørende dokumenter og håndtering heraf i afsnit Dokumenter. Krav# 14: Oprettelse af opgave ved modtagelse af dokumenter Beskrivelse: Løsningen kan ved modtagelse af dokumenter via Dokumentservicen oprette en opgave og tilknytte de relevante metadata fra dokumentet på opgaven. - Metadata på dokumentet kunne fx være KLE nummer, Personens CPRnummer. Sagsbehandlerens navn osv. - Se Krav# 17 vedrørende tilknytning af dokumenter til en opgave. - Se afsnit vedrørende Dokumentservice). - Se informationsmodellen (KY-dokument, KY-sag) i underbilag Fordel opgave Fordeling af opgaver består af to ting. For at kunne behandle en opgave skal: - Opgaven skal være tilknyttet en sag - Opgaven skal være tildelt en sagsbehandler eller et sagsbehandler-team. I nogle tilfælde vil alle informationerne på en opgave være udfyldt ved opgaveoprettelse (se afsnit og vedrørende automatisk fordeling), herunder både sag og sagsbehandler. Dermed vil opgaven kunne fordeles automatisk. Andre gange vil der mangle informationer, så den ikke kan fordeles automatisk. Så skal opgaven fordeles manuelt. Side 33 af 255

34 I nogle kommuner vil der være en medarbejder, der er dedikeret til at fordele opgaverne, i andre kommuner vil det være sagsbehandleren selv, der både fordeler og efterfølgende behandler sagerne. På den samlede liste over opgaver vil der altså være både opgaver, der er tilknyttet eksisterende sager, og der vil være opgaver, der endnu ikke er tilknyttet nogen sag. Opgaven vil som hovedregel altid skulle være tilknyttet en sag for at kunne behandles. Det betyder, at opgaven skal tilknyttes en sag, og hvis den ikke kan tilknyttes en eksisterende sag, skal der oprettes en ny sag, hvor den kan tilknyttes. Dette er illustreret i Figur nedenfor. Opgave oprettet Tilføj evt. andre oplysninger Opret ny sag og tilknyt opgave til denne Tilknyt opgave til eksisterende sag Tildel sagsbehandler Figur 9: Tilknytning af opgave til sag samt tildeling af sagsbehandler 4 Opgave fordelt / klar til behandl ing Da det ikke altid vil være muligt at vide hvor mange informationer, der er udfyldt, når opgaven oprettes, skal det være muligt for sagsbehandleren at tilføje og redigere oplysningerne på opgaven (via opgavelisten), så den bliver lettere at fordele korrekt. Dette er selvfølgelig relevant i forhold til sag og sagsbehandler, men også andre informationer såsom CPR-nummer eller ydelsesart kan være relevant at tilføje, for at den dermed lettere kan blive endeligt fordelt. Krav# 15: Tilføjelse af manglende oplysninger på en opgave Beskrivelse: Det er muligt for brugeren at tilføje eventuelt manglende oplysninger samt redigere eksisterende oplysninger for hver opgave. - a) Brugeren kan tilføje, slette og redigere oplysningerne på en opgave. b) Tilføjelse, redigering kan foretages direkte fra opgavelisten. c) Tilføjelse, redigering kan foretages direkte fra selve opgaven. d) Når brugeren tilknytter en opgave til en sag, er det muligt at vælge en eksisterende sag eller at oprette en ny sag. Se Krav# 21 vedrørende manuel oprettelse af sag. Krav# 16: Massebehandling af opgaver Beskrivelse: Brugeren kan massebehandle opgaver. 4 Rækkefølgen på tilføjelse af andre oplysninger, tilknytning af sag og Tildeling af sagsbehandler kan ske i vilkårlig sekvens. Side 34 af 255

35 - a) Brugeren kan tilføje, slette og redigere oplysningerne på flere opgaver samtidigt. Med massebehandling menes fx at fordele flere opgaver samtidig (fordele en række opgaver til en ny sagsbehandler) eller at ændre status på flere opgaver samtidig (afslutte en række opgaver samtidigt). Nogle opgaver er oprettet på baggrund af, at Løsningen har modtaget et dokument (se afsnit ). Løsningen har i disse tilfælde dannet en opgave, hvor dokumentet er tilknyttet. I disse tilfælde vil brugeren ofte skulle læse dokumentet inden, opgaven kan fordeles. Krav# 17: Opgaver med tilknyttede dokumenter Beskrivelse: Hvis der er tilknyttet et dokument på en opgave, er der let adgang til at læse dokumentet. - a) Brugeren kan direkte fra selve opgaven få adgang til at læse dokumentet. b) Brugeren kan direkte fra opgavelisten få adgang til at læse dokumentet. c) Når opgaven tilknyttes en sag, gemmes dokumentet automatisk på den givne sag. d) Det er muligt at kopiere dokumentet til flere sager (I det tilfælde at dokumentet er relevant for flere sager). Se Krav# 120 for manuel tilknytning af dokumenter til sag Automatisk tilknytning af opgave til sag Hvor det giver forretningsmæssig mening, bør opgaven tilknyttes automatisk til sagen. Det betyder, at hvis der er en entydig relation mellem opgaven og sagen, skal tilknytningen ske automatisk. Hvis der derimod kan være tvivl om hvilken sag, opgaven tilhører, bør tilknytningen ikke ske automatisk. Der vil fx oftest være en entydig relation, hvis det drejer sig om upload af et nyt dokument til en eksisterende sag via selvbetjeningsløsningen eller ved modtagelse af flyttebesked fra CPR, og der kun eksisterer én sag med det CPR-nummer i Løsningen. Krav# 18: Automatisk tilknytning af opgaver til sag Beskrivelse: Løsningen skal automatisk tilknytte en opgave til en eksisterende sag. a) Løsningen kan automatisk tilknytte en opgave til en eksisterende sag, hvis der kan etableres en entydig relation til én sag ud fra oplysninger på opgaven. Det skal afklares med Leverandøren præcist i hvilke tilfælde, Løsningen automatisk skal tilknytte opgaven til en sag. Side 35 af 255

36 Automatisk tildeling af opgave til sagsbehandler Hvor det er muligt, bør opgaven automatisk tildeles sagsbehandleren eller et team. Til dette benyttes forskellige fordelingsnøgler. Da kommunerne har forskellig organisering, skal det være muligt for kommunerne at vælge mellem de mest almindelige former for fordelingsnøgler, så Løsningen understøtter de forskellige kommunale organiseringer. Krav# 19: Automatisk tildeling af opgave til sagsbehandler Beskrivelse: Løsningen kan automatisk tildele en opgave til en sagsbehandler eller et sagsbehandler-team. En opgave kan fordeles ud fra områdeopdeling, CPR interval og opgavetype eller en kombination mellem de tre. a) Løsningen kan automatisk tildele en sagsbehandler eller et sagsbehandler-team til en opgave ud fra fordelingsnøglerne beskrevet herunder: a. Alle opgaver, hvor Parten i sagen bor i et specifikt geografisk område (socialdistrikter), skal fordeles til en specifik sagsbehandler/team, b. Alle opgaver, hvor Parten i sagen har CPR-nummer i et særligt CPR-nummer interval, skal fordeles til en specifik sagsbehandler/team. c. Med udgangspunkt i CPR-nummer på følgende form DDMMÅÅ- LLLL skal intervaller kunne laves på basis af dag (DD), måned (MM) eller løbenummer (LLLL). d. Alle opgaver af en bestemt opgavetype skal fordeles til en specifik sagsbehandler/team. b) Det er muligt at benytte alle fordelingsnøglerne i kombination. Fx både områdedelt samt cpr-opdeling. - Se Krav# 368 om snitflade til CPR Vejregister. - Se Krav# 204 for konfigurering af hvilke fordelingsnøgler, der benyttes i kommunen. - Se afsnit vedrørende Organisation. - Se afsnit vedrørende Klassifikation Opret sag Formålet med opret sag er, at kommunen på baggrund af en henvendelse kan oprette en sag med tilhørende dokumenter, så den er klar til den videre sagsbehandling. Som beskrevet i tidligere afsnit skal der som hovedregel oprettes en sag, hvis kommunen modtager en oplysning, der ikke tilhører en allerede eksisterende sag. Typisk vil en sag oprettes ved modtagelsen af en ansøgning eller en indstilling. På enkelte ydelsesarter kan en sag også oprettes ud fra beskeder fra Jobcentret. Nedenstående Tabel 1 viser, hvilket format Side 36 af 255

37 en ansøgning modtages i, samt den typiske efterfølgende behandling af oplysningen. Tabel 1: Behandling af ansøgning/indstilling efter modtagelsesformat Format Indgang i kommunen Sag oprettes i KY Fysisk dokumentret. Dokumentet modtages på papir i ydelsescen- Manuelt Digitalt dokumenmentservice Dokumentet modtages i Løsningen via doku- Manuelt/Automatisk (jf. afsnit ) fx fra ESDH, Postscanningsenhed eller andet eksternt system. Data Data modtages via Selvbetjeningsløsningen (jf. Automatisk afsnit ). Besked Besked fra jobcentret angående godtgørelser og målgruppe 2.7. Automatisk Krav# 20: Automatisk oprettelse af sag Beskrivelse: Løsningen skal kunne oprette sager automatisk på grundlag af hændelser, der er sket i andre it-løsninger. a) Løsningen kan automatisk oprette en sag, når der modtages en ansøgning fra Selvbetjeningsløsningen. b) Løsningen kan automatisk oprette en sag, når der modtages beskeder fra Jobcentret vedrørende godtgørelser og målgruppe 2.7. c) Løsningen kan, hvis der er tilstrækkeligt med metadata på ansøgningen, automatisk oprette en sag, når der modtages en ansøgning via Dokumentservice. d) Løsningen opdaterer sagsdata som fx oprettelsesdata, status, årsag til ansøgning mm. e) Hvis sagen er oprettet på en Person, der ikke i forvejen har en igangværende sag i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren med Personens CPR-nummer. f) Løsningen opdaterer Sags- og Dokumentindekset. g) Løsningen kan oprette en sag uafhængig af, hvor Personen har opholdskommune, men det signaleres hvis der ikke er overensstemmelse mellem opholdskommune og handlekommune, der modtager ansøgningen. - Se afsnit 5.9 vedrørende Selvbetjeningsløsningen. - Se afsnit og vedrørende godtgørelser. - Se afsnit vedrørende Dokumentservice. - Se afsnit vedrørende Beskedfordeleren. - Se afsnit vedrørende Sags- og Dokumentindeks. Side 37 af 255

38 Krav# 21: Manuel oprettelse af sag Beskrivelse: Det er muligt for brugeren at oprette en sag manuelt med tilhørende relevante oplysninger. a) Brugeren kan oprette en sag. b) Løsningen tilføjer sagsdata. c) Brugeren kan tilføje og ændre sagsdata. d) Hvis sagen er oprettet på en Person, der ikke i forvejen har en igangværende sag i Løsningen, opdaterer Løsningen abonnementet i Beskedfordeleren med Personens CPR-nummer. h) Løsningen opdaterer Sags- og Dokumentindekset. i) Løsningen kan oprette en sag uafhængig af, hvor Personen har opholdskommune, men det signaleres hvis der ikke er overensstemmelse mellem opholdskommune og handlekommune, der modtager ansøgningen. Den endelige liste over minimumsoplysninger ved oprettelsestidspunktet afklares med Leverandøren. - Ved oprettelse af sagen skal der som minimum angives: o CPR nummer på Personen (den primære part) o Den ansøgte ydelsesart o Startdato for sagen (skal kunne være i indeværende, forrige og kommende kalenderår) - Sagsdata kan fx være oprettelsesdato, status mm. - Se afsnit vedrørende Beskedfordeleren. - Se afsnit vedrørende Sags- og Dokumentindeks. - Se informationsmodellen (KY-sag) i underbilag 2.5 i forbindelse med sagsoprettelse. Krav# 22: Oprettelse af opgave ved sagsoprettelse Beskrivelse: Efter automatisk sagsoprettelse skal der automatisk oprettes en opgave, hvor den nyoprettede sag er tilknyttet. a) Når der automatisk er oprettet en sag, opretter Løsningen automatisk en ny opgave, hvor den nyoprettede sag er tilknyttet a. Dette gælder dog ikke i tilfælde, hvor sagen er oprettet på grundlag af en meddelelse fra jobcentret om godtgørelse. b) Ved manuel sagsoprettelse kan brugeren yderligere vælge at gå direkte til sagsbehandlingen, og i dette tilfælde vil der ikke blive oprettet en opgave. - Se Krav# 20 og Krav# 21 om sagsoprettelse. - Se beskrivelse af godtgørelsessager i afsnit Side 38 af 255

39 Krav# 23: Tilknytning af KLE Beskrivelse: Når der oprettes en sag (både manuelt og automatisk), skal der automatisk tilknyttes KLE-nummer på sagen. a) Når der oprettes en sag, tilknytter Løsningen automatisk et KLE-nummer på sagen, herunder også handlingsfacet samt kassationskode. b) Brugeren kan tilføje eller ændre et allerede tilknyttet KLE-nummer på sagen. c) Løsningen skal sikre, at emne, handlingsfacet og kassationskode overholder KLE. d) Kassationskoden i Løsningen må aldrig være kortere end 5 år. - Kassationskoden vil som hovedregel være sat automatisk til 5 år. - Det må ikke være muligt at sætte (hverken manuelt eller automatisk) kassationskoden til mindre end 5 år, eftersom Løsningen skal levere data til AMS 5 år tilbage i tiden. - Se også Krav# 57 vedrørende brugerens mulighed for at ændre kassationskoden i forbindelse med afgørelsen af en sag. - Se afsnit og vedrørende integration til Klassifikation. - I underbilag 2.15 Oversigt over ydelsesarter ses hvilke KLE-numre, der skal tilknyttes til de enkelte ydelsesarter Læs og løs opgave Som beskrevet tidligere i afsnit 5.1 benyttes opgavelisten til at fordele opgaverne. Derudover er opgavelisten også den enkelte sagsbehandlers indgang til Løsningen, hvorfra de kan plukke opgaver, der skal løses. Formålet med opgavelisten er her at give den enkelte sagsbehandler et overblik over, hvilke opgaver de skal løse og hjælpe med prioriteringen af opgaveløsningen. Opgavelisten kan også ses som sagsbehandlerens huskeliste, så ubehandlede opgaver ikke glemmes. Sagsbehandlerne kan være organiserede på mange forskellige måder i kommunerne. I nogle kommuner vil sagsbehandlerne behandle alle typer af ydelser fra start til slut. I andre kommuner kan det være mere specialiseret, så en sagsbehandler kun behandler nyansøgninger på kontanthjælp. Løsningen skal tage højde for dette og være fleksibel nok til at kunne håndtere de forskellige behov for opgavefordeling. Krav# 24: Læs opgaver Beskrivelse: Brugeren kan via en opgaveliste vælge en opgave og læse indholdet i opgaven. Side 39 af 255

40 a) Brugeren kan fra en opgaveliste vælge en opgave og se hele indholdet i opgaven. b) Brugeren kan navigere direkte fra opgaven til den tilknyttede sag o Hvis det er muligt entydigt at definere det præcise skærmbillede, hvor opgaven kan løses, navigeres direkte til dette. - I forhold til b) så forventer Kunden, at der navigeres så dybt som muligt. Hvis opgaven omhandler indtægter, så navigeres til indtægtsbilledet. Til tider vil det måske ikke være muligt at kende undersiden. I disse tilfælde navigeres blot til sagsforsiden. - Se Krav# 17 angående tilknyttede dokumenter til opgaver. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.1 for inspiration. Krav# 25: Ændring af status på opgave Beskrivelse: Det er muligt for brugeren at ændre status på en aktiv opgave. a) Brugeren kan ændre status på en opgave fra opgavelisten. b) Brugeren kan ændre status på en opgave fra selve opgaven. c) Brugeren kan ændre status på en opgave fra sagsoverblikket på den sag, hvor til opgaven er tilknyttet. - De forskellige muligheder for at ændre status på opgaver er medtaget for at kunne understøtte sagsbehandlerens fleksible arbejde. Fx skal status kunne opdateres fra selve sagen, således at brugeren ikke behøver at gå tilbage til opgavelisten for at markere en opgave som løst. - Se Krav# 166 for visning af aktive opgaver på sagen. 5.2 Behandling af ydelsessager I dette afsnit beskrives kernefunktionaliteten i Kommunernes Ydelsessystem; det at behandle en ydelsessag. Nedenstående figur er et udklip af Figur, hvor aktiviteterne i afsnit 5.1 er foldet sammen, så kun aktiviteterne i afsnit 5.2 vises. Figuren giver indsigt i de aktiviteter, der typisk udføres i forbindelse med behandlingen af en ydelsessag, illustreret i den hyppigst forekommende sekvens i en sagsbehandlers arbejde. Nummeret i hver aktivitet henviser til det afsnit, hvor aktiviteten samt krav er beskrevet. Side 40 af 255

41 5.1 Opgaver og sager Oplys sag Fastsæt ydelsessats og beregn ydelse Træf afgørelse Effektuer Vedligeholdelse af sag Afslut og arkiver sag 5.2 Behandling af ydelsessager Figur 10: Aktiviteter og typisk sekvens i behandlingen af en ydelsessag En ydelsessag indeholder hele sagens livsforløb, fra en Person ansøger om en ydelse eller bliver indstillet til en ydelse af Jobcentret, får bevilget ydelsen, ydelsen udbetales og sagen til sidst afsluttes. Hvis det drejer sig om en forsørgelsesydelse, vil den bevilgede ydelse typisk udbetales flere gange, så Effektuer (5.2.4) vil gennemløbes igen og igen, indtil kommunen modtager nye oplysninger (jf ). Alt efter hvilke oplysninger, der modtages, vil der dannes en ny opgave, og man går tilbage i sekvensen. Se i underbilag 2.3 for en beskrivelse samt diagram over forretningsprocesserne for de forskellige ydelsesarter. Vær herunder opmærksom på at der kan være forskelle i sekvens og aktiviteter mellem de forskellige ydelsesarter. De efterfølgende krav i afsnittet vil som hovedregel gælde for samtlige ydelsesarter. Hvis der er krav, der er specifikke for en given ydelsesart, vil det fremgå tydeligt af beskrivelsen. Nogle af ydelsesarterne vil dog ikke være omfattet af hele funktionaliteten. Fx vil Løsningen ikke beregne beløbet til udbetaling for en enkeltydelse. Tabel giver et indblik i hvilken funktionalitet, der er understøttet i hver enkelt ydelsesart. Se desuden afsnit for krav til specifikke visninger i forbindelse med behandling af en ydelsessag Oplys sag Formålet med at oplyse sagen er - på baggrund af en ansøgning eller nye oplysninger til en eksisterende sag - at indsamle og vurdere informationer, så der kan træffes en afgørelse. Selve afgørelsen træffes ikke under oplysningen af sagen, men i praksis vil Sagsbehandleren undervejs i sagsoplysningen typisk få en idé om udfaldsrummet og kan derfor løbende målrette sagsoplysningen. Typisk indsamles informationerne med henblik på at 1) afgøre hvorvidt Personen har ret til den ansøgte ydelse og forudsat at Personen har ret til den ansøgte ydelse 2) at fastsætte ydelsen og beregne det beløb, som skal udbetales, jf. afsnit Når sagen er fuldt oplyst, er der indsamlet tilstrækkelige informationer til at kunne træffe en afgørelse. I tilfælde af at denne afgørelse indebærer en bevilling, er der ligeledes indsamlet tilstrækkelige oplysninger til at kunne fastlægge og beregne ydelsen. Følgende opgaver vil typisk finde sted under oplysning af sagen: - Indberetning af oplysninger, som sagsbehandleren tilvejebringer fra Personen eller tredjepart. Side 41 af 255

42 - Vurdering af oplysninger fra ansøgning eller henvendelse fra Personen eller tredjepart, herunder beregning af rådighedsbeløb og formue i sager vedr. enkeltydelser. - Vurdering af oplysninger, som Løsningen indhenter fra eksterne systemer. - Sammenholde indberettede og indhentede oplysninger, fx fra eksterne systemer. - Vurdering af om oplysningsgrundlaget er fyldestgørende til at kunne træffe en informeret afgørelse og efterfølgende at kunne fastsætte ydelse og beregne et beløb til udbetaling. - Indhentelse af supplerende oplysninger, fx ved manglende oplysninger. - Vurdering af behovet for og eventuel gennemførelse af partshøring, eksempelvis ved modstrid mellem indhentede og indberettede indkomstoplysninger. Herudover kan der være en række specifikke opgaver ved enkelte ydelsesarter, jf. bl.a. afsnit I Løsningen skelnes mellem de indhentede oplysninger (fra eksterne systemer og registre) og indberettede oplysninger (fra Personen). I nogle tilfælde vil samme oplysning både indhentes og indberettes. Fx skal Personen oplyse eventuelle indtægter og sende dokumentation herfor. Samtidig indhenter Løsningen via e-indkomst Personens eventuelle indtægter. Løsningen skal således håndtere flere sæt af samme data (se eventuelt relationerne Indberettet af ansøger og Indhentet af kommunen i informationsmodellen (KY-Uddannelseshjælp eller kontanthjælp) i underbilag 2.5). Som oftest vil sager ikke kunne oplyses tilstrækkeligt i én arbejdsgang. Der vil ofte være behov for at parkere sagen, fx fordi der mangler oplysninger 5. Det at foretage Oplysning af sagen er som oftest den mest komplekse og tidskrævende opgave for sagsbehandleren, når denne behandler en ydelsessag. Bemærk, at sager vedrørende uddannelseshjælp eller kontanthjælp altid inkluderer en eventuel ægtefælle/samlever og dennes oplysninger vedrørende indtægter, økonomi mv. Tilsvarende gælder i enkeltydelsessager for ægtepar. I disse sager tilknyttes personen, der ansøger, som den primære part, og en eventuel ægtefælle/samlever som sekundær part. Dette betyder, at ægtefællen/samleveren til en Person, som ansøger om uddannelseshjælp eller kontanthjælp, altid vil indgå i oplysning af sagen. Krav# 26: Indhent oplysninger i eksterne registre Beskrivelse: Inden en nyoprettet sag oplyses første gang, indhenter Løsningen automatisk de mulige relevante oplysninger for en given ydelsestype fra eksterne systemer. a) Løsningen indhenter automatisk nedenstående oplysninger fra eksterne systemer inden sagen oplyses første gang: A. Er ansøger tilmeldt via jobcentret via jobcenterintegrationen. B. Persondata via CPR, herunder oplysninger om ægtefælle, samlever og børn. C. Oplysninger om indtægtsoplysninger via E-indkomst. D. Oplysninger om eventuelt virksomhed via CVR. E. Oplysninger om formue mv. via SKAT R75. F. Oplysninger om en ansøgers skattekort via SKAT eskattekort. G. Oplysninger om, hvorvidt ansøger har fået udbetalt feriepenge og i så fald hvornår, via ATP Feriekonto. H. Oplysninger om opholdsgrundlag via UdlændingeInformationsSyste- 5 Det er forhåbningen, at selvbetjeningsløsningen (jf. afsnit 5.8) vil mindske behovet for at indhente supplerende oplysninger, men der vil stadig være behov for at indhente supplerende oplysninger Side 42 af 255

43 met. I. Oplysning om hvorvidt Personens ægtefælle eller samlever modtager SU via E-indkomst. J. Oplysning om Personen modtager ekstra børnetilskud eller oplysning om, at Personen ikke modtager ekstra børnetilskud via Ydelsesindeks. K. Oplysning om boligstøttebeløb for 34 sager om særlig støttes via Ydelsesindekset. b) Løsningen kan ved vedligeholdelse af sagen slå op i ovenstående registre og opdatere sagsinformationen. - Se kapitel 6.4 for nærmere oplysninger om, hvilke systemer der integreres til. - Oplysninger, der skal hentes, er beskrevet i de respektive informationsmodeller og følgende er eksempler på, hvilke data, der skal hentes og hvor de kommer fra, men er ikke fyldestgørende for hele løsningen: o Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5, ift. punkt A. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt B. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt C. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt D. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt E. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt F. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt G. o Se informationsmodellen (KY-Person) i underbilag 2.5, ift. punkt H. o Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5, ift. punkt J. - Se afsnit vedrørende Vedligeholdelse af sag. - I forhold til punkt b) så kan vedligeholdelse af sag fx være, når der modtages beskeder fra eksterne systemer. En flyttebesked fra CPR bør fx medføre et opslag i CPR, så adressen opdateres i Løsningen. Krav# 27:Manuelt opslag i eksterne registre Beskrivelse: Brugeren skal i løsningen på ethvert tidspunkt kunne foretage et nyt opslag i de eksterne registre beskrevet i Krav# 26 og herigennem indhente de til hver en tid aktuelle informationer. - Manuelle genopslag kunne fx være relevante ved genoplysning af en sag på et tidspunkt efter den første afgørelse er truffet. - Se Krav# 96 for automatisk opdatering af sagsdata. Krav# 28: Hent oplysning om samlevende hos ATP Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningen skal, på brugerens foranledning, kunne indhente oplysninger om, hvorvidt en Person eller dennes sambo er eller har været noteret som samlevende i ATP til brug for oplysning om, hvorvidt der er gensidig forsørgelsespligt LAS 2c. Side 43 af 255

44 a) Brugeren kan foretage et opslag i ATPs register over samlevende og der returneres svar om, hvorvidt Personen eller dennes sambo er eller har været noteret som samlevende. b) Oplysningerne må kun indhentes for ansøgere om og modtagere af uddannelseshjælp eller kontanthjælp. - Se Lov nr. 894 af 04/07/2013: Lov om ændring af lov om aktiv socialpolitik, SU-loven, Lov om børnetilskud og forskudsvis udbetaling af børnebidrag og forskellige andre love. - Snitfladen til ATPs register over samlevende er under afklaring pr. november Krav# 29: Automatisk overførsel af data fra ansøgning til sag Beskrivelse: Data fra ansøgninger og løbende supplerende oplysninger, der modtages via selvbetjeningsintegrationen, overføres automatisk til sagen. - Et eksempel kan være personens indtægtsoplysninger automatisk er overført til sagen. Det vil sige, at der ikke vil være noget tastearbejde for sagsbehandleren forbundet med en ansøgning, der er kommet ind via Selvbetjeningsløsningen. Krav# 30: Indberetning af oplysninger Beskrivelse: Det skal være muligt for brugeren at angive manglende oplysninger samt opdatere allerede eksisterende oplysninger (både de indberettede og indhentede). a) Brugeren kan tilføje eventuelle manglende oplysninger. b) Brugeren kan opdatere allerede eksisterende oplysninger. c) Brugeren kan angive dato for, hvornår informationen er gældende fra og til. - Det kan fx dreje sig om oplysninger fra en ansøgning (i det tilfælde at kommunen har modtaget ansøgningen på papir). Det kan også være oplysninger brugeren selv har indhentet, eksempelvis persondata, valg af skattekort (hovedkort/bikort/frikort), information om indtægter, informationer om formue mv. - Oplysninger vedrørende ægtefæller/samlever jf. Krav# 31 indgår ligeledes i dette krav. - Se informationsmodellen (KY-sag, KY-dokument, Beslutningsgrundlag, Beregningsgrundlag, Oplys sag) i underbilag 2.5 for hvilke informationer, der indgår i oplysningen af en sag. Vær herunder opmærksom på. at ydelsesarterne ikke alle benytter samme informationer (jf. eventuelt underbilag 2.7). Krav# 31: Oplysning af ægtefælles/samlevers forhold Beskrivelse: Det skal på sager vedrørende visse ydelsesarter være muligt for brugeren at Side 44 af 255

45 indberette de samme oplysninger for henholdsvis personen og en eventuel ægtefælle/samlever. Tilsvarende indhentes samme oplysninger automatisk for henholdsvis Personen og for ægtefællen/samleveren. a) I sager vedr. uddannelseshjælp eller kontanthjælp indhentes samme oplysninger som beskrevet i Krav# 26 automatisk også for Personens eventuelle ægtefælle/samlever a. Det må dog ikke være muligt at indhente oplysninger om samlever, før der er truffet afgørelse om, at det er en samlever. b) I sager vedr. enkeltydelser indhentes samme oplysninger som beskrevet i Krav# 26 automatisk også for Personens eventuelle ægtefælle. c) I sager vedr. uddannelseshjælp eller kontanthjælp skal det være muligt for brugeren at indhente oplysningerne for ægtefæller/samlevere manuelt som beskrevet i Krav# 27 a. Det må dog ikke være muligt at indhente oplysninger om samlever, før der er truffet afgørelse om, at det er en samlever. d) I sager vedr. enkeltydelser skal det være muligt for brugeren at indhente oplysninger for ægtefæller manuelt som beskrevet i Krav# I underbilag 2.7 gives eksempler på, hvordan oplysningerne for Person og ægtefælle/samlever anvendes ved beregning af beløb til udbetaling i sager om uddannelseshjælp eller kontanthjælp. - Se Krav# 159 vedrørende visning og overblik over ægtefælle/samlevers oplysninger. Nogle oplysninger skal Personen selv indberette, men Løsningen indhenter de samme oplysninger via eksterne systemer (fx lønindkomst). Derved kan der opstå situationer, hvor Personen har indberettet noget andet end det indhentede. I disse tilfælde skal det være muligt for sagsbehandleren at vælge, hvilke der er de korrekte. Krav# 32: Valg af gældende oplysninger ved uoverensstemmelser Beskrivelse: Ved uoverensstemmelse mellem de indberettede og indhentede oplysninger skal brugeren kunne markere hvilken oplysning, der er den gældende. - Med uoverensstemmelse mellem gældende oplysninger menes, at Løsningen skal fange uoverensstemmelser mellem to "versioner" af samme oplysning (samme felt) fra forskellige kilder. Fx indtægt indberettet af Personen, og indtægt indhentet via E-indkomst. Kunden forventer således ikke, at der skal opdages uoverensstemmelser på tværs af forskellige slags oplysninger. - Se Krav# 26 - Krav# 31 om indberettede og indhentede oplysninger. - Se Krav# 163 for visuel markering af uoverensstemmelser - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.5 for eksempel på, hvordan kunden kunne forestille sig en løsning. Sagsoverblik/partskontakt (SAPA) er en løsning, der kan give sagsbehandlerne bedre overblik i deres daglige arbejde ved at give mulighed for at google en borger og give et 360 overblik over borgeren. Løsningen kan give kommunale sagsbehandlere hurtig adgang til centrale informationer og hændelser vedrørende borgeren på tværs af kommunens fagsystemer. Fra SAPA kan sagsbehandleren hoppe til en borgers sag i et fagsystem og omvendt. SAPA indeholder, udover borgerens grundoplysninger, visning af sager på tværs af sagsbærende Side 45 af 255

46 fagsystemer og konkrete sagsdata, herunder sager, dokumenter, bevillinger/ydelser, journalnotater, ind-/udgående kommunikation. Sagsbehandleren kan endvidere tegne abonnement på beskeder om forretningshændelser og oprette sager i fagsystemer. Krav# 33: Hop til SAPA Kategori: (K) Type: Ikke funktionelt Beskrivelse: Løsningen skal tilbyde sagsbehandleren at hoppe til SAPAs visning af oplysninger om Personen. - Se afsnit for anvenderkrav til dialogintegration også kaldet hop. Krav# 34: Hop til Løsningen Kategori: (K) Type: Ikke funktionelt Beskrivelse: Løsningen skal give brugere af andre it-systemer mulighed for at hoppe til en sag eller et dokument i Løsningen. - Eksempler på andre it-systemer kunne være SAPA. - Det er kun muligt at hoppe til Løsningen, hvis den givne bruger som minimum har læserettigheder i Løsningen. - Se afsnit for anvenderkrav til dialogintegration også kaldet hop. I nogle tilfælde kan der være behov for, at sagsbehandleren kan indtaste en alternativ adresse, som er en anden adresse end den, Personen er registreret med i CPR. Det kan fx være i forbindelse med, at Personen benytter en partsrepræsentant, altså en person, der repræsenterer Personen og modtager dennes breve. Det kan også være, fordi Personen først dagen før meldte flytning, så den ikke er slået igennem i CPR endnu. Denne alternative adresse skal Løsningen benytte, når der skal afsendes breve. Krav# 35: Benyttelse af alternativ adresse Beskrivelse: Det skal være muligt for brugeren at indtaste en alternativ adresse som fremover vil benyttes af Løsningen i stedet for den indhentede adresse fra CPR. - Den alternative adresse benyttes i forbindelse med indfletning af adresse ved udsendelse af breve. - Se Krav# 96 vedrørende automatisk opdatering af sagsoplysninger. - Se Krav# 127 om udsendelse af breve. Som udgangspunkt vil sagsbehandleren altid benytte data, der er indhentet fra eksterne systemer. Men fejl eller mangler i data fra eksterne registre må ikke forhindre, at sagsbehandleren manuelt kan behandle sagen. Et eksempel kan være, at Løsningen skal kunne håndtere Personer, der ikke har noget hjem (og derfor ikke står opført i folkeregistret med bopæl i kommunen). I sådanne tilfælde vil sagsbehandleren fx ringe til Personen for afklaring af, hvor denne har sovet. Det nedskrives i et journalnotat, at Personen har oplyst, at han opholder sig i kommunen, og sagsbehandleren kan derefter behandle sagen. Det skal således altid være muligt for sagsbehandleren at behandle sagen manuelt. Side 46 af 255

47 Krav# 36: Håndtering af Særtilfælde/ fejl i data fra eksterne registre Beskrivelse: Fejl eller mangler i data fra eksterne registre må ikke forhindre, at brugeren manuelt kan behandle sagen. - a) Manglende forbindelse til eksternt register må ikke forhindre brugeren i at behandle en sag. b) Fejl i data indhentet fra eksternt register må ikke forhindre brugeren i at behandle en sag. c) Manglende data (der burde have været indhentet) fra eksternt register må ikke forhindre brugeren i at behandle en sag. Dette krav går på, at der ikke må være valideringer i forhold til manglende/fejlagtige data fra eksterne systemer, der må forhindre brugeren i at behandle sagen Indhent supplerende oplysninger / partshøring Under oplysning af en sag vil der opstå tilfælde, hvor sagsbehandleren har behov for at kontakte Personen eller tredjepart for at få yderligere oplysninger eller valideret de eksisterende. Det sker enten ved Indhentning af supplerende oplysninger eller ved Partshøring. Indhentning af supplerende oplysninger er relevant, hvis sagsbehandleren mangler oplysninger for at være i stand til at vurdere sagen. Personen oplyses om hvilke oplysninger, der mangler samt om den frist, der gælder for at afgive oplysningerne. Hvis det er relevant, anmodes tredjepart (fx tidligere arbejdsgiver, pengeinstitut eller pensionskasse) om oplysninger. Eksempelvis indhentes oplysninger om pensionsformue mv. fra personer i fleksydelsesordningen ca. 6 måneder før, de når fleksydelsesalderen. Formålet med partshøring er at vurdere, om der er indhentet oplysninger, som Personen ikke ved, vil indgå i afgørelsen, og som kan være til ugunst for Personen. Er det tilfældet, skal der ske partshøring. Bemærk at partshøring, såfremt det er hensigtsmæssigt, kan foretages samtidig med, at der indhentes supplerende oplysninger fra Personen. Funktionaliteten til indhentning af supplerende oplysninger og partshøring medfører ingen specifikke krav. Der benyttes generel tværgående funktionalitet beskrevet andre steder. Fx benytter sagsbehandleren brevfunktionaliteten beskrevet i afsnit til at udforme brevet. Benytter journalnotats-funktionaliteten beskrevet i afsnit og funktionaliteten til statusændringer beskrevet i afsnit Partshøring kan foretages af sagsbehandleren, eller initieres af Løsningen på baggrund af en hændelse som beskrevet i underbilag 2.13 Hændelsesliste. Der er derfor ingen krav i dette underafsnit, men afsnittet er bibeholdt for at gøre opmærksom på denne vigtige aktivitet, sagsbehandleren udfører i forbindelse med oplysningen af sagen Beregn rådighedsbeløb og formue Ved behandlingen af sager vedrørende enkeltydelser og ved udbetaling af visse andre ydelser er der under oplysning af sagen behov for at lave en rådighedsberegning. Formålet er at beregne Personens og eventuel ægtefælles rådighedsbeløb med henblik på at vurdere, om Personen selv kan betale udgiften, der søges dækket. Rådighedsbeløbet vil indgå i den konkrete vurdering af, hvorvidt Personen får bevilget ydelsen eller ej. Side 47 af 255

48 Rådighedsbeløbet er forskellen mellem indtægter og rimelige og nødvendige udgifter. Hvilke, der er rimelige og nødvendige, er en konkret vurdering fra sag til sag. For sagsbehandleren ligger opgaven i at indsamle dokumentation for indtægter og udgifter for efterfølgende at vurdere hvilke udgifter, der er rimelige og hvilke der ikke kan medtages i rådighedsberegningen. Ved behandling af sager vedr. enkeltydelser og udbetaling af visse andre ydelser kan der endvidere være behov for at kunne opgøre Personens formue. Krav# 37: Beregn rådighedsbeløb Beskrivelse: En bruger skal i løsningen kunne foretage en beregning af rådighedsbeløb ud fra oplysninger, som brugeren indberetter og gemmer på sagen. a) Rådighedsbeløbet for en person er beregnet ved at trække summen af godkendte udgifter fra summen af godkendte indtægter. b) Brugeren kan angive en bemærkning til hvert beløb. c) Brugeren kan godkende om hvert beløb anvendes i beregningen. d) Beregningen kan foretages for begge ægtefæller i en sag. - Rådighedsberegningen indgår i oplysning af sager vedr. fx enkeltydelser og udbetaling af visse andre ydelser, for Personen og dennes eventuelle ægtefælle. - Se eventuelt Krav# 38 vedr. de oplysninger, der kan indgå i en beregning af rådighedsbeløb. Krav# 38: Oplysninger ved beregning af rådighedsbeløb Beskrivelse: Der er i Løsningen foruddefineret en række relevante typer af udgifter (og deres eventuelle maksimumbeløb) samt relevante indtægter, der skal vises, når brugeren påbegynder beregning af rådighedsbeløb og skal kunne rettes af brugeren. a) Løsningen viser de typer, som den kommunale administrator har konfigureret skal vises som standard. b) Løsningen giver brugeren mulighed for at kunne indberette indtægter/udgifter i den specifikke sag for de typer, der vises som standard. c) Løsningen giver brugeren mulighed for at kunne registrere yderligere indtægter/udgifter i den specifikke sag. d) Løsningen skal sikre, at der ikke kan indberettes en udgift, som overstiger det maksimumbeløb, der er konfigureret. Hvis maksimumbeløbet er 0 (nul) kr., skal der ikke valideres for dette. - Eksempler på udgifter, der vises som standard, omfatter: Husleje, El, Telefon (maks. 100 kr.), Løn, Pension. - Se eventuelt informationsmodellen (KY-Enkeltydelse, Beslutningsgrundlag) i underbilag Se Krav# 216 vedrørende kommunal konfigurering. Side 48 af 255

49 Krav# 39: Beregn formue Beskrivelse: En bruger skal i Løsningen kunne foretage en beregning af formue ud fra oplysninger, som brugeren indberetter og gemmer på sagen. a) Formuebeløbet for en Person er beregnet ved at summere godkendte formueposter. b) Brugeren kan angive en bemærkning til hvert beløb. c) Brugeren kan godkende om hvert beløb anvendes i beregningen. d) Beregningen kan foretages for begge ægtefæller/samlevere i en sag. - Formueberegningen indgår i oplysning af sager vedr. fx uddannelseshjælp eller kontanthjælp, enkeltydelser og udbetaling af andre ydelser. Den skal kunne foretages for Personen og dennes eventuelle ægtefælle/samlever. Samlevere indgår ikke i enkeltydelsessager. - Se Krav# 40 vedr. de oplysninger, der kan indgå i en beregning. Krav# 40: Oplysninger i formueopgørelse Beskrivelse: Der er i Løsningen foruddefineret en række relevante formueposter, der vises, når brugeren påbegynder beregning af formue og som skal kunne rettes af brugeren. a) Løsningen viser de beløbstyper, som den kommunale administrator har konfigureret og skal vises som standard. b) Løsningen giver brugeren mulighed for at kunne registrere yderligere formueposter i den specifikke sag. - Eksempler på formueposter, der vises som standard, inkluderer: Likvid formue, Fast ejendom, Bil. - Se informationsmodellen (Beslutningsgrundlag) i underbilag Se Krav# 217 vedrørende kommunal konfigurering. Mange kommuner indgår aftaler med eksempelvis optikere og behandlere om faste priser på en række varer og tjenester, som kommunen indkøber i sager vedrørende andre ydelser, eksempelvis udvidet helbredstillæg og personlige tillæg. Krav# 41: Adgang til kommunens prisaftaler Beskrivelse: En bruger skal i løsningen have let adgang til kommunens eventuelle prisaftaler i forbindelse med fastsættelse af ydelsen. a) Brugeren kan ved maks. to klik/tastetryk tilgå kommunens prisaftaler, hvis brugeren har påbegyndt behandlingen af en sag om enkeltydelser eller andre ydelser. Side 49 af 255

50 b) Løsningen skal anvende henvisningen, som er konfigureret af den kommunale administrator, til at give en bruger adgang til prisaftalen. - Behovet kan opstå eksempelvis i en sag vedrørende udvidet helbredstillæg. - Adgang til prisaftale kan ske ved, at Løsningen indeholder et link til et dokument med prisaftalen. - Se Krav# 220 vedrørende kommunal konfigurering af adgang til prisaftale Beregn fleksydelsesanciennitet Fleksydelse er en ordning, som personer, der er visiteret til et fleksjob, automatisk indmeldes i ved visiteringen. Såfremt Personen ikke aktivt fravælger at deltage i ordningen, afgør kommunen, om Personen opfylder betingelserne for at deltage. Det er primært et krav om anciennitet, dvs., at Personen (afhængig af fødselsår) skal kunne nå at betale fleksydelsesbidrag i et nærmere angivet antal år. Allerede betalte bidrag til efterløn medregnes i opgørelsen. Hvis Personen opfylder betingelserne og dermed deltager i ordningen, opkræver kommunen et kvartalsvist bidrag fra Personen. Krav i dette afsnit er rettet specifikt mod understøttelse af fleksydelsesordningen. De skal ses som supplement til de generelle krav i kapitel 5, som retter sig mod alle de ydelser, som Løsningen skal understøtte. Herunder krav om oplysning af sag, beregning, afgørelse, effektuering og udbetaling. Underbilag 2.14 (Beregninger og regler vedrørende fleksydelse) indeholder vejledende beskrivelser af beregninger og regler vedrørende beregning af anciennitet og betalingsfrie perioder. Krav# 42: Beregning af anciennitet i fleksydelsesordningen Beskrivelse: En bruger skal i Løsningen kunne foretage en beregning af ancienniteten for en Person og få fastslået, om Personen opfylder betingelserne for at deltage i fleksydelsesordningen ud fra oplysninger, som brugeren indberetter og gemmer på sagen. a) Personens anciennitet er beregnet korrekt i henhold til lovgivningen. b) Beregningen er foretaget ud fra oplysninger om medlemskab af a-kasse, indbetaling af efterlønsbidrag, fleksydelsesbidrag og eventuel dispensation, som brugeren har indberettet på sagen. c) Løsningen har oplyst brugeren, om personen opfylder betingelserne for at deltage i fleksydelsesordningen. - Resultaterne anvendes som grundlag for, at brugeren kan træffe afgørelse om Personens deltagelse i fleksydelsesordningen. - Se informationsmodellen (KY-fleksydelse) i underbilag Se eksempler på beregninger og regler vedrørende fleksydelse og fleksydelsesbidrag i underbilag Krav# 43: Beregning af betalingsfrie perioder i fleksydelsesordningen Beskrivelse: En bruger skal i Løsningen kunne igangsætte en beregning af antallet af bi- Side 50 af 255

51 dragsperioder, hvor Personen kan undlade at betale bidrag uden at miste retten til at modtage fleksydelse. - a) Løsningen har fastsat antallet af bidragsperioder, hvor Personen kan undlade at betale bidrag uden at miste retten til at modtage fleksydelse, korrekt i henhold til lovgivningen. b) Resultatet er fastsat ud fra oplysninger om anciennitet og antallet af betalte bidrag, som er gemt på sagen. Se Krav# 91 vedrørende anvendelse af antallet af betalingsfrie perioder i løsningen Fastsæt ydelsessats og beregn ydelsesbeløb Når en sag er oplyst tilstrækkeligt, kan det beløb, som skal udbetales, beregnes, såfremt det er vurderet, at Personen, der ansøger, har ret til den ansøgte ydelse. Som det første fastsættes ydelsessatsen, der er udgangspunktet for at beregne det beløb, som udbetales til Personen. Løsningen fastsætter ydelsessatsen og beregner det beløb, som skal udbetales til Personen ud fra de oplysninger, som er registreret i Løsningen under oplysningen af sagen. Disse oplysninger kan være indberettet af sagsbehandleren eller indhentet fra eksterne systemer. Hvis der er tale om genoplysning af en eksisterende sag på et tidspunkt efter, at den første afgørelse i sagen er truffet, fx pga. nye oplysninger i sagen, kan der endvidere være registreret oplysninger i Løsningen på et tidligere tidspunkt, som også indgår. Lovgivningen fastlægger for hver ydelsesart det regelsæt, som bestemmer, hvilke betingelser en Person skal opfylde for at være berettiget til ydelsen og fastsætter hvordan beregningen af det beløb, som Personen skal have udbetalt, skal foretages. I forbindelse med sager om uddannelseshjælp eller kontanthjælp skal Løsningen også kunne fastsætte ydelsessatsen og beregne det beløb, som skal udbetales til en ægtefælle/samlever. De primære kilder er Lov om aktiv socialpolitik (LAS), Lov om en aktiv beskæftigelsespolitik (LAB) og Lov om fleksydelse. Reglerne, herunder hvad der skal til for at oplyse sagen tilstrækkeligt, varierer fra ydelsesart til ydelsesart. Eksempelvis inkluderer oplysning af en sag om uddannelseshjælp eller kontanthjælp også en eventuel ægtefælle/samlevers økonomiske situation, hvorimod det kun er ægtefælle, der indgår i enkeltydelsessager. For de øvrige ydelser indgår hverken ægtefælle eller samlever. I sager om uddannelseshjælp eller kontanthjælp skal sagsbehandleren endvidere konkret vurdere behovet for engangshjælp og indberette et beløb, såfremt det bevilges. Følgende ydelsesarter behandles i dette afsnit: Uddannelseshjælp eller kontanthjælp, herunder særlig støtte (LAS kapitel 4) Revalideringsydelse (LAS kapitel 6) Ledighedsydelse (LAS kapitel 7) Fleksydelse (Lov om fleksydelse) Ressourceforløbsydelse (LAS kapitel 6 a) Side 51 af 255

52 Fleksløntilskud (LAB kapitel 13) Enkeltydelse (LAS kapitel 10 eller INL kapitel 6) Anden ydelse, eksempelvis helbredstillæg og personligt tillæg til pensionister (Lov om social pension og Lov om højeste, mellemste, forhøjet almindelig og almindelig førtidspension m.v.) Igangsætning af beregning af beløb til udbetaling Der vil være behov for at kunne beregne beløb til udbetaling, herunder at fastsætte ydelsessats, på forskellige tidspunkter i sagsbehandlingen i henhold til sagens effektueringsplaner (se afsnit om fastlæggelse af effektueringsplan). Det kan forekomme: under oplysning af sagen, både ved første ansøgning og efterfølgende, fx i forbindelse med nye oplysninger i sagen i forbindelse med, at der træffes afgørelse om bevilling ved effektuering og bestilling af udbetaling, fx ved de månedlige udbetalinger af forsørgelsesydelser. Når løsningen foretager beregning i en sag, gemmes resultatet af beregningen i sagens oplysninger om bevilget ydelse og effektueringsplan med tilhørende oplysninger. Disse oplysninger er i en kladdetilstand, indtil der træffes afgørelse om bevilling og effektueringsplanen færdiggøres. Herefter udgør disse oplysninger grundlag for effektuering og bestilling af udbetaling. Der vil efterfølgende blive igangsat beregninger automatisk, når der effektueres og bestilles udbetalinger, eksempelvis ved månedlig udbetaling af forsørgelsesydelser. Se eventuelt afsnit om effektuering. Der vil derfor være behov for, at brugeren kan igangsætte beregninger i en given sag, fx pga. af ændringer i sagens oplysninger. Der kan også være behov for at foretage en beregning for en periode, som ligger tilbage i tid, eksempelvis hvis der kommer en afgørelse i en klagesag, som betyder, at der oprettes en sag med start tilbage i tid eller ændres på sagens oplysninger med tilbagevirkende kraft. Nedenstående krav beskriver to forskellige måder, hvorpå beregning af beløb til udbetaling kan igangsættes. Krav# 44: Automatisk beregning af ydelsesbeløb ved udbetaling Beskrivelse: Løsningen skal til brug for udbetaling automatisk fastsætte ydelsessats og beregne alle nødvendige beløb til brug for udbetaling på fastsatte tidspunkter for alle sager. a) Fastsættelse af ydelsessatser og alle beregninger i alle sager skal være foretaget rettidigt i forhold til effektueringsplanen og de regler, som er fastsat vedrørende automatisk effektuering og udbetaling, således at udbetaling kan foretages korrekt og rettidigt i henhold til lovgivningen. b) Hvis der på effektueringsplanen i en sag er angivet særskilt, at denne ikke skal indgå i den automatiske behandling, skal den være udeladt. c) Hvis der på effektueringsplanen i en sag er angivet særskilt, at denne skal behandles på et specifikt tidspunkt, er behandlingen foretaget på dette tidspunkt. Side 52 af 255

53 - Se Krav# 47 vedrørende fastsættelse af ydelsessats. - Se Krav# 48 - Krav# 55 vedrørende beregning af beløb til udbetaling. - Se Krav# 215 vedrørende fastsatte tidspunkter for udbetaling. - Se Krav# 64, Krav #65 og Krav# 109 vedrørende særskilte oplysninger i effektueringsplaner. Krav# 45: Manuel igangsætning af beregning af ydelsesbeløb Beskrivelse: Det skal være muligt for en bruger at igangsætte fastsættelse af ydelsessats og beregning af beløb til udbetaling på en specifik sag for en af brugeren valgt periode. Beregningens resultat skal gemmes på sagen, men skal ikke automatisk medføre, at der sker effektuering og bestilles udbetaling. Der skal dog være direkte adgang for brugeren til at foretage effektuering og bestille en udbetaling ud fra resultatet af beregningen. a) Løsningen skal sikre, at fastsættelse af ydelsessats og beregning af beløb til udbetaling foretages korrekt i henhold til lovgivningen ud fra de oplysninger, som er registreret i sagen. b) Brugeren kan umiddelbart se resultatet af beregningen. c) Brugeren kan vælge at effektuere resultaterne og bestille udbetaling. d) Brugeren skal kunne vælge en periode, som beregningen foretages for, inden for indeværende og forrige kalenderår. e) Perioden kan ikke gå længere tilbage end sagens startdato. f) Perioden kan ikke gå længere tilbage end til ibrugtagningstidspunktet. g) Perioden kan ikke gå længere frem end indeværende udbetalingsperiode. h) Løsningen skal ud fra oplysninger, som er gemt på sagen, beregne korrekt for hver af de udbetalingsperioder, der ligger inden for den valgte periode. i) Beregningen skal for hver udbetalingsperiode anvende oplysninger og regler, som havde gyldighed på det tidspunkt. - Behovet kan opstå i forbindelse med eksempelvis oplysning af sagen eller ændringer i sagens oplysninger, der påvirker beregninger for indeværende eller tidligere udbetalingsperioder. - Se Krav# 47 vedrørende fastsættelse af ydelsessats. - Se Krav# 48 - Krav# 55 vedrørende beregning af beløb til udbetaling. - Se Krav# 71 vedrørende manuel effekturing. Side 53 af 255

54 Krav# 46: Beregning skal benytte nyeste oplysninger Beskrivelse: Løsningen skal ved alle beregninger benytte de oplysninger, der indgår i sagen, har gyldighed i udbetalingsperioden og er registreret senest. Dette gælder både oplysninger, som indeholder én værdi og oplysninger, som indeholder værdier for flere perioder inden for udbetalingsperioden. a) Hvis der er registreret én version af en specifik oplysning, der er gyldig i udbetalingsperioden, er denne anvendt. b) Hvis der er registreret flere versioner af samme oplysning, der er gyldig i udbetalingsperioden, er den, der er registreret senest, anvendt. - Mange af de sager, som håndteres ved brug af Løsningen, er aktive over længere perioder, eventuelt i adskillige år. I løbet af sagens levetid vil oplysninger, som ligger til grund for beregninger og udbetalinger, typisk ændres over tid. - Eksempelvis kan der på en sag registreres et beløb vedrørende Personens indtægter i udbetalingsperioden den 20. i måneden, som bliver ændret til et nyt beløb den 23. i måneden. Når beregning af beløb til udbetaling foretages, fx den 27. i måneden, skal det senest registrerede beløb anvendes. - Se Krav# 48 vedrørende beregning af beløb til udbetaling. - Se afsnit vedrørende bitemporalitet. - Se informationsmodellen (Generelle egenskaber i KY-sag) i underbilag 2.5 vedrørende historikegenskaber Krav vedrørende beregning af beløb til udbetaling Generelt set indgår følgende elementer i beregningen af det beløb, som Personen skal have udbetalt: Fastsættelse af den ydelsessats, som Personen er berettiget til (se Krav# 47). Til hver ydelsessats svarer et beløb, som er udgangspunktet for beregning af det beløb, som skal udbetales til Personen. Beregning af det beløb, som Personen og eventuelt dennes ægtefælle/samlever, skal have udbetalt (se Krav# 48). Denne beregning skal - afhængig af ydelsesart og oplysningerne i den konkrete sag - tage højde for eventuelle tillæg og fradrag. Dette inkluderer en række elementer, herunder: o Beregning af indkomstgrundlag (se Krav# 49). o Beregning af konsekvenser af sanktioner (se Krav# 50). o Beregning og indeholdelse af ATP (se Krav# 51). o Beregning og indeholdelse af A-skat (se Krav# 52). o Fradrag for forskudsvis udlagt børnebidrag (se Krav# 53). o Beregning af skattemæssige konsekvenser af boligrenter i forbindelse med særlig støtte (se Krav# 54). o Manuelt indberettede tillæg/fradrag (se Krav# 55). Reglerne for, hvordan ydelsessatsen fastsættes og det korrekte beløb til udbetaling beregnes for de forskellige ydelsesarter, fastlægges af den til enhver tid gældende lovgivning. Eksempelvis fastsættes beløbet til udbetaling for uddannelseshjælp eller kontanthjælp ud fra oplysninger om Per- Side 54 af 255

55 sonens indtægter og eventuel ægtefælle/samlevers indtægter (herunder eventuelle offentlige forsørgelsesydelser) mv. I underbilag 2.7 (Beregninger og regler) og underbilag 2.14 (Beregninger og regler vedrørende fleksydelse) gives eksempler på, hvordan reglerne kan udmøntes, herunder hvilke oplysninger i sagen, som er nødvendige. Disse beskrivelser skal ses som et supplement til nedenstående krav. Krav# 47: Fastsæt ydelsessats Beskrivelse: Løsningen skal fastsætte den ydelsessats, som en Person er berettiget til, korrekt ud fra oplysninger, som er registreret i Løsningen under oplysning af sagen. a) Ydelsessatsen skal være fastsat korrekt i henhold til lovgivningen og sagens oplysninger. b) Hvis det fremgår af lovgivningen, at der skal være fastsat ydelsessats for ægtefælle/samlever, er dette foretaget korrekt. - Lovgivningen, som Løsningen skal håndtere, varierer fra ydelse til ydelse. Eksempelvis indgår både ansøgeren og dennes ægtefælle/samlever i sager vedrørende uddannelseshjælp eller kontanthjælp. - Se informationsmodellen (Ydelseskatalog, Beregningsgrundlag) i underbilag Se underbilag 2.7 for eksempler på forskelle inden for lovgivningen på området. Krav# 48: Beregn beløb til udbetaling Beskrivelse: Løsningen skal beregne beløb, som skal udbetales, korrekt. a) Resultatet af beregningen er korrekt i henhold til lovgivningen, herunder gældende satser og grænsebeløb. b) Beregningen er foretaget med udgangspunkt i den fastsatte ydelsessats, udbetalingsperiodens længde og alle relevante oplysninger i sagen. c) Beregningen inkluderer alle registrerede oplysninger, der påvirker størrelsen af det beløb, som udbetales. d) Hvis det fremgår af lovgivningen, at der skal beregnes beløb til udbetaling for en eventuel ægtefælle/samlever, er dette foretaget korrekt. e) Hvis det fremgår af lovgivningen, at en eventuel ægtefælle/samlevers indtægter mv. skal indgå i beregningerne, er dette foretaget korrekt. - Resultatet af beregningen afhænger af lovgivningen og de oplysninger, der er registreret i sagen. Eksempler på oplysninger, der påvirker beløb til udbetaling, er sanktioner, indtægter, ægtefælle/samlevers indtægter (ved uddannelseshjælp eller kontanthjælp), fradrag for forskudsvis udlagt børnebidrag, individuelle tillæg/fradrag, ATP, skat og boligstøtte. - Se informationsmodellen (KY-effektuering, Ydelseskatalog, Beslutnings- Side 55 af 255

56 grundlag, Beregningsgrundlag) i underbilag Se Krav# 47 vedrørende fastsættelse af ydelsessats. - Se Krav# 346 om anvendelse af Ydelsesindekset. - Se underbilag 2.7 for eksempler på forskelle inden for lovgivningen på området. De efterfølgende krav i dette afsnit er elementer, der indgår i beregningen af beløb til udbetaling. Krav# 49: Beregning af indkomstgrundlag Beskrivelse: Løsningen skal beregne indkomstgrundlaget korrekt til brug for beregning af beløb til udbetaling. a) Indkomstgrundlaget for ansøger er beregnet korrekt i henhold til lovgivningen. b) Hvis det er nødvendigt for beregningen at beregne et korrekt indkomstgrundlag for en eventuel ægtefælle/samlever, er dette foretaget. c) Beregningerne er foretaget med udgangspunkt i de indkomstoplysninger, som er indhentet og/eller indberettet under oplysning af sagen. - Det varierer fra ydelse til ydelse, hvilke oplysninger, der indgår i beregningen af indkomstgrundlaget. Eksempelvis er der forskel på, hvilke oplysninger, der indgår i indkomstgrundlaget i en kontanthjælpssag og en sag vedrørende revalideringsydelse. Boligstøtte indhentes til beregning af 34 sager og særlig støtte. - Se informationsmodellen (Beregningsgrundlag) i underbilag Se Krav# 346 om anvendelse af Ydelsesindekset. Krav# 50: Beregn konsekvenser af sanktioner Beskrivelse: Løsningen skal beregne konsekvenserne af afgørelser om sanktioner korrekt og sikre, at disse konsekvenser slår igennem i beregningen af beløb til udbetaling. - a) Konsekvenser af sanktioner er beregnet korrekt i henhold til lovgivningen. b) Konsekvenser af sanktioner er indregnet korrekt i beregningen af beløb til udbetaling for den aktuelle udbetalingsperiode i henhold til lovgivningen. c) Konsekvenser af en sanktion indregnes kun, hvis der er registreret en afgørelse om godkendelse af sanktionen. d) Hvis en sanktion skal påvirke flere udbetalingsperioder, skal Løsningen sikre, at dette sker. e) Hvis det fremgår af lovgivningen, at sanktionen også skal påvirke en eventuel ægtefælle/samlever, er dette foretaget korrekt. Eksempelvis vil en sanktion efter LAS 42 stk. 2 nedsætte kontanthjælpen i 20 uger, hvilket vil påvirke flere udbetalingsperioder. En sådan sanktion skal i øvrigt også gælde for Personens ægtefælle. En sanktion efter LAS 40 a Side 56 af 255

57 kan også påvirke flere udbetalingsperioder, idet hjælpen kan standses i 1-3 måneder, og i stedet udbetales dag for dag i den periode. - Se Krav# 48 vedrørende beregning af beløb til udbetaling. - Se Krav# 62 om afgørelse om sanktion. - Se informationsmodellen (KY-effektuering) i underbilag 2.5. Krav# 51: Beregn og indehold ATP-bidrag Beskrivelse: Løsningen skal beregne og indeholde både personens og kommunens andel af et eventuelt ATP-bidrag korrekt og sikre, at det slår igennem i beregningen af beløb til udbetaling. a) Hvis det fremgår af lovgivningen, at der skal indbetales til ATP, skal Løsningen beregne ATP-bidraget korrekt og sikre, at beløbet indeholdes. b) Både Personens og kommunens andel af ATP-bidraget skal beregnes korrekt. c) Personens andel af ATP-bidraget skal indregnes korrekt i beløb til udbetaling. d) Hvis der udbetales til både Personen og en eventuel ægtefælle/samlever, skal Løsningen sikre, at beregning og indeholdelse af ATP-bidrag foretages korrekt for begge personer. - Se Krav# 48 vedrørende beregning af beløb til udbetaling. - Se informationsmodellen (ATP, Skatteberegning) i underbilag 2.5. Krav# 52: Beregn og indehold A-skat Beskrivelse: Løsningen skal beregne og indeholde AMB og A-skat korrekt. a) Hvis det fremgår af lovgivningen, at der skal trækkes AMB og/eller A- skat, skal Løsningen beregne disse beløb korrekt og sikre, at de indeholdes. b) De beregnede beløb skal indregnes korrekt i beløb til udbetaling. c) Hvis der udbetales til både Personen og en eventuel ægtefælle/samlever, skal løsningen sikre, at beregning og indeholdelse af AMB og A-skat foretages korrekt for begge personer. - Forsørgelsesydelser, fx er uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud A-skattepligtige. - Se informationsmodellen (ATP, Skatteberegning) i underbilag 2.5. Krav# 53: Foretag fradrag for forskudsvis udlagt børnebidrag Beskrivelse: Løsningen skal fastsætte og indeholde fradrag for forskudsvis udlagt børnebidrag korrekt og sikre, at det slår igennem i beregningen af beløb til udbetaling. Side 57 af 255

58 a) Hvis der i sagens oplysninger er registreret, at der skal foretages fradrag for forskudsvis udlagt børnebidrag, skal Løsningen sikre, at dette gøres korrekt i henhold til lovgivningen og validering mod de objektive kriterier for fradraget. b) Konsekvensen af indeholdelsen skal indregnes korrekt i beløb til udbetaling i henhold til lovgivningen. - Det er kun på visse ydelsesarter: kontanthjælp, uddannelseshjælp og revalideringsydelse, at der afhængig af oplysninger i sagen og lovgivningen skal foretages fradrag for forskudsvis udbetalt børnebidrag. - De objektive kriterier for fradrag fremgår af afsnit om forskudsvist udlagt børnebidrag. - Se Krav# 48 vedrørende beregning af beløb til udbetaling. - Se Krav# 293 vedrørende snitflade til at modtage oplysninger vedrørende forskuds udlagt børnebidrag fra UDK. - Se informationsmodellen (Beslutningsgrundlag, Beregningsgrundlag) i underbilag 2.5. Krav# 54: Beregn skatteværdi af renter på boliglån Beskrivelse: Løsningen skal indregne skatteværdien af renter, bidrag mv. for lån optaget i andels- eller ejerbolig i beregning af særlig støtte (LAS 34). a) Hvis der er registreret oplysninger om lån i boligen i en sag om særlig støtte skal Løsningen beregne skatteværdien korrekt i henhold til lovgivningen. b) Ved beregning skal aktuelle oplysninger om Personens fradrag og trækprocent være anvendt. c) Skatteværdien skal indgå korrekt i beregningen af særlig støtte. - Se informationsmodellen (Beregningsgrundlag) i underbilag 2.5. Krav# 55: Indberetning af individuelle tillæg/fradrag Beskrivelse: Det skal være muligt for brugeren manuelt at indberette individuelle tillæg eller fradrag i en specifik sag, så de indgår i beregning af beløb til udbetaling. a) En bruger skal kunne indberette de nødvendige oplysninger om et individuelt tillæg/fradrag på en specifik sag. b) Brugeren skal kunne vælge typen af tillæg/fradrag og indberette beløb, tidspunkt for effektuering eller antal gange og frekvens for effektuering. c) Løsningen skal ved indberetning sikre, at reglerne, som er konfigureret på ydelsen og typen af tillæg/fradrag, overholdes. d) Registrerede tillæg/fradrag skal indregnes korrekt i beregningen af beløb Side 58 af 255

59 til udbetaling. e) Løsningen skal ved indberetning oprette et journalnotat på sagen automatisk. - Se Krav# 211 vedrørende konfigurering af typer af individuelle tillæg/fradrag. - Se informationsmodellen (Ydelseskatalog, Bevilling, Bevilget ydelse) i underbilag Se afsnit vedrørende journalnotater Beregning ved udbetaling af helbredstillæg og udvidet helbredstillæg I dette afsnit angives et specifikt krav til beregning vedrørende udbetaling af helbredstillæg og udvidet helbredstillæg. Kravet er det eneste til særskilt understøttelse af beregning af beløb til udbetaling i forhold til andre ydelser. Kravet udgør en undtagelse fra hovedreglen om, at Løsningen ikke understøtter beregninger vedrørende enkeltydelser og andre ydelser. Læs mere om andre ydelser i afsnit 3.3 og underbilag 2.3 om sagsbehandlingsprocesserne vedrørende enkeltydelser og andre ydelser. Krav# 56: Beregning af helbredstillæg og udvidet helbredstillæg Beskrivelse: Løsningen skal beregne det beløb, som skal udbetales i helbredstillæg eller udvidet helbredstillæg. - a) Det beløb, som skal udbetales i helbredstillæg, er beregnet korrekt i henhold til lovgivningen. b) Det beløb, som skal udbetales i udvidet helbredstillæg, er beregnet korrekt i henhold til lovgivningen. Se Krav# 292 vedrørende snitflade til at indhente oplysninger til beregningen Træf afgørelse Under oplysning af sagen indsamles alle de oplysninger, der skal til at afgøre sagen (jf. afsnit 5.2.1). På baggrund af disse oplysninger vurderer sagsbehandleren, om der er behov for en fastsættelse og beregning af ydelsen (jf ). Når disse aktiviteter er udført, kan sagsbehandleren træffe en afgørelse i sagen og indberette denne i Løsningen. Den indsats, der er forbundet hermed, vil ofte være begrænset, da størstedelen af sagsbehandlingen er foretaget under oplysning af sagen. Afgørelsen vil være en bevilling, et afslag eller afslutning af igangværende bevilling. Når der træffes en afgørelse, skal Personen orienteres herom. I forbindelse med afgørelsen vil sagsbehandleren desuden færdiggøre en effektueringsplan (se afsnit ), såfremt der bevilges en ydelse. Det samme skal ske ved afgørelse om indmeldelse i fleksydelsesordningen, idet effektueringsplanen i dette tilfælde danner grundlag for opkrævning af fleksydelsesbidrag. Som nævnt i afsnit kan der tidligere i sagens forløb have været foretaget beregninger. Resultater herfra vil være gemt på sagen i kladdetilstand Dags dato (14. januar 2014) træffes alle afgørelser som hovedregel af en sagsbehandler, da der i de fleste Ydelser, der håndteres i Løsningen, ikke er lovmæssig hjemmel til at træffe objektive au- Side 59 af 255

60 tomatiske afgørelser. Det er dog forventningen, at dette vil komme med tiden, og Løsningen skal således være forberedt på dette. Krav# 57: Indberet afgørelse Beskrivelse: Det skal være muligt for en bruger at indberette, at der er truffet en afgørelse med et givet udfald, fx bevilling, afslutning af bevilling eller afslag på bevilling. a) Løsningen validerer, at de nødvendige minimumsoplysninger for den relevante ydelsesart er registreret på afgørelsen. b) Hvis de nødvendige minimumsoplysninger ikke er registreret, gøres brugeren opmærksom på dette. c) Løsningen ændrer status på sagen. d) Hvis afgørelsen medfører bevilling af en ydelse, registrerer Løsningen de nødvendige oplysninger om bevilling og effektueringsplan. Dette gælder også, hvis ydelsen er tilbagebetalingspligtig. e) Hvis udfaldet er afslag på bevilling, kan brugeren registrere en årsag til afslaget. Årsagen kan være suppleret af kommentar. f) Løsningen afsender besked om bevilling til Jobcenterløsning. g) Løsningen afsender besked om udfald af afgørelsen til AMS Det Fælles DataGrundlag. h) Brugeren har mulighed for manuelt at ændre kassationskoden fra standardværdien. i) Det skal være muligt at oprette en bevilling med tilbagevirkende kraft inden for indeværende og forrige år. - Se Krav# 63 om automatisk oprettelse af effektueringsplan. - Oprettelse af bevilling med tilbagevirkende kraft er fx relevant i det tilfælde, hvor der foreligger en ankeafgørelse, der medfører behov for at udbetale kontanthjælp for de seneste 14 måneder. - Bemærk at krævede oplysninger for en afgørelse kan være forskellige fra ydelsesart til ydelsesart. - Se Krav# 23 vedrørende kassationskoder. - Se Krav# 286 om Jobcenterløsning. - Se Krav# 291 om AMS Det Fælles DataGrundlag. - Se informationsmodellen (KY-sag, KY-dokument, KY-bevilling, KYeffektuering, Beslutningsgrundlag, Træf afgørelse, Bevilling, Effektuering, Sanktionering, Beregningsgrundlag) i underbilag 2.5. Krav# 58: Besked om afgørelse Beskrivelse: Når afgørelsen er truffet, informeres Personen skriftligt om udfaldet. a) Løsningen kan afsende en bevillingskrivelse (inklusiv en effektueringsplan) eller et begrundet afslag med klagevejledning. Side 60 af 255

61 b) Brevet kan indeholde information om tilbagebetalingspligt. c) Brugeren kan benytte brevfunktionaliteten beskrevet i Krav# 127 til at udforme brevet. - Se afsnit vedrørende generelle krav til breve. - Se Krav# 64 vedrørende effektueringsplan. Det er ikke obligatorisk at sende en skriftlig besked om afgørelsen, idet beskeden også kan gives mundtligt. Der kan være årsager til, at en sagsbehandler ønsker at se på hvilket grundlag, en tidligere afgørelse blev truffet. Det kan fx være, hvis parten i sagen stiller spørgsmål til afgørelsen, eller der er nye oplysninger i sagen. Hvis det er en afgørelse, der tidsmæssigt ligger et stykke tilbage, kan nogle af oplysningerne i mellemtiden have ændret sig. Derfor er det vigtigt, at sagsbehandleren kan se de oplysninger, som var til stede på det tidspunkt, afgørelsen blev truffet. Krav# 59: Fremfinding af grundlaget for afgørelsen Beskrivelse: De oplysninger, der er blevet benyttet i forbindelse med at træffe en afgørelse, skal brugeren til enhver tid kunne fremfinde igen samlet. Dette er særlig relevant, hvis der efterfølgende er blevet ændret i oplysningerne. - Se Krav# 152 vedrørende visning af sagen oplysninger pr. brugervalgt dato og tid. - Se afsnit vedrørende Bitemporalitet Behandling af sanktioner I forbindelse med sager om forsørgelsesydelser, eksempelvis uddannelseshjælp eller kontanthjælp og ledighedsydelse, skal Personen som hovedregel deltage i et kontaktforløb med Jobcentret. Såfremt Personen fx ikke møder op til samtaler eller tilsidesætter sin oplysningspligt, indstiller Jobcentret til Ydelsescentret, at Personen skal sanktioneres økonomisk, ligesom Jobcentret i visse tilfælde kan træffe afgørelse om sanktion. Indstillinger om sanktioner overføres automatisk fra JobcenterIøsningerne til Løsningen, der oprettes en opgave, og Ydelsescentret træffer afgørelse om sanktionen gennemføres eller ikke. I visse tilfælde kan Ydelsescentret på eget initiativ træffe afgørelse om sanktion, fx hvis Ydelsescentret bliver bekendt med, at Personen har tilsidesat sin oplysningspligt jf. LAS 42 stk. 2. Såfremt sanktionen skal gennemføres, skal Løsningen sikre, at konsekvenserne slår igennem på det beløb, som udbetales til Personen og eventuelt også ægtefællen/samleveren i sager vedr. uddannelseshjælp eller kontanthjælp. Dette involverer en række regler, som er fastsat for de forskellige ydelsesarter, der bl.a. fastsætter den økonomiske størrelse af sanktionen, varigheden og hvorvidt sanktionen også skal gælde for Personens ægtefælle/samlever. Krav# 60: Se indstilling fra jobcenter om sanktion Beskrivelse: Det skal være muligt for en bruger at se en indstilling om sanktion, der er gemt på en sag. Der skal være direkte adgang til at angive en afgørelse om godkendelse eller afvisning af sanktionen. Side 61 af 255

62 a) Alle indstillinger om sanktioner modtaget fra Jobcenter-løsningen er tilgængelige for en bruger. b) Løsningen har dannet lovhenvisning på sanktionsindstillinger, som er dannet på grundlag af besked fra Jobcentret via snitflade. c) Brugeren kan tilføje/ændre oplysning om lovhenvisning. d) Brugeren kan navigere direkte til en funktion, hvor afgørelse om godkendelse/afvisning af sanktion kan registreres. - Lovhenvisningen (paragraf, stk. nr.) dannes ud fra oplysning om målgruppe og hændelse, som indgår i sanktionsindstillingen fra Jobcenter-løsningen. - Se Krav# 282 og Krav# 283 om beskeder fra Jobcenter-løsning. - Se Krav# 62 om godkendelse/afvisning af sanktion. - Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5. Krav# 61: Opret indstilling om sanktion Beskrivelse: Det skal være muligt for en bruger på eget initiativ at oprette en sanktionsindstilling på en sag. Der skal være direkte adgang for brugeren til at angive en afgørelse om sanktionen. a) Brugeren kan oprette en sanktionsindstilling. b) Brugeren kan registrere oplysning om lovhenvisning. c) Brugeren kan navigere direkte til en funktion, hvor afgørelse om godkendelse/afvisning af sanktion kan registreres. d) Der skal kunne oprettes flere sanktioner på samme sag. - Lovhenvisning er til paragraf, stk., nr. - Se Krav# 282 og Krav# 283 om beskeder fra Jobcenter-løsning. - Se Krav# 62 om godkendelse/afvisning af sanktion. - Se informationsmodellen (KY-kontaktforløb) i underbilag 2.5. Krav# 62: Angiv afgørelse om sanktion Beskrivelse: Det skal være muligt for en bruger at angive en afgørelse om sanktion. a) Løsningen skal sikre, at der ikke kan træffes afgørelse om sanktion, der strider mod lovgivningen. - Afgørelsen kan tage udgangspunkt i en indstilling om sanktion fra Jobcentret (se eventuelt Krav# 60), eller en sanktion, som er indberettet på Ydelsescentrets eget initiativ (se eventuelt Krav# 61). - Se krav Krav# 50 om gennemførelse af sanktion. - Se informationsmodellen (KY-effektuering, KY-kontaktforløb, Træf afgørelse) i underbilag 2.5. Side 62 af 255

63 Fastlæg effektueringsplan Hvis der er truffet afgørelse om, at Personen er berettiget til ydelsen, sendes som en del af bevillingsskrivelsen oplysninger fra effektueringsplanen. Denne er en oversigt over ydelsens størrelse, hvilken frekvens der udbetales med mv. Hvis der er foretaget beregning af beløb til udbetaling tidligere end det tidspunkt, hvor effektueringsplanen fastlægges, vil der være registreret en kladde effektueringsplan i sagen, som er udgangspunktet for at færdiggøre effektueringsplanen. Som oftest vil der ikke ligge nogen opgave for sagsbehandleren i denne aktivitet, da effektueringsplanen for langt de fleste sager følger standarden for den pågældende ydelsesart mht. udbetalingstidspunkter mv. Men der kan være særtilfælde, hvor det er nødvendigt at ændre effektueringsplanen for den enkelte sag. Forsørgelsesydelserne udbetales pt. som hovedregel bagud den sidste bankdag i måneden. Krav# 63: Automatisk oprettelse af effektueringsplan Beskrivelse: Løsningen skal sikre, at de oplysninger, som er nødvendige for effektuering og bestilling af udbetalinger - eller opkrævninger i en sag om fleksydelsesbidrag gemmes i sagen, så de kan vedligeholdes og bruges ved efterfølgende effektueringer af udbetalinger og opkrævninger. a) Løsningen skal sikre, at oplysninger til brug for effektuering og bestilling af udbetalinger automatisk gemmes i sagens oplysninger om bevilget ydelse og effektueringsplan. b) Løsningen skal sikre, at oplysninger til brug for effektuering og bestilling af betaling via debitorsystem automatisk gemmes i sagens oplysninger om bevilget ydelse og effektueringsplan. c) Løsningen skal sikre, at oplysninger til brug for effektuering og bestilling af opkrævninger i sager om fleksydelsesbidrag automatisk gemmes i sagens oplysninger om bevilget ydelse og effektueringsplan. d) Løsningen skal sikre, at effektueringsplaner oprettes korrekt i henhold til lovgivningen, sagens oplysninger og de oplysninger, som er konfigureret i Løsningen for den aktuelle ydelsesart, kalender for beregning, effektuering og udbetaling eller opkrævning af fleksydelsesbidrag. - Forsørgelsesydelser som uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud udbetales månedsvis. Er Personen under administration kan uddannelseshjælp og kontanthjælp udbetales i flere rater i henhold til oplysninger på en administrationsordning. - I situationer, hvor beløbsmodtager er en organisatorisk enhed i kommunen, kan beløbet overføres via kommunens debitorsystem, som alternativ til udbetaling via udbetalingssystem. - Effektuering af opkrævninger er relevant i forbindelse med fleksydelsesbidrag. Side 63 af 255

64 - Se afsnit og Krav# 222 vedrørende konfigurering af ydelser og kalender for effektuering og udbetaling samt opkrævning af fleksydelsesbidrag. - Se Krav# 109 vedrørende tilknyttet administrationssag. - Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag 2.5. Krav# 64: Ændring af effektueringsplan i sager vedr. forsørgelsesydelser Beskrivelse: Det skal være muligt for en bruger at ændre i oplysninger vedrørende effektueringsplanen på den enkelte sag. a) Brugeren kan ændre de nødvendige oplysninger om effektuering og udbetaling i sagen. b) Brugeren kan ændre de nødvendige oplysninger om effektuering og debitor-betaling i sagen. c) De nødvendige oplysninger udgør som minimum betalingsdato(er), frekvens og hvorvidt hver enkelt udbetaling skal godkendes manuelt. d) Brugeren skal kunne indberette de nødvendige oplysninger, så sagen effektueres samtidig med almindelig massebestilling af udbetaling. e) Brugeren skal kunne indberette de nødvendige oplysninger om betaling hurtigst muligt. f) Brugeren skal kunne indberette de nødvendige oplysninger til, at Løsningen kan danne et straksudbetalingsbilag. g) Løsningen skal sikre, at ændringerne er i overensstemmelse med lovgivning og de oplysninger, som er konfigureret i Løsningen om den relevante ydelse. - Se Krav# 63 om automatisk oprettelse af effektueringsplan. - Se afsnit og Krav# 222 vedrørende konfigurering af ydelser og kalender for effektuering og udbetaling. - Se Krav# 80 vedrørende manuel godkendelse/annullering af udbetaling. - Se informationsmodellen (KY-effektuering) i underbilag 2.5. Krav #65: Indberet oplysninger om effektuering i sager vedr. enkeltydelser og andre ydelser Beskrivelse: Det skal være muligt for brugeren manuelt at indberette nødvendige oplysninger vedrørende bevilling og effektueringsplan på en specifik sag, så Løsningen kan udbetale en bevilget enkeltydelse eller anden ydelse korrekt. a) Brugeren kan ændre de nødvendige oplysninger for at kunne fastsætte effektuering og udbetaling i sagen. b) Brugeren kan ændre de nødvendige oplysninger for at kunne fastsætte effektuering og debitor-betaling i sagen. c) De nødvendige oplysninger udgør som minimum valg af ydelsesart, mod- Side 64 af 255

65 tager, bevilget beløb, individuelle tillæg/fradrag, antal udbetalinger, betalingsdato(er), frekvens, hvorvidt hver enkelt udbetaling skal godkendes (se eventuelt Krav# 80), hvorvidt udbetaling kun skal ske ved modtagelse af regning. - Se Krav# 66 vedrørende registrering af alternativ modtager. - Se eventuelt informationsmodellen (KY-enkeltydelser, KY-andre ydelser) i underbilag 2.5. Krav# 66: Registrering af alternativ modtager Beskrivelse: Det skal være muligt for brugeren manuelt at tilknytte en virksomhed som alternativ modtager på effektueringsplanen i en ydelsessag eller på en betalingsaftale i en administrationssag. Som en del heraf skal brugeren i Løsningen kunne fremsøge virksomheder fra CVR-registret. a) Brugeren skal kunne registrere de nødvendige oplysninger om en alternativ modtager, så der kan udbetales til denne. b) Brugeren skal som en del af registreringen kunne fremsøge virksomheder fra CVR-registret ved hjælp af CVR-nummer eller navn og adresse på virksomheden. Løsningen skal overføre de nødvendige oplysninger fra CVR-registret. c) Brugeren skal kunne tilknytte alternativ modtager til effektueringsplanen i en ydelsessag eller til en betalingsaftale i en administrationssag. d) Løsningen skal ved effektuering og udbetaling i sagen anvende de registrerede oplysninger, så der udbetales rettidigt og korrekt til den alternative modtager. - Se informationsmodellen (KY-bevilling, KY-effektuering) i underbilag Se afsnit 5.3 vedrørende administrationssager. - Se afsnit vedrørende ØiR snitflade til udbetalingssystem. - Se afsnit vedrørende snitflade til CVR-registret. Krav# 67: Registrering af specifik bankkonto Beskrivelse: Det skal være muligt for brugeren manuelt at registrere et specifikt bankkontonummer som alternativ til Nemkonto. a) Brugeren skal kunne registrere et specifikt bankkontonummer som et alternativ til NemKonto for en specifik Person. b) Brugeren skal kunne registrere et specifikt bankkontonummer som et alternativ til NemKonto for en specifik alternativ modtager. c) Brugeren skal kunne tilknytte kontonummeret til alle eller udvalgte effektueringsplaner for Personen eller den alternative modtager. d) Løsningen skal anvende oplysningerne, når der overføres udbetalings- Side 65 af 255

66 anmodninger til udbetalingssystem. e) Løsningen skal sikre, at en registrering af specifik bankkonto fremgår af særskilt kontrolrapport. - Se informationsmodellen (KY-bevilling, KY-effektuering) i underbilag Se afsnit vedrørende ØiR snitflade til udbetalingssystem. - Se afsnit vedrørende kontrolrapporter Behandl udmeldelse af fleksydelsesordning Fleksydelse er en ordning, som personer, der er visiteret til et fleksjob, automatisk indmeldes i ved visiteringen. Brugeren kan træffe afgørelse om at udmelde en Person af fleksydelsesordningen med angivelse af årsagen hertil. Derefter skal brugeren have mulighed for at kunne behandle de økonomiske konsekvenser af udmeldelsen. Afhængig af årsagen til udmeldelse, kan der være behov for at udbetale overskydende fleksydelsesbidrag til Personen eller boet efter Personen eller at overføre beløbet til en pensionsordning. Det tilbagebetalte bidrag er skatte- eller afgiftspligtigt, og metoden for beregning afhænger af årsagen til udmeldelse. Selve beregningen af skat eller afgift understøttes ikke af Løsningen. Selve udbetalingen af overskydende fleksydelsesbidrag foretages som udbetaling af anden ydelse (se eventuelt Krav #65). Krav i dette afsnit er rettet specifikt mod understøttelse af fleksydelsesordningen og skal ses som supplement til de generelle krav i kapitel 5, som retter sig mod alle de ydelser, som Løsningen skal understøtte, herunder krav om oplysning af sag, beregning, afgørelse, effektuering og udbetaling samt krav vedrørende opkrævning af fleksydelsesbidrag i afsnit Underbilag 2.14 (Beregninger og regler vedrørende fleksydelse) indeholder vejledende beskrivelser af beregninger og regler vedrørende tilbagebetaling af fleksydelsesbidrag. Krav# 68: Beregn overskydende fleksydelsesbidrag ved udmeldelse af fleksydelsesordningen Beskrivelse: Løsningen skal beregne bruttoværdien af eventuelle overskydende fleksydelsesbidrag, som Personen skal have udbetalt eller overført til pensionsordning, og udpege metode for beskatning/afgiftsberegning. a) Bruttoværdien af et overskydende fleksydelsesbidrag er beregnet korrekt i henhold til lovgivningen. b) Løsningen har udpeget den korrekte metode for beskatning/afgiftsberegning i henhold til lovgivningen. - Selve beregningen af skat/afgift foretages uden for Løsningen afhængig af den metode, som er blevet udpeget, eksempelvis ved at kontakte SKAT. - Se informationsmodellen (KY-fleksydelse) i underbilag Etabler sag og afgørelse på baggrund af inddata fra Jobcenter-løsning Som hovedregel er det Ydelsescentret, der både bevilger og effektuerer ydelserne på baggrund af eksempelvis information fra Jobcentret om kontaktforløb mv. Der er dog nogle få undtagelser, idet Side 66 af 255

67 fleksløntilskud (LAB) og enkelte andre ydelser bevilges af Jobcentret og effektueres i Ydelsescentret, eksempelvis godtgørelse til befordringsgodtgørelse efter LAB 82 og udgifter ved deltagelse i tilbud efter LAB 83. I disse tilfælde er der behov for, at der i Løsningen kan oprettes en sag med tilhørende bevilling, effektueringsplan mv. ud fra information fra en Jobcenterløsning, således at ydelsen kan effektueres automatisk uden Ydelsescentrets involvering. Dette supplerer sagsbehandlerens generelle mulighed for at oprette og behandle sager, som også gælder for sager om disse ydelser. Krav# 69: Automatisk etablering af sag ud fra information fra Jobcenter-løsning Beskrivelse: Løsningen skal kunne registrere de oplysninger, som er nødvendige for, at der kan effektueres og udbetales visse ydelser udelukkende på baggrund af oplysninger, som overføres fra en Jobcenter-løsning. a) Løsningen kan på baggrund af data fra Jobcenterintegrationen gøre følgende uden en brugers indblanding: A. Løsningen kan oprette en sag vedrørende den type af ydelse, som svarer til den type godtgørelse, der fremgår af beskeden. B. Sagen er tilknyttet korrekt til den Person, som har fået bevilget godtgørelsen. C. Oplysninger fra beskeden er registreret korrekt på sagen. D. Løsningen kan registrere en afgørelse om bevilling med tilhørende effektueringsplan E. Løsningen kan effektuere og udbetale ydelsen. F. Løsningen kan afslutte og lukke sagen samt genoptage sagen. - Se Krav# 92 om effektuering ud fra oplysninger fra Jobcenterløsning. Dette vedrører et begrænset antal godtgørelsesydelser, der kan overføres via integration til Jobcenter-løsning. - Se Krav# 279 vedrørende besked fra Jobcenterløsning. - Se informationsmodellen (KY-Sag, KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag Se hændelseslisten i underbilag Effektuer Når der er truffet en afgørelse, bevilget en ydelse og effektueringsplanen er fastlagt, er det tid til at effektuere afgørelsen. Dette vedrører Beregning (jf. afsnit 5.2.2) Bestilling af udbetalingen (jf. afsnit ) Kontering (jf. afsnit ) Derudover er der for fleksydelsesbidrag en særlig aktivitet; bestilling af opkrævning (jf. afsnit ). For sager om visse godtgørelser Side 67 af 255

68 mv., der bevilges af Jobcentret og udbetales af Ydelsescentret, er der også behov for automatisering af dette Bestil udbetaling Løsningen anvendes til at håndtere økonomiske ydelser, der som hovedregel udbetales til den Person, som er berettiget til ydelsen eller i visse tilfælde til en alternativ modtager, eksempelvis tandlæger eller optikere eller boligselskaber og forsyningsselskaber. Endelig kan der være beløb som skal betales til en organisatorisk enhed inden for kommunen. Forsørgelsesydelserne, herunder fleksydelse, udbetales som hovedregel månedsvis bagud, således at pengene er til disposition den sidste bankdag i måneden, dvs., der massebestilles udbetalinger. Der kan også være tale om udbetalinger, som skal foretages på andre tidspunkter, herunder dag-til-dag udbetalinger. Når der effektueres, sker det i henhold til sagens effektueringsplan. Der foretages beregning og der bestilles udbetaling (eller opkrævning af fleksydelsesbidrag) og konteres. Det er helt centralt, at Løsningen kan bestille udbetalinger ved at aflevere udbetalingsanmodninger til et eksternt udbetalingssystem og sikre, at bogføring af udbetalingen sker i et eksternt økonomisystem ved at overføre posteringer hertil. På denne måde adskilles den fagspecifikke sagsbehandlingsfunktionalitet i Løsningen fra mere generel udbetalings- og bogføringsfunktionalitet, som Løsningen deler med andre fagsystemer. Der kan være behov for, at den enkelte udbetaling af en forsørgelsesydelse som kontanthjælp eller udbetaling af en enkeltydelse, skal godkendes af en bruger, før den kan effektueres. Ved eksempelvis kontanthjælp kan det skyldes, at Personen har indtægter i udbetalingsperioden, som skal nedsætte beløbet til udbetaling, når Personen har fremsendt dokumentation for indtægterne. Ved enkeltydelser kan det skyldes, at Personen skal dokumentere en given udgift, for at udbetalingen godkendes. I sager vedrørende enkeltydelser eller andre ydelser samt administrationssager, hvor der er bevilget hjælp til betaling af bestemte tjenester eller varer, modtager Ydelsescentret endvidere regninger fra behandlere eller andre leverandører af tjenester eller varer, som skal betales. Løsningen skal kunne modtage elektroniske fakturaer, ligesom en sagsbehandler skal kunne registrere papirregninger. Nogle udbetalinger, eksempelvis udbetaling af enkeltydelser, skal i særlige tilfælde foretages straks. Dette betyder som hovedregel, at Løsningen skal bestille udbetalingen umiddelbart efter, at de nødvendige oplysninger er indberettet, og anmode udbetalingssystemet om, at udbetalingen foretages hurtigst muligt, dvs. samme eller næste bankdag. Undtagelsesvis kan brugeren vælge at udskrive et straksudbetalingsbilag, som efterfølgende kan benyttes ved kontant udbetaling eller udstedelse af check. Løsningen skal ikke sende udbetalingsanmodning for et sådant straksudbetalingsbilag, men kontere det korrekt. Krav# 70: Automatisk effektuering af udbetalinger Beskrivelse: Løsningen skal effektuere udbetalinger på fastsatte tidspunkter ved at overføre oplysninger til et eksternt udbetalingssystem. a) Løsningen skal automatisk effektuere beregning, udbetaling og kontering på de tidspunkter, der er konfigureret i Løsningen for de enkelte ydelses- Side 68 af 255

69 arter. b) Alle beregninger og udbetalinger er effektueret korrekt og rettidigt i henhold til oplysningerne på sagens effektueringsplaner. c) Hvis der på en effektueringsplan i en sag er registreret specifikke oplysninger om undtagelse fra den generelle effektuering, herunder særskilt tidspunkt for effektuering og udbetaling, er den effektueret korrekt og rettidigt i henhold til disse oplysninger. d) Hvis der til en ydelsessag er tilknyttet en administrationsordning med oplysninger, der påvirker effektuering og udbetaling, er der taget højde herfor ved effektuering og udbetaling. - Forsørgelsesydelser som uddannelseshjælp, kontanthjælp, revalideringsydelse, ledighedsydelse og fleksløntilskud udbetales månedsvis. Er Personen under administration, kan uddannelseshjælp og kontanthjælp udbetales i flere rater. - For enkeltydelser og andre ydelser effektueres der typisk en eller flere gange ugentligt. - Se Krav# 215 vedrørende kalender for effektuering og udbetaling for forsørgelsesydelser og løbende enkeltydelser. - Se Krav# 64 vedrørende specifikke oplysninger på den enkelte sags effektueringsplan). - Se Krav# 72 vedrørende massebestilling af udbetalinger. - Se Krav# 73 vedrørende anmodning om udbetaling hurtigst muligt. - Se Krav# 109 vedrørende tilknyttet administrationssag. - Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag Se afsnit om ØiR snitflade til udbetalings- og økonomisystemer. Som supplement til den automatiske effektuering skal en bruger kunne igangsætte effektuering manuelt. Krav# 71: Manuel effektuering og bestilling af udbetaling Beskrivelse: Det skal være muligt for en bruger at igangsætte effektuering i en specifik sag, så Løsningen kan bestille en udbetaling. - a) Brugeren skal kunne igangsætte effektuering i en specifik sag valgt af brugeren. b) Løsningen skal sikre, at der anmodes om rettidig og korrekt udbetaling ud fra de oplysninger, der er gemt på sagens effektueringsplan. c) Udbetalingsanmodningen skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan udbetale korrekt og rettidigt. d) Udbetalingsanmodningen er konteret korrekt. e) Ydelsesindeks er opdateret korrekt. Der kan i visse tilfælde være behov for, at brugeren kan bestille en udbeta- Side 69 af 255

70 ling, der fx baseres på en beregning, som er foretaget for tidligere udbetalingsperioder. Det kan være i en sag, hvor der er kommet en afgørelse i en tilknyttet klagesag. - Se Krav# 45 om manuel igangsætning af beregning. - Se afsnit om ØiR snitflade til udbetalings- og økonomisystemer. Når der effektueres, involverer det nedenstående elementer: Krav# 72: Massebestilling af udbetalinger Beskrivelse: Løsningen skal sikre bestilling af udbetaling, således at alle udbetalinger for alle bevilgede ydelser i alle sager (massebestilling) automatisk sker korrekt og rettidigt til rette modtager. Udbetalinger bestilles ved at aflevere udbetalingsanmodninger til økonomisystemet via snitflade. a) Der er anmodet om udbetaling korrekt og rettidigt i alle sager, hvori der skal ske udbetaling i den aktuelle udbetalingsperiode. b) Udbetalingsanmodningerne skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan udbetale korrekt og rettidigt. c) Udbetalingsanmodningerne indeholder den korrekte information i henhold til de oplysninger, som er indberettet på effektueringsplanen i de enkelte sager. d) Alle beløb, der indgår i alle bestilte udbetalinger, er konteret korrekt. e) Ydelsesindeks er opdateret korrekt for alle udbetalinger. - Se Krav# 209, Krav# 210 og Krav# 215 og kravene i afsnit 5.2.2, og vedrørende effektuering. - Se afsnit vedrørende kontering. - Se og vedrørende snitflade til Ydelsesindeks. - Se afsnit om ØiR snitflade til udbetalings- og økonomisystem. Krav# 73: Bestil udbetaling hurtigst muligt Beskrivelse: Løsningen skal kunne bestille en udbetaling, der gennemføres hurtigst muligt, så den er til disposition samme eller næste bankdag. a) Hvis der er registreret udbetaling hurtigst muligt, har Løsningen anmodet om udbetaling korrekt og rettidigt, så den er til disposition hurtigst muligt, dvs. samme eller næste bankdag. b) Udbetalingsanmodningerne skal indeholde tilstrækkelige oplysninger til, at udbetalingssystemet kan udbetale korrekt hurtigst muligt. c) Udbetalingsanmodningerne indeholder den korrekte information i henhold til de oplysninger, som er indberettet på effektueringsplanen. d) Udbetalingsanmodningerne er konteret korrekt. e) Ydelsesindeks er opdateret korrekt. Side 70 af 255

71 - Hensigten er, at udbetalingen sker samme eller næste bankdag, såfremt udbetalingssystemet og tilknyttede systemer, herunder sammenhæng med pengeinstitutter etc. tillader det. - Se afsnit vedrørende kontering. - Se og vedrørende snitflade til Ydelsesindeks. - Se afsnit om ØiR snitflade til udbetalings- og økonomisystemer. Krav# 74: Dan straksudbetalingsbilag Beskrivelse: Løsningen skal kunne danne et straksudbetalingsbilag, der kan udskrives lokalt. a) Løsningen skal kunne danne et straksudbetalingsbilag korrekt i forhold til de oplysninger, der er registreret i sagens effektueringsplan. b) Straksudbetalingsbilaget er udskrevet med de korrekte oplysninger fra sagen, når brugeren har valgt at udskrive bilaget lokalt. c) Straksudbetalingsbilaget er konteret korrekt. d) Ydelsesindeks er opdateret korrekt. - Straksudbetalingsbilaget er et alternativ til bestilling af udbetaling hurtigst muligt via udbetalingssystemet, og bruges, når en Person skal have udbetalt penge her og nu. - Se Krav# 135 vedrørende lokalt print. - Se afsnit vedrørende kontering. - Se og vedrørende snitflade til Ydelsesindeks. - Se afsnit om ØiR snitflade til økonomisystem. Krav# 75: Bestil debitor-betaling Beskrivelse: Løsningen skal kunne bestille en betaling til en organisatorisk enhed inden for kommunen, som foretages via kommunens debitorsystem. a) Anmodninger om debitor-betaling skal indeholde tilstrækkelige oplysninger til, at debitorsystemet kan betale korrekt og rettidigt. b) Anmodninger om debitor-betaling indeholder den korrekte information i henhold til de oplysninger, som er indberettet på effektueringsplanen. c) Løsningen skal sikre, at alle nødvendige oplysninger er overført til et eksternt debitorsystem. d) Anmodninger om debitor-betaling er konteret korrekt. - Dette er et alternativ til bestilling af udbetaling via udbetalingssystemet, såfremt betalingsmodtageren er en organisatorisk enhed i kommunen. Dette kan forekomme, fx hvis der foretages fradrag for betaling for dag- eller klubtilbud efter LAS 96. Her overføres pengene via kommunens debitorsystem. - Se afsnit vedrørende kontering. - Se afsnit om ØiR snitflade til debitor- og økonomisystemer. Side 71 af 255

72 - Se informationsmodellen (KY-effektuering, Debitorbetaling) i underbilag 2.5. Krav# 76: Udbetalingsspecifikation til person Beskrivelse: Løsningen skal levere en udbetalingsspecifikation via fjernprintsløsningen ved enhver udbetaling til en Person, der har fået bevilget en ydelse. a) Løsningen kan afsende en udbetalingsspecifikation ved enhver bestilling af udbetaling til en Person. b) Udbetalingsspecifikationen indeholder som minimum oplysninger om bevilget ydelsesbeløb, tillæg og fradrag, herunder beløb anvendt til administration samt indeholdt ATP og A-skat mv. for den aktuelle udbetaling og for året til dato. Det endelige indhold og format afklares med leverandøren. - Vær opmærksom på at en udbetaling også kan være på 0 kr. Personen skal også i dette tilfælde modtage en udbetalingsspecifikation, så han/hun kan se, hvorfor han/hun ikke har modtaget penge. - Se Krav# 72 og Krav# 73 vedrørende udbetalinger til Personer. - Se Krav# 357 vedrørende brug af fjernprintløsningen. - Se informationsmodellen (KY-effektuering, Bevilling, Effektuering, Sanktionering, ATP + Skatteberegning) i underbilag 2.5. Krav# 77: Overførsel af oplysninger til indkomstregistret (eindkomst) Beskrivelse: Løsningen skal, når der udbetales skattepligtige ydelser automatisk, overføre oplysninger pr. Person eller alternativ modtager til indkomstregistret (eindkomst). - a) Løsningen har afleveret de korrekte og nødvendige oplysninger til indkomstregistret ved enhver udbetaling af skattepligtige ydelser. b) Oplysningerne udgør som minimum ydelser, bruttobeløb, indeholdt A- skat, AMB, ATP, B-skattepligtige beløb og øvrige obligatoriske oplysninger krævet af indkomstregistret. c) Oplysningerne er indberettet under det korrekte SE-nummer. Se Krav# 359 vedrørende snitflade til indkomstregistret (eindkomst). Krav# 78: Tilbagebetalingspligtigt beløb restanceføres i debitorsystem Beskrivelse: Løsningen skal restanceføre tilbagebetalingspligtige beløb i et eksternt debitorsystem. a) Tilbagebetalingspligtige beløb er restanceført korrekt og rettidigt. b) Løsningen skal sikre, at kun beløb, som er godkendt af en bruger, re- Side 72 af 255

73 - stanceføres. c) Løsningen skal sikre, at alle nødvendige oplysninger er overført til et eksternt debitorsystem. Se afsnit om ØiR snitflade til debitorsystem. Krav# 79: Betalingsmeddelelse til alternativ modtager Beskrivelse: Løsningen skal ved hver udbetaling til alternativ modtager aflevere oplysninger til en betalingsmeddelelse til udbetalingssystemet. a) Løsningen har afleveret de korrekte og nødvendige oplysninger for en betalingsmeddelelse til udbetalingssystemet ved enhver udbetaling til en alternativ modtager. b) Oplysningerne udgør som minimum beløb, hvem betalingen vedrører, årsagen til betalingen samt en valgfri tekst. Det endelige indhold og format afklares med leverandøren. - Betalingsmeddelelsen svarer til en betalingsmeddelelse fra Betalingsservice eller en linje på et kontoudtog fra et pengeinstitut. - Se informationsmodellen (KY-andre ydelser, KY-enkeltydelser, Betalingsadministration) i underbilag Se afsnit om ØiR snitflade til udbetalingssystem. Krav# 80: Manuel godkendelse af udbetaling Beskrivelse: Det skal være muligt for brugeren at godkende eller annullere en specifik udbetaling før den udbetales, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. - a) Brugeren skal kunne godkende en specifik udbetaling, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. b) Brugeren skal kunne annullere en specifik udbetaling, såfremt det er angivet i effektueringsplanen, at der skal godkendes manuelt. c) Løsningen skal sikre, at udbetaling kun bestilles, såfremt den er godkendt. d) Udbetalingen skal gemmes som annulleret, hvis den er blevet annulleret af brugeren. Se Krav# 64 og Krav #65 vedrørende angivelse af, at der skal godkendes manuelt. Krav# 81: Manuel registrering af regning Beskrivelse: Det skal være muligt for en bruger i Løsningen at indberette en regning, der Side 73 af 255

74 modtages papirbaseret. a) Brugeren skal kunne indberette de nødvendige oplysninger om en regning, som minimum kreditoroplysninger, betalingsidentifikation, betalingsdato, beløb. b) Brugeren skal kunne tilknytte regningen til en effektueringsplan i en ydelsessag eller til en betalingsaftale i en administrationssag. c) Løsningen skal sikre, at der er registreret tilstrækkelige oplysninger til, at regningen kan betales Krav# 82: Automatisk registrering af regning Beskrivelse: Løsningen skal automatisk registrere en regning, der modtages elektronisk. a) Alle regninger, der modtages elektronisk via snitflade er registreret korrekt i løsningen. b) Alle regninger er tilknyttet korrekt til den ydelsessag eller administrationssag, som regningen vedrører. c) Alle bilag, der modtages sammen med en regning, er tilknyttet til sagen som dokumenter. d) Efter registrering af regningen har brugeren adgang til at behandle den i løsningen. - Disse regninger modtages som e-fakturaer via kommunens NemHandelsløsning. - Se Krav# 83 vedrørende godkendelse af regning. - Se afsnit vedrørende snitflade til automatisk modtagelse af regning. Krav# 83: Godkendelse af regning Beskrivelse: Brugeren skal i Løsningen kunne godkende eller afvise en regning modtaget fra en ekstern part. a) Brugeren har adgang til at godkende eller afvise en regning, inden den betales. b) Løsningen skal sikre, at regningen kun betales, hvis den er godkendt. c) Løsningen skal for en godkendt regning overføre de nødvendige oplysninger til udbetalingssystemet, så udbetaling kan ske korrekt og rettidigt. d) Løsningen skal sikre, at en godkendt regning konteres korrekt, og at de nødvendige oplysninger overføres til et eksternt økonomisystem korrekt og rettidigt, så der kan bogføres. - Se Krav# 81 vedrørende manuel registrering af regning. - Se Krav# 82 vedrørende automatisk registrering af regning. Side 74 af 255

75 - Se afsnit om ØiR snitflade til udbetalings- og økonomisystemer Kontering Løsningen understøtter gennem korrekt kontering, at kommunens økonomistyring, herunder regnskabsaflæggelse og håndtering af statsrefusion mv. sker på et korrekt grundlag for de ydelser, som håndteres i Løsningen. Dette vedrører alle sager om forsørgelsesydelser, enkeltydelser og andre ydelser, opkrævning af fleksydelsesbidrag samt administrationssager. Eksempelvis skal beløb, som udbetales i kontanthjælp, konteres forskelligt afhængig af den type af aktivering, som Personen deltager i, og om Personen har haft sammenhængende fravær i en given periode. Løsningen skal derfor kunne kontere udbetalinger og opkrævninger mv. i henhold til kommunens kontoplan og lovgivning om eksempelvis statsrefusion samt kommunens eventuelle opdeling i administrative enheder og distrikter. Selve bogføringen sker i kommunens økonomisystem, som Løsningen derfor skal have snitflader til ( Økonomi). Der er i nogle tilfælde behov for, at Løsningen kan foretage omkontering, hvis der med tilbagevirkende kraft ændres i oplysninger, som har ligget til grund for beregning og kontering. Eksempelvis kan det på et senere tidspunkt blive oplyst fra Jobcentret, at en Person, som modtager kontanthjælp, i en periode har deltaget i en anden type aktivering, end det har været oplyst på udbetalingstidspunktet. I dette tilfælde skal ændringen påvirke konteringen med tilbagevirkende kraft, men ikke påvirke udbetalinger til Personen. Når der bevilges en ydelse, afgøres det, om ydelsen undtagelsesvist er med tilbagebetalingspligt. Der kan være tale om beløb, der af brugeren markeres som tilbagebetalingspligtigt. Det kan også være beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige, eksempelvis som følge af en sanktion. Eksempelvis kan brugeren efter konkret individuel vurdering bevilge et beløb som løbende ydelse eller enkeltydelse, som Personen skal betale tilbage. Det kan eventuelt også på et senere tidspunkt konstateres, at et beløb er tilbagebetalingspligtigt. Beløb, som er tilbagebetalingspligtige, konteres på særlige konti og der overføres oplysninger til et debitorsystem, således at beløbene kan restanceføres korrekt. Krav# 84: Korrekt kontering Beskrivelse: Løsningen skal ud fra sagens oplysninger sikre, at konteringen af alle beløb sker korrekt og rettidigt i henhold til lovgivningen, de kontoplaner og de konteringsregler, som er konfigureret i Løsningen. - a) Alle beløb er konteret korrekt i henhold til lovgivningen, de kontoplaner og konteringsregler, som er konfigureret i Løsningen. b) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. c) Dette gælder også for beløb vedrørende fleksydelsesbidrag, som opkræves via et eksternt debitorsystem. d) Dette gælder også for tilbagebetalingspligtige beløb. e) Løsningen skal sikre, at de nødvendige oplysninger overføres til økonomisystem korrekt og rettidigt for alle konteringer, således at der kan bogføres. Eksempler på beløb, som skal konteres og overføres til bogføring i et eksternt økonomisystem, inkluderer: Side 75 af 255

76 o Bruttobeløb på bevilgede ydelser o Beløb til udbetaling (udbetales til personen, til alternativ modtager eller overføres til en anden enhed i kommunen) o Fradrag for sanktioner o Fradrag for forskudsudlagt børnebidrag o ATP (både persons og kommunens andel), AMB, A-skat o Beløb trukket til administration af persons økonomi o Individuelle tillæg/fradrag o Tilbagebetalingspligtige beløb o Fleksydelsesbidrag - Der er også tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. Eksempelvis hvis en del af en bevilget ydelse er tilbagebetalingspligtig. - Se Krav# 212 og Krav# 214 vedrørende konfigurering af konteringsregler. - Se Krav# 86 vedrørende tilbagebetalingspligtige beløb. - Selve bogføringen sker i et eksternt økonomisystem ud fra oplysninger, der overføres fra løsningen på tidspunktet for bestilling af udbetaling, debitorbetaling eller opkrævning (se ). - Se informationsmodellen (KY-bevilling, KY-effektuering, KY-kontaktforløb, KY-kontering, Ydelseskatalog, Beslutningsgrundlag, Beregningsgrundlag, Bevilling, Sanktionering, ATP + Skatteberegning) i underbilag 2.5. Krav# 85: Korrekt kontering med tilbagevirkende kraft Beskrivelse: Løsningen skal automatisk konsekvensberegne og sikre korrekt omkontering af de nødvendige beløb, hvis der med tilbagevirkende kraft ændres i oplysninger i sagen, som har indflydelse på kontering. a) Alle konsekvenser af ændringer i sagens oplysninger med tilbagevirkende kraft er beregnet og konteret korrekt og rettidigt i henhold til lovgivningen, de kontoplaner og konteringsregler, som er konfigureret i Løsningen. b) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, der skal konteres forskelligt. c) Dette gælder også for tilbagebetalingspligtige beløb. d) Løsningen skal sikre, at de nødvendige oplysninger overføres til økonomisystem korrekt og rettidigt, således at der kan bogføres. e) Løsningen skal kun kontere med tilbagevirkende kraft i indeværende og forrige år. f) Løsningen skal kun kontere med tilbagevirkende kraft tilbage til ibrugtagningstidspunktet. - Se Krav# 86 vedrørende tilbagebetalingspligtige beløb. - Se afsnit om snitflade til økonomisystemet. Side 76 af 255

77 Krav# 86: Kontering af tilbagebetalingspligtige beløb Beskrivelse: Løsningen skal sikre, at kontering af tilbagebetalingspligtige beløb sker korrekt og rettidigt. a) Alle tilbagebetalingspligtige beløb er konteret korrekt og rettidigt i henhold til lovgivningen, de kontoplaner og konteringsregler, som er konfigureret i løsningen. b) Dette gælder også i tilfælde, hvor det samlede beløb, der udbetales, er en sum af flere beløb, hvoraf kun nogle er tilbagebetalingspligtige. c) Dette gælder også for beløb, der af brugeren er markeret som tilbagebetalingspligtige. d) Dette gælder også for beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige. e) Et tilbagebetalingspligtigt beløb, som Løsningen automatisk har konstateret, skal kun konteres som sådan, hvis det er godkendt af brugeren. I modsat fald konteres det ikke som tilbagebetalingspligtigt. f) Løsningen skal sikre, at de nødvendige oplysninger overføres til eksternt økonomisystem korrekt og rettidigt, således at der kan bogføres. - Der kan være tale om beløb, der af brugeren markeres som tilbagebetalingspligtigt. Det kan også være beløb, som Løsningen automatisk konstaterer, er tilbagebetalingspligtige, eksempelvis som følge af en sanktion. Brugeren skal kunne godkende eller afvise tilbagebetalingspligten. - I enkelte tilfælde, eksempelvis ved bevilling af særlig støtte efter LAS 34, hæfter begge ægtefæller/samlevere under visse betingelser solidarisk for den del, der er ydet til dækning af renter og afdrag vedrørende ejerboliger og andelsboliger. Dette håndteres ved særskilt kontering af sådanne beløb (jf. LAS 92 stk. 1-3). - Se Krav# 50 vedrørende konsekvenser af sanktioner. - Se Krav# 84 og Krav# 85 vedrørende kontering. - Se Krav# 88 om markering af tilbagebetalingspligtigt beløb. - Se Krav# 10 vedrørende automatisk oprettelse af opgave. - Se afsnit vedrørende snitflade til eksternt økonomisystem. Krav# 87: Manuel kontering Beskrivelse: Det skal være muligt for brugeren at kunne foretage en manuel kontering på en sag. a) Brugeren skal kunne indberette de oplysninger, som er nødvendige for, at Løsningen kan foretage kontering rettidigt og korrekt. a) Løsningen skal sikre, at de nødvendige oplysninger overføres korrekt og rettidigt til eksternt økonomisystem, så der kan bogføres Side 77 af 255

78 - Som hovedregel foretager Løsningen al kontering på baggrund af de oplysninger, som er registreret i sagen, men der kan være behov for at kunne foretage konteringer manuelt, eksempelvis ved fraflytning fra kommunen eller dødsfald. - I en sag, hvor kommunen bruger løsningen til at administrere en persons pension, kan der være behov for at kunne registrere det pensionsbeløb, som er overført fra UDK til kommunen, såfremt det ikke er sket automatisk. - Se eventuelt informationsmodellen (KY-kontering, Ydelseskatalog, Bevilling, Effektuering) i underbilag Se afsnit vedrørende ØiR snitflade til eksternt økonomisystem. Krav# 88: Markering af tilbagebetalingspligtigt beløb Beskrivelse: Det skal være muligt for brugeren at markere, at et beløb, som skal udbetales, er tilbagebetalingspligtigt, således at beløbet konteres korrekt. a) En bruger skal kunne markere et beløb som tilbagebetalingspligtigt før udbetalingstidspunktet. b) En bruger skal kunne markere et beløb som tilbagebetalingspligtigt på et senere tidspunkt. Gyldigheden er begrænset til indeværende og forrige år, dog ikke tidligere end ibrugtagningstidspunktet. Løsningen skal i dette tilfælde sikre, at beløbet om nødvendigt omkonteres med tilbagevirkende kraft. c) En bruger skal kunne markere et tilbagebetalingspligtigt beløb som værende ikke-tilbagebetalingspligtigt på et senere tidspunkt. Gyldigheden er begrænset til indeværende og forrige år, dog ikke tidligere end ibrugtagningstidspunktet. Løsningen skal i dette tilfælde sikre, at beløbet om nødvendigt omkonteres med tilbagevirkende kraft. d) Løsningen skal sikre, at brugeren angiver en årsag: lov, paragraf, stk., nr. e) Brugeren skal kunne godkende, om beløbet skal restanceføres i debitorsystemet. Løsningen skal gemme denne oplysning på effektueringsplan i sagen. - Se Krav# 86 vedrørende kontering af tilbagebetalingspligtig ydelse. - Se Krav# 85 vedrørende kontering med tilbagevirkende kraft. - Se eventuelt informationsmodellen (Bevilling) i underbilag Se afsnit vedrørende snitflade til eksternt økonomisystem Opkrævning af fleksydelsesbidrag Fleksydelse er en ordning, som personer, der er visiteret til et fleksjob, automatisk indmeldes i ved visiteringen. Det sker i Ydelsescentret ud fra oplysninger fra Jobcentret, som visiterer til fleksjob. Der oprettes en sag i Løsningen, som oplyses, bl.a. med hensyn til Personens anciennitet (se afsnit ), og der træffes afgørelse om, hvorvidt Personen opfylder betingelserne. Hvis Perso- Side 78 af 255

79 nen opfylder betingelserne og dermed deltager i ordningen, opkræver kommunen et bidrag fra Personen. Opkrævningen sker pt. kvartalsvis. Når Personen når fleksydelsesalderen, kan vedkommende overgå til at modtage fleksydelse, såfremt vedkommende opfylder betingelserne herfor. Personen vil efterfølgende modtage fleksydelse og indbetale bidrag samtidig, indtil Personen udmeldes af ordningen pga. eksempelvis pensionering eller dødsfald. Krav i dette afsnit er rettet specifikt mod understøttelse af fleksydelsesordningen og skal ses som supplement til de generelle krav i kapitel 5, som retter sig mod alle de ydelser, som Løsningen skal understøtte, herunder krav om oplysning af sag, beregning, afgørelse, effektuering og udbetaling. Underbilag 2.14 (Beregninger og regler vedrørende fleksydelse) indeholder vejledende beskrivelser af beregninger og regler vedrørende beregning af anciennitet og betalingsfrie perioder. Krav# 89: Opkrævning af fleksydelsesbidrag Beskrivelse: Løsningen skal beregne det beløb, som skal opkræves i fleksydelsesbidrag og sikre, at der bestilles opkrævning. a) Det beløb, som skal opkræves, er beregnet korrekt i henhold til lovgivningen og sagens oplysninger for alle opkrævninger, der skal foretages i den aktuelle opkrævningsperiode. b) Løsningen skal ved effektuering og bestilling af opkrævninger benytte de oplysninger, herunder oplysninger om betalingsfrie perioder, der er registreret i sagens effektueringsplan. c) Der er afleveret opkrævningsanmodninger med de korrekte og tilstrækkelige oplysninger til eksternt debitorsystem, således at alle opkrævninger sker korrekt og rettidigt til rette person i henhold til lovgivningen og de oplysninger, som er registreret på effektueringsplanen. d) Opkrævningsanmodningen er konteret korrekt. e) Løsningen skal sikre, at de nødvendige oplysninger overføres til økonomisystem korrekt og rettidigt, således at der kan bogføres korrekt. - Se Krav# 222 vedrørende konfigurering af opkrævning af fleksydelsesbidrag. - Se Krav# 91 om betalingsfrie perioder. - Se informationsmodellen (Ydelseskatalog, Bevilling, Fleksydelsesbidragsopkrævning) i underbilag Se afsnit om snitflade til debitor- og økonomisystem. Krav# 90: Opkrævningsspecifikation vedrørende fleksydelsesbidrag Beskrivelse: Når der opkræves fleksydelsesbidrag, skal Løsningen aflevere oplysninger om opkrævningsgrundlaget til brug for en opkrævningsspecifikation til hver enkelt Person, der opkræves. Det endelige indhold og format afklares med leverandøren. Side 79 af 255

80 - Se Krav# 89 vedrørende opkrævning af fleksydelsesbidrag. - Se afsnit om snitflade til debitorsystemet. - Se informationsmodellen (Ydelseskatalog, Bevilling, Fleksydelsesbidragsopkrævning) i underbilag 2.5. Krav# 91: Indberet pause i betaling af fleksydelsesbidrag Beskrivelse: En bruger skal i Løsningen kunne indberette, at Personen holder pause i indbetalingen af fleksydelsesbidrag. - a) Løsningen skal registrere perioden, som brugeren indberetter med startog slutmåned, på sagen. b) Løsningen skal sikre, at pausens længde ikke overstiger det antal betalingsfrie perioder (herunder bidragsfrie perioder), som Personen har ret til. c) Løsningen sikrer, at der ikke opkræves bidrag i perioden. d) Løsningen genoptager automatisk opkrævningen efter udløbet af pausen. Se Krav# 43 vedrørende beregning af antallet af betalingsfrie perioder Effektuering på baggrund af inddata fra Jobcenter-løsning I sager om de andre ydelser, som bevilges af Jobcentret og effektueres i Ydelsescentret, eksempelvis godtgørelse til udgifter ved deltagelse i tilbud efter LAB 82 og 83, registreres der oplysninger i Løsningen, som danner udgangspunkt for effektuering og senere afslutning af sagen. I disse tilfælde skal den bevilgede ydelse kunne effektueres automatisk uden Ydelsescentrets involvering. Krav# 92: Automatisk effektuering af sag ud fra information fra Jobcenter-løsning Beskrivelse: Løsningen skal automatisk kunne foretage effektuering og udbetaling af ydelser udelukkende på baggrund af oplysninger, som er overført fra en Jobcenterløsning. a) Løsningen skal effektuere rettidigt og korrekt i henhold til lovgivningen ud fra oplysninger, der modtages fra Jobcenter-løsningen om bevilling af ydelser, således at der kan konteres, udbetales og bogføres. b) Løsningen skal sikre, at der effektueres for alle bevillinger, der vedrører ydelser, hvor det er centralt konfigureret på ydelsen, at der kan bevilges på denne måde. c) Løsningen skal sikre, at der kun kan effektueres for bevillinger, der vedrører ydelser, hvor det er centralt konfigureret på ydelsen, at der kan bevilges på denne måde. d) Løsningen skal sikre, at effektuering og udbetaling kun foretages, hvis beløbet er mindre end det maksimale beløb for godtgørelse, som er kon- Side 80 af 255

81 figureret i Løsningen. e) Løsningen skal sikre, at beløbet periodiseres i forhold til start- og slutdato for godtgørelsen, hvis dette er angivet i oplysningerne fra jobcentret. - Se Krav# 69 vedrørende oprettelse af sag ud fra oplysninger fra Jobcenterløsning. - Se Krav# 221 vedrørende konfigurering af maksimalt beløb. - Se Krav# 281 vedrørende snitflade til Jobcenter-løsning. - Se informationsmodellen (KY-Sag, KY-effektuering, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog, Bevilling, Effektuering) i underbilag Vedligeholdelse af sag Mange sager kan løbe over længere perioder, hvor der fx sker udbetalinger hver måned. Ofte vil sagsbehandleren ikke gå ind på sagen hver måned. Sagerne og dertil hørende udbetalinger vil således køre automatisk måned efter måned. Men forskellige hændelser og interne regler kan medføre, at der er behov for, at enten sagsbehandleren eller Løsningen vedligeholder sagen. Når det er sagsbehandleren, der vedligeholder sagen, betyder det, at Løsningen opretter en opgave til sagsbehandleren, som sagsbehandleren derefter løser (beskrevet i afsnit 5.1). Løsningen kan også vedligeholde sagen uden sagsbehandlerens indblanding. Kravene til disse automatiske reaktioner beskrives i dette afsnit. Nogle gange vil vedligeholdelse af sagen således blot betyde, at Løsningen opretter en opgave til sagsbehandleren. I andre tilfælde kan Løsningen reagere automatisk på de nye oplysninger og foretage automatiske handlinger. Det kan også være en kombination af de to. Et eksempel kan være, at en Person er død. Denne hændelse bliver Løsningen bekendt med via en CPR-besked. I dette tilfælde stoppes udbetalingen automatisk, når CPR-beskeden modtages. Der oprettes derefter en opgave til sagsbehandleren, hvorefter sagsbehandleren færdigbehandler opgaven. Der kan være flere kilder til, at vedligeholdelsen af sagen påbegyndes. A. Ved modtagelse af beskeder fra andre it-systemer (fx via beskedfordeleren beskrevet i afsnit ). B. Ved modtagelse af dokumenter fra andre it-systemer (via dokumentservicen beskrevet i afsnit Dokumentservice). C. Ved interne regler i Løsningen. D. Via andre kanaler (fx , personlige henvendelser, telefonopkald osv.). I underbilag 2.13 ses en liste over de relevante hændelser, der kan indtræffe, som Løsningen skal kende til. Denne liste indeholder både hændelser udefra (A+B) og interne regler (C). For hver hændelse er der i underbilaget beskrevet, hvordan Løsningen skal reagere på hændelsen. De oplysninger, der kommer ind via mere manuelle kanaler (D), vil brugeren skulle håndtere manuelt og de vil ikke blive oprettet på opgavelisten (medmindre brugeren selv opretter en opgave). Brugeren vil som oftest selv fremsøge den relevante sag og behandle sagen derigennem. Der vil således ikke være krav, der dækker disse typer af informationer, da sagsbehandleren blot fremsø- Side 81 af 255

82 ger sagen (jf. afsnit 5.1.1) og derefter benytter funktionaliteten beskrevet i afsnit 5.2 til at håndtere, hvordan oplysningerne skal behandles. Krav# 93: Automatiske reaktioner på hændelser og interne regler Beskrivelse: Alt efter hvilken hændelse der indtræffer, kan Løsningen reagere automatisk, når der modtages oplysninger om hændelsen. a) Løsningen kan reagere på samtlige hændelser og interne regler beskrevet i underbilag 2.13 b) Løsningen kan for hver enkelt hændelse og intern regel reagere på den i underbilag 2.13 beskrevne måde c) Løsningen reagerer for hver hændelse kun på de ydelsesarter, der er noteret i underbilag 2.13 d) Løsningen kan ved modtagelse af en besked eller en intern regel foretage en eller flere af følgende reaktioner i kombination: A. Oprette en sag B. Oprette en opgave C. Stoppe automatisk udbetaling af ydelsen (ændre godkendelse af effektueringsplanen på sagen fra automatisk til manuel) D. Opdatere sagsoplysninger E. Fastsætte ydelsessats og beregne ydelse F. Træffe afgørelse G. Effektuere H. Sende breve I. Registrere hændelse i sagshistorik J. Korrigere i forhold til kontering K. Gemme registrering i log Det skal afklares endeligt med Leverandøren, hvilke hændelser og interne regler der udløser hvilke automatiske reaktioner. - I forhold til punkt c, så menes der, at det kun er de ydelser, der er noteret i kolonnen Hvilke ydelser er hændelsen relevant for, hvor de automatiske reaktioner skal træde i kraft. Fx er hændelsen kontaktforløb ændret kun relevant for forsørgelsesydelser og skal dermed ikke træde i kraft ved enkeltydelser. - Se Krav# 202 vedrørende den kommunale administrators mulighed for at konfigurere hvordan Løsningen reagerer på de forskellige hændelser. - Se Krav# 207 og Krav# 208 vedrørende administrators mulighed for at konfigurere interne regler. - Se Krav# 20 vedrørende oprettelse af sag. - Se Krav# 10 vedrørende oprettelse af en opgave. - Se Krav# 26 vedrørende opdatering af sagsinformation via opslag i eksterne Side 82 af 255

83 registre. - Se Krav# 95 og Krav# 96 vedrørende opdatering af sagsoplysninger, jf. punkt D. Krav# 94: Omdannelse fra besked til opgave Beskrivelse: Når Løsningen modtager en besked, vil der ofte skulle dannes en opgave til brugeren. a) Ved opgaver oprettet på baggrund af en besked, er beskeden omdannet til en for brugeren forståelig opgavetype samt opgavebeskrivelse. b) Der må ikke gå informationer tabt fra omdannelse af en besked til en opgave, medmindre dette er aftalt med Kunden Opdatering af sagsoplysninger Når der kommer nye oplysninger i en given sag, skal disse opdateres på sagen. Hvis det er oplysninger sagsbehandleren selv indtaster manuelt, vil det ske i forbindelse med genoplysningen af sagen. Kravene til (gen)oplysning af sag er beskrevet i afsnit Andre gange vil opdatering af sagsoplysninger kunne ske automatisk i forbindelse med vedligeholdelse af sagen. Når Løsningen modtager oplysninger digitalt, skal oplysningerne så vidt muligt overføres til sagen, så sagsbehandleren ikke behøver indtaste oplysningerne manuelt. Ved benyttelse af selvbetjeningsløsningen (se afsnit 5.9) modtager Løsningen data på struktureret form og alle data skal kunne overføres til sagen direkte. Dette gælder både i ansøgningsøjeblikket og ved vedligeholdelse af sagen. Krav# 95: Opdatering af sagsoplysninger fra Selvbetjeningsløsningen Beskrivelse: Når der modtages sagsinformation i Løsningen via Selvbetjeningsløsningen, overføres disse automatisk til sagen. Dette gælder både ved ansøgningstidspunktet og ved vedligeholdelse af sagen. - Data fra Selvbetjeningsløsningen vil typisk være ansøgninger, men kan også være Personens opdateringer af sagsdata fra Min Sag. Dette er særligt relevant i forbindelse med modtagelse af en ansøgning, hvor fx alle ansøgningsdata skal overføres (jf. Krav# 20). - Se afsnit 5.9 Selvbetjening vedrørende Selvbetjening. - Se informationsmodellen (KY-dokument, KY-sag, Oplys sag, Beslutningsgrundlag, Beregningsgrundlag, Ydelseskatalog) i underbilag 2.5. Krav# 96: Opdatering af sagsoplysninger via opslag i eksterne registre Beskrivelse: Løsningen kan opdatere sagens oplysninger på baggrund af informationer indhentet via eksterne registre. Side 83 af 255

84 a) Opdateringer af sagsinformationer kan initieres manuelt af brugeren. b) Opdateringer af sagsinformationer kan initieres automatisk på baggrund af hændelser. c) Ved opslag i eksterne registre kan Løsningen opdatere relevante oplysninger på sagen. d) I det tilfælde, at der allerede eksisterer manuelt indtastede data, skal de nye data være gældende. Brugeren gøres opmærksom på, at der er kommet nye data. - I forhold til punkt a, så initieres dette via Krav# I forhold til punkt b, så initieres dette via Krav# I forhold til punkt d, så kan dette være relevant, hvis fx der er indtastet en alternativ adresse. Hvis der så kommer en adresseopdatering fra CPR, skal den nye adresse benyttes, men sagsbehandleren skal gøres opmærksom på, at der er kommet en ny adresse (så de eventuelt har mulighed for at skrive den alternative adresse ind igen) Opdatering af metadata på sagen En sag, som behandles i Løsningen, vedrører én specifik Person (primær part), som har ansøgt om eller er blevet indstillet til en ydelse. Dertil kan der være en eller flere yderligere parter, som skal tilknyttes sagen af hensyn til fx beregninger (eksempelvis ægtefælle/samlever og børn). Dette kan gøres både i forbindelse med oprettelse af sagen og i forbindelse med vedligeholdelse af sagen. Krav# 97: Tilknytning af yderligere personer til sag Beskrivelse: Brugeren skal kunne knytte og eventuelt fjerne relation mellem sagen og relevante personer (parter). Der skal være en entydig relation mellem sagen og de tilknyttede parter, så deres relationer i sagen er klar. a) Brugeren kan knytte og fjerne relationer mellem en sag og en part. b) Brugeren kan vælge typen af relation, når parten tilknyttes. c) Det er muligt at tilknytte en partsrepræsentant. - Bemærk desuden at ægtefællen/samleveren til en Person, der ansøger om uddannelseshjælp eller kontanthjælp, som udgangspunkt også vil modtage hjælp. Der er således en særlig relation mellem en sag om uddannelseshjælp eller kontanthjælp og begge ægtefæller/samlevere. I de kommuner, hvor der er en fast sagsbehandler knyttet til sagen, kan der være behov for at overflytte hele sagen til en anden sagsbehandler. Det kan fx være pga. en dårlig relation mellem sagsbehandleren og Personen. Det skal derfor være muligt at ændre den primære sagsbehandler på en enkelt sag. Det kan derefter betyde, at fx alle opgaver på denne sag vil blive fordelt til den nye sagsbehandler i stedet. Side 84 af 255

85 Krav# 98: Ændring af primær sagsbehandler Beskrivelse: Det er muligt for brugeren at ændre den primære sagsbehandler på en enkelt sag. - Se Krav# 233 vedrørende den kommunale administrators mulighed for at flytte en hel sagsstamme Afslut sag En sag afsluttes efter det er besluttet, at Personen ikke skal modtage nogen ydelse (længere). Der kan være flere årsager til at afslutte en sag og det kan ske under forskellige faser i en sag. Det kan fx være pga. et afslag på ansøgningen; det kan være, at forholdene i en aktiv sag har ændret sig, så der ikke længere er grundlag for, at Personen modtager ydelsen, eller det kan være, at ydelsen er færdigudbetalt som fx ved enkeltydelser. Selve beslutningen om at afslutte sagen foregår i aktiviteten Træf afgørelse, og det forventes ikke, at brugeren skal gøre noget aktivt i forbindelse med at afslutte sagen. Bemærk for sager vedrørende uddannelseshjælp eller kontanthjælp, hvor ansøgerens ægtefælle/samlever er tilknyttet som sekundær part, kan være behov for at oprette en særskilt sag for ægtefællen/samleveren i de tilfælde, hvor ægtefællen/samleveren selv er omfattet af ændringskravet og dermed kan være berettiget til uddannelseshjælp eller kontanthjælp efter, at ansøgerens sag er afsluttet. Når en sag er afsluttet, kan der som udgangspunkt ikke længere redigeres eller tilføjes informationer til sagen, ligesom Løsningen ikke længere vil modtage beskeder vedrørende den givne sag (det er dog muligt at genåbne en lukket sag). Det er stadig muligt at omkontere samt ændre tidligere udbetalte ydelser til tilbagebetalingspligtig hjælp. I dag er der ikke lovgivningsmæssigt krav til, at Løsningen skal arkivere, da de sager, der behandles i Løsningen, ikke i sig selv ikke er bevaringsværdige. De oplysninger der skal bevares om kontanthjælp mm., modtager Statens Arkiver fra Danmarks Statistik og AMS. Krav# 99: Afslut sag Beskrivelse: Løsningen skal registrere, at der er truffet afgørelse om afslag på ansøgning eller afslutning af bevilling og gennemføre konsekvenserne af afslaget. a) Løsningen har ændret status på sagen. b) Løsningen har gemt sagen med kassationskode, der blev sat ved afslutning af sagen. c) Hvis Personen ikke har andre igangværende sager i Løsningen, har Løsningen opdateret abonnementet i Beskedfordeleren med fjernelse af Personens CPR-nummer. Side 85 af 255

86 d) Løsningen har opdateret Sags- og Dokumentindekset. - Se Krav# 57 vedrørende træf afgørelse. - Se afsnit vedrørende Status og låsning af sager samt opgaver. - Se afsnit vedrørende Beskedfordeler. - Se afsnit vedrørende Sags- og Dokumentindeks. Krav# 100: Adgang til afsluttede sager Beskrivelse: Når en sag er afsluttet, kan den fremsøges ved at søge på afsluttede sager. a) En afsluttet sag kan fremsøges ved at søge på afsluttede sager. b) Der kan anvendes samme søgekriterier som beskrevet i Krav# 9. c) Der er læseadgang til hele sagen, men brugeren kan ikke redigere allerede registrerede data. d) Der kan tilføjes journalnotater til sagen efter denne er afsluttet. e) Systemgenererede hændelser kan registreres, uanset om sagen er igangværende eller afsluttet. - Se Krav# 101 vedrørende genåbning af sag. - Se afsnit vedrørende mulighed for at overføre en kopi af den afsluttede sag til en anden kommune. Selvom der er truffet afgørelse om et afslag og sagen er afsluttet, kan der til tider være behov for at genåbne sagen. Det kan fx være i tilfælde af, at kontaktforløbet genoptages i Jobcentret eller i tilfælde af, at Personen klager over afgørelsen og får medhold. Krav# 101: Genoptag sag Beskrivelse: Brugeren skal kunne genoptage en afsluttet sag. Der kan derefter arbejdes videre med sagen som en igangværende sag. a) Brugeren kan genoptage en sag. b) Hvis sagen er genoptaget på en Person, der ikke har andre igangværende sager i Løsningen, har Løsningen opdateret abonnementet i Beskedfordeleren med Personens CPR-nummer. c) Løsningen har opdateret status på sagen. d) Løsningen opdaterer Sags- og Dokumentindekset. - Se afsnit vedrørende status på sager. - Se afsnit vedrørende Beskedfordeler. Når en sag er lukket, sættes der en kassationsfrist for, hvornår sagen skal slettes. Med slettes menes en fysisk sletning i databasen, således at sagen ikke kan genfindes, og der bør ikke være noget spor efter sagen, når den er blevet slettet. Side 86 af 255

87 For at undgå en katastrofe, hvor sager fx ved en fejl bliver slettet permanent, forestiller Kunden sig, at der indføres et mellemlag, hvor kun en bruger med den særlige rolle Sagskassations Administrator (jf. afsnit 6.7.4for beskrivelse af roller) i en begrænset periode kan genfinde de slettemarkerede sager. For eksterne systemer vil en slettemarkeret sag fremgå som slettet, og det ekstra mellemlag er således kun en intern tilstand, inden sagen slettes endegyldigt. Figur 1 nedenfor viser, hvordan dette mellemlag er tænkt. I stedet for at slette sagen direkte, når kassationsfristen udløber, så slettemarkeres sagen. På samme måde kan den kommunale administrator også slettemarkere fejloprettede sager, før kassationsfristen udløber (jf. Krav# 232). Når en sag er slettemarkeret, har de kommunale brugere ikke længere adgang til sagerne. Men brugeren med den særlige rolle Sagskassations Administrator vil stadig kunne fremsøge en slettemarkeret sag og eventuelt genskabe sagen. Efter den fastsatte dato vil den slettemarkerede sag så endegyldigt slettes, så heller ikke brugeren med den særlige rolle Sagskassations Administrator vil kunne genfinde sagen. Sag Åben Kommunal bruger kan fremsøge sag [Sagsbehandler lukker sagen. Kassationsfrist er sat] Sag Lukket [Kassationsfristen udløber og sagen slettemarkeres automatisk] [Kommunal administrator slettemarkerer sag manuelt] Sag kan kun fremsøges, hvis brugeren har rollen Sagskassations Administrator Sag Slettemarkeret Sag Slettemarkeret [1 år efter slettemarkeringsdatoen slettes sag automatisk] Sag er fysisk slettet [3 år efter lukket-dato slettes sag automatisk] Sag Slettet Krav# 102: Automatisk slettemarkering af sager Figur 11: Sagstilstande i forbindelse med sletning Beskrivelse: Løsningen skal automatisk slettemarkere lukkede sager, når kassationsfristen udløber. a) Løsningen slettemarkerer lukkede sager, når kassationsfristen udløber. b) Løsningen opdaterer Sags- og dokumentindeks og Ydelsesindeks opda- Side 87 af 255

88 teres, så sagen og tilhørende dokumenter også slettes fra indekserne. c) Løsningen sender besked til Beskedfordeleren om sletning af sagen. - Vær opmærksom på at i forhold til eksterne systemer er sagen slettet ved en slettemarkering. Slettemarkeringen er kun en intern tilstand. - Se krav Krav# 232 for administrators mulighed for at slettemarkere sager manuelt. - Jf. OIO standarderne for Sag i forhold til mulige kassationskoder og frister. - Se afsnit vedrørende Sags- og dokumentindeks. - Se afsnit vedrørende Ydelsesindeks. - Se afsnit vedrørende Beskedfordeler. - Se afsnit vedrørende roller. Krav# 103: Fremsøgning og genskabelse af slettemarkerede sager Beskrivelse: En bruger med rollen Sagskassations Administrator kan fremsøge og genskabe de slettemarkerede sager. - Se afsnit vedrørende roller. Krav# 104: Automatisk sletning af sager Beskrivelse: Løsningen skal automatisk slette de slettemarkerede sager. a) Løsningen sletter de slettemarkerede sager, efter de har haft tilstanden slettemarkeret i et år. b) I det tilfælde, hvor en sag er blevet slettemarkeret manuelt af en kommunal administrator, skal der minimum være gået 5 år, efter sagen blev lukket af brugeren, inden den slettemarkerede sag kan slettes. - Med slettes menes der i dette krav en fysisk sletning. Det må ikke være muligt at genfinde sagen på nogen vis. - Årsagen til punkt b) er, at hvis en kommunal administrator sletter en sag inden kassationsfristens udløb, kan det risikeres at slette sagen endegyldigt inden den egentlige kassationsfrist. Derfor sættes en grænse på 5 år (som er den korteste kassationsfrist for en sag). - Se krav Krav# 232 for administrators mulighed for at slettemarkere sager manuelt. - Jf. OIO standarderne for Sag i forhold til mulige kassationskoder og frister. 5.3 Administration af Persons økonomi Når en Person modtager forsørgelsesydelse eller pension, kan der opstå et behov for, at Ydelsescentret administrerer en del af Personens økonomi. Kommunen kan med hjemmel i Aktivloven eller pensionslovene træffe afgørelse om at foretage betaling af eksempelvis husleje, el og varme på Side 88 af 255

89 Personens vegne eksempelvis, hvis Personen har misligholdt sine huslejebetalinger eller hvis det skønnes, at Personen ikke kan administrere kontanter. Det er også muligt for kommunen at administrere Personens økonomi i større eller mindre omfang på baggrund af en frivillig aftale med denne. Dette medfører typisk, at Ydelsescentret, inden ydelsen udbetales til Personen, betaler en eller flere af Personens faste udgifter og eventuelt også, at ydelsen udbetales til Personen i flere rater i løbet af en udbetalingsperiode. Der etableres en selvstændig sag ( administrationssag ), som knyttes til en ydelsessag. Administrationssagen gennemgår de samme hovedtrin som ydelsessagerne, dvs., sagen oplyses, der træffes afgørelse eller indgås en frivillig aftale. Såfremt der iværksættes administration, etableres som en del af administrationssagen en administrationsordning, der kan sammenlignes med en budgetkonto med tilhørende betalingsservice. Til administrationsordningen tilknyttes via en administrationsplan en eller flere bevilgede ydelser, hvorfra beløb til administration skal trækkes. Der tilknyttes en eller flere betalingsaftaler til de udgifter, som skal betales. Se nedenstående Figur. Ydelssessag Bevilling Administrationssag Bevilget ydelse Betalingsaftale Effektuering Beløb til administration Administrationsordning Administrationsplan Effektueringsplan Administrationskonto Restbeløb Ydelsesmodtager Betaling af regninger Alternativ modtager Figur 12: Administrationsordning Normalt vil det resterende ydelsesbeløb blive udbetalt til ydelsesmodtageren, når der udbetales forsørgelsesydelser generelt, dvs. som hovedregel sidste dag i måneden. Hvis det resterende ydelsesbeløb skal udbetales til ydelsesmodtageren på et andet tidspunkt eller i rater, eksempelvis med lige store ugentlige beløb, tilknyttes en rateudbetalingsplan til administrationsordningen. Se nedenstående Figur 2. Side 89 af 255

90 Ydelssessag Bevilling Administrationssag Bevilget ydelse Betalingsaftale Effektuering Beløb til administration Administrationsordning Rateudbetalingsplan Administrationsplan Effektueringsplan Administrationskonto Ydelsesmodtager Restbeløb udbetalt i rater Betaling af regninger Alternativ modtager Figur 2: Administrationsordning med rateudbetaling af restbeløb til ydelsesmodtager Krav i dette afsnit er rettet specifikt mod Løsningens understøttelse af disse administrationssager og skal ses som supplement til de generelle krav, som retter sig mod de øvrige ydelser, som Løsningen skal understøtte. Se desuden afsnit for krav til specifikke visninger i forbindelse med administration af Personens økonomi Læg Personens budget under oplysning af administrationssag Ved oplysning af en administrationssag er der typisk behov for at kunne lægge et budget med indtægter og udgifter for at vurdere, hvorvidt administration skal iværksættes og i så fald hvilke udgifter, der skal administreres. Budgettet kan sammenlignes med et almindeligt 12 måneders husholdningsbudget. Krav# 105: Læg budget ved oplysning af administrationssag Beskrivelse: En bruger skal i Løsningen kunne lægge et budget for Personen til brug for oplysning af en administrationssag. a) Brugeren kan lægge et budget for en Person med angivelse af udgifter og indtægter på månedsbasis. b) Brugeren skal kunne vælge blandt de typer af indtægter og udgifter, som er konfigureret lokalt. c) Brugeren skal kunne tilføje indtægter og udgifter til det specifikke budget. d) Løsningen skal danne og vise summer for budgettet. e) Budgettet er knyttet til Personens administrationssag. - Se Krav# 218 vedrørende oplysninger, der kan indgå i et budget. - Se informationsmodellen (Budget) i underbilag 2.5. Side 90 af 255

91 5.3.2 Træf afgørelse i administrationssag Typisk er formålet med en administrationssag at sikre, at Personen får betalt husleje, således at vedkommende ikke sættes ud af sin bolig. Det kan dog også forekomme, at Personen frivilligt indgår en aftale om administration. Administrationsordningen knyttes til en eller flere ydelsesbevillinger, hvorfra der trækkes et beløb til administration. Bemærk, at der eksempelvis for to ægtefæller/samlevere, der modtager uddannelseshjælp, kontanthjælp eller pension kan administreres fælles udgifter såsom husleje. Der er ofte tale om en forsørgelsesydelse, som allerede er bevilget i løsningen, men en stor del af administrationssagerne vedrører pensionsydelser, der udbetales af Udbetaling Danmark og endelig administreres i nogle sager andre ydelser, som ikke håndteres i Løsningen, fx sygedagpenge. I sådanne tilfælde skal der oprettes en ydelsessag med en bevilling på en anden ydelse, som administrationsordningen kan tilknyttes (se eventuelt Krav# 209, Krav# 210 og Krav# 200). Der er endvidere behov for at indberette betalingsaftaler for de udgifter, der administreres af Ydelsescentret, og eventuelt en udbetalingsplan, hvis det resterende beløb skal opdeles i rater og udbetales til Personen på andre tidspunkter end det normale. Det skal være muligt at kunne spare op af forsørgelsesydelsen til udgifter, der betales kvartalsvis eller halvårligt, således at Personens udbetalte ydelse udjævnes. Det håndteres af brugeren, der kan bruge budgettet, når det bestemmes hvilket beløb, der skal trækkes fra den bevilgede ydelse. Krav# 106: Indberet afgørelse eller frivillig aftale om administration Beskrivelse: Det skal være muligt for en bruger at indberette en afgørelse eller frivillig aftale om administration af en Persons økonomi. a) En bruger skal kunne indberette de nødvendige oplysninger om en afgørelse om at administrere Personens økonomi. b) En bruger skal kunne indberette og efterfølgende redigere de nødvendige oplysninger om en frivillig aftale om at administrere Personens økonomi. c) Der skal oprettes en administrationsordning med særskilt konto, som løbende bruges til registrering af saldoen på Personens administrationsordning. d) Brugeren skal kunne indberette et overtræksbeløb på ordningen. Defaultværdien skal være nul (0) kr. e) Overtræksbeløbet må ikke overskride det maksimale overtræksbeløb. f) Løsningen skal gøre brugeren opmærksom på det, hvis det ved tilknytning af administrationsplaner og betalingsaftaler kan forudses, at der inden for indeværende og de to følgende udbetalingsperioder vil opstå en negativ saldo, som overskrider det indberettede overtræksbeløb. - Se Krav# 219 vedrørende maksimalt overtræksbeløb. - Se Krav# 107 vedrørende tilknytning af administrationsordning til bevilget ydelse. - Se Krav# 108 vedrørende tilknytning af betalingsaftaler. - Se informationsmodellen (KY-effektuering, Beslutningsgrundlag, Bevilling, Side 91 af 255

92 Træf afgørelse) i underbilag 2.5. Krav# 107: Tilknyt administrationsordning til bevilget ydelse Beskrivelse: Det skal være muligt for en bruger at knytte administrationsordningen til bevillingen på en eller flere ydelser, hvorfra der kan trækkes et beløb til administration. a) Det er muligt for brugeren at knytte administrationsordningen til bevillingen på en eller flere ydelser. b) Administrationsordningen kan tilknyttes bevillinger i to Personers ydelsessager. c) Der er oprettet en administrationsplan, som udpeger en specifik bevilling og indeholder information om det beløb, som skal trækkes fra ydelsen til administrationsordningen, samt hvornår beløbet skal overføres (typisk ved effektuering af den bevilgede ydelse). - Bemærk, at administrationsordningen kan tilknyttes bevillinger i to Personers ydelsessager, eksempelvis hvis der administreres fælles udgifter for to ægtefæller/samlevere, der begge modtager uddannelseshjælp, kontanthjælp eller pension. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag 2.5. Krav# 108: Tilknyt betalingsaftale til administrationsordning Beskrivelse: Det skal være muligt for en bruger at tilknytte en betalingsaftale til administrationsordningen, for hver udgift, som betales. a) Det er muligt for brugeren at indberette de nødvendige oplysninger til at oprette en betalingsaftale knyttet til administrationsordningen. b) Betalingsaftalen indeholder de oplysninger, som er nødvendige for, at løsningen rettidigt og korrekt kan betale en af de udgifter, som kommunen administrerer, når administrationsordningen effektueres. c) Oplysningerne inkluderer som minimum betegnelse, betalingsidentifikation, beløb, alternativ modtager, betalingstidspunkt og frekvens, markering for om betalingen skal godkendes manuelt ved hver effektuering. d) Hvis beløbet skal overføres til en anden enhed i kommunen via debitorsystem, er det muligt for brugeren at angive de nødvendige oplysninger på betalingsaftalen til, at denne overførsel kan foretages korrekt, når der effektueres. - Se Krav# 66 vedrørende registrering af alternativ modtager. - Se Krav# 83 vedrørende manuel godkendelse. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag Se afsnit om snitflade til debitorsystemet i forbindelse med overførsel. til anden enhed i kommunen, fx betaling for dagtilbud jf. LAS 96. Side 92 af 255

93 Krav# 109: Tilknyt udbetalingsplan til administrationsordning Beskrivelse: Det skal være muligt for en bruger at tilknytte en udbetalingsplan til administrationsordningen. a) Det er muligt for brugeren at indberette de nødvendige oplysninger til at oprette udbetalingsplan knyttet til administrationsordningen. b) Udbetalingsplanen fastsætter, hvordan det resterende ydelsesbeløb på den bevilgede ydelse, som ikke er fratrukket til administration, udbetales til Personen. c) Der skal kunne udbetales lige store brøkdele fordelt jævnt over udbetalingsperioden eller et antal udbetalinger med specifikke beløb på specifikke ugedage, dage eller datoer. d) Løsningen skal sikre, at præcis det resterende ydelsesbeløb, som ikke er fratrukket til administration, udbetales i udbetalingsperioden i henhold til udbetalingsplanen. - Udbetalingsplanen indeholder oplysninger, der bruges ved udbetaling i rater og udbetaling af det resterende ydelsesbeløb, som ikke er anvendt til administration. - Hvis der ikke er registreret en udbetalingsplan, udbetales restbeløbet jf. effektueringsplanen i ydelsessagen. Se afsnit Se Krav# 110 vedrørende effektuering for administrationssager. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag Effektuering vedrørende administrationsordning Når administrationsordningen er etableret med tilhørende administrationsplaner, betalingsaftaler og udbetalingsplan sker der løbende effektuering af ordningen. Dette svarer til, at der gemmes en effektueringsplan på en ydelsessag, som er udgangspunkt for effektuering og bestilling af udbetalinger. I administrationssager effektueres der i henhold til den administrationsordning, der er gemt i sagen. Det sikrer, at der på de fastsatte tidspunkter overføres penge fra den eller de bevilgede ydelser til administrationsordningen i henhold til administrationsplanen, udbetales i henhold til de indberettede betalingsaftaler, og at den resterende ydelse udbetales til Personen eventuelt i henhold til en udbetalingsplan. Krav# 107: Modtag oplysninger om pensionsydelse til administration Beskrivelse: Løsningen skal løbende kunne modtage overførsel af oplysninger om overførsel af pension fra Udbetaling Danmark og kontere beløbet på den dertil oprettede bevilling og bevilget ydelse. a) Løsningen kan modtage oplysninger om overførsel af pension fra Udbetaling Danmark for alle de sager, hvor der administreres økonomi for en Side 93 af 255

94 Person, der modtager pension fra Udbetaling Danmark. b) Oplysningerne er registreret korrekt på den administrationssag og tilknyttede ydelsessag, som oplysningerne vedrører. - Når Ydelsescentret administrerer økonomien for en Person, modtager Personen enten en forsørgelsesydelse, som er bevilget i Ydelsescentret, eller en pensionsydelse, som er bevilget af Udbetaling Danmark. Der kan derfor være behov for at få overført pensionsydelsen fra Udbetaling Danmark. - Se eventuelt informationsmodellen (KY-effektuering) i underbilag 2.5. Krav# 110: Effektuér administrationsordninger Beskrivelse: Løsningen skal effektuere administrationsplan, udbetalingsplan, og betalingsaftaler på alle administrationsordninger. a) Alle administrationsordninger er effektueret, således at følgende sker rettidigt og korrekt i henhold til administrationsplaner, udbetalingsplaner og betalingsaftaler: a. Overførsel fra den bevilgede ydelse til administrationsordningen. b. Betaling til alternative modtagere. c. Udbetaling af resterende ydelsesbeløb til Personen i henhold til udbetalingsplanen, hvis der er registreret en sådan. d. Kontering af alle beløb. e. Aflevering af udbetalingsanmodninger til udbetalingssystemet og/eller dannelse af straksudbetalingsbilag. - Se Krav# 107 vedrørende overførsel fra den bevilgede ydelse til administrationsordningen. - Se Krav# 108 vedrørende betaling til alternativ modtager. - Se Krav# 109 vedrørende udbetaling af resterende ydelsesbeløb til Personen. - Se Krav# 84 vedrørende kontering. - Se Krav# 72 og Krav# 73 vedrørende aflevering af udbetalingsanmodninger til udbetalingssystemet. - Se Krav# 74 vedrørende dannelse af straksudbetalingsbilag. - Se afsnit om ØiR snitflade til udbetalings- og økonomisystemer. Krav# 111: Negativ saldo må ikke overstige maksimalt overtræksbeløb Beskrivelse: Løsningen skal sikre, at en eventuel negativ saldo på administrationsordningen ikke overskrider det indberettede overtræksbeløb. a) Løsningen skal sikre, at en negativ saldo på en administrationsordning på intet tidspunkt overstiger det overtræksbeløb, som er indberettet på administrationsordningen. b) Løsningen skal sikre, at der er dannet en opgave til brugeren, hvis saldo- Side 94 af 255

95 en på en administrationsordning bliver negativ. c) Løsningen skal sikre, at der er dannet en opgave til brugeren, hvis der er betalinger, som ikke kan effektueres pga. mulig overskridelse af overtræksbeløbet. - Behovet kan opstå, hvis der eksempelvis er variable poster på en huslejeregning. I en given måned kan huslejebeløbet overstige det normale. Hvis en eventuel negativ saldo på administrationsordningen overstiger det indberettede overtræksbeløb, medfører det, at der er betalinger, som ikke kan effektueres. - Se Krav# 10 vedrørende automatisk oprettelse af opgave. Krav# 112: Deaktivering af administrationsordning Beskrivelse: Løsningen skal deaktivere administrationsordningen, hvis en eller flere af de bevilgede ydelser, som administrationsordningen er tilknyttet, stoppes. a) Løsningen skal sikre, at administrationsordningen deaktiveres samtidig, hvis en eller flere af de bevilgede ydelser, som ordningen er tilknyttet, stoppes. b) Løsningen skal sikre, at en deaktiveret administrationsordning ikke effektueres. c) Løsningen skal sikre, at der er dannet en opgave til brugeren, når en administrationsordning deaktiveres. d) Det skal være muligt for brugeren at genaktivere administrationsordningen Afslutning af administrationsordning Når der ikke længere skal foretages administration, skal sagsbehandleren afslutte administrationsordningen og tilhørende administrationsplan(er), betalingsaftaler og udbetalingsplan, inden administrationssagen kan lukkes. Som en del af dette skal sagsbehandleren tage stilling til, hvordan en eventuel restsaldo på administrationsordningen skal behandles. Krav# 113: Afslutning af administrationsordning Beskrivelse: Brugeren skal kunne afslutte en administrationsordning. a) Det skal være muligt for en bruger at afslutte en administrationsordning. b) Løsningen skal sikre, at alle tilhørende administrationsplaner, betalingsaftaler og udbetalingsplaner afsluttes og konteres korrekt samtidig med administrationsordningen. c) Brugeren skal kunne vælge, hvordan en eventuel restsaldo skal behandles. Den kan udbetales eller tilbageføres til driftskontoen for en ydelse, Side 95 af 255

96 - som administrationsordningen er tilknyttet. d) Hvis saldoen tilbageføres, skal løsningen ud fra saldoen (nettobeløb) beregne det bruttobeløb, som skal konteres på driftskontoen. e) Hvis der undtagelsesvis er en negativ saldo, skal brugeren gøres opmærksom herpå. Brugeren skal i dette tilfælde manuelt foretage afslutning og kontering af de enkelte dele af administrationsordningen. Se Krav# 87 vedrørende manuel kontering. 5.4 Tværgående funktionalitet Dette afsnit indeholder funktionalitet, der kan være relevant under hele sagsbehandlingsforløbet, dvs. tværgående funktionalitet, som brugeren altid skal kunne trække på Valideringer Krav# 114: Validering af uforenelige ydelser Beskrivelse: Løsningen skal ved oprettelse af en sag samt ved afgørelse om bevilling validere om ydelsen, ifølge bevillingsreglerne for ydelsen, er uforenelig med ydelser, som allerede er bevilget til Personen. a) Løsningen har foretaget validering af uforenelige ydelser ved oprettelse af sag. b) Løsningen har foretaget validering af uforenelige ydelser ved registrering af afgørelse. c) Hvis det forsøges at oprette sag med uforenelig ydelse, gør Løsningen brugeren opmærksom herpå og kræver, at brugeren eksplicit bekræfter sagsoprettelsen. d) Hvis det forsøges at bevillige uforenelige ydelser, gør Løsningen brugeren opmærksom herpå og kræver, at brugeren eksplicit bekræfter afgørelsen om bevilling. - Se Krav# 21 og Krav# 22 om oprettelse af sag. - Se Krav# 57 om indberetning af afgørelse. - Se underbilag 2.2 Oversigt over uforenelige ydelser. Krav# 115: Begrænsning i bevilling af ydelser Beskrivelse: Løsningen skal sikre, at en bruger ikke kan bevilge en ydelse til sig selv eller sin ægtefælle/samlever. - Leverandøren skal være opmærksom på den særlige problematik omkring registrering af sagsbehandlerens oplysninger i forhold til databehandling (fx skal der sandsynligvis indhentes samtykke). Side 96 af 255

97 SKAT lukker på en given dato for modtagelse af oplysninger til det foregående indkomstår.(datoen udmeldes årligt på SKATs hjemmeside). Det skal således ikke være muligt for en bruger i Løsningen at indberette til kontering i et låst indkomstår, da Løsningen derved ikke ville kunne indberette korrekt til SKAT efterfølgende. Krav# 116: Ingen indberetninger i et låst indkomstår Beskrivelse: Løsningen skal sikre, at brugeren ikke kan indberette til kontering i et låst indkomstår. Hvis en bruger forsøger at indberette til kontering i et låst indkomstår, skal brugeren gøres opmærksom på, hvorfor dette ikke kan lade sig gøre. - Se Krav# 213 vedrørende den centrale administrators mulighed for at konfigurere datoen for låsningen af indkomståret. Krav# 117: Validering af personnummer Beskrivelse: Hvis brugeren indtaster et personnummer skal Løsningen, for at undgå indtastningfejl, validere, om personnummeret har korrekt format. a) Løsningen validerer, om personnummeret er korrekt opbygget. b) Brugeren informeres, hvis valideringen ikke går igennem. - CPR-nummer kan valideres ved hjælp af modulus 11 kontrol. Leverandøren bedes dog være opmærksom på, at der eksisterer CPR-numre, der ikke går igennem modulus 11 kontrollen. Jf. [indhentet ] - Vær desuden opmærksom på at Løsningen også vil indeholde administrative personnumre. Krav# 118: Ingen aktive opgaver på afsluttede sager. Beskrivelse: En sag kan ikke afsluttes, hvis der eksisterer aktive opgaver på sagen. - a) En sag kan ikke afsluttes, hvis der eksisterer aktive opgaver på sagen. b) Brugeren skal tage stilling til, om aktive opgaver på sagen kan afsluttes sammen med sagen. c) Hvis brugeren har angivet, at opgaverne kan afsluttes, afslutter Løsningen opgaver og sag. Se krav Krav# 57 vedrørende indberetning af afgørelse Side 97 af 255

98 5.4.2 Dokumenter I Løsningen både gemmes, læses og produceres dokumenter. Det er tanken, at alle de dokumenter, der er relevante for behandlingen af en sag, vil være tilgængelige via Løsningens brugergrænseflade. Dette afsnit beskriver de krav, der relaterer sig til håndtering af dokumenter. Krav# 119: Automatisk tilknytning af dokumenter til sag Beskrivelse: Løsningen skal tilknytte dokumenter til sagen automatisk, hvor det er muligt. a) Hvis sagen er tilknyttet en ansøgning i Selvbetjeningsløsningen, har Løsningen tilknyttet dokumenter modtaget via Selvbetjeningsløsningen til sagen via ansøgningens relation til sagen. b) Hvis sagen har modtaget dokumenter via Dokumentservicen, er dokumenterne knyttet til sagen Vis metadata fra dokumentet. c) Løsningen har opdateret Dokumentindekset med dokumentreference. Kriterier for tilknytning af dokumenter til sagen afklares i Designfasen. - Eksempler på metadata fra dokumentet er: CPR-nummer, ydelsesart, KLEnummer og sagsid. - Se Krav# 20 om automatisk oprettelse af sag. - Se Krav# 14 om modtagelse af dokumenter. - Se Krav# 351 om modtagelse af ansøgninger fra Selvbetjeningsløsningen. - Se Krav# 353 om Dokumentservicen. - Se afsnit vedrørende Sags- og dokumentindeks. - Se informationsmodellen KY-dokument, KY-sag i underbilag 2.5. Krav# 120: Manuel tilknytning af dokumenter til sag Beskrivelse: Brugeren skal ved sagsoprettelse og på et hvert tidspunkt i sagsbehandlingen kunne tilknytte et eller flere dokumenter til sagen. - a) Brugeren kan udvælge et eller flere dokumenter fra lokalt bibliotek eller Løsningen og knytte dem/det til sagen. b) Brugeren kan tilknytte en med eventuelle vedhæftede dokumenter til sagen. c) Brugeren kan, i forbindelse med tilknytningen til sagen, give hvert enkelt dokument et nyt brugervendt navn. d) Løsningen har opdateret Dokumentindekset med dokumentreference. Eksempler på dokumenter, der skal tilknyttes en sag er: dokumentation for indtægter eller formue, en (selve en og eventuelle vedhæftede filer i binært format). Side 98 af 255

99 - Se Krav# 21 om manuel oprettelse af sag. - Se afsnit vedrørende Sags- og dokumentindeks. - Se informationsmodellen KY-dokument, KY-sag i underbilag 2.5. I dag modtages mange dokumenter via s. Derfor skal det være muligt for sagsbehandleren let at overføre selve en samt de eventuelle vedhæftede dokumenter til Løsningen. Dette er også relevant i de tilfælde, hvor sagsbehandleren kommunikerer med Personen via . I disse tilfælde skal en vedlægges sagen som dokumentation. Behovet er således, at det er let at gemme både ind- og udgående s og eventuelle vedhæftninger på sagen. Krav# 121: Drag n drop funktionalitet Beskrivelse: Brugeren skal kunne gemme dokumenter, dokumenter vedhæftet i s samt selve en på en sag ved hjælp af drag n drop funktionalitet. a) Brugeren kan trække dokumenter, s og dokumenter vedhæftet e- mails lokalt fra brugerens maskine til sagen i Løsningen. b) Løsningen tilknytter dokumenterne til sagen. c) Løsningen kan håndtere tilknytning af s fra de mest benyttede e- mail-programmer, herunder MS Outlook, Lotus Notes og Groupwise. d) Løsningen har opdateret Dokumentindekset med dokumentreference. - Vær opmærksom på, at drag n drop skal kunne afvikles i citrix miljø, jf. kravene til Kundens it-miljø, bilag Se Krav# 120 om manuel tilknytning af dokumenter til en sag. - Se afsnit vedrørende Sags- og dokumentindeks Krav# 122: Åbne og læse dokumenter via lokal applikation Beskrivelse: Brugeren skal kunne åbne dokumenter, der er tilknyttet sager i Løsningen i den applikation, dokumentet blev dannet i. a) Brugeren kan åbne dokumenter, der er tilknyttet sager i Løsningen i den applikation, dokumentet blev dannet i, hvis applikationen er installeret på brugerens pc. b) Løsningen åbner tilknyttede pdf-dokument via den lokale pdf-reader. c) Løsningen åbner tilknyttede s via den lokale klient (fx MS Outlook). d) Løsningen åbner tilknyttede tekstdokumenter og regneark via den lokale kontor-applikation (fx MS Office). e) Løsningen åbner tilknyttede billeddokumenter via den lokale billedvisningsapplikation. f) Hvis brugeren ikke har en applikation installeret, som kan åbne den givne filtype, gøres brugeren opmærksom herpå. Side 99 af 255

100 Krav# 123: Kopier dokument fra en sag til en anden Beskrivelse: Brugeren skal kunne kopiere et dokument og tilknytte kopien til en anden sag. Løsningen kan ikke garantere, at de dokumenter, der modtages via dokumentservice (jf. afsnit ), altid er relevante for de sager, der eksisterer i Løsningen. Det kan fx være, at et indscannet dokument ved en fejl sendes til Ydelsescentret, men burde have været til Jobcentret. Løsningen skal kunne håndtere, hvordan dette irrelevante dokument ekspederes videre i kommunen. Krav# 124: Ikke relevante dokumenter Beskrivelse: Brugeren skal kunne returnere fejlplacerede dokumenter, der er indkommet via Dokumentservicen. a) Brugeren har angivet, at et dokument er fejlplaceret. b) Løsningen udstiller det fejlplacerede dokument via Dokumentservice, så et eksternt system har mulighed for at udsøge og hente de fejlplacerede dokumenter via Dokumentservicen. - Se Krav# 14 om modtagelse af dokumenter. - Se afsnit vedrørende Dokumentservice. Krav# 125: Begrænsning af filtyper Beskrivelse: Løsningen skal sikre, at dokumenter af filtypen.exe, cmd eller andre lignende eksekverbare filer ikke kan gemmes og tilknyttes sager i Løsningen. - Se Krav# 14 om modtagelse af dokumenter. - Se Krav# 120 om manuel tilknytning af dokumenter. Krav# 126: Sletning af dokumenter Beskrivelse: Løsningen skal sikre, at dokumenter, der er gemt på en sag, ikke kan redigeres eller slettes. a) Dokumenter på en sag kan ikke redigeres eller slettes. b) Undtagelser herfor er følgende: a. Breve der endnu ikke er afsendt. Brugeren kan redigere og slette breve ved brugen af brevskabeloner, så længe brevet ikke er gemt på sagen og afsendt. b. I tilfælde af flytning af dokumenter beskrevet i Krav# 123. c. I tilfælde af irrelevante dokumenter beskrevet i Krav# 124. Side 100 af 255

101 - I tilfælde af behov for redigering kan brugeren gemme en ny version af dokumentet med et andet navn og knytte den til sagen. - Se afsnit om breve og brevskabeloner Breve og brevskabeloner Der anvendes i dag en lang række breve og brevskabeloner i forbindelse med sagsbehandlingen, fx vedrørende partshøring, samtykke, orienteringer, bevillinger, afslag mv. Sagsbehandleren vil under sagsbehandlingen have behov for at sende breve til Personen og eventuelt også til tredjepart. For at lette sagsbehandlerens arbejde skal der være let adgang til en række brevskabeloner, så sagsbehandleren ikke skal bruge tid på at formulere de samme breve igen og igen. I nogle at disse brevskabeloner er indholdet fast (med indflettede strukturerede data), mens der i andre derudover vil være behov for, at sagsbehandleren kan tilføje tekst som fx en konkret individuel begrundelse for afslag. Løsningen vil ved idriftsættelse indeholde en række centralt oprettede brevskabeloner, som kommunerne kan benytte i forbindelse med sagsbehandlingen. Da kommunerne har forskellige behov, vil der dog være behov for, at nogle kommuner opretter deres egne lokale skabeloner i tilfælde af, at de centrale ikke er tilstrækkelige. De lokale skabeloner kan både være udtryk for helt nye typer af breve, der ikke eksisterer som centrale brevskabeloner, og det kan være tilpassede lokale versioner af de centrale skabeloner for at understøtte kommunernes forskelligheder. Se underbilag 2.12 for en ikke-udtømmende liste over breve, samt eksempler på en række breve. I det følgende beskrives krav til Løsningens håndtering af breve og brevskabeloner. Krav# 127: Udarbejdelse af breve Beskrivelse: Brugeren skal kunne udarbejde et brev baseret på en brevskabelon. a) Brugeren kan vælge mellem et antal brevskabeloner, der er tilgængelige i Løsningen. b) De tilgængelige brevskabeloner kan være centrale skabeloner, der er ens for alle kommuner eller lokale skabeloner, der er specifikke for brugerens kommune. c) Løsningen udfylder flettefelter og kommunale grundoplysninger i den valgte skabelon med relevante data fra sagen. d) Brugeren kan udfylde felter, der ikke er flettefelter i skabelonen. e) Brevet kan downloades lokalt og redigeres i de to gængse tekstbehandlingsformater ODF (.odt) og OOXML (.docx). f) Formatering og placering af indholdselementer bibeholdes, når brevet åbnes og redigeres. g) Brugeren kan gemme brevet som kladde eller færdigt brev, hvorefter det knyttes til sagen. Antal tegn i et brev afklares med Leverandøren i afklaringsfasen. - Se Krav# 178 om oversigt over brevskabeloner. - Se Krav# 179 om adgang til brevskabeloner. Side 101 af 255

102 - Det er obligatorisk for det offentlige at anvende de åbne standarder for redigerbare tekstdokumenter ODF og OOXML - se evt. Digitaliseringsstyrelsen: [indhentet ] Krav# 128: Centrale brevskabeloner Beskrivelse: Løsningen indeholder op til 150 centrale brevskabeloner, der kan anvendes af alle kommuner. a) Brugerne kan tilgå op til 150 centrale brevskabeloner, som leverandøren har oprettet i løsningen. b) Skabelonerne vil have både faste sektioner, flettefelter, hvor der skal indflettes informationer fra sagen samt sektioner, hvor brugeren kan indtaste fritekst i brevet. c) Information, der allerede forefindes i Løsningen, kan indflettes automatisk, herunder eksempelvis CPR-nummer, personens navn og adresse, Sags-ID, ydelsesbetegnelse og beregnet beløb til udbetaling. Det eksakte antal og indhold af centrale brevskabeloner aftales mellem Leverandøren og Kunden. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i centrale brevskabeloner. - Se underbilag 2.12 for eksempler på breve. - Se Krav# 178 om oversigt over brevskabeloner. - Se Krav# 179 om adgang til brevskabeloner. - Se Krav #382 om unikt, læsbart sags-id. Krav# 129: Lokale brevskabeloner Beskrivelse: Brugeren skal kunne anvende en lokal brevskabelon. a) Brugerne kan tilgå lokale brevskabeloner, såfremt en lokal administrator har oprettet disse. b) Skabelonerne vil have både faste sektioner, flettefelter, hvor der skal indflettes informationer fra sagen samt sektioner, hvor brugeren kan indtaste fritekst i brevet. c) Information, der allerede forefindes i Løsningen, kan indflettes automatisk, herunder eksempelvis CPR-nummer, personens navn og adresse, Sags-ID, ydelsesbetegnelse og beregnet beløb til udbetaling. - Leverandøren er ikke ansvarlig for at oprette lokale brevskabeloner. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i lokale brevskabeloner. - Se Krav# 224 om brevskabeloner oprettet af den kommunale administrator. - Se Krav# 178 om oversigt over brevskabeloner. - Se Krav# 179 om adgang til brevskabeloner. - Se Krav #382 om unikt, læsbart sags-id. Side 102 af 255

103 Krav# 130: Kommunespecifikke grundoplysninger Beskrivelse: Centrale og lokale brevskabeloner skal indeholde kommunespecifikke grundoplysninger. - Eksempler på kommunespecifikke oplysninger er: logo, adresse og åbningstider. - Se Krav# 225 om opsætning af kommunespecifikke grundoplysninger. - Se underbilag 2.12 med eksempler på breve og de kommunespecifikke grundoplysninger. Krav# 131: Oprettelse af brev baseret på tom skabelon Beskrivelse: Brugeren skal kunne danne et brev, som ikke indeholder faste skabelonelementer udover kommunens grundoplysninger. a) Løsningen har dannet et brev, der kun indeholder de kommunespecifikke grundoplysninger. b) Brevet kan downloades lokalt og redigeres i de to gængse tekstbehandlingsformater ODF (.odt) og OOXML (.docx). c) Formatering og placering af indholdselementer bibeholdes, når brevet åbnes og redigeres. - Se Krav# 130 om kommunespecifikke grundoplysninger. - Se Krav# 178 om oversigt over brevskabeloner. - Se Krav# 179 om adgang til brevskabeloner. Krav# 132: Håndtering af brev som kladde Beskrivelse: Brugeren skal kunne gemme et brev som kladde og kunne genoptage redigeringen af kladden på et senere tidspunkt. a) Brugeren kan gemme et brev som kladde. b) Brugeren kan redigere kladden. c) Brugeren kan gemme kladden som færdigt brev. - Se Krav# 127, Krav# 128, Krav# 129 om brevskabeloner. - Se Krav# 178 om oversigt over brevskabeloner. - Se Krav# 179 om adgang til brevskabeloner. Krav# 133: Angiv forsendelsestype for breve Beskrivelse: Brugeren skal kunne angive forsendelsestype for et brev. - a) Brugeren kan angive, at brevet skal sendes anbefalet eller med krav om afleveringsattest. b) Brugeren kan angive, at brevet skal sendes som A- eller B-post. Se Krav# 226 om konfigurering af defaultværdi for breve som A- eller B-post. Side 103 af 255

104 Krav# 134: Afsendelse af breve via fjernprint Beskrivelse: Brugeren skal kunne afsende et brev via en fjerprintløsning. a) Hvis brugeren har angivet, at et brev med et antal bilag skal afsendes, anvender Løsningen snitfladen til Fjernprint til afsendelse af breve og bilag. b) Når brugeren har angivet, at breve og bilag skal afsendes, gemmer Løsningen brev og bilag i PDF/A-2 format på Personens sag. c) Løsningen har registreret, at brevet håndteres af fjernprintløsningen. d) Løsningen har medsendt information om, hvorvidt breve sendes som A- eller B-post på grundlag af den kommunale administrators registrering eller den enkelte brugers valg. - Via fjernprintløsningen kontrolleres det, om borgeren er tilmeldt Digital Post. Hvis dette er tilfældet, sendes brevet til Digital Post. Hvis Personen ikke er tilmeldt Digital Post, sendes brevet med almindelig papirpost. - Løsningen får i retursvaret fra fjernprintløsningen besked om, hvorvidt brevet er sendt til Digital Post eller med papirpost. - Se Krav# 357 om Fjernprintløsningen. - Se Krav# 226 om den kommunale administrators valg af defaultopsætning af A eller B-post. - Se Krav# 133 om brugerens valg af A eller B-post. Som oftest vil Løsningen sende brevet via integration til fjernprintløsningen (jf. Krav# 134) Men der kan være tilfælde, hvor brevet ikke skal sendes via denne kanal. Fx hvis Personen sidder fysisk til møde med sagsbehandleren. I disse tilfælde er der behov for, at sagsbehandleren kan printe brevet lokalt og udlevere det til personen. I disse tilfælde skal Løsningen ikke sende brevet via fjernprintløsningen. Krav# 135: Valg af lokalt print til udskrivning af breve og rapporter Beskrivelse: Brugeren skal kunne udskrive breve og rapporter på lokal printer. a) Brugeren kan angive, at breve og rapporter skal udskrives lokalt. b) Hvis brugeren har angivet, at brevet skal afsendes, har Løsningen gemt brevet i PDF/A-2 format på Personens sag. c) Løsningen kan udskrive breve med modtageroplysninger placeret i brevhovedet, så det passer til en rudekuvert. d) Løsningen har registreret, at brevet/rapporten er udskrevet lokalt. For de fleste breve er det sagsbehandleren, der initierer, at der skal afsendes brev. Men i enkelte tilfælde kan Løsningen automatisk udsende breve uden sagsbehandlerens indblanding Krav# 136: Automatisk udsendelse af breve Beskrivelse: Løsningen skal kunne udsende breve automatisk på grundlag af hændelser, der registreres på sagen via snitfladen til print. Side 104 af 255

105 a) Løsningen har udsendt breve på grundlag af hændelser, der afstedkommer automatisk udsendelse af breve, jf. underbilag 2.13 Hændelsesliste. b) Løsningen har gemt brevet i PDF/A-2 format og tilknyttet det Personens sag. c) Løsningen har udsendt brevet via af fjernprintløsningen. d) Løsningen har medsendt information om, hvorvidt breve sendes som A- eller B-post på grundlag af den kommunale administrators registrering. e) Løsningen har registreret en hændelse om udsendelsen af brevet på sagen. Eksempler på breve, der udsendes automatisk, er: - Udbetalingsspecifikationer (ved udbetaling af ydelser). - Erklæring om oplysningspligt (udsendes regelmæssigt i sager vedrørende forsørgelsesydelser). - Brev om opfølgning på boligoplysninger (særlig støtte, LAS 34). - Se Krav# 357 om fjernprintsløsningen. - Se Krav# 226 om den kommunale administrators opsætning af A- eller B- post. Visse breve (fx brev om, at en Person, der ikke betaler sit fleksydelsesbidrag inden for en vis frist, udmeldes af ordningen) kan sendes anbefalet eller med krav om afleveringsattest Journalnotat og registrering af hændelser Brugeren vil løbende i sagsbehandlingen have behov for at skrive journalnotater. Et journalnotat er sagsbehandlerens sted at gøre af løse noter, fx i forbindelse med telefonsamtaler. Ofte vil journalnotater indeholde samme tekst på tværs af sager, og derfor har kommunen mulighed for at benytte journalnotatsskabeloner. Sagsbehandleren kan således ved oprettelsen af et journalnotat vælge at tage udgangspunkt i en journalnotatsskabelon, hvor det meste indhold er forhåndsudfyldt. Sagsbehandleren kan indtaste de informationer, der mangler, og på den måde hurtigt kunne danne et journalnotat. Ud over de manuelle journalnotater brugeren skriver, indtræffer der en række hændelser i forbindelse med en sag, hvor det er nødvendigt at registrere, hvad der er sket. Det er fx, når Løsningen sender et brev til Personen, eller når Løsningen modtager besked fra Jobcenterløsningen, at der er oprettet et kontaktforløb etc. Alle disse hændelser skal således registreres automatisk. Journalnotaterne og de specifikke registreringer af hændelser vil altid være knyttet til en sag og vil være med til at danne overblikket i sagshistorikken (jf. afsnit 5.5.4). Hændelse der igangsætter opgaven Startbetingelse Sagsbehandleren har foretaget en handling, der kræver, at der skrives et journalnotat. Alternativt er der indtruffet en hændelse, der skal registreres på en sag. Sagsbehandleren har fremfundet den relevante sag, hvor journalnotatet skal tilknyttes. Side 105 af 255

106 Slutresultat Alternativt har Løsningen modtaget information om en hændelse. Journalnotatet er oprettet og knyttet til en sag. Alternativt er der registreret en hændelse på sagen. Krav# 137: Oprettelse af journalnotat Beskrivelse: Brugeren skal kunne oprette et journalnotat på hvilket som helst tidspunkt under behandlingen af en sag. a) Brugeren har oprettet et journalnotat på sagen. b) Brugeren kan benytte en skabelon i forbindelse med oprettelsen af journalnotatet. c) Journalnotater kan udarbejdes på grundlag en journalnotatsskabelon, hvortil der kan tilføjes yderligere oplysninger. d) Brugeren kan tilknytte journalnotatet til flere sager for Personen. e) Løsningen opdaterer Dokumentindekset med reference til journalnotatet. - Et journalnotat kan tilknyttes flere sager, fx hvis Personen har både en kontanthjælpssag og en enkeltydelsessag, hvor notatet er relevant. - Se Krav# 229 om skabelon for journalnotat. - Se afsnit Sags- og Dokumentindekset. Krav# 138: Formatering og stavekontrol i journalnotat Beskrivelse: Løsningen skal sikre, at journalnotatet har simpel tekstredigering og stavekontrol. a) Tekstredigering af notatet kan som minimum understøtte formatering af tekst med fed, kursiv og understregning. b) Tekstredigering af notatet kan som minimum understøtte opstilling ved brug af punktliste. c) Løsningen gør brugeren opmærksom på stavefejl i journalnotatet. Krav# 139: Indhold i journalnotat Beskrivelse: Et journalnotat skal som minimum indeholde følgende informationer: Dato og tidsstempel for oprettelse eller redigering Overskrift Notetekst Navn på den person, der har oprettet eller redigeret journalnotatet Reference til et eventuelt relateret dokument a) Et journalnotat indeholder som minimum ovenstående informationer. b) Et journalnotat kan indeholde minimum tegn. - Se informationsmodellen KY-sag i underbilag 2.5. Krav# 140: Ændring og sletning af journalnotat Beskrivelse: Brugeren skal kunne redigere og slette et ulåst journalnotat. Side 106 af 255

107 a) Brugeren kan redigere eller slette et journalnotat, der ikke er låst. b) Løsningen opdaterer dokumentreferencen i Dokumentindekset. - Se Krav# 228 om angivelse af, at låste journalnotater ikke skal vises på sagen. - Se afsnit Sags- og Dokumentindekset. Journalnotatet låses automatisk et antal dage efter den dag, noten blev oprettet. Antallet af dage kan opsættes på kommunalt niveau (se eventuelt Krav# 227). Krav# 141: Automatisk registrering af hændelser i sagshistorikken Beskrivelse: Løsningen skal registrere udvalgte hændelser på en sag. a) Hændelserne i underbilag 2.13 registreres som minimum i Løsningen. b) Hændelsen registreres med samme metadata som journalnotater. c) Hvis hændelsen er dannet på grundlag af en besked, der er modtaget i Løsningen, registreres hændelsen med det dataindhold, beskeden indeholdt. Den endelige liste med hvilke hændelser, der skal registreres automatisk, afklares med Leverandøren. - Eksempler på handlinger, der kan ligge til grund for registrering af hændelser: Når der sendes eller modtages et dokument/brev. Når der træffes en afgørelse (bevilling, afslag, gennemførelse af sanktion, afvisning af sanktion, godkendelse af udbetaling, ændringer i beregningsgrundlag mv.). Når der modtages beskeder fra eksterne systemer. Når der sker statusskift på sagen. Når en opgave er afsluttet, fx behandlet flytning, behandling af erklæring om oplysningspligt. Når Løsningen reagerer automatisk på interne regler jf. Krav# Se Krav# 139 om journalnotat. - Se Krav# 171 om visning af sagshistorik. - Se hændelseslisten i underbilag Krav# 142: Internt arbejdsnotat Beskrivelse: Brugeren skal kunne oprette et internt arbejdsnotat på sagen. - a) Løsningen har oprettet et internt arbejdsnotat. b) Arbejdsnotatet er undtaget fra aktindsigt. c) Løsningen signalerer, at der findes et internt notat på sagen. Et internt arbejdsnotat kan fx benyttes til at notere, at Personen ved en tidligere henvendelse i Ydelsescentret har været voldelig. Side 107 af 255

108 - Se Krav# 171 om visning af sagshistorik Status og låsning af sager samt opgaver En sag og en opgave kan have forskellige former for status. I dette afsnit beskrives de forskellige statusser, samt hvordan det er muligt at ændre disse. En sag i Løsningen vil altid have en status. Løsningen følger OIO Standarden for Sag (i standarden kaldes status for sagstilstande). Men derudover vil der være behov for at udvide med nogle yderligere substatusser. I standarden er det ikke muligt at gå tilbage i status. Denne begrænsning forestiller Kunden sig ikke kan overholdes i Løsningen, da en sag fx kan løbe over en lang periode og kan indeholde mange udbetalinger og flere genoplysninger af sagen. Kunden forestiller sig, at de specificerede statusser i standarden skal suppleres med yderligere statusser for fx at tilgodese forretningsbehovene for at kende fremdriften (eller manglen på samme) i en sag. Figur 3 nedenfor viser et tilstandsdiagram med den forventede sammenhæng mellem status og statusskift. Opstået Oplyst Afgjort Bestilt Udført Afsluttet Under oplysning [Vedligeholdelse af sagen] [Ved manuel godkendelse af udbetaling] [Ved partshøring/ indhentning af supplerende oplysninger] Figurforklaring OIO Sagsstatus (tilstand) Afventer borger Afventer borger Figur 34: Forventede sagstatusser KY Substatus (ikke OIO) Krav# 143: Sagsstatus (sagstilstand) Beskrivelse: Løsningen skal sikre, at der kan registreres og opdateres en status på sagen. a) Løsningen kan antage statusser beskrevet i OIO specifikationen for Sag eller løsningsspecifikke substatusser. b) Status/substatus kan registreres og ændres af brugeren. c) Status/substatus kan registreres og ændres af Løsningen på grundlag af hændelser med relation til sagen. d) Ved kommunikation med eksterne parter benyttes altid OIO Sagstilstande e) Når der er sket et statusskift, har Løsningen registreret en hændelse om skiftet på sagen. Eventuelle tilføjelser af substatusser aftales mellem Kunden og Leverandøren i Side 108 af 255

109 Designfasen. - Se nyeste version af OIO sagsstandarden på [indhentet august 2013] Krav# 144: Opgavestatus Beskrivelse: Løsningen skal sikre, at en opgave kan have følgende statusser: Ubehandlet Under behandling Behandlet Den endelige navngivning og eventuelle tilføjelser aftales med Leverandøren. Da forskellige brugere har adgang til samme sager/opgaver, vil det være sandsynligt, at flere brugere tilgår disse sager/opgaver samtidig. Derfor vil der være behov for at sikre sagerne og opgaverne mod, at der opstår uoverensstemmelser i data. Krav# 145: Låsning af sager Beskrivelse: Løsningen skal sikre, at kun en enkelt bruger kan redigere sagen ad gangen. a) Når en bruger åbner en sag, kan sagen læses, men ikke redigeres af andre brugere, der tilgår sagen. b) Når en bruger åbner en sag, der allerede redigeres af anden bruger, viser Løsningen tydeligt, at sagen er i ikke-redigerbar tilstand og angiver, hvem der redigerer sagen. Se informationsmodellen (KY-sag) i underbilag 2.5. Krav# 146: Låsning af opgaver Beskrivelse: Løsningen skal sikre, at kun en enkelt bruger kan redigere en opgave tilknyttet en Person ad gangen. - a) Når en bruger redigerer i en opgave, der er knyttet til en Person, kan opgaven ikke redigeres af andre brugere. b) Når en bruger åbner en opgave, der er knyttet til en Person, der allerede redigeres af anden bruger, viser Løsningen tydeligt, at opgaven er i ikkeredigerbar tilstand og angiver, hvem der redigerer opgaven. Hvis en opgave er knyttet til en sag, sikrer låsningen af sagen, at en opgave ikke kan redigeres af flere brugere samtidigt. Dette krav sikrer, at opgaver, der er tilknyttet Personen, ikke kan redigeres af flere brugere samtidigt. Side 109 af 255

110 - Se krav Krav# 15 om redigering af oplysninger på en opgave. Krav# 147: Frigivelse af sager og opgaver Beskrivelse: Løsningen skal sikre, at en sag eller opgave frigives til redigering. a) Når brugeren vælger at gå ud af sagen eller opgaven, frigives denne, så andre brugere kan redigere i sagen eller opgaven. b) Hvis brugeren en inaktiv i en vis periode, frigives sag eller opgave til redigering af andre brugere. - Se Krav# 145 og Krav# 146 om låsning af sag og opgave. - Kravet skal ses i sammenhæng med kravet vedrørende auto-gem (se bilag 12.6 Øvrige optioner). - Se krav om persistering af auto-gemt data på tværs af sessioner (se bilag 12.6 Øvrige optioner). 5.5 Visninger Mange af de funktionelle krav indebærer implicit, at der laves en grafisk brugergrænseflade, så brugeren kan udnytte den beskrevne funktionalitet. Der er i mange af disse tilfælde ikke lavet specifikke krav til, hvordan og hvad den grafiske brugergrænseflade skal indeholde. Der er dog en række områder, hvor Kunden har følt behov for at tydeliggøre specifikke behov til den grafiske brugergrænseflade for at sikre, at brugergrænsefladen i så høj grad som muligt understøtter brugerens arbejde. Disse områder vil blive uddybet i dette afsnit, og dette afsnit indeholder således beskrivelser samt krav til specifikke informationer og visninger i Løsningen. Kravene Krav# Krav# 180 skal derfor læses som eksempler på løsninger, hvor Kunden forventer at kravet opfyldes, men hvis Leverandøren kan redegøre for at alternative løsningsmodeller opfylder behovet i lige så høj grad som kravbeskrivelsen, kan de alternative løsningsmodeller benyttes. De specifikke krav til visninger i Løsningen er samlet i dette afsnit, og der vil være henvisninger til og fra de funktionelle krav, hvor visningerne er relevante. Afsnittet er opdelt i underafsnit, hvor hvert underafsnit omhandler et særligt område. Det skal tydeliggøres, at kravene i dette afsnit ikke skal ses som en fyldestgørende samlet liste over visninger i Løsningen, men blot er et udtryk for nogle særlige krav til visninger. Dette afsnit bør læses i sammenhæng med de generelle krav til brugervenlighed (jf.6.5), som på samme vis har til formål at sikre, at Løsningen understøtter brugernes arbejde Visninger generelt Krav# 148: Angivelse af bruger Beskrivelse: Alle skærmbilleder skal indeholde en angivelse af, hvem der er logget ind. Hvis en bruger er logget ind med fuldmagt, skal det også fremgå af Løsningen. a) Navnet på den bruger, der er logget ind, vises på hvert skærmbillede. Side 110 af 255

111 b) Hvis en bruger er logget ind med fuldmagt, skal dette ligeledes fremgå. - Ovenstående krav er relevant for både sagsbehandlerdelen af Løsningen såvel som Selvbetjeningsløsningen. Krav# 149: Angivelse af Person Beskrivelse: Alle skærmbilleder vedrørende en sag skal indeholde en angivelse af, hvilken Person sagen omhandler. a) Navn og CPR-nummer på den Person, sagen omhandler, vises på hvert skærmbillede. - Brugeren må på intet tidspunkt være i tvivl om, hvilken person der sagsbehandles. Krav# 150: Visning af kommunenavn og logo Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens brugergrænseflade skal kunne vise kommunelogo og kommunenavn for den kommune, der anvender Løsningen. a) Navn samt kommunelogo (i form af et ikon) er placeret i Løsningens øverste venstre hjørne. b) Løsningen kan håndtere ikoner i minimum 3 grafiske filformater, herunder JPEG, PNG og GIF. Den nøjagtige placering og størrelse af ikonet aftales med Leverandøren i Designfasen. - Kunden fremskaffer logoer i passende format. Krav# 151: Visning af navn på Løsningen Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Løsningens brugergrænseflade skal kunne vise navnet på Løsningen. Løsningens navn Kommunernes Ydelsessystem er placeret øverst i Løsningens skærmbilleder. Kravet udgør et designprincip, som KOMBIT ønsker at fremme på tværs af monopolsbrudsløsningerne. Side 111 af 255

112 Der vil i en række situationer være behov for, at sagsbehandleren kan se sagens oplysninger, som de så ud på et givet tidspunkt tilbage i tid, eksempelvis ved forespørgsler eller i forbindelse med behandling af klagesager. Dette muliggøres af de bitemporale egenskaber, som Løsningen understøtter jf. afsnit Krav# 152: Visning af sagens oplysninger pr. brugervalgt dato og tid Beskrivelse: Løsningen skal kunne vise alle sagens oplysninger, som de var registreret på et givet tidspunkt, som vælges af brugeren. a) Brugeren kan vælge en dato og tidspunkt, hvorefter Løsningen viser brugeren, hvordan sagens oplysninger så ud på daværende tidspunkt. b) Brugeren må i denne visning ikke kunne foretage ændringer i historiske data. c) Det er tydeligt for brugeren, at der vises historiske data. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.3 for eksempel på, hvordan Kunden kunne forestille sig en Løsning. - Vær opmærksom på at dette krav ikke betyder, at det er umuligt at lave ændringer med tilbagevirkende krav i Løsningen. Visse sagsbehandlere arbejder med to skærme samtidigt for at kunne håndtere de store mængder af information, der indgår i sagsbehandlingen eller for at kunne håndtere henvendelser, der ikke vedrører den sag, de aktuelt arbejder på. Krav# 153: Visning på flere skærme Beskrivelse: Løsningen skal sikre, at brugeren kan arbejde med flere sager eller elementer af en enkelt sag på flere skærme samtidigt. a) Brugeren har mulighed for at arbejde i Løsningen med flere sager på flere skærme. b) Flg. elementer fra en sag skal som minimum kunne vises selvstændigt: o Opgaveliste o Primære sagsoplysninger (overblikssider) o Sagsoplysninger (detailsider) o Dokumenter på sagen o Journalnotater c) Løsningen skal sikre konsistens i data, således at det altid er de senest indtastede data, der er de korrekte. Endelig afklaring vedrørende hvilke elementer fra en sag, der skal kunne vises på et selvstændigt skærmbillede, afklares med Leverandøren. - Et eksempel på en brugssituation kunne være, at sagsoplysninger vises på Side 112 af 255

113 den ene skærm, mens sagsbehandleren skriver et journalnotat på den anden skærm. Et andet eksempel kunne være, at sagsbehandleren er i gang med at behandle en sag, men bliver ringer op af Personen. Så slår sagsbehandleren Personens sag op i et nyt vindue, så det ikke er nødvendigt at lukke den sag, som sagsbehandleren var i gang med at behandle. - Med overblikssider og detailsider henvises til underbilag 2.10 Eksempler på skærmbilleder afsnit 2.4 for uddybning af, hvad Kunden forestiller sig Visninger i forhold til opgavelisten Dette afsnit indeholder de specifikke krav til visninger vedrørende opgavelisten. Se afsnit 5.1 for uddybning. Krav# 154: Visning af opgaveliste Beskrivelse: Opgavelisten skal understøtte de to formål beskrevet i afsnit At give let mulighed for at fordele opgaver - At give den enkelte sagsbehandler overblik over de opgaver, denne skal løse Krav# 155: Filtrering og søgning i opgaveliste Beskrivelse: Brugeren kan filtrere og søge i opgavelisten. a) På opgavelisten kan brugeren: A. Filtrere for denne bruger irrelevante opgaver fra, så disse ikke vises. B. Filtrere på flere forekomster i samme kolonne og/eller filtrere på flere kolonner samtidig. C. Filtrere ud fra et eller flere af nedenstående intervaller: Fødselsdatointervaller: på både dag, måned og år Dato for oprettelse: periode Deadline for løsning: periode D. Søge i opgavelisten. - Med filtrering på flere forekomster i samme kolonne menes eksempelvis, at der kan filtreres, så der kun vises ydelsesarter, der enten er Kontanthjælp eller Enkeltydelse. Dette vil give sagsbehandlerne en mere fleksibel måde at filtrere irrelevante opgaver fra. - Se Krav# 11 for hvilke informationer en opgave indeholder - Se underbilag 2.10 Eksempler på skærmbilleder afsnit for eksempel på, hvordan Kunden kunne forestille sig en løsning. Side 113 af 255

114 Krav# 156: Individuel standardfiltrering/søgning i opgavelisten Beskrivelse: Det er muligt for den enkelte bruger at opsætte og gemme sin egen standardfiltrering/søgning. a) Brugeren kan gemme og slette egne individuelle filtreringer/søgninger. b) De individuelle filtreringer/søgninger er tilgængelige næste gang brugeren logger på Løsningen. c) Brugeren kan vælge en af de individuelle filtreringer/søgninger, som opgavelisten åbner som standard, når brugeren åbner opgavelisten. d) De individuelle filteringer/søgninger kan være en kombination af alle de forskellige filtreringer/søgninger beskrevet i Krav# 155. Krav# 157: Individuel opsætning af oplysninger på opgavelisten Beskrivelse: Brugeren kan individuelt konfigurere hvilke oplysninger, der vises på opgavelisten. a) Brugeren kan vælge hvilke oplysninger, der vises på brugerens opgaveliste. b) Denne opsætning kan gemmes som standardopsætning for den enkelte bruger. - Fx kan man forestille sig at en bruger ikke ønsker at se oplysninger om, hvilket team opgaven er tildelt, hvis kommunen ikke arbejder med teams. Man kunne også forestille sig, at en bruger ikke ønsker at se ydelse sat på hold, hvis denne bruger udelukkende arbejder med enkeltydelser. - Se Krav# 11 hvilke oplysninger en opgave indeholder Visninger i forhold til behandling af ydelsessager Krav til behandling af ydelsesager ses i afsnit 5.2. Dette afsnit indeholder de specifikke krav til visninger hertil: herunder oplysning af sag, fastsættelse af ydelsessats og beregning af ydelse, træf afgørelse, effektuer, vedligeholdelse af sag samt afslut og arkiver sag. Meget af sagsbehandlerens arbejde vil foregå i forbindelse med oplysning af sagen, hvor sagsbehandleren vurderer de eksisterende oplysninger, vurderer eventuelle uoverensstemmelser, indberetter nye oplysninger osv. For at Løsningen kan understøtte sagsbehandlerens arbejde, er det helt centralt, at der skabes nogle gode overbliksgivende skærmbilleder, hvor der både er let adgang til at indberette, men hvor det også er hurtigt at danne sig overblik over eventuelle manglende oplysninger osv. De forskellige ydelsesarter benytter mange af de samme oplysninger, men der er også forskellige informationsbehov mellem ydelsesarterne. Skærmbillederne skal være tilpassede de forskellige ydelsesarter, så der kun vises relevant information (fx er ægtefællen/samleverens oplysninger relevante på en sag om uddannelseshjælp eller kontanthjælp, men ikke på en sag om ledigheds- Side 114 af 255

115 ydelse). Ligeledes skal skærmbillederne være kontekstafhængige, sådan at der fx ikke vises børneoplysninger, hvis Personen ikke har børn. Krav# 158: Overblik over sagens oplysninger Beskrivelse: Løsningen skal vise sagens oplysninger (de indberettede, indhentede samt modtagne og beregnede), således at brugeren får et overblik over de relevante oplysninger. a) Skærmbillederne skal struktureres sådan, at oplysningerne grupperes, så det understøtter brugernes arbejdsgang. b) Der kan hentes og vises en oversigt over en Persons ydelser fra Ydelsesindekset. Den endelige opdeling/gruppering i oplysninger afklares i forbindelse med udviklingen af skærmbillederne i samarbejde med brugere. - Se Krav# 26, Krav# 29, Krav# 30, Krav# 31 og Krav# 36 samt Krav# 279 Krav# 280, Krav# 281, Krav# 282, Krav# 283, Krav# 290 og Krav# 346 for eksempler på relevante oplysninger. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 og 2.4 for inspiration. Ved nogle ydelsesarter skal ægtefællen/samleverens forhold oplyses i samme detaljegrad som ansøgerens. Der er derfor behov for, at sagsbehandleren har et let overblik over begge ægtefæller/samleveres forhold. I særlige tilfælde på uddannelseshjælp eller kontanthjælp kan den ene ægtefælle/samlever desuden modtage uddannelseshjælp eller kontanthjælp på baggrund af den anden ægtefælle/samlevers ansøgning om uddannelseshjælp eller kontanthjælp, og er således ikke selv ansøger. I dette særtilfælde skal det være tydeligt på sagen, hvilken af de to personer, der har ansøgt og hvilken person, der ikke har ansøgt om ydelsen. Krav# 159: Overblik over ægtefællen/samleverens oplysninger Beskrivelse: Ved overblik over sagens oplysninger skal der for de relevante ydelsesarter være let adgang til ægtefælle/samlevers oplysninger. Det skal på sagen være tydeligt, om personen har ansøgt om ydelsen eller om personen modtager ydelsen på baggrund af ægtefællen/sam-leverens ansøgning. - Se Krav# 31 vedrørende oplysninger om ægtefælle/samlever. I forbindelse med nogle af de forsørgelsesydelser, som håndteres i Løsningen, kan personen og eventuelt dennes ægtefælle/samlever sanktioneres økonomisk. I disse sager vil der være behov for, at brugeren kan få et overblik over de sanktioner, der indgår i sagen. Krav# 160: Overblik over sanktioner i sagen (Sanktionsoverblik) Beskrivelse: Det skal være muligt for en bruger at se et overblik over alle sanktioner og sanktionsindstillinger i en eller flere sager for personen, som er primær part i sagen, og dennes ægtefælle/samlever. Side 115 af 255

116 - a) Alle indstillinger om sanktioner er tilgængelige for en bruger i et samlet overblik. b) Brugeren kan filtrere og sortere, hvilke sanktioner og sanktionsindstillinger, der vises, ud fra Person, sag, typer af sanktion, registreringsperioder, udbetalingsperioder og status på sanktionerne/indstillingerne. c) Brugeren kan navigere direkte fra overblikket til detailoplysningerne om den enkelte sanktion eller sanktionsindstilling. d) Brugeren kan navigere direkte til at træffe afgørelse om sanktionen. Se Krav# 62 vedrørende afgørelse om sanktion. Krav# 161: Kontekstafhængige skærmbilleder Kategori: Type: Funktionelt Beskrivelse: Skærmbillederne viser kun de oplysninger, der er relevante i den givne kontekst, så overblikket ikke forstyrres af irrelevante oplysninger. - Et eksempel kunne være, at børneoplysninger ikke vises på en sag, hvis Personen ikke har børn. Et andet eksempel kunne være, at ægtefællens indtægtsoplysninger ikke vises i de ydelsesarter, hvor disse ikke er relevante. I Krav# 161 beskrives behovet for kontekstafhængige skærmbilleder, så brugerens overblik ikke forstyrres af irrelevante oplysninger. Men der kan være situationer, hvor de kontekstafhængige skærmbilleder kan være begrænsende. Fx hvis Løsningen fejlagtigt tror, at Personen ikke har børn (og derfor ikke viser børneoplysninger), men det viser sig, at Personen faktisk har børn. I disse tilfælde skal det være muligt for brugeren at få adgang til det fulde sæt af oplysninger og dermed manuelt kunne opdatere oplysningerne. Krav# 162: Adgang til det fulde sæt af oplysninger på en sag Kategori: Type: Funktionelt Beskrivelse: Brugeren har mulighed for at få adgang til det fulde sæt af oplysninger på en sag, selvom disse ikke vises som udgangspunkt. Krav# 163: Visuel markering af uoverensstemmelser i oplysninger Beskrivelse: Løsningen skal tydeligt vise eventuel uoverensstemmelse mellem de indberettede og de indhentede oplysninger. - Se Krav# 32 vedrørende valg af gældende oplysninger ved uoverensstemmelser. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.5 for eksempel på, hvordan Kunden kunne forestille sig en Løsning. Fastsættelse af ydelsessats og beregning af ydelsen (jf. afsnit 5.2.2) foretages af Løsningen. Det skal derfor være muligt for brugeren at se, hvordan Løsningen er nået frem til resultatet i forhold til Side 116 af 255

117 fastsættelsen og beregninger. Det skal være så udførligt beskrevet, at brugeren uden større regneøvelser efterfølgende er i stand til at forklare Personen, hvorfor resultatet ser ud, som det gør. Krav# 164: Visning af specifikation af beregningsgrundlag Beskrivelse: En bruger skal i løsningen kunne se en specifikation af en forventet eller foretaget udbetaling sammen med de beregninger, der ligger til grund for en udbetaling. a) Brugeren kan se en specifikation af en forventet eller foretaget udbetaling sammen med de beregninger, der ligger til grund for en udbetaling. b) Brugeren kan se en specifikation af en forventet eller foretaget opkrævning af fleksydelsesbidrag. c) Specifikationen skal som minimum indeholde de mellemresultater, som følger af lovgivningens regler for fastsættelse af ydelsessats, tillæg/fradrag, sanktioner mv. d) De enkelte fradrag til en administrationsordning skal ligeledes fremgå. - Se Krav# 44 og Krav# 45 vedrørende beregning af ydelsesbeløb. - Se Krav# 47 og Krav# 48 vedrørende fastsættelse af ydelsessats og beregning af beløb. - Se eksempel på anvisningsrapport i underbilag 2.9. Der vil være situationer, hvor den samme Person er part på flere sager i Løsningen. Dette kan være relevant information for sagsbehandleren i forhold til vurderingen af en sag. Fx er det relevant at vide, at der allerede eksisterer en kontanthjælpssag, hvis den samme Person søger om en enkeltydelse. Krav# 165: Visning og adgang til relaterede sager Beskrivelse: Hvis en part i sagen (Personen, ægtefælle/samlever, børn) også er part i andre sager i Løsningen, gøres brugeren visuelt opmærksom på dette. Brugeren har mulighed for direkte at navigere til de relaterede sager. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 for inspiration. Når en bruger slår op på en sag (fx fordi en Person ringer til Ydelsescentret), skal det via selve sagen være tydeligt for brugeren, hvis der eksisterer aktive opgaver på sagen. De skal dermed ikke behøve at gå ind på opgavelisten for at se, om sket noget nyt på sagen eller for at ændre en opgaves status. Da den samme opgave kan være relevant for flere sager (fx er behandling af en flyttemeddelelse både relevant for Personens enkeltydelsessag og Personens kontanthjælpssag), skal opgaverne vises på tværs af sager, så alle opgaver vedrørende Parten i sagen vises. Side 117 af 255

118 Krav# 166: Visning af aktive opgaver samt opgavestatus på sagen/personen Beskrivelse: Brugeren har let adgang fra den enkelte sag til at se hvilke aktive opgaver, der eksisterer på sagen/personen, samt opgavernes status. a) Brugeren kan på den enkelte sags overbliksside se, hvilke aktive opgaver den primære part på sagen har i Løsningen. b) Brugeren kan ændre opgavestatus fra selve sagen. - Se Krav# 25 vedrørende ændring af opgavestatus. - I forhold til punkt a), så forestiller Kunden sig, at alle opgaver på tværs af alle sager i Løsningen vises på sagen. Hvis eksempelvis Personen både har en kontanthjælpssag og en enkeltydelsessag, så vises opgaverne fra begge sager lige meget, hvilken sag sagsbehandleren kigger på. - Gamle opgaver, der allerede er blevet behandlet, bør ikke vises på sagsoverblikket, men kan ses på sagshistorikken (jf. afsnit 5.5.4). - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 for inspiration. Krav# 167: Visning af sagsstatus Beskrivelse: Brugeren har let adgang fra den enkelte sag til at se sagsstatus. a) Brugeren kan på den enkelte sags overbliksside se sagsstatus. b) Brugeren kan manuelt ændre status på sagen. - Se afsnit vedrørende sagsstatus. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.2 for inspiration. Krav# 168: Visning og registrering af mellemkommunal refusion samt klagesag Beskrivelse: Brugeren kan se og registrere på sagen, hvis der er tale om en mellemkommunal refusion og/eller en klagesag. a) Brugeren kan se og registrere på sagen, at sagen har en tilhørende mellemkommunal refusionssag relateret til denne sag. b) Brugeren kan se og registrere på sagen, at sagen har en tilhørende klagesag relateret til denne sag. c) Brugeren kan tilføje en relation til den relaterede mellemkommunale refusionssag/ klagesag. - Registreringen af både mellemkommunal refusion og klagesager har ikke direkte indflydelse på sagen i Løsningen, men er blot en registrering af, at der eksisterer en klagesag/mellemkommunal refusionssag. Disse typer af sager vil befinde sig i et andet kommunalt it-system. Typisk i kommunens ESDH. - Vedrørende tilføjelse af en relation til de relaterede sager forestiller Kunden Side 118 af 255

119 sig eksempelvis en mulighed for at indsætte et link. Krav# 169: Visning af særlige adresser samt navne- og adressebeskyttelse Beskrivelse: Det markeres visuelt på sagen, hvis Personen er bosat på en af adresserne fra listen med særlige adresser og/eller ved navne og adressebeskyttelse. a) Det markeres visuelt på sagen, hvis Personen er bosat på en af adresserne fra listen med særlige adresser. b) Er Personen omfattet af navne- og adressebeskyttelse i CPR, skal dette markeres visuelt, så brugeren tydeligt kan se, at adressen er hemmelig. c) Ved et enkelt tastetryk/klik skal brugeren kunne få adgang til Personens navn og adresse. - Se Krav# 231 vedrørende vedligehold af særlige adresser. - Det skal markeres, at der er tale om en navne og adressebeskyttelse, men det betyder ikke, at adressen skal være skjult, eftersom brugeren gerne må se adresser, der er beskyttet. Årsagen til den visuelle markering er, at brugeren er opmærksom på, at andre personer ikke må se adressen. Under sagsbehandlingen benytter kommunerne forskellige former for interne vejledninger, tjeklister, links mm. Der bør i Løsningen være en fleksibel måde for den enkelte kommune at give deres sagsbehandlere let adgang til disse informationer. Ofte vil et link til en hjemmeside eller et dokument være tilstrækkeligt. Krav# 170: Links og lokale vejledninger Beskrivelse: Der er let adgang for brugeren for at tilgå lokale vejledninger. Såfremt den kommunale administrator har opsat lokale links og vejledninger, kan brugeren få adgang til disse fra det pågældende skærmbillede. - Se Krav# 230 vedrørende opsætning af links, vejledninger Visning af Sagshistorik og Udbetalingshistorik Brugeren kan under sagsbehandlingen have behov for at se forskellige typer af historik på sagen. Følgende krav er specifikke krav i forhold til at understøtte sagsbehandlerens arbejdsopgaver. Sagshistorikken skal give sagsbehandleren et samlet overblik over, hvad der er sket i sagen. Sagshistorikken skal således indeholde alt relevant i forhold til at danne sig et overblik over sagen. Typisk sorteret i kronologisk orden. Side 119 af 255

120 Krav# 171: Visning af sagshistorik Beskrivelse: Brugeren kan se et samlet overblik over, hvad der er sket i sagen via sagshistorik. - a) Brugeren kan se et samlet overblik over, hvad der er sket i sagen via sagshistorik. b) Sagshistorikken indeholder som minimum følgende oplysninger: o Registrering af oprettelse/redigering af journalnotater o Registrering af statusskift på sagen o o Registrering af statusskift på opgaver på sagen Løsningens automatiske registreringer af hændelser samt hændelsesbeskedens indhold, dog ikke hændelser hvor der er fravalgt visning af den kommunale administrator grundet lav grænseværdi o Registrering af modtagne dokumenter o Registrering af afsendte dokumenter o Alle data fra beskeder fra jobcentret Se afsnit vedrørende noter/journalnotater og automatiske registreringer af hændelser. - Se afsnit vedrørende sags og opgave status. - Se krav Krav# 203 vedrørende hændelser der ikke skal vises grundet en lav grænseværdi. - Se afsnit vedrørende beskeder fra Jobcentret. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.6 for inspiration. Krav# 172: Søgning og filtrering i sagshistorikken Beskrivelse: I sagshistorikken er det muligt at sortere, filtrere og søge. a) Brugeren kan sortere og filtrere i sagshistorikken o Der kan som minimum sorteres og filtreres på dato for oprettelse, type, sagsbehandler og hændelse. Der kan filtreres ud fra intervaller i dato for oprettelse b) Brugeren kan søge i sagshistorikken o Der kan som minimum søges på dato samt fritekstsøgning. Den endelige filtrering/sortering og søgemekaniske afklares med Leverandøren. - Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.6 for inspiration. For at understøtte brugerens arbejde skal der være et overbliksbillede, der viser udbetalinger til Personen. Dette inkluderer også udbetalinger til Personen på tværs af sager. Brugeren tilgår udbetalingshistorikken via den enkelte sag, men udbetalinger til samme Person i andre sager vises også. Krav# 173: Overblik og historik på udbetalinger i sagen (Udbetalingshistorik) Beskrivelse: Det skal være muligt for en bruger at se et overblik over alle betalinger for en Person samt dennes ægtefælle/samlever. Side 120 af 255

121 a) Brugeren kan se et overblik over alle betalinger for en Person samt dennes ægtefælle/samlever. b) Oversigten skal vise betalinger, som er til Personen selv eller til alternativ modtager. c) Samtlige udbetalinger, Personen har modtaget, vises - også på tværs af sager. d) Fra overblikket er der direkte adgang til den enkelte udbetalingsspecifikation. - Med samtlige udbetalinger Personen har modtaget, også på tværs af sager (jf. punkt C) menes, at udbetalinger fra alle sager skal vises på samme overblik. Altså også selvom udbetalingerne er fra forskellige sager (eksempelvis en kontanthjælpssag, en enkeltydelsessag) og Ydelsescentret samtidig administrerer vedkommendes økonomi. - Se Krav# 76 vedrørende udbetalingsspecifikationer. Krav# 174: Filtrering og sortering i Udbetalingshistorik Beskrivelse: Det skal være muligt at filtrere og sortere hvilke betalinger, der vises i udbetalingshistorikken a) Brugeren kan sortere og filtrere i udbetalingshistorikken. b) Der kan som minimum sorteres og filtreres ud fra sagsparter, sager, typer af udbetaling, registreringsperioder, udbetalingsperioder og status på udbetalingerne. Den endelige filtrering/sortering afklares med Leverandøren. Krav# 175: Overblik og historik på konteringer i sagen (Konteringshistorik) Beskrivelse: Det skal være muligt for en bruger at se et overblik over alle konteringer for en sag. - Dette overblik kan anvendes af brugeren eksempelvis i forbindelse med manuel omkontering. - se Krav# 87 vedrørende manuel omkontering. Krav# 176: Filtrering og sortering i Konteringshistorik Beskrivelse: Det skal være muligt at filtrere og sortere konteringer i konteringshistorikken. Der kan som minimum sorteres og filtreres ud fra kontonumre, perioder og beløb. Side 121 af 255

122 Den endelige filtrering/sortering afklares med leverandøren Visninger vedrørende administrationssager Krav til administrationssager ses i afsnit 5.3. Dette afsnit indeholder de specifikke krav til visninger hertil. Krav# 177: Overblik over administrationsordning Beskrivelse: Det skal være muligt for en bruger at se et overblik over administrationsordningen. a) Brugeren kan se et overblik over administrationsordningen med alle administrationsplaner, betalingsaftaler og udbetalingsplaner samt saldo på ordningen. b) Der er direkte adgang fra overblikket til detaljerne om de enkelte administrationsplaner, betalingsaftaler og udbetalingsplaner og tilhørende effektueringer. c) Brugeren har mulighed for at filtrere og sortere hvilke administrationsplaner, betalingsaftaler og udbetalingsplaner, der er på sagen. d) Der kan som minimum filtreres og sorteres ud fra valg af typer, perioder og status Visninger i forhold til breve og brevskabeloner Krav til breve og brevskabeloner ses i afsnit Dette afsnit indeholder de specifikke krav til visninger hertil. Krav# 178: Overblik over brevskabeloner Beskrivelse: Brugerne skal have adgang til et samlet overblik over tilgængelige brevskabeloner. - a) Brugeren har adgang til et samlet overblik over tilgængelige brevskabeloner. b) Overblikket bør som minimum indeholde kategori, art (om den er central eller lokal), dato for oprettelse/redigering og titel. c) Fra overblikket kan brugeren tilgå og benytte skabelonerne som beskrevet i Krav# 127. Se underbilag 2.10 Eksempler på skærmbilleder afsnit 2.7 for inspiration. Side 122 af 255

123 Visse handlinger foretaget i Løsningen vil altid betyde, at der skal sendes et brev. Fx skal der altid sendes et brev, når sagsbehandleren afslår en ansøgning. I disse tilfælde skal det ikke være nødvendigt for brugeren at gå til skabelon-overblikket (jf. Krav# 178). Her er der direkte link til den relevante skabelon. Så hvis sagsbehandleren under behandling af en kontanthjælpsansøgning afslår ansøgningen, skal der være direkte adgang til et kontanthjælps-afslagsbrev. Krav# 179: Direkte afgang til brevskabeloner Beskrivelse: Når brugeren træffer en afgørelse, skal der alt efter ydelsesarten og afgørelsens resultat være direkte adgang for brugeren til den relevante brevskabelon. a) Når brugeren træffer en afgørelse, skal der alt efter ydelsesarten og afgørelsens resultat være direkte adgang for brugeren til den relevante brevskabelon. b) Brugeren kan tilgå og benytte den specifikke brevskabelon som beskrevet i Krav# 127. c) Hvis der eksisterer en lokal version af brevskabelonen, skal den lokale version benyttes. Det afklares med Leverandøren hvilke brevskabeloner, der er relevante i forhold til hvilke afgørelser. - Se Krav# 129 og Krav# 224 vedrørende lokale brevskabeloner. Krav# 180: Overblik over afsendte breve Beskrivelse: Brugeren skal have adgang til et samlet overblik over de afsendte breve på sagen. a) Brugeren har adgang til et samlet overblik over de afsendte breve på den enkelte sag. b) Det fremgår, om brevet er sendt via Digital Post, om brevet er sendt via almindelig papirpost eller om brevet er udleveret til Personen personligt. c) I tilfælde af at brevet er sendt via papirpost, fremgår det, om brevet er sendt med A- eller B-post, samt om det er sendt som anbefalet eller krav om afleveringsattest. d) Der er via overblikket direkte adgang til, at brugeren kan se de afsendte breve. - Se Krav# 135 vedrørende valg af lokal print. - Se Krav# 133 vedrørende valg af A- og B-post samt anbefalede breve. 5.6 Håndter opgave vedrørende sag I det følgende afsnit listes krav relateret til arbejdsopgaver, der ligger uden for den normale sagsog opgavefordeling samt behandling af ydelsessag. Afsnittet er opdelt i følgende afsnit: Side 123 af 255

124 Intern og ekstern kontrol Kontrol for socialt bedrageri Saml sag til afsendelse Sammenhæng med økonomisystemer Kontrolkravene er tæt forbundne med kravene til 5.8, rapporter og udtræk Intern og ekstern kontrol Den interne og eksterne kontrol omfatter bl.a. ledelsestilsyn, dokumentationskontrol, kontrol af brugere med indberetningsadgang, eksterne revisors kontrol mv.. Kontrollen har bl.a. til formål at sikre/styrke fagligheden i sagsbehandlingen og herigennem sikre lovmedholdighed, samt overholdelse af standarder. Følgende kontroller er relevante at gennemføre: - Ledelsestilsyn: Kontrol af brugernes sagsbehandling, fx om den har den rette faglige kvalitet. Her vil der være en række forskellige udsøgningskriterier. - Kontrol af brugere med indberetningsadgang: Kontrol af om en bruger har udbetalt penge til sig selv, familiemedlemmer, personer på samme bopæl mv. - Revisorkontrol: Kontrol af om sagsbehandlingen er gennemført i overensstemmelse med god praksis og relevante standarder. - Øvrig kontrol: Fx kontrol af sager, hvor betalingen går til en tredjepart, fx en tandlæge eller et flyttefirma. Frekvensen for hvornår kontrollen gennemføres er ofte ad-hoc-baseret, hvorfor det både kan være flere gange dagligt såvel som med dages, ugers og måneders mellemrum. Krav# 181: Detaljering af søgninger i flere niveauer Beskrivelse: Det skal være muligt for brugeren gradvist at detaljere sin søgning. Der skal ikke være begrænsninger i antallet af niveauer, brugeren kan søge i. a) Brugeren har i et første søgningsniveau mulighed for, fx at udsøge sager i en given tidsperiode. I det næste søgningsniveau har brugeren mulighed for med afsæt i søgningsresultaterne fra det første søgningsniveau at detaljere søgningen yderligere, fx alle sager med indsendte kontoudtog. Se eventuelt eksempler på udsøgningskriterier Krav# 182 for en indikation på søgeniveauer. Krav# 182: Generelle søgekriterier relateret til udsøgning af sager Beskrivelse: Brugeren skal kunne anvende et overordnet sæt af kriterier til udsøgning af sager. - a) Brugeren kan udsøge sager på baggrund af konkrete kriterier. Eksempler på udsøgningskriterier Side 124 af 255

125 o Periode o Bruger o Alder på Person o Paragraf o Sagstype o Nyopstartede / løbende o Cpr.nr. interval o Markeret for kontrol o Osv. - Søgemulighederne vil være begrænset af, hvilke data, der findes i Løsningen. Krav# 183: Specifikke søgekriterier: Udtræk af sager til ledelsestilsyn Beskrivelse: Brugeren skal kunne udsøge sager med henblik på gennemførelse af ledelsestilsyn. Brugeren kan udsøge sager på baggrund af konkrete kriterier efter brugeren, jf. Krav# 182, har udført en generel udsøgning. - Sagerne skal, i det omfang data er registreret i Løsningen, eksempelvis kunne udtrækkes på baggrund udsøgningskriterier relateret til o Dokumentation i ansøgningsskemaet (fx foreligger der dokumentation for indestående på pensionsordning) o Opholdsbetingelser (har pågældende fx lovligt ophold i Danmark) o FKO-kontrol (er der fx undersøgt for uoplyst formue) o Ungenedsættelser (er der fx taget stilling til evt. nedsat ydelse) o Bevilling og journalføring (er der fx foretaget vurdering af ret til ydelse) o Særlig støtte (er der fx dokumentation for boligudgift, hvis relevant) o Orientering (er der fx markeret for udført orientering af personen) o Sanktioner (antal/type/periode fx fordelt på sagsbehandler) o Konteringer (fx i forhold til beløbsstørrelser) - Søgemulighederne vil være begrænset af, hvilke data, der findes i Løsningen. Krav# 184: Specifikke søgekriterier: Udtræk med henblik på kontrol af brugere med indberetningsadgang Beskrivelse: Brugeren skal kunne udsøge sager med afsæt i brugere med indberetningsadgang Brugeren kan udtrække sager, således det bliver muligt at kontrollere, om brugere har udbetalt penge til sig selv, personer på samme bopæl, familie samt 10 yderligere lignende kriterier, som anvendes efter brugeren, jf. Krav# 182, har udført en generel udsøgning. Side 125 af 255

126 - Eksempelvis skal det det være muligt at udtrække betalingsmodtagere på sager behandlet af en valgt bruger. Det skal eksempelvis også være muligt at fremsøge udbetalinger på kontonumre, som ikke er Nemkontonumre. - Søgemulighederne vil være begrænset af, hvilke data, der findes i Løsningen. Krav# 185: Øvrige kontroller Beskrivelse: Brugeren skal kunne udsøge sager med henblik på gennemførelse af en række øvrige kontroller. Brugeren kan udsøge sager på baggrund af konkrete kriterier efter brugeren, jf. Krav# 182, har udført en generel udsøgning. - Øvrige kontroller kan eksempelvis være kontrol af sager, hvor betalingen går til en tredjepart, eksempelvis en tandlæge eller et flyttefirma. Krav# 186: Kontekstbestemt kontrol Beskrivelse: Udover de i Krav# 182 til Krav# 185 nævnte kriterier, skal det være muligt at søge kontekstbestemt ud fra et særligt fokus i en kontrolindsats. Brugeren kan i tillæg til de faste kriterier søge fleksibelt på tværs af Løsningens data. - Eksempler på søgninger, der kan være relevante, er sager, hvor personer er registreret med børn, men hvor børnene potentielt er bosiddende i udlandet. Det kan dog også være alle mulige andre søgninger. Krav# 187: Markering af, at en sag er kontrolleret Beskrivelse: Det skal markeres, når en sag har været kontrolleret Brugeren kan se, når en sag har været kontrolleret, herunder for hvad og af hvilken bruger Kontrol af socialt bedrageri Kontrol relateret til socialt bedrageri starter typisk ved, at det kommunale kontrolteam gennemfører stikprøver eller udfører kontrol på baggrund konkret mistanke, fx på baggrund af henvendelse fra Personer eller på baggrund af en række kriterier der opfyldes. Enkelte kommuner anvender egne kontrolværktøjer. Side 126 af 255

127 Krav# 188: Udsøgning af sager med henblik på kontrol for socialt bedrageri Beskrivelse: Jf. Krav# 181 skal det også, for så vidt angår socialt bedrageri, være muligt at detaljere søgninger i niveauer og opsætte overordnede kriterier for udsøgning af sager (forventeligt 10 50) ligesom det også skal markeres, når en sag har været kontrolleret for socialt bedrageri. - Brugeren kan for så vidt angår socialt bedrageri - Lave detaljeret søgning i niveauer. - Opsætte overordnede kriterier for udsøgning. - Se markering, når en sag har været kontrolleret. - Se Krav# 181 for detaljerede søgninger. - Se Krav# 182 for opsætning af overordnede kriterier for udsøgning. - Se Krav# 187 for markering, når en sag har været kontrolleret Saml sag til afsendelse Samling af en sag kan være relevant ved fx en Persons begæring om aktindsigt, jf. lov om offentlighed i forvaltningen. Ved begæringen skal personen have adgang til al data, herunder dokumentation, som knytter sig til sin sag. Tilsvarende kan der være behov for, fx ved en persons flytning fra en kommune til en anden, at sende sagen til modtagende kommune. Der er i den forbindelse et behov for, at tilflytningskommunen på en let og smidig måde kan anmode om at modtage en kopi af fraflytningskommunens sag, ligesom fraflytningskommunen på en let og smidig måde kan overføre en kopi af sagen til tilflytningskommunen. Krav# 189: Saml sag og afsend Beskrivelse: En bruger skal kunne samle al sagsdata og afsende dette. a) Brugeren kan samle al sagsdata og afsende denne til en Person eller en anden kommune. Det forudsættes, at Personen har givet samtykke jf. Krav# 191. b) Brugeren skal kunne udvælge særlige dele af al sagsdata, så det ikke nødvendigvis er al data, der sendes. c) Hvis modtager er en Person, sker afsendelsen via fjernprint. - Med al sagsdata forstås dokumentation for en relevant sag, journalnotater, sagshistorik mv. - Der henvises i øvrigt til Selvbetjeningsafsnittet (5.9), hvor Person kan tilgå egen sag, og herunder bl.a. al sagsdata. - Se eventuelt krav Krav# 357 i forhold til fjernprint. Side 127 af 255

128 Krav# 190: Anmodning om overførsel af sagsoplysninger hos fraflytningskommune Beskrivelse: Brugeren skal i Løsningen kunne foretage en anmodning om digital overførelse af sagoplysninger hos Personens fraflytningskommune. - En anmodning vil oprettes som en opgave hos fraflytningskommunen. Krav# 191: Overførsel af kopi af sag pba. anmodning fra tilflytningskommune Beskrivelse: Løsningen skal understøtte, at der ved anmodning fra tilflytningskommune kan overføres en kopi af sagen. Det forudsættes, at Personen har givet samtykke. a) Brugeren kan i Løsningen, hvis der er modtaget en anmodning fra tilflytningskommunen, overføre en kopi af hele sagen eller dele af sagen til tilflytningskommunen. b) Samtykke for Personen, hvis sag skal overføres, er registeret. - Se eventuelt Krav# 190 i forhold til modtagelse af anmodning fra tilflytter kommuner samt Krav# 189 for krav relateret til afsendelse af kopi. - Overførsel vil oprettes som en opgave hos tilflytningskommunen, indeholdende de overførte sagsdata (pdf). Krav# 192: Udvælgelse af sagsdele til afsendelse Beskrivelse: Løsningen skal understøtte, at en bruger kan udvælge relevant sagsdata til overførelse. a) En bruger kan udvælge relevante sagsdata, herunder dokumentation for en relevant sag, journalnotater, sagshistorik mv. i forbindelse med samling og afsendelse af sag. - Funktionalitet kunne eksempelvis være baseret på afkrydsning af checkbokse, så brugere aktivt kan udvælge de dele, der jf. Krav# 189, skal samles. Krav# 193: Markering af sager, som har været udleveret til aktindsigt eller registerindsigt Beskrivelse: Løsningen understøtter, at en sag, der har været udleveret til aktindsigt eller registerindsigt, markeres. - a) Når en sag, herunder eventuelle sagsdokumenter, har været udleveret til i forbindelse med en aktindsigt eller en registerindsigt, så kan brugeren se det på sagen, herunder også hvornår, hvad og til hvem informationen har været udleveret. Behovet opstår, da kommunerne har mulighed for at kræve betaling, hvis Side 128 af 255

129 samme information efterspørges af samme part flere gange, fx ved gentagne aktindsigtsanmodninger, som omfatter uændret information Sammenhæng med økonomisystemer For at sikre revisionsspor og sammenhæng mellem Løsningen og det kommunale økonomisystem, skal Løsningen understøtte en række tværgående opgaver, som vedrører de økonomiske konsekvenser af de handlinger og registreringer, der foretages i løsningen. Krav# 194: Sporbarhed af økonomiske transaktioner Beskrivelse: Løsningen skal sikre, at alle konteringer foretaget i Løsningen og alle posteringer sendt til det kommunale økonomisystem, kan spores til en bestemt registrering i Løsningen. a) Såfremt en kontering er foretaget i Løsningen, kan den spores til den registrering i Løsningen, som er kilden. b) Såfremt en postering er dannet i Løsningen og sendt til det kommunale økonomisystem, kan posteringen spores til den registrering i Løsningen, som er kilden. c) Såfremt en postering er sendt til det kommunale økonomisystem fra Løsningen, og som er afledt af en registrering i Løsningen, kan posteringen i Løsningen sammenstilles med posteringerne i det kommunale økonomisystem. d) Det skal være muligt for en bruger at fremfinde relevante oplysninger i Løsningen om posteringer og de tilhørende registreringer. Der skal kunne fremfindes ud fra minimum følgende oplysninger: posterings-id, CPRnummer, ydelsestype, periode, beløb, bruger-id. Se afsnit om ØiR snitflade til udbetalings-, debitor- og økonomisystemer. Krav# 195: Kontototaler Beskrivelse: Løsningen skal for alle konti løbende vedligeholde totaler pr. konto. - a) Brugeren skal have adgang til at aflæse totalbeløb på en konto for en valgfri periode angivet af brugeren Til brug for bl.a. afstemning er der særligt behov for totaler pr. måned og år for eksempelvis ydelser, indeholdt A-skat, ATP, AMB mv. 5.7 Systemadministration I dette afsnit beskrives krav til forskellige former for konfigurationsmuligheder. Der vil både indledningsvist og i resten af Løsningens levetid være behov for at kunne foretage konfigurering af stamdata, regler, parametre, defaultværdier mv., som anvendes af Løsningen eksempelvis ved valideringer, beregninger og kontering. Side 129 af 255

130 Mange af disse oplysninger skal konfigureres på centralt niveau, så det sikres, at de gælder for alle kommuner, og at ændringer slår igennem i alle kommuner. Her er typisk tale om satser og grænseværdier, der er fastsat ved lov, og som forventes at blive ændret regelmæssigt, eksempelvis ved årlige bekendtgørelser. Disse oplysninger forventes at blive vedligeholdt samlet på vegne af alle kommuner af en central administrator-funktion, der er placeret samlet i én organisatorisk enhed. Dertil kommer en række oplysninger, som skal konfigureres på kommunalt niveau, så de gælder for brugere af Løsningen inden for den pågældende kommune. Det kan eksempelvis være sagsbehandlingsfrister, der afspejler kommunens serviceniveau eller underopdeling af den fælles kontoplan for at understøte den kommunale økonomistyring. Disse oplysninger forventes at blive vedligeholdt af en kommunal administrator, der udpeges af den enkelte kommune. De to niveauer skal generelt understøtte kommunernes forskellige praksis samtidig med, at den samlede vedligeholdelse af Løsningen lettes. Afsnittet er inddelt i grupperinger af krav, som hænger funktionelt sammen. Nedenstående Figur 4 viser, hvilke grupperinger systemadminsitrationsafsnittet er inddelt i. Tallet i boksen svarer til underafsnittet. 5.7 Generelle konfigurationer Opgaver og vedligeholdelse af sag Ydelser, regler og beregninger Brevskabeloner Journalnotater Andet Figur 45: Oversigt over afsnit i Systemadministration Derudover vil der være både centrale konfigurationskrav (som påvirker samtlige kommuner) og lokale konfigurationskrav (som kun påvirker den enkelte kommune). Disse konfigurationskrav vil have henvisninger til de funktionelle krav, hvor konfigureringen er relevant, og vil være spredt i de relevante underafsnit. Det er Kundens forventning, at når der foretages ændringer i konfigurationerne (både lokalt og centralt), så vil disse ændringer træde i kraft på virkningsdatoen uden Leverandørens indblanding (fx skal Leverandøren ikke foretage kodeændringer, der skal ikke deployes ny version af Løsningen, der skal ikke foretages nye installering osv.). Hvis en konfiguration ændres med ikrafttrædelse pr. dags dato eller tidligere, så forventer Kunden ikke at dette afspejles øjeblikkeligt for en Bruger som har en sag åben som er påvirket af ændringen. Her vil det være acceptabelt at Brugeren skal åbne sagen eller Løsningen igen for benytte den ændrede konfiguration. Det skal desuden være muligt altid at se, hvornår en konfigurationsændring er trådt i kraft. Krav# 196, Krav# 197, Krav# 198, Krav# 199, Krav# 200 og Krav# 201 er således gældende for samtlige krav i afsnit 5.7. Side 130 af 255

131 Krav# 196: Konfigurationer træder i kraft uden Leverandørens indblanding Beskrivelse: Når der foretages en konfigurationsændring, skal denne træde i kraft uden Leverandørens indblanding. Dette krav er gældende for samtlige krav i afsnit 5.7. Når der foretages en konfigurationsændring, skal det ved samtlige konfigurationskrav være muligt at sætte en virkningsperiode, således at administratoren selv kan fastsætte den dato, hvor konfigurationsændringen vil slå igennem og eventuelt stoppe. Krav# 197: Konfigurationer skal have virkningsdato Beskrivelse: Alle konfigurationsændringer skal have en virkningsperiode. Konfigurationsændringen skal slå igennem den dato, virkningsdatoen er sat til. Dette krav er gældende for samtlige krav i afsnit 5.7. Når der foretages en konfigurationsændring, skal det ved samtlige konfigurationskrav være muligt at se historikken på konfigurationsændringer. Fx skal det være muligt at se, hvornår en given sats er blevet ændret, hvornår der er blevet redigeret i en brevskabelon osv. Krav# 198: Mulighed for at se historik på konfigurationsændringer Beskrivelse: Det er muligt for administratoren at se hvilke konfigurationsændringer, der er foretaget samt deres virkningsperiode. Dette krav er gældende for samtlige krav i afsnit 5.7. Mange af de efterfølgende systemadministrationskrav er kun relevante for enten den lokale eller centrale administrator. Men i nogle krav vil de centrale og lokale konfigureringer omhandle det samme. Et eksempel er brevskabeloner, hvor der både kan eksistere centrale og lokale brevskabeloner for samme brev. Her bør det ikke være muligt for en lokal administrator at ændre eller overskrive den centrale skabelon (da de andre kommuner derved ville blive påvirket af denne ændring). Men hvis der eksisterer en lokal brevskabelon, så er det den skabelon, Løsningen skal benytte. Samme princip skal benyttes ved fx konfigurering af interne regler samt konfigurering af Ydelser. Krav# 199: Centrale kontra lokale konfigurationer Beskrivelse: I de tilfælde, hvor de centrale og lokale konfigurationer omhandler samme data, skal det være klart, hvilke konfigurationer der træder i kraft. a) De centrale konfigurationer kan aldrig ændres af lokale konfigurationer. b) Hvis der i en kommune er opsat lokale konfigurationer, skal disse have Side 131 af 255

132 forrang frem for de centrale konfigurationer. Dette krav er gældende for samtlige krav i afsnit Vær opmærksom på at det er den enkelte kommunes ansvar, at de lokale konfigurationer er lovmedholdelige. Krav# 200: Centrale konfigurationer er opsat ved idriftsættelse Beskrivelse: Alle centrale konfigurationer beskrevet i afsnit 5.7 skal være opsat ved idriftsættelse af Løsningen. Alle ydelser beskrevet i underbilag 2.15 inklusiv andre ydelser skal være opsat i Løsningen på tidspunktet for idriftsættelse af Løsningen. Dertil skal der opsættes et begrænset antal ydelsesarter af teknisk karakter. - Ydelsesarter af teknisk karakter skal bl.a. anvendes, hvis der er behov for at oprette en ydelse til at modtage pensionsindbetalinger til visse administrationsordninger. Se eventuelt afsnit om administrationssager. - De lokale konfigurationer sætter den kommunale administrator selv op i forbindelse med implementeringen af Løsningen. Krav# 201: Konfigurationer anvendes i alle funktioner Beskrivelse: Når en parameter er konfigureret, anvendes den af Løsningen i al behandling af sager, herunder ved beregning, kontering og effektuering. Dette krav er gældende for samtlige krav i afsnit Opgaver og vedligeholdelse af sag Kommunerne har forskellig praksis på en række områder. Derfor er der behov for, at den enkelte kommune kan opsætte, hvordan Løsningen skal reagere på givne hændelser. Det kan være forskelligt fra kommune til kommune, hvilke hændelser kommunen ønsker, at Løsningen skal danne en opgave ud fra. Derfor skal det være muligt for kommunen at til- og fravælge, hvilke opgaver der skal dannes. På samme måde kan det være forskelligt, om kommunen ønsker, at en hændelse skal kunne stoppe den automatiske udbetaling. Krav# 202: Konfigurering af opgaveoprettelse Beskrivelse: Den kommunale administrator kan konfigurere, hvilke hændelser Løsningen skal oprette opgaver ud fra samt, hvorvidt hændelsen skal stoppe den automatiske udbetaling. a) Den kommunale administrator kan ud fra hver hændelse konfigurere, hvorvidt der skal dannes en opgave b) Den kommunale administrator kan ud fra hver hændelse konfigurere, Side 132 af 255

133 hvorvidt hændelsen skal stoppe den automatiske udbetaling. c) Begge ovenstående punkter kan konfigureres for hver enkelt ydelsesart. d) Enkelte hændelser kan den kommunale administrator ikke fravælge opgaver på (hvilke hændelser der altid vil medføre en opgave aftales med Leverandøren). - Jf. punkt c: med konfigureren for hver enkelt ydelsesart menes, at det kan konfigureres for hver hændelse for hver ydelsesart. Eksempelvis en hændelse vedrørende børnefødsel medfører en opgave, hvis det drejer sig om en kontanthjælpssag, men ikke hvis den samme hændelse drejer sig om en revalideringssag. - I underbilag 2.13 ses hvilke hændelser der som udgangspunkt vil udløse en opgave samt stoppe den automatiske udbetaling. Krav# 203: Opsætning af grænseværdier for visning af hændelser Kategori: (K) Type: Ikke-funktionelt Beskrivelse: Bemærkning Den kommunale administrator skal for alle hændelser, der vedrører ændring af et beløb, kunne angive et minimumsbeløb for visning af hændelsen, således at hvis beløbet i hændelsen er mindre end minimumsbeløbet, så vises hændelsen ikke i Løsningen. a) Minimumsbeløbet for visning kan angives for flg. hændelser: - Start eller ændring af indkomst - Feriepenge udbetalt - Ændring i boligstøtte - Ændring i social pension - Overskydende skat Se Underbilag 2.13 Hændelsesliste. Krav# 204: Konfigurering af fordelingsnøgler Beskrivelse: Den kommunale administrator kan konfigurere, hvilke fordelingsnøgler kommunen vil fordele opgaver efter. a) Fordelingsnøglerne kan opsættes for hver enkel ydelsesart. b) Det er for hvert ydelsesart muligt at benytte flere fordelingsnøgler i kombination. c) Hvis der benyttes flere fordelingsnøgler, skal den kommunale administrator kunne vælge hvilke fordelingsnøgler, der først træder i kraft. d) Det kan opsættes, hvilke sagsbehandlere/teams de forskellige opgaver fordeles til ud fra fordelingsnøglerne Side 133 af 255

134 - Med opsættes for hver enkel ydelsesart menes, at der eksempelvis kan benyttes en fordelingsnøgle for kontanthjælp og en anden for revalideringsydelse. - Med mulighed for at benytte flere fordelingsnøgler i kombination menes, at der fx kan benyttes både områdedelt samt cpr-opdeling. - Se Krav# 19 vedrørende fordelingsnøgler. Krav# 205: Konfigurering af deadline for opgaver Beskrivelse: Den kommunale administrator kan opsætte hvilke deadlines, der er for de forskellige opgavetyper. Deadlines kan for samme opgavetype differentieres på ydelsesart. - Med differentieres på ydelsesart menes, at deadlines kan være forskellige i forhold til ydelsesarter, så det skal være muligt at opsætte deadlines i kombination af opgavetype og ydelsesart. Fx kan det tænkes, at der er forskellige deadlines for behandling af en flyttemeddelelse, hvis det drejer sig om en kontanthjælpssag i forhold til en enkeltydelsessag. - Se Krav# 11 vedrørende informationer på en opgave. Krav# 206: Vedligeholdelse af standard-opgaver Beskrivelse: Den kommunale administrator kan oprette, slette og redigere standard-opgaver som efterfølgende kan benyttes af brugeren En standard-opgave kan indeholde samme data som beskrevet i Krav# Se Krav# 13 vedrørende hvordan brugeren benytter en standardopgave. Krav# 207: Central konfigurering af interne regler Beskrivelse: I forbindelse med de interne regler beskrevet i underbilag 2.13 skal den centrale administrator kunne konfigurere en række regler og parametre. Den centrale administrator kan konfigurere relevante regler og parametre, der benyttes i forbindelse med de interne regler. Den endelige liste med hvilke regler og parametre, der kan konfigureres centralt, afklares med Leverandøren. - De relevante regler og parametre kunne fx dreje sig om: o Pensionsalder for bestemte grupper af fødselsdatoer. o Fleksydelsesalder for bestemte grupper af fødselsdatoer. Side 134 af 255

135 o Opfølgningsfrister (skal sættes op på hver enkelt ydelsesart). - Se Krav# 93 vedrørende interne regler. Krav# 208: Lokal konfigurering af interne regler Beskrivelse: I forbindelse med de interne regler beskrevet i underbilag 2.13 skal den kommunale administrator kunne konfigurere en række regler og parametre. Den kommunale administrator kan konfigurere relevante regler og parametre, der benyttes i forbindelse med de interne regler. Den endelige liste med hvilke regler og parametre, der kan konfigureres lokalt, afklares med Leverandøren. - De relevante regler og parametre kunne fx dreje sig om: o Opfølgningsfrister (skal sættes op på hver enkelt ydelsesart). o Tidsfrister i forhold til svar på partshøring og indhentning af supplerende oplysninger. - Se Krav# 93 vedrørende interne regler Ydelser, regler og beregninger Der vil både ved ibrugtagning og i den løbende drift af Løsningen være behov for at kunne oprette og ændre på stamdata og regler, særligt beregnings- og konteringsregler, for de ydelser, som Løsningen kan behandle. Det er afgørende, at disse ændringer kan foretages i god tid inden ikrafttrædelse for at sikre kontinuerlig drift eksempelvis ved årlige satsændringer eller ikrafttrædelse af nye regler (se eventuelt afsnit 6.2.4). En række ydelser, som fremgår af underbilag 2.15, skal konfigureres på centralt niveau, således at de behandles ens på tværs af alle kommuner. Det gælder særligt for forsørgelsesydelser (kontanthjælp, uddannelseshjælp, ledighedsydelse mv.), hvor Løsningen understøtter beregninger og regler baseret på lovgivningen. Det gælder også for de kendte enkeltydelser, hvor Løsningen i begrænset omfang understøtter beregninger og regler baseret på lovgivningen. Her må den konfigurering af fx konteringsregler, som er foretaget centralt, ikke kunne ændres på kommunalt niveau, men kan eventuelt suppleres med lokal underopdeling af kontoplanen. Dertil kan den enkelte kommune oprette enkeltydelser og andre ydelser, som kun anvendes lokalt, eksempelvis fordi kommunen vælger at udbetale særlige ydelser på familie- og børneområdet ved hjælp af løsningen. Her understøtter Løsningen som udgangspunkt ikke lovgivningsbestemte beregninger og regler ud over skatteberegning, hvorfor eksempelvis konteringsregler også skal opsættes lokalt. Side 135 af 255

136 Krav# 209: Central konfigurering af ydelser Beskrivelse: Det skal være muligt for en central administrator at konfigurere ydelser, som Løsningen skal håndtere, med tilhørende stamdata, parametre og regler. a) En central administrator skal i Løsningen kunne indberette de nødvendige oplysninger om stamdata, parametre og regler for alle de ydelser, som håndteres i Løsningen. b) De oplysninger, som skal kunne konfigureres centralt om en ydelse, omfatter som minimum: a. Beløbssatser og grænseværdier, omregningsfaktorer mv. på forsørgelsesydelser og enkeltydelser. b. Kalender for beregninger og udbetalinger på forsørgelsesydelser. c. Kobling til KLE. d. Beløbssatser på enkeltydelser og andre ydelser. e. Kontonumre, herunder mellemregningskonti, og konteringsregler samt betalingsarter til brug i kommunikation med debitorsystem. f. Defaultværdi for om ydelsen udbetales forud- eller bagudrettet samt for udbetalingstidspunkt/frekvens. g. Om ydelsen er skattefri, A-skattepligtig eller B-skattepligtig. h. Om der er træk af AMB på ydelsen. i. Om der er træk af ATP på ydelsen. j. Maksimalt beløb, der kan udbetales i én udbetaling. k. Defaultværdi for om udbetalinger skal godkendes manuelt eller ikke. l. Om hændelser må ændre godkendelse på effektueringsplaner under denne ydelsesart fra automatisk til manuel. m. Om der må indeholdes forskudsvis udlagt børnebidrag i ydelsen til afregning med Udbetaling Danmark. n. Om der manuelt må tilknyttes individuelle tillæg/fradrag til udbetalinger af denne ydelse. o. Om oplysningerne om ydelsesarten kan ændres på centralt og/eller kommunalt niveau. p. Kalender for beregninger og udbetalinger på enkeltydelser og andre ydelser. De endelige konfigureringsmuligheder afklares med Leverandøren. - Se Krav# 215 vedrørende kalender for beregninger og udbetalinger på forsørgelsesydelser. - Se Krav# 212 og Krav# 214 vedrørende konfigurering af konteringsregler. - Se Krav# 93 vedrørende automatiske reaktioner på hændelser. - Se Krav# 211 vedrørende konfigurering af individuelle tillæg/fradrag. - Se Krav# 215 vedrørende kalender for beregninger og udbetalinger på enkeltydelser og andre ydelser. Side 136 af 255

137 - Se Krav# 200 vedrørende leverandørens bistand til konfigurering af oplysninger for et antal eksisterende ydelser. - Se informationsmodellen (Ydelseskatalog) i underbilag 2.5. Krav# 210: Lokal konfigurering af ydelser Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere ydelser, som Løsningen skal håndtere, med tilhørende stamdata, parametre og regler. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger om stamdata, parametre og regler for alle de ydelser, som håndteres i Løsningen. b) De oplysninger, som skal kunne konfigureres lokalt om en ydelse, omfatter som minimum: a. Beløbssatser på enkeltydelser og andre ydelser. b. Kontonumre, herunder mellemregningskonti, og konteringsregler samt betalingsarter til brug i kommunikation med debitorsystem. c. Defaultværdi for om ydelsen udbetales forud- eller bagudrettet samt for udbetalingstidspunkt/frekvens. d. Om ydelsen er skattefri, A-skattepligtig eller B-skattepligtig. e. Om der er træk af AMB på ydelsen. f. Om der er træk af ATP på ydelsen. g. Maksimalt beløb, der kan udbetales i én udbetaling. h. Defaultværdi for om udbetalinger skal godkendes manuelt eller ikke. i. Om hændelser må ændre godkendelse på effektueringsplaner under denne ydelsesart fra automatisk til manuel. j. Om der må indeholdes forskudsvis udlagt børnebidrag i ydelsen til afregning med Udbetaling Danmark. k. Om der manuelt må tilknyttes individuelle tillæg/fradrag til udbetalinger af denne ydelse. l. Kalender for beregninger og udbetalinger på enkeltydelser og andre ydelser. m. Kobling til KLE (for ydelser, som kommunen selv opretter). De endelige konfigureringsmuligheder afklares med Leverandøren. - Se Krav# 212 og Krav# 214 vedrørende konfigurering af konteringsregler. - Se Krav# 93 vedrørende automatiske reaktioner på hændelser. - Se Krav# 211 vedrørende konfigurering af individuelle tillæg/fradrag. - Se Krav# 215 vedrørende kalender for beregninger og udbetalinger på enkeltydelser og andre ydelser. - Se eventuelt informationsmodellen (Ydelseskatalog) i underbilag 2.5. Side 137 af 255

138 Krav# 211: Konfigurering af typer af individuelle tillæg/fradrag Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere de tillæg og fradrag, der manuelt kan indberettes på effektueringsplaner i specifikke sager. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger om stamdata, parametre og regler for manuelle tillæg/fradrag. b) De oplysninger, som skal kunne konfigureres lokalt om en type manuelt tillæg/fradrag, omfatter som minimum: a. Navn og beskrivende tekst. b. Maksimalt beløb, der kan bevilges i én bevilling. c. Defaultbeløb. d. Om det individuelle tillæg/fradrag er et brutto-tillæg/fradrag (dvs. det indgår i skatteberegningen ved effektuering) eller et nettotillæg/fradrag (dvs. det ikke indgår i skatteberegningen ved effektuering). e. Kontonumre, herunder mellemregningskonti og betalingsarter samt konteringsregler for den enkelte type af tillæg/fradrag, som aktiveres når der knyttes et tillæg/fradrag til en bevilget ydelse i en specifik sag. f. Den eller de ydelser, hvor tillægget/fradraget kan anvendes. Løsningen skal validere, at der ikke tilknyttes brutto-tillæg/fradrag til skattefri ydelser. - Se Krav# 55 vedrørende indberetning af individuelle tillæg/fradrag. - Se Krav# 212 og Krav# 214 vedrørende konfigurering af konteringsregler. - Se informationsmodellen (KY-kontering, Ydelseskatalog) i underbilag 2.5. Krav# 212: Central konfigurering af konteringsregler Beskrivelse: Det skal være muligt for en central administrator at konfigurere regler for kontering. a) En central administrator skal i Løsningen kunne indberette de nødvendige oplysninger for ydelser og individuelle tillæg/fradrag, svarende til niveauet for kontonumre og grupperinger i Indenrigsministeriets kontoplan, herunder eventuelle oplysninger om tilbagebetalingspligt, betalingsart. b) De oplysninger, som skal kunne konfigureres på centralt niveau, omfatter som minimum: a. Grundoplysninger for ydelser og individuelle tillæg/fradrag, som matcher niveauet for kontonumre og grupperinger i Indenrigsministeriets kontoplan, herunder eventuelle oplysninger om tilbagebetalingspligt, betalingsart mv. b. Det skal være muligt at knytte kontonumre til en eller flere ydelser Side 138 af 255

139 og individuelle tillæg/fradrag. Det skal være muligt at knytte flere kontonumre kombineret med specifikke værdisæt for udvalgte typer af sagsrelaterede oplysninger. De endelige konfigureringsmuligheder afklares med Leverandøren. - Det er forskelligt fra ydelse til ydelse hvilke oplysninger, der kan påvirke konteringen. Oplysninger om eksempelvis den bevilgede ydelse, Personens alder og markering for tilbagebetalingspligt kan påvirke konteringen i en konkret sag. - Se informationsmodellen (KY-kontering, Ydelseskatalog) i underbilag 2.5. Krav# 213: Konfigurering af låsning af indkomstår Beskrivelse: Den centrale administrator kan sætte datoen for, hvornår der ikke længere kan indberettes til kontering. Datoen slår igennem, således at brugeren ikke kan indberette til kontering i det låste indkomstår. - Se Krav# 116 vedrørende stop for indberetninger til kontering i et låst indkomstår. Krav# 214: Lokal konfigurering af konteringsregler Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere regler for kontering, som supplerer de centralt konfigurerede konteringsregler. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger for at konfigurere regler for kontering, som supplerer de centralt konfigurerede konteringsregler. b) Løsningen skal ved kontering i en konkret sag benytte disse oplysninger i kombination med centralt konfigurerede konteringsregler til at finde det korrekte kontonummer ud fra konkrete værdier i sagens oplysninger. c) De oplysninger, som skal kunne konfigureres på kommunalt niveau, omfatter som minimum: a. Et eller flere SE/CVR-numre med tilhørende kontoplaner, der understøtter kobling til Indenrigsministeriets kontoplan, kommunens behov for intern opdeling af kontoplanen og indberetning til SKAT på særskilte SE-numre. b. Det skal være muligt at knytte kontonumre til en eller flere ydelsesarter og typer af individuelle tillæg/fradrag. Det skal være muligt at knytte flere kontonumre kombineret med specifikke værdisæt for udvalgte typer af sagsrelaterede oplysninger. Side 139 af 255

140 De endelige konfigureringsmuligheder afklares medlleverandøren. - Det er forskelligt fra ydelse til ydelse hvilke oplysninger, der kan påvirke konteringen på kommunalt niveau. Oplysninger om eksempelvis Personens tilhørsforhold til socialdistrikt kan påvirke konteringen i en konkret sag. - Se Krav# 212 vedrørende central konfigurering af konteringsregler. - Se informationsmodellen (KY-kontering, Ydelseskatalog) i underbilag 2.5. Krav# 215: Kalender for beregning, effektuering og udbetaling Beskrivelse: Det skal være muligt på centralt niveau og kommunalt niveau for de enkelte ydelsesarter at konfigurere, hvornår Løsningen skal foretage beregninger, effektueringer og udbetalinger. a) En central administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere kalender for beregning, effektuering og udbetaling på alle typer af ydelser. b) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere kalender for beregning, effektuering og udbetaling for administrationssager og typer af enkeltydelser og andre ydelser. c) De oplysninger, som kan indberettes, omfatter som minimum: faste intervaller, faste ugedage eller specifikke datoer for hver af de beregninger og udbetalinger, der er for ydelsestypen. d) Løsningen skal foretage beregninger, effektueringer og udbetalinger på de fastsatte tidspunkter. De endelige konfigureringsmuligheder afklares med Leverandøren. - Der kan være flere typer af beregninger og udbetalinger for en ydelsesart, fx kan der være behov for at foretage beregninger af forudbetalt og bagudbetalt kontanthjælp på forskellige tidspunkter. - Se Krav# 44 vedrørende automatisk beregning ved udbetaling Ydelsesspecifikke konfigurationer Krav# 216: Opsætning af elementer til rådighedsberegning Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere hvilke indtægter og udgifter, der som standard skal vises på rådighedsberegningen. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere hvilke typer af indtægter og udgifter, der som standard skal vises på rådighedsberegningen ved behandling af Side 140 af 255

141 - en konkret sag. b) For hvert type af beløb skal der som minimum kunne angives betegnelse, indtægt/udgift, placering i opstillingsrækkefølge. c) Det er desuden muligt at opsætte beløbsgrænse for hver enkelt type af udgift (fx max 100 kr. til telefon). Se Krav# 38 vedrørende rådighedsberegning. Krav# 217: Konfigurering af formueopgørelse Beskrivelse: Det skal være muligt for kommunal administrator at konfigurere de poster, der vises som standard ved opgørelse af formue. - a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere de poster, der vises som standard ved opgørelse af formue. b) For hvert beløb skal der som minimum kunne angives betegnelse, placering i opstillingsrækkefølge. Se Krav# 40 vedrørende formueopgørelse. Krav# 218: Opsætning af oplysninger til brug i budget ved administrationssag Beskrivelse: Det skal være muligt for en kommunal administrator at konfigurere de indtægter og udgifter, der kan anvendes i budgettet på en konkret sag. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere de indtægter og udgifter, der kan anvendes i budgettet på en konkret sag. b) For hver indtægt/udgift skal der som minimum kunne angives, om den indgår i standardopstillingen, betegnelse og placering i opstillingsrækkefølge. - Eksempler på sådanne indtægter og udgifter omfatter: Forsørgelsesydelse, Indtægter ved arbejde, Husleje, El, Telefon. - Se Krav# 105 vedrørende budget i en administrationssag. Krav# 219: Opsætning af maksimalt overtræksbeløb for administrationsordninger Beskrivelse: Det skal være muligt for en kommunal administrator at fastsætte et grænsebeløb for hvor stort et overtræk, der maksimalt kan tillades på en administrationsordning. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at fastsætte et grænsebeløb for hvor stort et overtræk, der maksimalt kan tillades på en administrationsordning. Side 141 af 255

142 - b) Defaultværdi skal være nul (0) kr. Se Krav# 106 vedrørende afgørelse eller frivillig aftale om administration. Krav# 220: Konfigurering af adgang til lokale prisaftaler Beskrivelse: Den skal være muligt for en kommunal administrator at konfigurere henvisninger til eksterne dokumenter, der indeholder lokale prisaftaler. - a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at konfigurere henvisninger til eksterne dokumenter, der indeholder lokale prisaftaler. b) Det skal være muligt at konfigurere henvisninger til et antal dokumenter og for hver ydelsesart at angive hvilket dokument, der skal henvises til. Se Krav# 41 vedrørende brug af prisaftale. Krav# 221: Konfigurering af maksimalt beløb for godtgørelse Beskrivelse: Den skal være muligt for en central administrator at konfigurere det maksimale beløb, der kan udbetales i godtgørelse ved automatisk effektuering ud fra oplysninger modtaget fra Jobcenterløsningen. - Godtgørelse efter LAB 83 er eksempler på relevante ydelser. - Se Krav# 92 om automatisk effektuering ud fra oplysninger fra Jobcenterløsnng. Krav# 222: Konfigurering til opkrævning af fleksydelsesbidrag Beskrivelse: Den skal være muligt for en kommunal administrator at foretage konfigurering, så Løsningen kan sikre opkrævning af fleksydelsesbidrag ved at kommunikere med et eksternt debitorsystem. a) En kommunal administrator skal i Løsningen kunne indberette de nødvendige oplysninger til at foretage konfigurering, så Løsningen kan sikre opkrævning af fleksydelsesbidrag ved at kommunikere med et eksternt debitorsystem. b) Oplysningerne omfatter som minimum: a. Beløbssatser og grænseværdier, omregningsfaktorer mv. b. Kalender for hvornår opkrævning foretages. c. Kobling til KLE. d. Beløbssatser. e. Kontonumre, herunder mellemregningskonti, og konteringsregler samt betalingsarter til brug i kommunikation med debitorsystem. De endelige konfigureringsmuligheder afklares med Leverandøren. Side 142 af 255

143 - Se Krav# 89 vedrørende opkrævning af fleksydelsesbidrag. - Se informationsmodellen (KY-kontering, KY-fleksydelse, Ydelseskatalog) i underbilag Brevskabeloner Krav# 223: Vedligehold af centrale brevskabeloner Beskrivelse: Den centrale administrator skal kunne oprette, slette og redigere centrale brevskabeloner i Løsningen. a) Centrale brevskabeloner kan oprettes, slettes og redigeres i Løsningen af brugere med adgang som central administrator. b) Når der sker ændringer, tilføjelser i de centrale skabeloner skal den kommunale administrator gøres opmærksom på dette. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i centrale brevskabeloner. - Se Krav# 128 om centrale brevskabeloner. Krav# 224: Vedligehold af lokale brevskabeloner Beskrivelse: Den kommunale administrator skal kunne oprette, slette og redigere lokale brevskabeloner i Løsningen. a) Lokale brevskabeloner kan oprettes, slettes og redigeres i Løsningen af brugere med adgang som kommunal administrator. b) Brugeren kan vælge om den lokale brevskabelon skal baseres på en allerede eksisterende central skabelon eller skal optræde som en helt ny skabelon uden relation til en central skabelon. c) Hvis det er en ny version af en allerede eksisterende central skabelon, skal den lokale skabelon erstatte den centrale skabelon i den pågældende kommune. Det skal dog stadig være muligt for den kommunale administrator at fremfinde den centrale brevskabelon. - Leverandøren er ikke ansvarlig for det faglige/juridiske indhold i lokale brevskabeloner. - Se Krav# 128 om centrale brevskabeloner. - Se Krav# 129 om lokale brevskabeloner. - Se Krav# 179 om direkte adgang til brevskabeloner. Krav# 225: Redigering af kommunespecifikke grundoplysninger i brevskabeloner Beskrivelse: Den kommunale administrator skal kunne redigere kommunespecifikke oplysninger, der benyttes i brevskabeloner. - De kommunespecifikke grundoplysninger vil indgå på både de centrale og lokale brevskabeloner. Side 143 af 255

144 - Se Krav# 130 om kommunespecifikke grundoplysninger. Krav# 226: Opsætning af A- og B-post Beskrivelse: Den kommunale administrator kan opsætte om breve som default, skal udsendes fra Løsningen som A- eller B-post. Når administrator har valgt A- eller B-post som defaultværdien, vil dette slå igennem, når sagsbehandleren skal sende et brev. - Se Krav# 133 om valg af forsendelsestype for breve Journalnotater Krav# 227: Frist for automatisk låsning af journalnotat Beskrivelse: Den kommunale administrator skal kunne konfigurere det antal dage, der skal gå, før Løsningen låser et journalnotat. Løsningen låser journalnotatet efter det antal dage, den lokale administrator har specificeret. - Se Krav# 140 om ændring og sletning af journalnotat. Krav# 228: Markering af låst journalnotat Beskrivelse: Den kommunale administrator skal kunne markere, at et givet låst journalnotat ikke skal fremgå af sagen. Den kommunale administrator kan fortsat fremfinde det markerede, låste journalnotat. - Journalnotater, der ikke fremgår af en Persons sag skal kunne genfindes af den kommunale administrator i tilfælde af revision. - Se Krav# 140 om ændring og sletning af journalnotat. Krav# 229: Vedligeholdelse af journalnotatsskabeloner Beskrivelse: Den kommunale administrator kan oprette, slette og vedligeholde lokale journalnotatskabeloner. a) Oprettede journalnotatsskabeloner kan vælges ved oprettelse af nye journalnotater. a) Journalnotatsskabelonen indeholder samme metadata som et journalnotat. - Se Krav# 137 om oprettelse af journalnotat. - Se Krav# 139 om indhold i journalnotat. Side 144 af 255

145 5.7.5 Andet Krav# 230: Konfigurering af links og lokale vejledninger Beskrivelse: Den kommunale administrator skal kunne opsætte links til eksterne dokumenter og websites. Ovenstående links kan opsættes kontekstafhængigt. Hvilke skærmbilleder, hvori der kan opsættes links, afklares med Leverandøren. - Eksempler på dokumenter kan for eksempel være lokale vejledninger til lovgivning og arbejdsgange. - Med kontekstafhængigt menes, at det er muligt at indsætte links, hvor brugeren har behov for det. Det vil sige, at på det skærmbillede, hvor brugeren har behov for et link til en lovsamling, der findes linket. - Se Krav# 170: Links og lokale vejledninger. Nogle adresser i kommunen bør sagsbehandleren være særlig opmærksom på i forbindelse med sagsbehandlingen (fx i forbindelse med mellemkommunal refusion). Det er et ønske, at kommunen kan vedligeholde en liste over disse adresser. Når Personen bor på en af disse adresser, skal det markeres på sagen, så sagsbehandleren bliver opmærksom på dette (jf. Krav# 169). Krav# 231: Vedligehold af særlige adresser Beskrivelse: Den kommunale administrator skal kunne vedligeholde en liste over særlige adresser i kommunen. a) Den kommunale administrator har oprettet, ændret eller slettet en adresse på listen over særlige adresser i kommunen. b) Løsningen har sikret, at kun adresser, der findes i CPR-registret, kan tilføjes listen. - Se afsnit om snitflade til CPR-registret. - Se Krav# 35 vedrørende benyttelse af alternativ adresse. - Se Krav# 169 vedrørende visning af særlige adresser. Krav# 232: Manuel slettemarkering af sager Beskrivelse: Den kommunale administrator skal kunne slettemarkere en sag, før kassationsfristen er udløbet. Ved slettemarkering har Løsningen opdateret Sags- og dokumentindeks samt Ydelsesindekset med oplysning om sletningen af sagen. - Se krav Krav# 102 for automatisk slettemarkering af sager. - Se afsnit vedrørende Sags- og dokumentindeks. - Se afsnit om afslutning og sletning af sager. Side 145 af 255

146 Krav# 233: Flytning af sagsstamme Beskrivelse: Den kommunale administrator kan flytte hele sagsstammen for en given sagsbehandler/team. - Årsagen til, man kunne ønske at flytte en sagsstamme, er fx, hvis en sagsbehandler er fraværende på grund af langtidssygdom. I dette tilfælde kan der være behov for at flytte alle medarbejderens sager til en ny medarbejder. Dette kaldes at flytte sagsstammen. - Se Krav# 98 vedrørende en brugers mulighed for at ændre den primære sagsbehandler. Krav# 234: Konfigurering af valuta Beskrivelse: Den centrale administrator skal kunne angive værdien for den valuta, der anvendes i Løsningen. Kravet skal sikre, at den centrale administrator, ved en enkel arbejdsgang, kan ændre betegnelsen kroner til euro i hele Løsningen, hvis Danmark overgår til euro. 5.8 Rapporter og udtræk Løsningen skal understøtte, at sagsbehandlere og ledere kan danne enkle, faste rapporter direkte fra Løsningen til brug for daglig opfølgning og ledelsesinformation. Denne grundfunktionalitet suppleres af muligheden for at eksportere data fra Løsningen til Serviceplatformen, hvorfra data kan tilgås af egentlige ledelsesinformationssystemer, der stiller mere omfattende rapporter og statistikmuligheder til rådighed Krav til faste rapporter Krav# 235: Krav til faste rapporter Beskrivelse: Brugeren skal kunne udtrække 20 fast definerede rapporter på grundlag af det strukturerede data, der er til rådighed i Løsningen. Leverandøren skal i Designfasen sammen med KOMBIT definere og udarbejde det eksakte indhold af de 20 rapporter. Eksempler på rapporter kunne være oversigt over udbetalinger fordelt på ydelsesarter. Se derudover eksempler på rapporter i Underbilag 2.9. Side 146 af 255

147 Krav# 236: Kontekstbestemte rapporter Beskrivelse: Rapporter skal kunne afvikles fra de skærmbilleder, hvor de typisk anvendes. Krav# 237: Præsentation og print af rapporter Beskrivelse: Rapporter skal præsenteres overskueligt, intuitivt og ensartet. Rapporter kan printes på en standardprinter i A4-format. Krav# 238: Eksport af rapporter Beskrivelse: Brugeren skal kunne eksportere rapporter på en form, som egner sig til maskinel viderebehandling og kan indlæses i markedsudbredte regnearksprogrammer. Eksportformatet kunne eksempelvis være CSV. Krav# 239: Sortering af rapportdata Beskrivelse: Brugeren kunne sortere i data, hvis det er relevant i en rapport. Eksempelvis sortering på fødselsdato, postnummer, stigende, faldende mv Krav til eksport af data Løsningen skal kunne aflevere data til eksterne modtagere til brug for kommunernes, andre myndigheders og Danmarks Statistiks arbejde med ledelsesanalyse, benchmarking og dokumentation. Krav# 240: Eksport af data til brug for ledelsesinformation Beskrivelse: Løsningen skal kunne aflevere et fuldt datasæt til Serviceplatformen. Datasættet udstilles til brug for 3. parts LIS-leverandører. Se eventuelt afsnit Ledelsesinformation via Serviceplatformen. Krav# 241: Aflever data til Danmarks Statistik Kategori: Type: Funktionelt Beskrivelse: Løsningen skal kunne aflevere et fuldt datasæt via snitfladen til Danmarks Statistik. Datasættet indeholder alle data registret i Løsningen de seneste 5 år. - Se eventuelt afsnit Danmarks Statistik. Side 147 af 255

148 Krav# 242: Aflever data til Arbejdsmarkedsstyrelsen (AMS) Kategori: Type: Funktionelt Beskrivelse: Løsningen skal aflevere AMS ydelsesdata til Arbejdsmarkedsstyrelsens statistiske datavarehus. a) Løsningen afleverer en gang månedligt et datasæt til Arbejdsmarkedsstyrelsens statistiske datavarehus, jf. den til enhver tid gældende bekendtgørelse om det fælles datagrundlag og statistiske datavarehus for beskæftigelsesindsatsen (pt. BEK nr af 23/12/2012). Data leveres for Personer omfattet af Lov om aktiv socialpolitik 13-13c, og 93 a samt Personer omfattet af Lov om aktiv socialpolitik f. Der afleveres ligeledes data for ægtefælle/samlever til en Person, hvis ægtefællen/samleveren også rammes af en sanktion på grundlag af kommunens afgørelse. b) Datasættet indeholder alle data registret i Løsningen de seneste 5 år. Se eventuelt AMS Statistiske Varehus for snitfladeinformation. 5.9 Selvbetjening Selvbetjeningsløsningen understøtter, at Digitale Ansøgere ved at tilgå en online løsning (Selvbetjeningsløsning) kan a) få information om ydelser og ansøgning om ydelser b) ansøge om ydelser og c) følge sin Ydelsessag. Det skal bemærkes, at der via Selvbetjeningsløsningen, alene kan ansøges om uddannelseshjælp, kontanthjælp, ledighedsydelse under ferie og enkeltydelse. Selvbetjeningsløsningens mål og succeskriterier er: En Digital Ansøger vil fra starten af ansøgningsprocessen få mere præcis information om, hvad der forventes i forbindelse med ansøgningen. Den Digitale Ansøger kan nemt, bekvemt og når og hvor de vil, ansøge om ydelser. Kommunen vil modtage digitale ansøgninger, som i højere grad har den rette dokumentation med den rette kvalitet. Kommunen vil opleve færre henvendelser fra Digitale Ansøgere i forbindelse med ansøgninger og løbende sager. Kommunen vil få mindre behov for at anmode Digitale Ansøgere om at fremsende supplerende oplysninger. Kommunen vil opleve mere tid til sagsbehandling grundet de færre henvendelser. Digitale Ansøgere vil opleve, at det er lettere at opnå adgang til de oplysninger, som allerede findes, og som er nødvendige for at søge om og få tildelt ydelse samt at holde sig opdateret i forbindelse med en løbende sag. Løsningens mål og succeskriterier skal indfries gennem en bedre, hurtigere, billigere og mere ensartet sagsbehandling på ydelsesområdet via: 1. Høj kvalitet i ansøgninger (for kommunen). 2. Høj kvalitet i ansøgningsprocessen (for den Digitale Ansøger) Side 148 af 255

149 3. Digital selvbetjening, der hjælper den Digitale Ansøger. 4. Lette og intuitive brugergrænseflader. 5. Genbrug af eksisterende data i ansøgnings- og sagsbehandlingsprocesserne. 6. Forhåndsvejledning, som bevirker, at den Digitale Ansøger allerede før ansøgning er påbegyndt, er oplyst om en ansøgningens mulige udfald. 7. Nemmere adgang til at finde Selvbetjeningsløsningen via søgemaskiner. Nærværende afsnit er suppleret af underbilag 2.17 og underbilag Det skal bemærkes, at der i nærværende afsnit både vil blive anvendt begreberne Person og Digital Ansøger for borgere, som overvejer at søge, er i proces med at søge eller har søgt om ydelser Krav til Selvbetjeningsløsningen I det følgende beskrives kravene til Selvbetjeningsløsningen. Figur nedenfor giver et overblik over, hvilke områder de funktionelle krav for Selvbetjeningsløsningen er inddelt i. De følgende krav er kategoriseret efter de i figuren illustrerede processer. 1. Dialog og vejledning 2. Ansøgning Fase 3. Ansøgning behandles 4. Afgørelse 5. Løbende sagsbehandling Figur 16 Den samlede arbejdsgang er opdelt i 5 delprocesser Processen Dialog og vejledning understøtter, at en Person har behov for dialog og vejledning 6 som grundlag for at vurdere muligheden for at kunne modtage en ydelse. Herunder at få viden om ansøgningsprocessen og forberede sin ansøgning. I Ansøgningsprocessen udarbejder den Digitale Ansøger en ansøgning til kommunen (jf. afsnit ). Visse Digitale Ansøgere vil springe informationsansøgningsprocessen over og gå direkte til ansøgningsprocessen. I Ansøgning og Ansøgning behandles (jf. afsnit ) behandles sagen og eventuel information eftersendes af den Digitale Ansøger. I afgørelsesprocessen (jf. afsnit ) træffer kommunen afgørelse, jf. bl.a. også afsnit (Træf afgørelse). Efter der er foretaget en afgørelse vil der, med mindre der er tale om et afslag, være en løbende sagsbehandling (jf. afsnit ). Udover de i figuren listede processer, så anføres der i afsnit en række generelle krav for Selvbetjeningsløsningen, som ikke knytter sig til specifikke områder i figuren, men er tværgående. Selvbetjeningsløsningen understøtter to aktører (Digital Ansøger og Tilknyttet Ansøger, jf. afsnit 3.5.2) Dialog og vejledning Når en Person står i den situation, at der opstår et behov for at ansøge om uddannelseshjælp, kontanthjælp, ledighedsydelse under ferie eller enkeltydelse opstår der typisk en række spørgsmål, som Personen søger svar på. Herunder spørgsmål om, hvordan man søger om fx uddannelseshjælp eller kontanthjælp, om man overhovedet er berettiget, og hvilken dokumentation, der er på- 6 Ved vejledninger forstås retskilder, herunder bekendsgørelser, cirkulærer og andre centralt fastsatte regler, der regulerer ydelsessagen. Side 149 af 255

150 krævet, når man søger. Det er derfor vigtigt, at Selvbetjeningsløsningen ikke kun håndterer selve den digitale ansøgning (jf. afsnit ), men også giver mulighed for, at Personen selv kan finde svar på relevante spørgsmål i den indledende proces forud for selve ansøgningen. Hændelse der igangsætter opgaven Startbetingelse En Person vil via Selvbetjeningsløsningen finde oplysninger om, hvad der er muligt for vedkommende under Lov om aktiv socialpolitik, hvordan Personen skal søge om en ydelse og om, hvilke oplysninger Personen skal finde frem inden en egentlig ansøgning. At Personen er inde på Selvbetjeningsløsningen uden at være logget på. Slutresultat En Person ved, hvad der skal til for at ansøge om en given ydelse. En Person har mulighed for at vælge at opgive ansøgningen eller gå videre til at påbegynde udarbejdelsen af en ansøgning. Krav# 243: Info om ansøgningsproces og krav Beskrivelse: Personen skal præsenteres grafisk for den proces, Personen skal igennem for at ansøge om og modtage ydelser, samt præsenteres for typiske dokumentationskrav. Personen præsenteres grafisk for ansøgningsprocessen. Bemærkning Personen kan tydeligt se, hvornår Personen bør være i kontakt med Ydelsescenter og Jobcenter. Det fremgår hvilke dokumentationskrav, der typisk gør sig gældende. Det fremgår hvilke muligheder der er for at uploade dokumentation. Krav# 244: Vejledning om mulighed for at modtage ydelse Beskrivelse: Personen skal kunne få vejledning om sine muligheder for at modtage ydelse inden ansøgningen påbegyndes. Bemærkning - Formålet er, allerede før ansøgning er påbegyndt, at informere de Personer, som højst sandsynligt ikke vil være berettigede til at modtage ydelser, så der ikke unødigt anvendes ressourcer på dels udarbejdelsen af ansøgningen og dels sagsbehandlingen af ansøgningen. Det kan fx være gennem korte spørgsmål, som gennem besvarelsen hurtigt giver Personen en indikation af, om det er relevant at søge, fx også gennem anvendelse af personaer (jf. underbilag 2.17). - Vejledningen skal give information om, hvilke muligheder Personen har, selvom han ikke er berettiget til ydelse. Personen skal, så vidt muligt, kunne søge tilstrækkelig vejledning til at han kan komme videre uden ydelsescentrets bistand. Side 150 af 255

151 Krav# 245: Online hjælp Beskrivelse: Leverandøren skal udarbejde online-hjælp til Selvbetjeningsløsningen. Online-hjælpen anvender, udover det i Krav# 410 anførte, visuelle og grafiske elementer. Bemærkning - Se evt. Krav# 410.Krav# Visuelle og grafiske elementer kan eksempelvis være i form af tegneseriestriber og/eller video Ansøgning Når en Person beslutter sig for at ansøge om uddannelseshjælp, kontanthjælp ledighedsydelse under ferie eller enkeltydelser, skal Personen som led i ansøgningen besvare en række spørgsmål og på baggrund af spørgsmålene bliver relevante inddateringsfelter og dokumentationskrav synlige. Alt efter hvilken ydelse, der søges om, er der specifikke krav for, hvilke oplysninger og dokumenter der skal indberettes, for at sagen kan behandles af kommunen. Det kan eksempelvis være vedhæftelse af dokumenter (dokumentationskrav) eller udfyldelse af en række felter. Personer kan også efter indsendelse af ansøgningen - uploade dokumentation. Når ansøgningen er indsendt og klar til sagsbehandling, dannes opgave til sagsbehandleren. Hændelse der igangsætter opgaven Den Digitale Ansøger ønsker at indsende en ansøgning om ydelse via Selvbetjeningsløsningen. Eksempler på Ansøgning og Dokumentationskrav fremgår af de eksisterende ansøgningsblanketter (KLE G01 Ansøgning om hjælp til forsørgelse efter Lov om aktiv socialpolitik og KLE G01 Ansøgning om enkeltydelse jf. [indhentet ]). Startbetingelse Den Digitale Ansøger er logget på med NemID (se bl.a. afsnit ). Slutresultat Sagen med eventuelle relaterede dokumenter er oprettet, og den Digitale Ansøger kan tilgå ansøgningen gennem Selvbetjeningsløsningen. Side 151 af 255

152 Krav# 246: Opret og afsend ansøgning Beskrivelse: Personen skal via Selvbetjeningsløsningen kunne oprette og afsende en ansøgning. a) Personen kan oprette og afsende ansøgning, som forud for afsendelsen er valideret for mangler og fejlindtastninger. b) Det er muligt at uploade relevant dokumentation sammen med ansøgning dog med begrænsningerne nævnt i Krav# 125. c) Al data, der kan forudfyldes, er forudfyldt ved Personens start på ansøgning. d) Det valideres løbende, at de rette dokumenter og øvrig data er uploadet/inddateret. e) På baggrund af de til enhver tid indtastede oplysninger, validerer Løsningen ud fra regler for specifikke målgrupper af Digitale Ansøgere, om der kan gives en indikation af, om Personen ikke er berettiget til en ydelse. Hvis dette er tilfældet, signaleres det til Personen, der kan vælge at fortsætte eller afbryde ansøgningsprocessen. f) Der gives vejledning om det videre forløb, herunder forventninger til sagsbehandlingen og ret og pligt for den Digitale Ansøger. Bemærkning - For krav relateret til opgavelisten henvises til afsnit Formålet med pkt. e er at give en forhåndsvejledning til bestemte målgrupper af Digitale Ansøgere, så de inden ansøgningen er afsluttet og afsendt får at vide, at de højst sandsynligt ikke vil være berettiget til uddannelseshjælp eller kontanthjælp, men at de altid har ret til at gennemføre og afsende ansøgningen. Det kan fx. være: o Studerende, der har afsluttet en uddannelse inden sommerferien og skal starte på en ny uddannelse til efteråret og dermed ikke har ret til kontanthjælp. o Unge under 25 år, som har ret til uddannelseshjælp eller kontanthjælp efter satsen som ung hjemmeboende eller ung udeboende, og dermed ikke har ret til særlig støtte til høje boligudgifter. o Personer der ikke har kontaktforløb oprettet via besked fra jobcenter eller det fælles datagrundlag. - Vejledningen skal give information om, hvilke muligheder Personen har, selvom han ikke er berettiget til ydelse. Personen skal, så vidt muligt, kunne søge tilstrækkelig vejledning til, at han kan komme videre uden ydelsescentrets bistand. Side 152 af 255

153 Krav# 247: Visuel og tekstuel navigation i ansøgningen Beskrivelse: Når Personen påbegynder ansøgningen, skal Personen præsenteres for processen med at udfylde ansøgningen. Personen skal ligeledes løbende kunne følge med i, hvor i processen Personen befinder sig. a) Personen præsenteres grafisk og tekstuelt processen forbundet med udfyldelse og afsendelse af ansøgning. b) Personen kan visuelt og tekstuelt løbende se, hvor i processen Personen befinder sig. c) Personen kan bevæge sig frem og tilbage i ansøgningen, via navigation, uden udfyldt data slettes. Bemærkning - Personen kan, forud for ansøgning, bl.a. præsenteres for de emneområder, som Personen skal igennem og godkende eller udfylde. Krav# 248: Oplysningspligt Beskrivelse: Personen skal i ansøgningen kvittere for, at man er bekendt med sin pligt til at give kommunen oplysninger om ændringer. Bemærkning - Eksempler på ændringer: Indtægter, flytning, ændring i civilstand, mv. Krav# 249: Ægtefælle-/samlevererklæring Beskrivelse: Hvis Personen har en samlever eller ægtefælle, skal den oplyste information og dokumentation om samlever/ægtefælle erklæres som værende korrekte af samlever/ægtefælle (Tilknyttet ansøger). a) Samlever/ægtefælle (Tilknyttet bruger) kan i selvbetjeningsløsningen erklære, at informationer angivet af samlever/ægtefælle er korrekte gennem anvendelse af Nem-Login. b) Samlever/ægtefælle orienteres via fremsendelse af link til Selvbetjeningsløsningen via den fjernprintløsningen. Bemærkning - For krav relateret til Nem-Login henvises bl.a. til afsnit For krav relateret til fjernprintsløsningen henvises bl.a. til afsnit Krav# 250: Samtykke i forbindelse med ansøgning Beskrivelse: Personen skal i ansøgningen, hvis denne ønsker det, kunne give samtykke til kommunens indhentelse af oplysninger. Side 153 af 255

154 Bemærkning - Oplysninger, der kan gives samtykke til indhentelse af, kan eksempelvis være fra arbejdsgiver, egen læge, tidligere bopælskommune, tilbudssted mv. Krav# 251: Kvittering for afsendt ansøgning Beskrivelse: Efter afsendelse af ansøgningen skal der udstedes kvittering, som skal kunne printes. a) Løsningen kan udstede en kvittering med relevante informationer. b) Personen kan printe kvitteringen i et på en standardprinter læsbart format. Bemærkning - Relevante informationer på kvitteringen er eksempelvis navn på den Digitale Ansøger; dato; sagstype; henvisning til ansøgningen; tidshorisont på svar; link til sagen i Selvbetjeningsløsningen, hvor bl.a. status på sagen løbende kan følges samt autosignatur fra den modtagende kommune. Krav# 252: Overblik over dokumentationskrav Beskrivelse: Selvbetjeningsløsningen skal vise, hvilke aktuelle dokumentationskrav der er til en ansøgning. Personen præsenteres visuelt og tekstuelt for dokumentationskrav til en ansøgning. Bemærkning - Den visuelle præsentation kan eksempelvis ske via ikoner. Krav# 253: Dynamisk ansøgning Beskrivelse: Selvbetjeningsløsningens ansøgningsmodul skal være dynamisk, således at konkrete inddateringsfelter og dokumentationskrav afhænger af svarene på foregående spørgsmål. Personen præsenteres kun for inddateringsfelter og dokumentationskrav, som er relevante for Personen. Bemærkning - Eksempelvis skal ikke alle Personer spørges om boligoplysninger, men alene Personer, der er omfattet af målgruppen for særlig støtte til høje boligudgifter. Side 154 af 255

155 Krav# 254: Præsentation af data fra tredjepartsløsninger Beskrivelse: Selvbetjeningsløsningen skal præsentere Personen for relevant data, som er tilgængelige i de tredjepartssystemer, Løsningen integrerer med. Personen kan altid overskrive data, som er indhentet via integrationer. Bemærkning - Hvad der er relevant data defineres af Kunden efter kontraktindgåelse. - Se eventuelt afsnit 6.4 for tredjepartsløsninger, der integreres med. Krav# 255: Min Sag før afgørelse Beskrivelse: Når en Digital Ansøger påbegynder en ansøgning, skal der automatisk oprettes en side, en slags Min Sag, i Selvbetjeningsløsningen til visning af oplysninger om sagsforløbet. Under Min Sag, skal det før afgørelsen er modtaget være muligt at tilgå ansøgningen samt øvrige oplysninger. a) Personen kan løbende tilgå en igangværende ansøgning og supplere med manglende dokumentation. b) Personen kan løbende følge status på sag, når ansøgning er afsendt. c) Personen kan ændre i stamdata (fx et tidligere oprettet telefonnummer) d) Personen kan ændre i foretagne valg (fx i forhold til at modtage SMS- og notifikationer ved nye hændelser). Bemærkning - For krav til status henvises bl.a. til krav omfattet af afsnit og for krav vedrørende nye hændelser (fx ændring i status) henvises bl.a. til Krav# 267. Krav# 256: Fuldmagt Beskrivelse: Den Digitale Ansøger skal i Selvbetjeningsløsningen kunne tilknytte Personer til hele eller dele af Selvbetjeningsløsningen, således at en anden Person gives fuldmagt til at agere på vegne af Personen. Der skal også kunne gives fuldmagt til læseadgang til informationer på Min Sag. a) En Digital Ansøger kan tilknytte andre Personer til hele eller dele af Selvbetjeningsløsningen, således de kan agere på vegne af Ansøger. b) Funktionaliteten skal baseres på Nem-Login. Bemærkning - Eksempelvis skal en Digital Ansøger kunne give fuldmagt til, at en anden Person hjælper med ansøgningen uden at fuldmagten nødvendigvis gælder hele Selvbetjeningsløsningen. Formålet er eksempelvis at understøtte de unge og socialt udsatte, der på nuværende tidspunkt får hjælp til at udfylde ansøgningen af fx forældre eller medarbejdere på væresteder for hjemløse. - For krav relateret til Nem-Login henvises bl.a. til afsnit Side 155 af 255

156 Krav# 257: Sidst udfyldte version af påbegyndt ansøgning Beskrivelse: Selvbetjeningsløsningen skal understøtte, at en Person kan have én ansøgningskladde. Bemærkning a) En Person kan gemme en ansøgning under udarbejdelse (ansøgningskladde) og efter at have logget af Selvbetjeningsløsningen, tilgå kladden og fortsætte udarbejdelsen. b) En Person har alene adgang til én kladde. Dvs., at det ikke skal være muligt at have to eller flere påbegyndte ansøgninger under Min Sag. Krav# 258: Dokumentationskrav løbende upload/upload til sidst Beskrivelse: Det skal være muligt at uploade 1) dokumentation løbende i de forskellige faser af ansøgningsprocessen og 2) vente med at uploade væsentlige dele af dokumentationen afslutningsvis i ansøgningsprocessen. a) Personen kan uploade dokumentation løbende og til sidst i ansøgningsprocessen. b) Ved ny dokumentation oprettes en opgave jf. bl.a. Krav# 16. c) Ny dokumentation knyttes til en Persons sag. Bemærkning - Det vil for flere Personer være mere hensigtsmæssigt at uploade dokumenter til sidst i processen frem for løbende. Krav# 259: Autogenereret liste over dokumentation, der mangler Beskrivelse: Når ansøgningen er udfyldt, skal Selvbetjeningsløsningen autogenerere en liste over den umiddelbart relevante dokumentation, Personen skal uploade med sin ansøgning. Bemærkning a) Personen præsenteres for en liste over dokumentation, som skal uploades. b) Personen skal kunne angive, at denne uploader dokumentation senere og modtage en tidsfrist herfor. c) Listen over dokumentation skal kunne udskrives. Eksempelvis kan der i forbindelse med den autogenerede liste laves en tidsindikation for frist for upload af dokumentationen. Side 156 af 255

157 Ansøgning behandles Når en ansøgning er afsendt, kan Personen følge sin sag på Min Sag og behøver derved ikke nødvendigvis at kontakte kommunen, for fx at høre om ansøgningen er modtaget eller lignende. Når en sagsbehandler har gennemgået ansøgningen, vil sagsbehandler notere, om der mangler relevante oplysninger eller dokumentation. Er der manglende informationer, vil det fremgå på Min Sag, ligesom det også vil fremgå, hvad tidsfristen er. Hvis Personen ikke har reageret inden for den fastsatte tidsfrist, træffes afgørelsen på det foreliggende grundlag. Personen kan altid via Min Sag supplere med manglende informationer bl.a. jf.krav# 261. Personen kan ligeledes, bl.a. jf. Krav# 267, vælge at modtage SMS- eller notifikation, når der sker nyt i sagen. Hændelse der igangsætter opgaven Startbetingelse Slutresultat Den Digitale Ansøger (eller Tilknyttet Ansøger) har afsendt en ansøgning. Den Digitale Ansøger har indsendt en ansøgning om ydelse via Selvbetjeningsløsningen. Sagen er fuldt oplyst, og sagsbehandleren har foretaget en behandling af ansøgningen og er nået til en afgørelse. Når en Kommune har modtaget en ansøgning til behandling, oplyses sagen jf. afsnit Mangler der oplysninger, så indhentes disse, jf. kravene omfattet af afsnit , og oplysninger kan indsendes via Selvbetjeningsløsningen. Når der indhentes dokumentation fra andre parter, skal alle relevante oplysninger i udgangspunktet gøres tilgængelige for Personen på Min Sag, jf Krav# Afgørelse Når der foreligger en afgørelse, jf. afsnit 5.2.3, fremgår det på Selvbetjeningsløsningen (Min Sag), hvad afgørelsen er. Hændelse der igangsætter opgaven Startbetingelse Slutresultat Sagen er behandlet af en sagsbehandler og der foreligger en afgørelse. Der foreligger en afgørelse. Den Digitale Ansøger har fået behandlet sin ansøgning og afgørelsen samt klagemuligheder er kommunikeret til den Digitale Ansøger. Krav# 260: Se afgørelse Beskrivelse: Afgørelsen skal være tilgængelig i Selvbetjeningsløsningen. Bemærkning - Se bl.a. afsnit for krav relateret til afgørelse. Side 157 af 255

158 Løbende sagsbehandling Formålet med Selvbetjeningsløsningen er bl.a. at skabe et samlet overblik over sagen for Personen, så Personen selv løbende kan give og modtage information i forbindelse med sin sag og derved opleve et reduceret behov for at kontakte kommunen. Eksempelvis kan Personen løbende indsende dokumentation (fx ægtefælle/samlevers lønseddel, egen lønseddel, ændringer i formue m.v.), løbende se hvilke ydelser der er modtaget, hvornår næste ydelse forventes udbetalt og hvilket foreløbigt beløb, det drejer sig om mv. Hændelse der igangsætter opgaven Startbetingelse Slutresultat Efter afgørelse af sagen er der behov for kommunikation mellem den Digitale Ansøger og kommunen. Der foreligger en afgørelse og Ansøgeren har fået bevilget en ydelse. Den Digitale Ansøger har overblik over sin sag og har mulighed for at supplere med information. Krav# 261: Min sag efter afgørelse Beskrivelse: Når en Digital Ansøger har modtaget en afgørelse og har en igangværende ydelsessag, skal Personen kunne tilgå og anvende Min Sag. a) Personen kan løbende følge status på sag b) Personen kan løbende uploade dokumentation. c) Personen kan se foregående og kommende udbetalinger. Det fremgår, om betalingerne er betalinger er til personen selv eller til alternativ modtager. Der er ligeledes adgang til en specifikation af udbetalingsgrundlaget. d) Personen kan ændre sin adresse og telefonnummer. e) Personen kan vælge eller fravælge at modtage SMS- og e- mailnotifikationer ved nye hændelser i sagen. f) Personen kan se tilstrækkelig information til, at de oplysninger der typisk er relevante i en aktindsigtssag, er tilgængelige via Min sag. Bemærkning - Se bl.a. krav omfattet af afsnit i forhold til pkt. a. - Se bl.a. Fejl! Henvisningskilde ikke fundet om Dokumentservice i orhold til pkt. b. - Se bl.a. Krav# 76 og Krav# 79 i forhold til pkt. c. - Se bl.a. Krav# 267 i forhold til pkt. e. Krav# 262: Adgang til historiske data Beskrivelse: En Person skal have adgang til sagshistorik. Bemærkning Ved flytning til anden kommune har Personen adgang til sagshistorik relateret til tidligere bopælskommuner. Side 158 af 255

159 Generelle krav til Selvbetjeningsløsningen Krav# 263: Min Sag for alle ansøgere Beskrivelse: Personer, der ikke tidligere har anvendt Selvbetjeningsløsningen, skal kunne tilgå og anvende Selvbetjeningsløsningen med de samme muligheder, som de Personer, der har anvendt Selvbetjeningsløsningen til eksempelvis ansøgning. Bemærkning - Eksempelvis vil Ansøgere, som ikke har afsendt ansøgning via Selvbetjeningsløsningen, kunne tilgå Min Sag og se status mv. - Se bl.a. Krav# 255 og Krav# 261 for eksempler på muligheder, som Personen har. Krav# 264: Log af selvbetjeningsløsningen Beskrivelse: En person skal kunne logge af selvbetjeningsløsningen. Bemærkning a) Løsningen lukker den igangværende brugersession og returnerer til den del af Løsningen, der ikke kræver, man er logget på. b) Personen kan herefter ikke tilgå Min Sag uden igen at logge på. Krav# 265: Vejledningsforpligtigelse Beskrivelse: Kommunen skal gennem Selvbetjeningsløsningen kunne opfylde sin pligt til at yde råd og vejledning om de muligheder, der findes for at søge om hjælp hos anden myndighed eller efter anden lovgivning. Kommunen kan i Selvbetjeningsløsningen lave kommunespecifik vejledning. Bemærkning - Vejledningen kan eksempelvis være i forhold til ændring af skattekort, ansøgning om boligstøtte, indtægtsbestemt friplads mv. Side 159 af 255

160 Krav# 266 Kommunespecifikke informationer Beskrivelse: Kommunerne skal i Selvbetjeningsløsningen kunne informere om særlige forhold gældende for kommunen. Det skal være muligt, at kommunespecifikke informationer vises situationsbestemt. Kommunen kan oprette kommunespecifikke og situationsbestemte informationer i Selvbetjeningsløsningen, som kan ses af Personer. Præcist hvor det skal være muligt at lave kommunespecifik tilpasning af information til Personen aftales nærmere mellem Leverandøren og KOMBIT, dog må det forventes, at der kan være behov for kommunespecifikke informationer i forbindelse med vejledning til forskellige målgrupper af Digitale Ansøgere. Bemærkning - Eksempelvis kontaktinformation, links og informationer om proces for ansøgning mv - Eksempelvis i forbindelse med at en Persons formue skal angives, hvor en kommune med landdistrikter eksempelvis kan være interesseret i at vejlede om, at heste skal indgå i angivelsen af personlig formue. Krav# 267: Notifikation via og SMS Beskrivelse: Personen skal kunne få besked via eller SMS fra Selvbetjeningsløsningen. a) Når der foreligger nyt i sagen på Selvbetjeningsløsningen, får Personen besked via eller SMS. b) Beskeden indeholder link til Selvbetjeningsløsningen og information om den hændelse, der har udløst Notifikationen. Notifikationen sendes via e- mail eller SMS baseret på Personens ønske angivet i Selvbetjeningsløsningen. De eksakte hændelser, der medfører en besked, afklares mellem Kunden og Leverandøren. Bemærkning - Nyt i sagen kan eksempelvis være ændringer i tidsfrister (fx i forhold til levering af dokumentation), ved møder, udbetaling af ydelser osv. (jf. bl.a. Krav# 261). - Se bl.a. krav til SMS snitflade jf. afsnit Krav# 268 Initiativpligt for Ydelsessag Beskrivelse: Selvbetjeningsløsningen skal grafisk vise, hvem der har initiativpligt i sagsforløbet. Side 160 af 255

161 Bemærkning - Sagens status kan eksempelvis anvendes som udgangspunkt for visning af initiativpligten. - Initiativpligten kan illustreres med swimlanes, så Personen får overblik over de eventuelle næste trin. Krav# 269: Videoer Beskrivelse: Det skal være muligt for KOMBIT at indlejre videosekvenser i Selvbetjeningsløsningen af sekunders varighed, som kan vises situationsbestemt. Bemærkning - Videosekvenser skal underbygge Personens forståelse af brugen af Selvbetjeningsløsningen og give eksempler på de mest benyttede sagsforløb. - Det er KOMBIT, der udvikler og leverer videosekvenserne, og som skal have mulighed for at indlejre dem. Krav# 270: Animationer Beskrivelse: Det skal være muligt for KOMBIT at indlejre små animationer i Selvbetjeningsløsningen, så de kan vises situationsbestemt. Bemærkning - Animationer kan indgå som en del af vejledningen for Selvbetjeningsløsningen, eksempelvis kan det være i forbindelse med vejledning til, hvordan man opfylder et dokumentationskrav, eller en vejledning i udfærdigelse af en ansøgning. - Det er KOMBIT, der udvikler og leverer videosekvenserne, og som skal have mulighed for at indlejre dem. Krav# 271 Mulighed for reference til tidligere uploadet dokumentation Beskrivelse: Det skal være muligt at genbruge alt tidligere uploadet dokumentation. Personen kan referere til allerede uploadet dokumentation ved ansøgning, således at denne ikke skal uploade de samme oplysninger på ny. Bemærkning - Kan eksempelvis være relevant ved en engangsansøgning. Krav# 272: Tidsstempel Beskrivelse: Informationer, der inddateres eller uploades via Selvbetjeningsløsningen, skal have et tidsstempel (dansk normal tid). Bemærkning Brugeren har adgang til et tidsstempel på alle informationer, Personer har inddateret eller uploadet i Selvbetjeningsløsningen. Side 161 af 255

162 Krav# 273: Selvbetjeningsløsning via mobile enheder Beskrivelse: Selvbetjeningsløsningen skal kunne realiseres som en webbaseret løsning til mobile enheder og skal kunne afvikles via nyere versioner af almene browsere som Mobile Safari, Android Native Browser og Windows Phone Browser. Selvbetjeningsløsningen skal via mobile enheder have den samme funktionalitet, som Selvbetjeningsløsningen har, når den tilgås via PC, og skal yderligere baseres på responsive web design. Bemærkning Krav# 274: Adgang via NemLogin på mobile enheder Beskrivelse: Ved anvendelse af mobile enheder skal kommende versioner af NemLogin anvendes. Bemærkning Krav# 275: Håndtering af lav båndbredde Beskrivelse: Leverandøren bedes i tilbuddet redegøre for hvordan Løsningens selvbetjening håndterer lav båndbredde, samt angive anbefalet minimums båndbredde for anvendelse af selvbetjeningen, hvor krav til svartider, jf. Bilag 7 Drift, kan overholdes. Bemærkning 5.10 Krav til dataudveksling Løsningen skal udveksle data med andre myndigheder og organisationer for at kunne understøtte brugernes behandling af ydelsessager. I dette afsnit beskrives en række krav til dataudveksling, der foregår på forskellige tidspunkter i sagsbehandlingsprocessen; før og under oprettelse af sag, oplysning af sag og vedligeholdelse af sagen. Kravene beskrives samlet for at bevare sammenhængen mellem krav, der vedrører samme myndighed og integrationer. Beskrivelsen af kravene til de specifikke integrationer er angivet i afsnit 6.4 under de ikkefunktionelle krav Jobcenteroplysninger Jobcentret varetager beskæftigelsesindsatsen overfor ledige borgere med henblik på at få borgeren i arbejde eller uddannelse via aktivering o.l. tiltag. Ydelseskontoret træffer afgørelse om de forsørgelsesydelser, der kan bevilges til de ledige på nær enkelte undtagelser, hvor Jobcentret kan bevilge ydelsen fx godtgørelse og fleksløntilskud. Opgavedelingen mellem de to aktører understøttes af digital udveksling af beskeder mellem aktørernes it-løsninger; Jobcenterløsningerne på den ene side og Kommuneres Ydelsessystem på den anden side. De følgende afsnit omhandler kravene til integrationen med Jobcenterløsningerne. Kravene er baseret på den eksisterende Jobcentersnitflade, som implementeres i Løsningen ved brug af Beskedfordeleren. Jobcenterløsningerne afleverer beskeder om hændelser i Jobcentret og Ydelsescentret returnerer oplysninger om bevilling af ydelse til en Person. Side 162 af 255

163 Ikke-sagshenførbare beskeder I flere tilfælde kan Løsningen have behov for at kunne modtage beskeder om en Person, selvom sagsbehandlingen i Ydelsescentret endnu ikke er begyndt, og der derfor ikke er oprettet en sag i Løsningen, som beskederne kan tilknyttes. Det skyldes, at Jobcenterløsningen sender beskeder, uanset om der oprettes en sag i Ydelsescentret eller ej. Registreringen af beskederne skal give sagsbehandleren et overblik over Jobcenterhændelser, der vedrører en given Person. Når der oprettes en sag, skal beskederne kobles til sagen og kontaktforløbsid. fra beskeden, skal gemmes på sagen. Alle beskeder fra Jobcentret vedrørende kontaktforløbsid en, kobles herefter til sagen. Krav# 276: Håndter ikke-sagshenførbare beskeder Beskrivelse: Løsningen skal kunne registre og vise beskeder fra Jobcentret, der vedrører en Person, men som ikke kan knyttes til en sag i Løsningen. a) Løsningen har gemt beskeden om kontaktforløb, aktivitet, fravær, sanktioner, visitationsgruppe og tilkendegivelse om tilbud fra Jobcentret med den angivne kontaktforløbsid. b) Brugeren kan få vist ikke-sagshenførbare beskeder for en Person i Løsningen. - Se underbilag 2.13 Hændelsesliste for yderligere information om reaktion på meddelelser fra Jobcentret. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Krav# 277: Kobling af ikke-sagshenførbare beskeder til en sag Beskrivelse: Løsningen skal kunne koble en eller flere ikke-sagshenførbare beskeder til en nyoprettet sag på Personen. a) Hvis der er oprettet en sag med samme CPR-nummer og en forsørgelsesydelse, der matcher den LAB-målgruppe, der er angivet i en ikkesagshenførbar besked, er beskeden gemt på sagen. b) Løsningen har gemt kontaktforløbsid fra beskeden på sagen. Side 163 af 255

164 c) Hvis koblingen ikke kan foretages automatisk i tilfælde, hvor brugeren opretter sagen, skal Løsningen signalere, at der findes ikke-sagshenførbare oplysninger på Personen og give mulighed for knytte dem til sagen. d) Hvis koblingen ikke kan foretages automatisk i tilfælde, hvor Løsningen opretter sagen, skal Løsningen danne en opgave til sagsbehandleren om kobling af beskeder til sagen. e) Løsningen har udført handlingen, der initieres af hændelsen, jf. hændelseslisten i underbilag Se underbilag 2.16 Mapning mellem ydelser og Jobcenter målgrupper/målgruppestatus - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. Krav# 278: Oprydning i ikke-sagshenførbare beskeder Beskrivelse: Løsningen skal kunne foretage oprydning af ikke-sagshenførbare beskeder. Hvis Løsningen modtager besked om afslutning af kontaktforløb, og der ikke er oprettet en sag i Løsningen, skal registrerede ikke-sagshenfør-bare beskeder fjernes Besked fra Jobcentret om kontaktforløb En Person, der søger om en forsørgelsesydelse i Ydelsescentret, skal have rettet henvendelse til Jobcentret, inden sagsbehandleren kan træffe en afgørelse om bevilling af en ydelse. Når Jobcentret registrerer, at Personen har et kontaktforløb med en given målgruppe, jf. Lov om en aktiv beskæftigelsesindsats, i Jobcenterløsningen, sendes der via Jobcenterløsningen en meddelelse til Løsningen. Meddelelsen anvendes primært til at etablere kommunikation mellem kontaktforløbet i Jobcentret og sagen i Ydelsescentret, så det efterfølgende er muligt at sende meddelelser om aktiviteter, godtgørelser, fravær og sanktionsindstillinger, men indholdet af meddelelsen vises også på sagen. Hvis Jobcentret ændrer kontaktforløbet på Personen, sender Jobcenterløsningen en meddelelse med ændringerne, der gemmes i Løsningen. Ændringer kan danne udgangspunkt for en eventuel genoplysning af sagen. Hvis Jobcentret ændrer målgruppen på Personen, vil dette ligeledes blive sendt som en meddelelse til Løsningen, og sagsbehandleren kan vurdere, om målgruppeskiftet medfører behov for ændring af typen på den bevilgede ydelse. Når Jobcentret afslutter et kontaktforløb, sendes der besked om ændringen, og Løsningen danner en opgave til sagsbehandleren om at ajourføre sagen. Jobcentret kan genoptage et afsluttet kontaktforløb indenfor 28 dage efter stopdatoen. Der sendes Side 164 af 255

165 besked til Løsningen om genoptagelse, hvorefter brugeren kan tage stilling til genoptagelse af sagen. Krav# 279: Modtag besked om kontaktforløb fra Jobcenterløsning Beskrivelse: Løsningen skal via Jobcentersnitfladen kunne modtage og gemme en besked fra Jobcenterløsningen om, at en Person har fået et kontaktforløb, at kontaktforløbet er ændret, genoptaget eller stoppet i Jobcentret. a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om kontaktforløbet og udført handlingen, der initieres af hændelsen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 93 om automatisk reaktion på hændelser. - Se Krav# 158 om visning af sagens oplysninger. - Se Krav# 69 om etablering af sag på grundlag af besked fra Jobcentret. - Se hændelseslisten i underbilag Se informationsmodellen KY-kontaktforløb i underbilag Besked fra Jobcentret om aktiviteter Jobcentret tilbyder Personen aktiveringstilbud i form af aktiviteter, der er knyttet til målgruppen/målgruppestatussen for Personens kontaktforløb i Jobcentret. Jobcentret informerer Ydelsescentret om, hvilke aktiviteter Personen er tilknyttet i en given periode. Aktiviteter er gældende for en bevilling og skal ligge indenfor bevillingsperioden. Aktivitet, målgruppe/målgruppestatus og bevilling er tæt koblede og har indflydelse på refusionsprocenten for de bevilgede ydelser. Udover kontering er aktiviteterne vigtige i forhold til modtagelse af beskeder om fravær og sanktionsindstillinger. Jobcentret registrerer, at en Person har en aktivitet i en given periode. Jobcenterløsningen sender besked til Ydelsescenterløsningen om aktiviteten og eventuelle ændringer til aktivitetens oplysninger, afbrydelser eller sletninger. Ændringen af aktiviteten gælder for hele den periode, som aktiviteten omfatter og påvirker beregningen og konteringen i Løsningen. Ændringerne af konteringen foregår uden sagsbehandlernes medvirken. Krav# 280: Modtag besked om aktivitet fra Jobcenterløsning Beskrivelse: Løsningen skal via Jobcentersnitfladen kunne modtage og gemme en besked fra Jobcenterløsningen om en Persons deltagelse i en aktivitet, ændring, afbrydelse eller sletning af aktiviteten. Side 165 af 255

166 a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om aktiviteten og udført handlingen, der initieres af hændelsen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se Krav# 93 om automatisk reaktion på hændelser. - Se informationsmodellen KY-kontaktforløb i underbilag Se hændelseslisten i underbilag Besked fra Jobcentret om godtgørelser Der kan udbetales godtgørelse/introduktionsudgift efter LAB 82 og 83 og Integrationslovens 23F til brug for befordringsgodtgørelse og udgifter forbundet ved deltagelse i en given aktivitet. Jobcentret bevilger godtgørelsen og informerer Ydelsescentret, som udbetaler godtgørelsen som en dag-til-dag udbetaling eller i forbindelse med udbetaling af forsørgelsesydelsen på grundlag af beskeden. Modtagelse af besked om godtgørelse og håndtering af udbetalingen skal ske uden involvering af sagsbehandleren via automatisk sagsoprettelse, effektuering og afslutning af sag. Kun i de tilfælde, hvor ydelsescentret angiver beløbet for godtgørelsen, skal sagsbehandleren orienteres via en opgave om bevilling af beløbet. Krav# 281: Modtag besked om godtgørelse fra Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en besked fra Jobcenterløsningen om oprettelse, ændring eller sletning af en godtgørelse, der er tilknyttet en aktivitet. a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om godtgørelsen og udført handlingen, der initieres af hændelsen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se Krav# 93 om automatisk reaktion på hændelser. - Se informationsmodellen KY-kontaktforløb i underbilag 2.5. Side 166 af 255

167 - Se hændelseslisten i underbilag Besked fra Jobcentret om fravær og sanktioner Jobcentret registrerer, når en Person har berettiget fravær fra sit kontaktforløb eller uberettiget fravær fra en specifik aktivitet. Jobcentret informerer Ydelsescentret om fraværet. Fraværsregistreringen skal dels påvirke konteringen af den bevilgede ydelse, og dels håndteres som en sanktionsindstilling, når fraværet er uberettiget. Jobcentret kan derudover foretage en samlet indstilling til sanktionering på baggrund af en eller flere negative hændelser, der er sket i forbindelse med Personens kontaktforløb. Et eksempel på en negativ hændelse kan være Udeblivelse fra jobsamtale. Den samlede indstilling indgives til Ydelsescentret som en sanktionsindstilling. Sanktionsindstillingen er Jobcentrets indstilling til træk i ydelsen. Den danner grundlag for, at Ydelsescentret vurderer og fastsætter trækket i den bevilgede ydelse på Personens sag. Krav# 282: Modtag besked om fravær fra Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en besked fra Jobcenterløsningen om, at en Person har haft fravær fra sit kontaktforløb eller uberettiget fravær fra en aktivitet. a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om godtgørelsen og udført handlingen, der initieres af hændelsen. c) Løsningen har sikret, at en meddelelse om uberettiget fravær fra en aktivitet har dannet en sanktionsindstilling. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se Krav# 93 om automatisk reaktion på hændelser. - Se Krav# 60 og Krav# 61 om registrering af sanktioner. - Se informationsmodellen KY-kontaktforløb i underbilag Se hændelseslisten i underbilag Krav# 283: Modtag besked om sanktionsindstilling fra Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en besked fra Jobcenterløsningen med en sanktionsindstilling eller en ændring til en sanktionsindstilling. Side 167 af 255

168 a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om sanktionsindstillingen og udført handlingen, der initieres af hændelsen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se Krav# 93 om automatisk reaktion på hændelser. - Se Krav# 60 og Krav# 61 om registrering af sanktioner. - Se informationsmodellen KY-kontaktforløb i underbilag Se hændelseslisten i underbilag Besked fra Jobcentret om visitationsgruppe Når Jobcentret visiterer en borgeren ved en samtale om borgerens kontaktforløb, afgør jobcentersagsbehandleren om borgeren er åbenlyst uddannelsesparat, uddannelsesparat, jobparat eller aktivitetsparat. Borgere, der visiteres som aktivitetsparate, har ret til et aktivitetstillæg, hvis de deltager i en aktivitet. Aktivitetstillægget udbetales af Ydelsescentret og indgår i beregningen af ydelsen. Målgruppen på et kontaktforløb afgør, hvilke borgere, der er aktivitetsparate, og hvilke der er jobparate. Der er dog en enkelt undtagelse; målgruppen Kontanthjælpsmodtagere omfattet af integrationsprogrammet, der kan være enten jobparat eller aktivitetsparat. Jobcenteret sender besked om, hvordan borgere i denne målgruppe er visiteret, og Løsningen gemmer oplysningen på sagen til brug for udbetaling af aktivitetstillæg. Krav# 284: Modtag besked om visitationsgruppe fra Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en besked fra Jobcenterløsningen om, at en Person er visiteret som Jobparat eller Aktivitetsparat. a) Løsningen har modtaget og gemt beskeden på Personens sag. b) Løsningen har registreret en hændelse om visitationsgruppen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se informationsmodellen KY-kontaktforløb i underbilag Se hændelseslisten i underbilag Side 168 af 255

169 - Mapningen mellem kontaktforløbets målgruppe og visitationsgruppe er som følger: LAB 2.2 Kontanthjælp: Jobparat LAB 2.3 Kontanthjælp: Aktivitetsparat LAB 2.4 med målgruppestatus Forrevalidend: Aktivitetsparat LAB 2.12 Uddannelseshjælp: Uddannelsesparat eller Åbenlyst uddannelsesparat LAB 2.13 Uddannelseshjælp: Aktivitetsparat Kontanthjælpsmodtagere omfattet af integrationsprogrammet: Enten Jobparat eller Aktivitetsparat Besked fra Jobcentret om tilkendegivelse om deltagelse i tilbud Når unge under 30 får et kontaktforløb i Jobcentret, skal de tilkendegive, om de ønsker at deltage i tilbud. Datoen hvorpå den unge angiver, at han vil deltage i tilbud har betydning for, hvornår der kan gives aktivitetstillæg til den unge. Krav# 285: Modtag besked om tilkendegivelse om deltagelse i tilbud fra Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne modtage og gemme en besked fra Jobcenterløsningen om, at en Person har tilkendegivet, at han ønsker at deltage i tilbud samt datoen, hvorpå tilkendegivelsen er givet. a) Løsningen har modtaget og gemt besked om tilkendegivelse eller ændring af tilkendegivelsen på Personens sag. b) Løsningen har registreret en hændelse om tilkendegivelsen. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 158 om visning af sagens oplysninger. - Se informationsmodellen KY-kontaktforløb i underbilag Se hændelseslisten i underbilag Mapningen mellem kontaktforløbets målgruppe og visitationsgruppe er som følger: LAB 2.2 Kontanthjælp: Jobparat LAB 2.3 Kontanthjælp: Aktivitetsparat LAB 2.4 med målgruppestatus Forrevalidend: Aktivitetsparat LAB 2.12 Uddannelseshjælp: Uddannelsesparat eller Åbenlyst uddannelsesparat LAB 2.13 Uddannelseshjælp: Aktivitetsparat Side 169 af 255

170 Kontanthjælpsmodtagere omfattet af integrationsprogrammet: Enten Jobparat eller Aktivitetsparat Bevillingsbesked Ydelsessagsbehandleren oplyser sagen i Løsningen og afgør, at Personen skal have bevilget en ydelse (med undtagelse af fleksløntilskud og godtgørelser). Sagsbehandleren angiver typen af ydelse og en virkningsdato, hvorpå ydelsen skal træde i kraft. Hvis Personen har et kontaktforløb i Jobcentret, skal Løsningen informere Jobcentret om den bevilgede ydelse. Jobcentret informeres ligeledes, hvis bevillingen stoppes. Sagsbehandleren kan, på baggrund af hændelser såsom sanktionering af Personen eller flytning, vurdere, at bevillingen skal stoppes. Jobcentret skal informeres om ændringen med angivelse af en stopdato for den bevilgede ydelse, da Jobcentrets opfølgningsforpligtigelse overfor Personen bortfalder ved stop af ydelsen. Krav# 286: Afsend besked om en bevilget ydelse til Jobcenterløsning Beskrivelse: Løsningen skal via snitfladen til Jobcenter kunne udstille oplysninger om en bevilget ydelse til Jobcenterløsningen. a) Løsningen overfører oplysninger om en af nedenståede bevilgede ydelser til jobcenterløsningen ved oprettelse af ydelsen og ved redigering af start- eller slutdato. Kontanthjælp (Aktivloven 11) Kontanthjælp (60 årige u. pensionsrettigheder, Aktivloven) Kontanthjælp under aktivering (Aktivloven 11) Uddannelseshjælp (Aktivloven 11) Forrevalidering (Aktivloven 47 stk. 4 og 5) Revalidering (Aktivloven 52, jf. 47 stk.3) Ressourceforløbsydelse (Aktivloven 68) Ledighedsydelse ved fleksjob (Aktivloven 74) Fleksløntilskud (Lov om en aktiv beskæftigelsesindsats 70f) Fleksydelse (Lov om fleksydelse 17) Særligt udsatte unge under 18 år (Lov om en aktiv beskæftigelsesindsats 75c) b) Løsningen overfører oplysninger om sletning af ydelse, hvis ydelsen er lukket med årsagen fejloprettet, eller hvis sagen er slettet. - Se Krav# 347 om Beskedfordeleren, der skal anvendes til distribution af hændelser mellem jobcenterløsningerne og Løsningen og Underbilag 2.6 Integrationer for information om jobcentersnitfladerne, der skal tilgås via Beskedfordeleren: Underbilag Snitfladebeskrivelse _Standardsnitflade til Jobcenter, Underbilag P11-1 Snitfladebeskrivelse_Bevillingsoplysninger til Jobcenter, Underbilag Snitfladebeskrivelse Bilag Målgruppeskift. - Se Krav# 57 om indberetning af afgørelse. - Se informationsmodellen KY-Bevilling i underbilag 2.5. Side 170 af 255

171 - Se underbilag 2.16 Mapning mellem ydelser og jobcenter målgrupper/målgruppestatus Arbejdsmarkedsstyrelsens Fælles DataGrundlag Ydelsescentret skal levere data til Arbejdsmarkedsstyrelsen om bevilling af kontanthjælp og uddannelseshjælp. Kontanthjælp og uddannelseshjælp er de eneste ydelser, som skal registreres i AMS Fælles DataGrundlag. Når der bevilges kontanthjælp eller uddannelseshjælp, ændrer AMS borgerens tilmeldingsstatus fra kontanthjælps/uddannelseshjælpsansøger til modtager. Arbejdsmarkedsstyrelsen anvender data til statistik og videreformidler oplysninger til Jobcentret, men holder også styr på til- og afmeldestatus for de borgere, der behandles i hhv. Ydelses- og Jobcentrene, og borgere, der selv tilmelder sig via Jobnet.dk Ikke-sagshenførbare beskeder I flere tilfælde kan Løsningen have behov for at kunne modtage beskeder om en Person, selvom sagsbehandlingen i Ydelsescentret endnu ikke er begyndt, og der derfor ikke er en sag, som beskederne kan tilknyttes. Det skyldes, at Det Fælles Data Grundlag (DFDG) sender beskeder, uanset om der er oprettet en sag i Ydelsescentret eller ej. Når der oprettes en sag, skal beskederne kobles til sagen. Krav# 287: Håndter ikke-sagshenførbare beskeder Beskrivelse: Løsningen skal kunne modtage og gemme beskeder fra DFDG, der vedrører en Person, men som ikke kan knyttes til en sag i Løsningen. - Se Krav# 364 om snitfladen til DFDG. - Se underbilag 2.13 Hændelsesliste for yderligere information om reaktion på meddelelser fra DFDG. Krav# 288: Kobling af ikke-sagshenførbare beskeder til en sag Beskrivelse: Løsningen skal kunne koble ikke-sagshenførbare beskeder til en sag, når der oprettes en sag med samme CPR-nummer som beskeden og kontanthjælp eller uddannelseshjælp som forsørgelsesydelse. a) Løsningen har koblet ikke-sagshenførbare beskeder til en Persons sag. b) Alle beskeder fra DFDG vedrørende Personen, der oprettes en sag på, kobles herefter til sagen. - Se Krav# 364 om snitfladen til DFDG. - Se underbilag 2.13 Hændelsesliste for yderligere information om reaktion på meddelelser fra DFDG. Krav# 289: Oprydning i ikke-sagshenførbare beskeder Beskrivelse: Løsningen skal sikre, at der sker oprydning af ikke sagshenførbare beskeder. Side 171 af 255

172 Hvis Løsningen modtager besked om afmelding af Person, og der ikke er oprettet en sag i Løsningen, skal beskeden om tilmelding og afmelding slettes. - Se Krav# 364 om snitfladen til DFDG. - Se underbilag 2.13 Hændelsesliste for yderligere information om reaktion på meddelelser fra DFDG Beskeder om til- og afmelding samt bevilling Jobcentret registrerer et kontaktforløb for en borger i Jobcenterløsningen og tilmelder borgeren som kontanthjælps- eller uddannelseshjælpsansøger. Tilmeldingen registreres i Arbejdsmarkedsstyrelsens (AMS) Fælles DataGrundlag via Jobcenterløsningen. Det Fælles DataGrundlag sender herefter besked til Ydelsescentret om, at borgeren er tilmeldt som ansøger. Løsningen gemmer beskeden, men afventer en ansøgning om kontanthjælp/uddannelseshjælp fra borgeren, før der oprettes en sag. Når sagen oprettes, kobles beskeden fra DFDG til sagen, så der efterfølgende kan kommunikeres med DFDG om bevillingen på sagen. Der modtages beskeder fra Det Fælles DataGrundlag og Jobcenterløsningerne, som har næsten identisk indhold, idet til- og afmelding fra Det Fælles DataGrundlag svarer til Kontaktforløb oprettet og afsluttet fra Jobcenterløsningerne. Løsningen skal gemme beskederne for at sikre, at der efterfølgende kan udveksles oplysninger mellem Løsningen og hhv. DFDG og Jobcenterløsningerne, men ikke alle beskeder danner opgaver til sagsbehandleren. Som udgangspunkt skal beskederne fra Jobcentret påvirke sagsbehandlingen i Løsningen ved dannelse af opgaver, mens beskederne fra AMS blot registreres i sagshistorikken på borgerens sag. Når ydelsessagsbehandleren træffer afgørelse om, hvorvidt borgeren er berettiget til ydelse, skal Løsningen sende besked til DFDG. Hvis borgeren ikke er berettiget til ydelse, afmelder DFDG borgeren. Hvis Ydelsescentret ikke har truffet en afgørelse pt. senest 15 dage efter modtagelsen af tilmeldingen, så registreres borgeren som tilmeldt uden ydelse og afmeldes som ansøger, hvis der ikke sker yderligere i sagen. Ved afmeldingen skal borgerens kontaktforløb i jobcenterløsningen afsluttes. For igen at være berettiget til kontant- eller uddannelseshjælp skal borgeren henvende sig i Jobcentret, der skal oprette et nyt kontaktforløb eller genoptage det tidligere. Løsningen gemmer beskeden om afmeldingen, da afmeldings og gentilmeldingsdato kan danne grundlag for sagsbehandlerens vurdering af en senere sanktionsindstilling fra Jobcentret. Krav# 290: Modtag besked fra DFDG om tilmelding eller afmelding af Person Beskrivelse: Løsningen skal via snitfladen til Det fælles Datagrundlag kunne modtage og gemme besked om, at en Person er tilmeldt eller afmeldt Jobcentret. a) Løsningen har modtaget og gemt beskeden. b) Løsningen har registreret en hændelse om til- eller afmelding og udført handlingen, der initieres af hændelsen. - Se Krav# 364 om snitfladen til DFDG. - Se krav Krav# 93 om automatisk reaktion på hændelser. - Se informationsmodellen (KY-Person) i underbilag 2.5). - Se underbilag 2.13 Hændelsesliste for yderligere information om reaktion på Side 172 af 255

173 meddelelser fra DFDG. Krav# 291: Afsend besked om afgørelse om bevilling til DFDG Beskrivelse: Løsningen skal via snitfladen til Det fælles Datagrundlag kunne afsende meddelelse til DFDG om udfaldet af en afgørelse om ansøgning om kontanthjælp eller uddannelseshjælp. - Se Krav# 364 om snitfladen til DFDG. - Se Krav# 57 om indberetning af afgørelse. - Se informationsmodellen (KY-Person) i underbilag 2.5) Social pension Udbetaling Danmark varetager udmåling og udbetaling af en Persons sociale pension, mens Løsningen håndterer udbetalinger i forbindelse med helbredstillæg, udvidede helbredstillæg og personlige tillæg. Krav# 292: Modtag besked om ændringer fra KMD Social Pension Kategori: (K) Type: Ikke funktionelt Beskrivelse: Løsningen skal via snitfladen til KMD Social Pension kunne modtage og gemme besked om likvid formue, samliv, personlig helbredsprocent eller personlig tillægsprocent samt efterfølgende ændringer hertil. a) Løsningen har gemt beskeden. b) Løsningen har registreret en hændelse om social pension og udført handlingen, der initieres af hændelsen. - Se Krav# 371 om snitflade til KMD Social Pension. - Se Krav# 56 om beregning af helbredstillæg og udvidet helbredstillæg. - Se Krav# 93 om automatisk reaktion på hændelser. - Se hændelseslisten i underbilag Forskudsvist udlagt børnebidrag Udbetaling Danmark (UDK) lægger ud for forskudsvist udbetalt børnebidrag på vegne af personer, der modtager kontanthjælp, uddannelseshjælp eller revalideringsydelse jf. Lov om aktiv Socialpolitik LAS 23 stk. 3, 25 stk. 4, 52 stk. 3 og 96a. Det forskudsudlagte beløb skal tilbageholdes i personens ydelse og returneres til UDK, når personen er partshørt, og ydelsescentret har truffet afgørelse om tilbageholdelsen. Det kan ikke udelukkes, at Løsningen på sigt også skal håndtere fradrag i ressourceforløbsydelse. KL, KOMBIT og UDK arbejder med specificeringen af en ny snitflade, der kan understøtte hele processen omkring det forskudsvist udlagte børnebidrag i modsætning til den eksisterende snitflade mellem KMD Aktiv og OPUS Debitor, som suppleres af en manuel work around, hvor kommunerne sender s til UDK om bestanden af personer, der modtager uddannelseshjælp eller kontanthjælp. Nedenfor stilles de forretningsmæssige krav, som Løsningen skal understøtte via implementeringen af den nye snitflade til UDKs it-løsninger. UDK sender anmodninger om fradrag for den samlede bestand af UDKs sager vedrørende forskudsvist udlagt børnebidrag. Anmodningen angiver det beløb, der skal fradrages i Personens ydelse pr. måned. Hvis ydelsescentret i kommunen træffer afgørelse med accept af fradraget, be- Side 173 af 255

174 tragtes anmodningen som en løbende anmodning, og UDK skal ikke anmode om fradrag for det samme barn igen næste måned, men skal opdatere anmodningen med ændringer til beløb eller slutdato for fradrag, hvis der sker ændringer i UDK-sagen. KY sender svar til UDK, når anmodningen er behandlet. Svaret informerer om, hvorvidt det anmodede fradrag forventes effektueret ved udbetaling af månedens ydelse. Når udbetalingen effektueres i KY, sender KY et svar med angivelse af, om der reelt er fradraget et beløb, og hvor meget, der er trukket. UDK opgave og ansvar - UDK sender én anmodning om fradrag i ydelsen pr. barn, som en borger er bidragspligtig for, pr. måned. - Anmodningen indeholder beløbet, der skal fradrages i den pågældende måned, nemlig det beløb, som er forfaldent til betaling i den måned, og forskudsvis udlagt af UDK. Det er UDK, der ved, hvilket beløb, der er relevant at fradrage på hvilket som helst tidspunkt i sagsforløbet. - UDK sender ændringer i til en anmodning. En ændring kan fx dreje sig om beløbet. - UDK sender besked om stop af en anmodning. - For anmodninger, som KY har afvist, fremsender UDK fornyede anmodninger den kommende måned. - UDK håndterer satsændring ved årsskiftet på alle anmodninger. KY opgave og ansvar - Løsningen sikrer, at en anmodning behandles i forhold til de objektive kriterier for fradrag, og at der sker partshøring af borgeren, før der træffes afgørelse om første fradrag i ydelsen samt ved fornyede oplysninger, der kræver partshøring. - Løsningen foretager fradraget i ydelsen på grundlag af den månedlige anmodning eller modtagne ændringer af anmodningen samt kontrol imod de objektive kriterier for fradrag. - Løsningen sender svar til UDK om afgørelser (ja/nej til fradrag i ydelsen - informationsstrømmen) - Løsningen sender svar til UDK om det reelle fradrag, der er sket i ydelsen på udbetalingstidspunktet (pengestrømmen) - Løsningen sikrer overførsel af det samlede beløb, der fradrages for en måned, overføres til UDK. - Løsningen foretager ingen former for beregning. Initiering For at igangsætte udvekslingen af oplysninger mellem KY og UDK, skal UDK ved idriftsættelsen af KY i en given kommune sende samtlige anmodninger om træk i ydelsen. Anmodningerne sendes på grundlag af de UDK-sager, der er registreret i UDKs systemportefølje. Fremsendelsen af samtlige anmodninger skal kun ske én gang pr. idriftsat kommune. KY modtager den samlede mængde af anmodninger for en kommune ad gangen i takt med idriftsættelsen. Anmodning og svar på anmodning UDK sender anmodning om fradrag i ydelse enten en gang om måneden ved månedsstart eller løbende henover måneden. Anmodningen omfatter fradrag af et beløb pr. måned pr. barn. Når KY modtager en anmodning, validerer Løsningen, om der findes en kontant/uddannelseshjælps/revalideringssag, hvori der lovligt kan fradrages et beløb, på det CPRnummer, anmodningen vedrører. Hvis dette ikke er tilfældet sendes svar til UDK om nej til træk i ydelsen med begrundelsen Ingen sag. Side 174 af 255

175 Hvis der findes en sag, hvor der kan ske fradrag efter LAS 96a, validerer KY, om de objektive kriterier for træk i ydelsen er til stede. Hvis dette ikke er tilfældet sendes svar til UDK om nej til træk i ydelsen med begrundelsen objektive kriterier ikke opfyldt. Hvis sagen opfylder de objektive kriterier, validerer KY, om der er truffet afgørelse om træk i ydelsen. Afgørelsen træffes, når borgeren er partshørt. Hvis der er truffet afgørelse med svaret ja, sendes der besked til UDK med angivelse af Ja til træk i ydelsen. Svaret ja sendes kun i forbindelse med at afgørelsen træffes og er gældende, indtil nye oplysninger ændrer afgørelsen, der ikke længere findes en sag, eller de objektive kriterier ikke opfyldes. Hvis der er truffet afgørelse med afslag på anmodning, sendes der besked til UDK med angivelse af nej til fradrag i ydelsen. KY sender svar på alle nye anmodninger om ja/nej til fradrag i ydelsen. For de anmodninger, hvor der er truffet afgørelse om accept af fradrag i ydelsen sendes månedsvist svar på, hvad der reelt er fradraget i ydelsen. Krav# 293: Modtag anmodning om fradrag i ydelsen ved forskudsvis udlagt børnebidrag Beskrivelse: Løsningen skal kunne modtage og gemme anmodning og ændringer til anmodninger om fradrag af børnebidrag i uddannelseshjælp, kontanthjælp eller revalideringsydelse for indeværende måned for en given sag via en snitflade til Udbetaling Danmark (UDK) a) Løsningen har gemt anmodningen eller ændringen til anmodningen. b) Anmodningen indeholder som minimum flg. oplysninger: - CPR-nummer på bidragsbetaler - CPR-nummer på det barn, bidraget vedrører - Startdato for bidrag - Slutdato for bidrag - Beløb (beløbet, der skal fradrages i ydelsen pr. måned) c) Løsningen har registreret en hændelse om anmodningen. d) Hvis der ikke er udført partshøring, har Løsningen dannet og udsendt partshøringsbrev til Personen. e) Hvis der ikke er registret en afgørelse på sagen, har Løsningen dannet en opgave til sagsbehandleren om at træffe afgørelse. f) Løsningen har valideret anmodningen mod de de objektive kriterier for fradrag og afsendt svar på behandlingen af anmodningen med flg. oplysninger: - CPR-nummer på bidragsbetaler - CPR-nummer på det barn, bidraget vedrører - Svar med værdierne Ja eller Nej og en af årsagerne: Ingen sag/objektive kriterier ikke opfyldt/anmodning afslået. g) Hvis der er registreret en afgørelse på sagen med accept af tilbageholdelse i uddannelseshjælpen eller kontanthjælpen, sikrer Løsningen at fradraget foretages i ydelsen på udbetalingstidspunktet - Se Krav# 372 om snitflade til UDK - Se Krav# 93 om automatisk reaktion på hændelser Side 175 af 255

176 - Se Krav# 53 om fradrag for forskudsvis udlagt børnebidrag - Se hændelseslisten i underbilag Se informationsmodellen KY-anmodning i underbilag De objektive kriterier, der anvendes til at beslutte, om der skal fradrages i ydelsen er: Den bidragspligtige persons ydelse er omfattet af Lov om Aktiv Socialpolitik 96a eller 23, stk. 3 (uddannelseshjælp), 25, stk. 4 (kontanthjælp) eller 52, stk. 3 (revalideringsydelse) Antallet af udeboende børn overstiger 2 ved LAS 96a Antallet af hjemmeboende børn > 0 ved LAS 96a Der opstår eller afsluttes en fogedsag ved LAS 96a, stk. 3 Krav# 294: Registrer afgørelse om tilbageholdelse af forskudsvis udlagt børnebidrag i ydelse Beskrivelse: Løsningen skal sikre, at sagsbehandleren kan træffe afgørelse om tilbageholdelse af forskudsvis udlagt børnebidrag i en given sag på grundlag af anmodningen fra Udbetaling Danmark. a) Afgørelsen kan kun foretages, hvis der er foretaget partshøring om fradrag i ydelsen. b) Afgørelsens udfald (Accept/Afvisning) er gemt på sagen. c) Afgørelsen kan opdateres indenfor de eventuelle tidsfrister, der sættes af udbetalingsløsningen. d) Løsningen har registreret en hændelse om afgørelsen. - Se Krav# 293 om anmodning om tilbageholdelse af forskudsvist udlagt børnebidrag. - Se afsnit om snitflade til økonomisystem. - Se Krav# 93 om automatisk reaktion på hændelser. - Se hændelseslisten i underbilag Krav# 295: Afsend svar om beløb, der er fradraget ved ydelsesudbetalingen Beskrivelse: Løsningen skal kunne afsende svar til UDK om, hvilket beløb, der er fratrukket i ydelsen på udbetalingstidspunktet via en snitflade til Udbetaling Danmark. - a) Løsningen har sendt svar om fradrag i ydelsen med angivelse af flg. oplysninger: - Anmodningsidentifikation for den anmodning, der fradrages for. - Afregningsidentifikator - Personnummer på bidragsbetaler - Beløb, der er fradraget i ydelsen b) Løsningen kan sende svar, om at det ønskede beløb ikke kan tilbageholdes i ydelsen, fordi beløbet er større end ydelsen. c) Løsningen har registreret en hændelse om det afsendte svar. Svaret Ja angiver, at der kan tilbageholdes forskudsvist udlagt børnebidrag i ydelsen. Svaret Nej angiver, at der ikke kan tilbageholdes forskudsvist udlagt børnebidrag i ydelsen. Side 176 af 255

177 - Se Krav# 372 om snitflade til UDK - Se evt. Krav# 294 om afgørelse om forskudsvist udlagt børnebidrag - Se hændelseslisten i underbilag Krav# 296: Overfør fradrag for forskudsvis udlagt børnebidrag Beskrivelse: Løsningen skal via snitflade til økonomisystem kunne overføre det samlede beløb, der fradrages for en måned til UDK pr. kommune. - a) Løsningen har afleveret oplysninger om det samlede beløb, der er blevet fradraget i en måned til økonomisystemet, hvorfra overførsel af beløbet til UDK håndteres. b) Oplysninger om det samlede beløb indeholder identifikation af kommunen, der afsender beløbet, cpr-numre på bidragspligtige, anmodningsidentifikation, afregningsidentifikator og beløb pr. anmodning. Se afsnit om ØiR snitflade til økonomisystem Feriepenge ATP modtager feriepenge fra arbejdsgivere, som er med i FerieKonto og udbetaler feriepenge til de omfattede personer via NemKonto. Når en person, der har en sag i Løsningen, får udbetalt feriepenge, skal ydelsen tilpasses. Der er derfor behov for at informere sagsbehandleren, når udbetalingen sker. Brugerne har endvidere behov for at kunne indhente oplysninger om borgerens feriepenge efter behov. Krav# 297: Modtag besked om udbetaling af feriepenge Kategori: (K) Type: Ikke funktionelt Beskrivelse: Løsningen skal via snitfladen FerieKonto kunne modtage en besked, når en Person får udbetalt feriepenge. a) Løsningen har modtaget og gemt en besked om udbetaling af feriepenge med flg. oplysninger: Beløb til udbetaling Udbetalingsdato Antal dage, der er udbetalt feriepenge for Dato for første feriedag Saldo feriepenge Saldo feriedage b) Løsningen har registreret en hændelse om udbetalingen og udført handlingen, der initieres af hændelsen. - Se Krav# 370 om snitflade til Feriekonto. - Se Krav# 93 om automatisk reaktion på hændelser. - Se hændelseslisten i underbilag Side 177 af 255

178 6 Ikke-funktionelle krav For at et it-system kan levere den service, brugeren har behov for, er det nødvendigt at stille en række forskellige tekniske krav. Denne type krav kaldes ikke-funktionelle, idet de ikke direkte relaterer sig til brugerens forretningsmæssige behov, men derimod beskæftiger sig med systemets servicemæssige kvalitet. De ikke-funktionelle krav er således til stede for at understøtte de funktionelle krav i kapitel 5 og koblingen hertil sker bla. gennem målarkitekturen, som beskrevet i kapitel 6.2. Kravene falder i kategorier som sikkerhed, tilgængelighed, brugervenlighed, etc. og de for Løsningen relevante ikke-funktionelle krav findes i dette afsnit. 6.1 Offentlige strategier og generelle arkitekturprincipper Som central spiller på det kommunale område tager Kunden til enhver tid udgangspunkt i de fællesoffentligt vedtagne initiativer, principper og strategier. Disse vil være retningsgivende og beskriver kontekst og rammebetingelser for den konkrete Løsning, og i denne sammenhæng er Kommunernes Arkitekturråds godkendte fælleskommunale arkitekturprincipper (marts 2013) relevante. Krav# 298 Arkitekturprincipper Kategori: (K) Type: Ikke funktionelt Beskrivelse: Løsningen skal udvikles efter de fælleskommunale arkitekturprincipper (se [indhentet ] Kommunernes Ydelsessystem (KY) er baseret på De Fælleskommunale Arkitekturprincipper og er i høj grad bygget op omkring Den Fælleskommunale Rammearkitektur. Løsningen anvender i udpræget grad Fælles forretningsservices fra Rammearkitekturen, frem for at udvikle egne services. Herudover har De Fælleskommunale Arkitekturprincipper præget udformningen af krav til KYs løsningsarkitektur. Nedenstående liste beskriver, hvilken indflydelse de enkelte principper har haft på løsningens arkitektur. A. Principper vedrørende it-styring og strategi A1. Der arbejdes mod en fælles rammearkitektur KY realiseres igennem udpræget brug af Den Fælleskommunale Rammearkitektur. Fra Rammearkitekturen anvendes Fælles Forretningsservices og Løsningen benytter de Fælleskommunale Arkitekturprincipper i realiseringen af de fem overordnede mål fremsat af Den Fælleskommunale Digitaliseringsstrategi, samt de seks kommunalt fremsatte behov til digitalisering [RA], [RA-PRINCIP], [DIGI-STRAT]. A2. Undgå leverandør- lock-in KY har separate drifts- og udviklingskontrakter, der er med til at sikre maksimal kontinuitet i overgangsfaser. Derudover er der (jfr. Arkitekturprincip C1, C2 og C3) sikret det tekniske gundlag for at data kan eksportes fra- og importeres til Løsningen. Side 178 af 255

179 A3 It-sikkerhed tænkes ind i løsninger fra starten KY anvender Rammearkitekturens Adgangsstyring, så autentifikation og autorisation følger den fælles model for både brugere via Løsningens brugergrænseflade og eksterne it-systemer via Løsningens tekniske snitflader. B. Principper vedrørende forretning og information B1. Forretningsservices genbruges på tværs af it-løsninger KY anvender flere af Rammearkitekturens Fælles Forretningsservices, samt flere af Rammearkitekturens fysiske services (se Forretningsservices og Fysiske services nedenfor). KY udstiller egne forretningsservice igennem en række snitflader (se Fysiske services (egenudviklede) nedenfor). B2: Opgavevaretagelsen er dokumenteret på tværs af forretningsdomæner KY har forretningsmæssige snitflader til processer i relaterede domæner hos landets Jobcentre, samt UDK, hvor bl.a. borgerens ansøgning omkring forskudsvist udlagt børnebidrag igangsættes. B3: Brugere indrages aktivt i behovsafklaring og udviklingsforløb KY har igennem hele processen med kravspecificering gjort brug af en arbejdsgruppe af kommunale sagsbehandlere og fageksperter, og der vil forsat blive gjort brug af den i igennem udviklingsforløbet. Konkret udføres en række (delleverance) prøver, herunder Brugeraccepttest. B4: It-løsninger udfordrer eksisterende regler og arbejdsgange KY har påvirket eksisterende regler og arbejdsgange primært på to områder. Samarbejdet mellem KYs forretnings- og informationsarkitekter og kommunernes fageksperter har vist punkter i lovgivningen, som med fordel kan tilpasses. Derudover har arbejdet med arbejdsgruppen, specielt med det store fokus på KYs Selvbetjening (og kommende arbejdsprocesser omkring denne), udfordret, hvordan Ydelsescentrene i dag varetager behandling af ydelsessager. Introduktionen af KYs Selvbetjening, samt den store fokus på automatisk indhentning af data i KY, vil give anledning til væsentlig forbedring og optimering af arbejdsgange i kommunerne. Ydermere gives der igennem disse initiativer en bedre oplevelse af forløbet for borgeren, igennem bedre information, mere vejledning, hurtigere sagsbehandling mv. B5: Der anvendes altid vedtagne begreber KYs begrebsmodel baserer sig på fælles standarder og indarbejder begreber fra OIO Sag og Dokument standarderne, samt fra forretningsdomænet Kommunale Ydelser. B6: Der er defineret entydigt ejerskab af forretningsservices KY har udarbejdet en begrebs- og informationsmodel. Derudover er KY entydigt ejer af den forretningsservice, som KY tilbyder. Forretningsservicen tilbydes konkret igennem en række fysisk realiserede snitflader. Snitfladerne anvendes af it-løsninger, der anvender KYs forretningsservice, eksempelvis den største (forventet) aftager af KY forretningsservice den til KY hørende borgervendte selvbetjening (herunder eksterne tredjeparts selvbetjeninger). Et andet konkret eksempel er SAPA, der giver et overblik om bl.a. ydelsessager for en borger. KY udstiller de fornødne snitflader for at KY Selvbetjeningen som forretningsservice kan aftage KYs forretningsservice. Se Fysiske Services (egenudviklede) nedenfor, for en liste af konkrete snitflader. B7: Forretningshændelser meddeles omverdenen KY anvender i så høj grad, det er muligt, Beskedfordeleren til at modtage, såvel som afsende Beskeder. Ved relevante tilstandsskift på sagsbehandlingsprocessen, afsendes en Besked via Beskedfordeleren, sådan at andre forretningssystemer kan konsumere disse. B8: Fælles autoritative reference- og grunddata anvendes Side 179 af 255

180 Løsningen benytter centrale grunddata, der trækkes indirekte gennem Serviceplatformen, for at opnå målet om minimering af genindtastning af data. Ligeledes er brugen af referencedata, specifikt KLE, tænkt ind som en fundamental del af Løsningen til at opnå sagsbehandlernes ønsker om en højere grad af automatisering igennem fx automatisk opgavefordeling. B9: Forandringsrobust arkitektur Som direkte følge af dette arkitekturprincip er det tydeligt kravsat, at der i Løsningsarkitekturen skal fokuseres på indkapsling af data og services, således at der opnås en høj grad af forandringsparathed (modifiability) i Løsningen, specielt med henblik på lovændringer. C. Principper vedrørende applikationer og teknologi C1: Data udstilles via åbne snitflader og kan genbruges Dette arkitekturprincip påvirker it-løsningen fra to sider; dels bevirker det, at Løsningen udstiller sine egenudviklede fysiske services (se nedenstående) ved brug af standardiserede åbne snitflader, der sikrer Løsningens integration i Rammearkitekturen; dels bevirker arkitekturprincippet, at Løsningen kan aftage forretningsservice fra andre (fysiske) services, udstillet af fagsystemer såvel som Støttesystemer. C2: Alle data er uafhængige af systemet, hvor de opbevares Dette arkitekturprincip overholdes igennem Løsningens brug af Rammearkitekturens Sag og Dokument Forretningsservices, hvorved sager og dokumenter opbevaret (og skabt) af Løsningen frit kan overføres til andre Løsninger, der ligeledes realiserer Rammearkitekturens Sag og Dokument forretningsservices. Samtidig kan Løsningen eksportere alle data bl.a. til brug for ledelsesinformationsystemer (LIS), og et nyt kommende ydelsessystem kan derfor også etablere en import af det fulde datasæt om nødvendigt. C3: Data identificeres entydigt Alle objekter i Løsningen identificeres med et unikt ID, et UUID. C4: It-løsninger er skalerbare efter formål Der stilles krav til at Løsningen skal være skalerbar både horisontalt og vertikalt, så øget belastning kan imødekommes efter behov. C5: It-løsninger er robuste overfor egne og andre systemers nedbrud Der stilles krav til, at Løsningen skal være fejltolerant, og kunne fortsætte sit virke i tilfælde af nedbrud i eksterne systemer. Det er dog overladt til Leverandøren at godtgøre, hvordan dette krav imødekommes (fx ved at cache visse data, implementere prøv-igen-strategier etc.) 6.2 Arkitektur Dette afsnit vil først skabe et overblik over Løsningen og dennes sammenspil med andre (eksterne) systemer (afsnit 6.2.1). Herefter gennemgås målarkitekturen for Løsningen (afsnit 6.2.2) og den løskoblede selvbetjeningskomponent (afsnit 6.2.3). Afsluttende beskrives en række tværgående egenskaber for Løsningen (afsnit 6.2.4) System og integrationskontekst Løsningen skal eksistere i en kontekst, hvor den skal kommunikere med mange andre systemer - eksisterende såvel som kommende. Der er her tale om et bredt spektrum af sammenhænge til generelle tværkommunale løsninger (Rammearkitekturen, fælleskommunale løsninger mfl.), kommunal systemportefølje (økonomi, ESDH mfl.) og så de løsningsspecifikke sammenhænge (selvbetjeningsløsninger mfl.). Side 180 af 255

181 Figuren nedenfor illustrerer på højt niveau den systemkontekst, løsningen skal indgå i: Selvbetjening Fælleskommunale løsninger Kommunens hjemmeside Fællesoffentlig portal SAPA FLIS Løsningen Fælleskommunal Rammearkitektur Serviceplatformen Beskedfordeling Støttesystemer Kommunal systemportefølje Fællesoffentlige registre Figur 57 Løsningens systemkontekst Målarkitektur Løsningens kontekst, som beskrevet i forrige afsnit 6.2.1, beskriver Løsningens sammenhæng med den kommunale forretnings øvrige systemportefølje og den fælleskommunale Rammearkitektur. I dette afsnit beskrives Løsningens målarkitektur, der vil sikre, at Løsningen lever op til den beskrevne kontekst. Der er to primære forretningsdrivere der påvirker Løsningens målarkitektur: Løsningen skal efterleve den fælleskommunale Rammearkitekturs arkitekturprincipper. Derudover er flere af Løsningens forretningsområder, eller delområder, er ofte genstand for ændring. Kunden ønske en Løsning hvis tekniske aspekter (løsningsarkitektur) understøtter disse forretningsdrivere. For at imødekomme ændringer i omstændigheder, der påvirker Løsningens forretning, ønskes en løsning der giver anledning til lave vedligeholdelses- og videreudviklingsomkostninger. Målarkitekturen beskrevet i dette afsnit har derfor fokus på en løsning med en intern komponentopdeling, der følger Løsningens forretningsprocesser. Derudover er der fokus på genbrug af eksisterende forretningsservices i Rammearkitekturen, samt Rammearkitekturens Støttesystemer. Løsningens interne modularisering skal derfor inkludere og bygge på eksisterende funktionalitet, på de forretningsområder hvor dette er relevant. Målarkitekturen er illustreret på nedenstående figur: Side 181 af 255

182 Figur 68: Logisk arkitektur for Løsningen (målarkitektur) Figur 6 viser en generel opdeling af Løsningen i logiske forretningskomponenter. Forretningskomponenter er logiske grupperinger af funktionalitet, som matcher de i kap. 5 beskrevne funktionelle områder af Løsningen. Disse komponenter illustrere et eksempel på funktionelle barriere,der isolerer og afgrænser funktionalitet, og dermed søger at sikre, at de disse kan vedligeholdelse individuelt. De relevante forretningskomponenter med generelle egenskaber er: Sag: Ansvarlig for Løsningens sager og deres integritet iht. gældende forretningsregler. Dokumenter: Ansvarlige for Løsningens dokumenter og deres integritet iht. gældende forretningsregler, samt relation til Sag Journalnotater: Ansvarlig for Løsningens journalnotater og deres integritet iht. gældende forretningsregler, samt relation til Sag. Part: Ansvarlig for Løsningens registrering af parter på en sag, samt at holde disse parters oplysninger opdateret fra centrale (autoritative) kilder. Bevillinger: Ansvarlig for Løsningens bevillinger på baggrund af en sagsoplysning, samt relation til Sag Post: Afsendelse af besked til Parter via fjernprintløsning. Udtræk: Ansvarlig for at håndtere udtræk af Løsningens data til relevante modtagere uden for Løsningen Administrator modul: Understøtter Løsningens muligheder for opsætning og konfiguration NemHandel/eFaktura: Understøtter Løsningens behov for at integrere med de Fælles offentlige løsning til betaling af faktura (på vegne af Part) Side 182 af 255