BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM MV.

Transkript

1 BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM MV.

2 VEJLEDNING Denne kravspecifikation er en del af kravspecifikationen af økonomisystem, herunder debitor, e- handel, boliglån og ressourcestyring. Den samlede kravspecifikation for økonomi udgøres af: Bilag 1 kravspecifikation A (fælles) Bilag 1 kravspecifikation C (økonomi) Denne del af den samlede kravspecifikation beskriver de forhold, som er specifikke for økonomi. Denne kravspecifikation beskriver opgaver, processer og arbejdsgange, som skal håndteres ved hjælp af kommunens fremtidige løsning. Dokumentet indeholder dels en række generelle forhold og ikke-funktionelle krav, dels en beskrivelse af et antal procesområder, som varetages hos kunden. Tilbudsgiver skal i løsningsbeskrivelsen redegøre detaljeret for sine og den tilbudte løsnings forudsætninger vedrørende de nævnte generelle forhold og forventninger samt ikke-funktionelle krav. Tilbudsgiver skal endvidere i løsningsbeskrivelsen redegøre detaljeret for, hvorledes den tilbudte løsning kan anvendes til at løse de opgaver og arbejdsgange, som er beskrevet i kravspecifikationen. Tilbudsgiver skal tilstræbe et detaljeringsniveau, som muliggør, at kunden ved gennemgang af løsningsbeskrivelsen kan danne sig et indtryk af den tilbudte løsnings egnethed til at understøtte de beskrevne processer og arbejdsgange samt løsningen af de beskrevne opgaver.

3 INDHOLD 1. Indledning Generelt Procescases 1 2. Kunden 2 3. Udbuddets omfang 3 4. Generelle krav til tilbuddet Basiskrav Hovedtidsplan Projektledelse Opsætning og konfigurering Tilgængeliggørelse af eksisterende data (option) Implementeringsbistand Test Uddannelse Uddannelse i forbindelse med brugen af systemunderstøttelsen Uddannelse i forbindelse med ibrugtagningen af løsningen (option) Etablering, drift og vedligeholdelse af samt adgang til uddannelsesmiljø (option) Dokumentation Dokumentation af analysefasen Dokumentation af løsningen Brugersupport Udviklingsplaner Projektmodel Bemanding Involvering af kundens medarbejdere Samarbejde om optimering af brugen af systemet Regnskabsafslutning og læseadgang til historiske data (option) Generelle krav til løsningen Forventninger til leverandøren Lovmæssige krav Åbne standarder Sikkerhed og kontroller Brugervenlighed og fleksibilitet Forhold vedr. it-arkitektur, integration mv Brugeradministration Integration i forhold til økonomisystemet It-sikkerhed It-arkivering Data til Fælleskommunalt Ledelsesinformationssystem (FLIS) Data til ledelsesinformation generelt (option) Data til complianceanalyser (option) Dataudtræk Metadata og søgbarhed Programmering af batchjobs Krav til driftsplaner Svartider, oppetider mv. 18

4 5.15 Offentlig Digitalisering Beskrivelse af opgaveområder og processer Kontoplan Budget og budgetopfølgning Debitor Ressourcestyring Indkøb og e-handel Anlægsstyring og anlægsregnskab Betaling, bogføring og kreditor Rapportering og analyse Økonomi og regnskab herunder årsregnskab og omkostningsregnskab Likviditetsstyring (option) Boliglån Mellemkommunale opkrævninger/udbetalinger (option) 58

5 1. INDLEDNING 1.1 Generelt Denne del af det samlede udbud omfatter udbud af kundens økonomisystem. Dette dokument udgør den specifikke del af kravspecifikationen for udbuddet, som samlet udgøres af: Bilag 1 kravspecifikation A (fælles) Bilag 1 kravspecifikation C (økonomi) Kravspecifikationen er struktureret således, at der i starten af kapitlerne er en generel beskrivelse, hvor det er relevant. Herefter følger de specifikke krav til hvert område. Den generelle beskrivelse er ment som en baggrundsbeskrivelse, som de efterfølgende krav skal opfylde. Kravene er nummereret Krav nn og Tilbud nn, hvor Krav nn er udtryk for et krav til systemet/løsningen, og hvor Tilbud nn er udtryk for et krav til tilbuddet. Det er ud for kravene anført, hvilke krav der er mindstekrav. 1.2 Procescases Der er gjort brug af procescases til at specificere en række krav. En procescase er en struktureret tekst, som beskriver et forretningsområde eller en forretningsproces og dens krav til itunderstøttelse. Procescasene er overordnede af karakter og er udarbejdet for relevante, centrale forretningsprocesser. En procescase består af: Navn for processen Formål og overordne krav Beskrivelse af forretningsprocessen og dens kritiske processer Specifikke krav til it-løsningen Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen Procescases er ikke beskrevet i detaljer. Der er i tidsplanen indlagt en analyse- og designfase efter valget af leverandør bl.a. med det formål at arbejde videre med og fylde detaljer i disse procescases. Det forventes, at leverandøren aktivt forholder sig til procescasene og tilbyder en løsning, der understøtter og sikrer en opfyldelse af de angivne procescases. BILAG 1 C KRAVSPECIFIKATION SIDE 1

6 2. KUNDEN Kundens organisation er kendetegnet ved en høj grad af decentralisering. Opgaveområderne omfattet af kravspecifikationen løses således både i centrale og decentrale organisatoriske enheder. Kunden anslår antallet af brugere på den nuværende økonomiløsning til at være som følger: Kategorier Brugere Administratorer Ca. 4 Superbrugere Ca. 20 Brugere Ca. 600 Kunden har en central økonomisupport funktion, hvor medarbejderne er systemadministratorer, foretager brugeroprettelser og yder umiddelbar teknisk support til brugere i hele organisationen. I den centrale økonomifunktion findes omkring 8 medarbejdere med bredt kendskab til systemet og dets funktionsmåde og superbruger niveau på mere specifikke områder. I fagcentrene findes omkring 12 økonomimedarbejdere, som er involveret bredt i kommunens økonomiprocesser og tilrettelægger centrets interne arbejdsgange på økonomiområdet. Disse medarbejdere deltager i budgetlægning, budgetopfølgning, øvrig rapportering, ad-hoc analyser, regnskabsmæssig kontrol, design af kontoplaner mv. De har bredt kendskab til systemerne og deres muligheder og anvender mange forskellige funktionaliteter. Nogle af fagcentrene anvender specifikke moduler/systemer og har evt. administrator og/eller superbrugerfunktion på disse. Krav 1. Leverandøren skal afgive tilbud med udgangspunkt i det nuværende antal brugere. BILAG 1 C KRAVSPEFICIKATION SIDE 2

7 3. UDBUDDETS OMFANG Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem mv.. Det er i Bilag 1 kravspecifikation A (fælles) angivet hvilke it-løsninger, kunden benytter til at løse opgaver inden for økonomi, og hvilke systemer der i dag eksisterer integrationer til. Krav 2. Udgangspunktet for nærværende udbud er alene at forbedre systemunderstøttelsen inden for de områder, der i dag systemunderstøttes. Det er derfor ikke hensigten at udvide systemunderstøttelsen til at dække nye områder, udover hvad der afspejles af kravspecifikationens procescases. BILAG 1 C KRAVSPEFICIKATION SIDE 3

8 4. GENERELLE KRAV TIL TILBUDDET Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem. Systemet skal understøtte de krav, som en kommunal virksomhed som kunde bør stille til en tidssvarende økonomiløsning. Der er følgende optioner, der, jf. udbudsmaterialets krav hertil, SKAL gives tilbud på (MINDSTE- KRAV): Tilgængeliggørelse af eksisterende data, jf. pkt. 4.5 Uddannelse i forbindelse med ibrugtagning af løsningen, jf. pkt Etablering, drift og vedligeholdelse af samt adgang til uddannelsesmiljø, jf. pkt Regnskabsafslutning og læseadgang historiske data, jf. pkt Data til ledelsesinformation - generelt, jf. pkt. 5.8 Data til Complianceanalyser, jf. pkt. 5.9 Likviditetsstyring, jf. pkt Mellemkommunale opkrævninger/udbetalinger jf. pkt Bistand til realisering af effektiviseringspotentiale (jf. bilag 1 A) Forlængelse af kontrakten med 2 x 2 år ad gangen. Hermed forstås, at leverandørens tilbud inden for disse områder skal prissættes separat, således at kunden har mulighed for at til-/fravælge områderne. 4.1 Basiskrav Krav 3. Krav 4. Krav 5. Krav 6. Tilbud 1. Tilbud 2. Det er et krav, at leverandøren skal levere et økonomisystem baseret på et standardsystem. Det er et krav, at løsningen i så høj grad som muligt anvender systemets standardfunktionalitet, og at der kun i begrænset omfang foretages tilretninger og specialudvikling. Det er et krav, at løsningen er integreret datamæssigt, således at ændringer og inddateringer slår øjeblikkeligt igennem i hele systemet. Det er et krav, at processerne er automatiske, så det ikke er manuel arbejdskraft, der skal anvendes for at få systemerne til at køre. Leverandøren skal i underbilag til bilag 2 med udgangspunkt i den i Bilag 1 kravspecifikation A (fælles) beskrivelse af de nuværende systemer og deres indbyrdes sammenhæng angive, hvilke systemer kunden fortsat skal gøre brug af. Leverandøren skal i underbilag til bilag 2 med udgangspunkt i den i Bilag 1 kravspecifikation A (fælles) beskrivelse af de nuværende systemer og deres indbyrdes sammenhæng angive, hvilke systemer kunden fremover ikke skal gøre brug af. 4.2 Hovedtidsplan Krav 7. Det er et krav, at senest den 15. oktober 2015 skal økonomisystemet være klar til indberetning af budgettet for Den 1. december 2015 skal økonomisystemet være klar til at varetage samtlige opgaver af hensyn til håndtering af forsupplementsperioden. Den 1. januar 2016 skal økonomisystemet være klar til drift i hele kommunen (mindstekrav). BILAG 1 C KRAVSPEFICIKATION SIDE 4

9 Tilbuddet skal indeholde en analyse- og designfase, som igangsættes efter valget af leverandør. I denne fase skal løsningsbeskrivelsen viderebearbejdes i form af en endelig løsningsbeskrivelse. Tilbud 3. Tilbud 4. Tilbud 5. Leverandøren skal med udgangspunkt i ovenstående angive en hovedtidsplan med relevante aktiviteter til gennemførelse af projektet. Hovedtidsplanen angives i bilag 5. Leverandøren skal i bilag 3 angive og beskrive de relevante aktiviteter til gennemførelse af projektets analyse- og designfase. Leverandøren skal i bilag 3 redegøre for projektforløbet som helhed, herunder for relevante aktiviteter til implementering af løsningen. Følgende aktiviteter skal som minimum beskrives: Projektledelse Opsætning og konfigurering Tilgængeliggørelse af eksisterende data (option) Implementeringsbistand Testplanlægning og afprøvning Uddannelse ved ibrugtagning af løsningen (option). 4.3 Projektledelse Leverandøren har det totale projektledelsesansvar for alle dele af leverancen samt for overholdelsen af tidsplanen. Leverandørens projektleder har også initiativpligt over for aktiviteter, der skal gennemføres af kunden. Leverandørens projektleder skal arbejde tæt sammen med kundens projektansvarlige. Tids- og projektplanerne skal omfatte planlægningsaktiviteter, der kan sikre systematik og sammenhæng samt god fælles forståelse af de aktuelt forestående aktiviteter. Krav 8. Det er et krav, at tilbuddet medtager al den til gennemførelsen af projektet nødvendige projektledelse fra leverandørens side (mindstekrav). 4.4 Opsætning og konfigurering Krav 9. Det er et krav, at leverancen skal omfatte den til gennemførelsen af projektet nødvendige bistand fra leverandørens side til opsætning og konfigurering af løsningen (mindstekrav). 4.5 Tilgængeliggørelse af eksisterende data (option) Kunden ønsker at sikre en så let overgang til det nye system som muligt. Kunden ønsker derfor, at eksisterende data i kundens nuværende system, videst muligt omfang gøres tilgængelige i det nye system ved brug af den samme funktionalitet, som stilles til rådighed for nye data. Krav 10. Tilbud 6. Det er et krav, at leverandøren i tilbuddet medtager forslag til tilgængeliggørelse af eksisterende data. I det omfang tilgængeliggørelsen forudsætter involvering af tredjepart, skal dette angives (mindstekrav). Leverandøren skal i bilag 13 medtage tilgængeliggørelse af eksisterende data som option, og den endelige tilgængeliggørelse af eksisterende data fastlægges som en del af analyse- og designfasen. Omkostninger til tredjepart medtages ikke. BILAG 1 C KRAVSPEFICIKATION SIDE 5

10 4.6 Implementeringsbistand Leverancen skal omfatte den nødvendige bistand til en succesfuld implementering og ibrugtagning af systemet, bl.a. i forhold til den initiale systemopsætning, tilrettelæggelse af arbejdsgange, implementering af snitflader til de tilgrænsende systemer, opsætning af roller og brugerrettigheder mv. Krav 11. Det er et krav, at tilbuddet medtager samtlige den til gennemførelsen af projektet nødvendige implementeringsbistand fra leverandørens side (mindstekrav). 4.7 Test Som en del af den samlede projektplan skal der udarbejdes en detaljeret testplan, som sikrer, at der sker en grundig afprøvning. Det forventes, at afprøvningen bl.a. omfatter en brugerafprøvning, hvor repræsentanter fra kommunen deltager i arbejdet med at teste den samlede systemfunktionalitet. Krav 12. Det er et krav, at leverancen omfatter alle ydelser fra leverandørens side, der er nødvendige for realisering af testplanen, herunder også deltagelse i samtlige kontraktmæssigt fastsatte afprøvninger af systemet (mindstekrav). 4.8 Uddannelse Leverandøren skal tilbyde uddannelse i forbindelse med ibrugtagning og brugen af systemet. Krav 13. Krav 14. Krav 15. Det er et krav, at uddannelsen forestås af kompetente undervisere med erfaring i undervisning og brugen af systemet. Det er et krav, at uddannelsen gennemføres, så der i uddannelsen er fokus på, at de enkelte moduler/områder er en integreret del af en samlet system/løsning, så der samtidig undervises specifikt i forhold til modulet og generelt i forhold til den samlede løsning. Leverandøren skal tilbyde uddannelse af kundens brugere i hele kontraktperioden Uddannelse i forbindelse med brugen af systemunderstøttelsen Kunden ønsker en løbende videreuddannelse af brugerne. Derfor ønsker Kunden at indgå en fast aftale om en løbende efteruddannelse efter en klippekortordning. Ikke brugte klip kan af kunden overføres til næste år. Ikke brugte klip i kontraktperioden skal kunne modregnes i forbindelse med den endelige opgørelse af fastprisaftalens omkostninger. Klippekortet skal omfatte 10 uddannelsesdage med op til 24 deltagere. Tilbud 7. Leverandøren skal i bilag 13 medtage omkostningerne til en klippekortordning baseret på 10 årlige uddannelsesdage. Omkostningerne til klippekortordningen medtages som en del af den faste månedlige driftsudgift Uddannelse i forbindelse med ibrugtagningen af løsningen (option) Leverandøren skal kunne levere al brugeruddannelse, herunder uddannelse af systemadministratorer, superbrugere og brugere. Leverandøren skal ligeledes kunne levere det nødvendige uddannelsesmateriale. BILAG 1 C KRAVSPEFICIKATION SIDE 6

11 Kunden ønsker den størst mulige fleksibilitet i forhold til uddannelse af brugere, både i forhold til uddannelsens omfang og i forhold til den konkrete tilrettelæggelse. Undervisningen foregår hos kunden. Ved hands-on-undervisning er der plads til 12 brugere af gangen i kundens IT-lokale. Krav 16. Tilbud 8. Uddannelse skal være indeholdt i tilbuddet. Uddannelse af brugere medtages som option, og det konkrete uddannelsesforløb aftales som en del af analyse- og designfasen (mindstekrav). Leverandøren skal i underbilag til bilag 2 anføre, om undervisningen forudsætter lokaler eller bør foregå i lokaler med adgang til flere pc er. Krav 17. Leverandøren skal, som en del af tilbuddet, tilbyde uddannelse af følgende økonomi: Administratorer (ca.4 administratorer): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne forestå de opgaver, der relaterer sig til at være administrator af systemet. Administratorer (ca. 4 administrator/superbruger - debitor): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne forestå de opgaver, der relaterer sig til at være administrator af debitorsystemet. Administratorer (ca. 4 administrator/superbruger - ressourcestyring): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne forestå de opgaver, der relaterer sig til at være administrator af ressourcesystemet. Superbrugere (ca. 20 økonomi): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne forestå de opgaver, der relaterer sig til at være superbrugere af systemet. Krav 18. Krav 19. Krav 20. Krav 21. Krav 22. Superbrugeruddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne vejlede øvrige brugere. Uddannelsen skal tillige klæde superbrugerne på til at løse komplekse fagspecifikke problemer samt håndtere de basale elementer i brugerhåndtering. Uddannelsen af superbrugere skal være af ensartet kvalitet og skal derfor forestås af leverandøren. Leverandøren kan i undervisningen suppleres af en specialist fra kunden til at sikre den bedst mulige kobling mellem kommunens opgaveløsning og økonomisystemets muligheder, eller superbrugere kan efter undervisningen fra leverandøren - varetage den efterfølgende træning af brugerne i den daglige opgaveløsning. Uddannelsen af superbrugere og brugere skal foregå hos kunden, der stiller lokaler og udstyr til rådighed. Uddannelsen af superbrugere skal tilrettelægges, så kundens særlige forhold, konfiguration og arbejdsprocesser indgår. Uddannelsen af brugere koordineres tidsmæssigt med implementeringsforløbet, således at uddannelse i brugen af økonomisystemets moduler er koordineret med implementeringen af disse og foregår umiddelbart før den enkelte bruger skal benytte sy- BILAG 1 C KRAVSPEFICIKATION SIDE 7

12 stemet, så medarbejderne er parate til at løse opgaverne i den nye løsning på tidspunktet for dennes driftsstart. Krav 23. Tilbud 9. Kursusmaterialet skal foreligge minimum 14 dage før afholdelse af kurserne, og skal forinden i samarbejde med kunden være tilrettet eventuelle specifikke kunde-krav Leverandøren skal i bilag 3 afgive 2 alternative tilbud på uddannelsesaktiviteterne af brugerne. Leverandøren skal ved hvert tilbud beskrive hvilke undervisningsformer (f.eks. hands-on-holdundervisning, stormøder og e-learning), der vil blive benyttet til undervisning af de enkelte profiler (administratorer, superbrugere og brugere): - Det minimale uddannelsesforløb - Den anbefalede uddannelsesforløb Etablering, drift og vedligeholdelse af samt adgang til uddannelsesmiljø (option) I tilfælde af, at kunden selv ønsker at varetage uddannelsen af brugerne, ønsker kunden uhindret og ubegrænset adgang til et uddannelsesmiljø, der driftes og vedligeholdes af leverandøren. Uddannelsesmiljøet er ikke omfattet af servicemål og bodsbestemmelserne i bilag 9. Uddannelsesmiljøet skal gøre det muligt for kunden at oplære brugere i anvendelse af økonomisystemet mv. Uddannelsesmiljøet skal altid være opdateret, så nye funktioner i systemet, som følge af nye versioner/ændringer m.m., også er slået igennem i uddannelsessystemet. Leverandøren skal tillige kunne levere det nødvendige uddannelsesmateriale. Samtidig har kunden behov for lejlighedsvis at kunne afprøve nye løsningers integration til det tilbudte løn-/økonomisystem i et testmiljø, således at integrationer er velafprøvede inden de overføres til produktionsmiljøet. Ligeledes er der behov for afprøvning af nye løsninger i det enkelte system. Kunden ønsker at benytte uddannelsesmiljøet til test af systemet. Krav 24. Krav 25. Krav 26. Krav 27. Tilbud 10. Tilbud 11. Leverandøren skal stille et uddannelsesmiljø til rådighed for kunden. Adgangen til uddannelsesmiljøet skal være uhindret og ubegrænset i tidsrummet alle arbejdsdage kl Leverandøren skal i samarbejde med kunden sætte uddannelsesmiljøet op, så det afspejler kundens forhold, herunder at det indeholder et autentisk datagrundlag og autentiske brugerrettigheder. Den nærmere konfigurering af uddannelsesmiljøet fastlægges i analyse- og designfasen. Uddannelsesmiljøet skal kunne nulstilles efter endt undervisning, så undervisningen af nye kursister tager afsæt i det oprindelige datagrundlag. Det skal være muligt for kunden selv at kunne redigere i uddannelsesmiljøets datagrundlag. Leverandørens skal i underbilag til bilag 2 redegøre for det uddannelsesmiljø, som leverandøren kan stille til rådighed. Leverandørens skal i bilag 13 medtage etablering, drift og vedligeholdelse af samt adgang til uddannelsesmiljø som en option. BILAG 1 C KRAVSPEFICIKATION SIDE 8

13 4.9 Dokumentation Der skal leveres fuld dokumentation til det samlede system rettet mod slutbrugerne. Dokumentationen skal løbende vedligeholdes i hele kontraktperioden (vedligeholdelsesaftalen). Dokumentationen bør foreligge i et ajourført, online, søgbart format Dokumentation af analysefasen Som en del implementeringen skal leverandøren gennemføre en analyse- og designfase, der skal give leverandøren den fornødne viden til udarbejdelse af den endelige løsningsbeskrivelse på baggrund af kravspecifikationen jf. kontraktens bestemmelser. Krav 28. Resultatet af analyse- og designfasen skal dokumenteres i en løsningsbeskrivelse, som vil indgå i kontraktens bilag 2 (mindstekrav) Dokumentation af løsningen Leverandøren skal som en del af løsningen levere: Brugerdokumentation (f.eks. manualer, online hjælp) Administrationsdokumentation (udvidede manualer) Systemdokumentation (løsningsarkitektur, modulbeskrivelser, datamodel, opsætning) Vedligeholdelses- og driftsdokumentation (f.eks. installations- og systemdokumentation, fejlhåndtering) Krav 29. Krav 30. Krav 31. Krav 32. Tilbud 12. Al brugerrettet dokumentation skal foreligge på dansk. Tilbuddet skal omfatte tilstrækkelig dokumentation og vejledning til at understøtte brug og afstemning af systemet. Dokumentation skal leveres samtidigt med programmellet og godkendes som en del af overtagelsesprøven. Dokumentation skal vedligeholdes i hele kontraktperioden, således at det er ajourført i forhold til den version af løsningen, som kunden anvender. Leverandøren skal i underbilag til bilag 2 beskrive den dokumentation, som følger med løsningen Brugersupport Den generelle leverandørservice skal indeholde dansk brugersupport/helpdesk til support af kundens medarbejdere. Et begrænset antal brugere vil blive autoriserede til at henvende sig til brugersupporten. Tilbud 13. Leverandøren skal i bilag 10 beskrive omfanget og karakteren af den tilbudte brugersupport samt beskrive eventuelle valgmuligheder for serviceniveau i forhold til brugersupport. Kunden ønsker at leverandøren effektivt kan yde support til udvalgte brugere i organisationen via fjernadgang, således at supporteren kan se brugerens skærm. BILAG 1 C KRAVSPEFICIKATION SIDE 9

14 Krav 33. Leverandøren skal i underbilag til bilag 2 beskrive hvordan leverandørens supportere kan understøtte kundens ønske om fjernadgang til udvalgte brugeres skærme i forbindelse med support Udviklingsplaner For Kunden er det vigtigt at der anskaffes et fremtidssikret system, især i forhold til fremtidige digitale løsninger. Tilbud 14. Tilbud 15. Leverandøren skal i bilag 10 beskrive igangværende eller planlagte udviklingsplaner for det pågældende produkt, herunder aktuelle planer om nye versioner, moduler mv. Leverandøren skal endvidere angive om dele af den tilbudte løsning vil blive erstattet af nye delløsninger i kontraktperioden (vedligeholdelsesperioden). Omkostninger (licenser) ved kundens ibrugtagning af de beskrevne udviklingstiltag skal være indregnet i det afgivne tilbud. Kunden ønsker mulighed for at kunne påvirke udviklingsplaner og fremtidige initiativer i forhold til den tilbudte løsning. Tilbud 16. Leverandøren skal i bilag 10 beskrive leverandørens arbejdsgange i forhold til opsamling af viden fra kunden og prioriteringer til udviklingsplaner og fremtidige initiativer, samt hvorledes kunden vil blive inddraget i dette arbejde Projektmodel Tilbud 17. Leverandøren skal i bilag 3 beskrive den projektmodel, der tænkes anvendt i forbindelse med designfase og implementering af løsningen. Projektmodellen skal indeholde kundens roller og forventninger til disse samt beskrivelse af kontaktsnitflader mellem kunde og leverandør Bemanding Tilbud 18. Leverandøren skal i bilag 11 beskrive, hvilken bemanding leverandøren vil allokere til hhv. analyse- og designfasen og til resten af projektet i form af navngivne konsulenter med tilhørende cv er. Leverandøren skal redegøre for, hvorledes kontinuitet og kvalitet i leverancen fastholdes ved medarbejderafgang i projekt- og kontraktperioden Involvering af kundens medarbejdere Tilbud 19. Leverandøren skal i bilag 6 beskrive, hvordan kundens medarbejdere bliver involveret i analyse- og designfasen, hvilke profiler, der efterspørges, og hvilket omfang involveringen har. Endelig skal leverandøren beskrive omfanget af de ressourcer kunden skal anvende for at drifte løsningen Samarbejde om optimering af brugen af systemet Kunden ønsker sammen med leverandøren at gøre økonomiadministrationen nemmere, bedre og billigere. Der er kundens vurdering, at der er et betydeligt potentiale for at tilbyde opgavevaretagere og institutioner en opgaveunderstøttelse, som gør det muligt at løse opgaverne nemmere og bedre, hvilket vil give øget tilfredshed og kvalitet. Der er desuden et betydeligt potentiale for effektiviseringer, det vil sige for at reducere tidsforbruget til økonomiopgaver. BILAG 1 C KRAVSPEFICIKATION SIDE 10

15 Effektiviseringen drives af digitalisering, forbedret systemunderstøttelse, ændrede arbejdsprocesser og standardisering. Samtidig går en lang række af arbejdsprocesserne på økonomiområdet på tværs af den centrale økonomifunktion og opgavevaretager/institutioner. Leverandøren forventes at påtage sig et betydeligt medansvar for, at administrative processer med relation til økonomistyringen løbende forbedres og effektiviseres. Kunden forventer, at leverandøren vil bistå kunden med at identificere, kvalificere og implementere effektiviseringer i de arbejdsprocesser, som berører kunden. Kunden forventer, at leverandøren løbende, og mindst én gang årligt, overvejer og kommer med konkrete forslag til forbedring af it-understøttelsen af økonomiadministrationen, herunder forslag til bedre udnyttelse af leverandørens system. Tilbud 20. Leverandøren skal i underbilag til bilag 2 beskrive, hvorledes leverandøren ønsker at støtte op om kundens tilgang til en mere optimal brug af den tilbudte løsning. Tilbud 21. Det beskrevne samarbejde skal være indregnet i prisen i bilag Regnskabsafslutning og læseadgang til historiske data (option) Ved udløb af denne kontrakt skal opgaven genudbydes. Det kan indebære, at kunden skal overdrage opgaven til en ny leverandør. Kunden ved af erfaring, at det er vanskeligt at konvertere data, hvorfor det kan være nødvendigt i en periode at opretholde en spørgeadgang til historiske data. Spørgeadgangen omfatter læseadgang herunder rapportadgang - til samtlige data i systemet, som de forefindes ved kontraktens udløb. Spørgeadgangen skal foregå ved brug af det benyttede system eller et system med lignende spørgefunktionalitet. Der skal være mulighed for at foretage udtræk, som ikke ligge i faste rapportskabeloner (ad-hoc søgninger). Endvidere vil der være behov for fuld adgang til systemet i de første 4 måneder efter evt. overgang til andet system i forbindelse med afslutning af kommunens regnskab. Forventet antal brugere i årene efter kontraktens udløb: Fuld adgang Læseadgang 1. måned Alle måned 10 Resten måned Alle 2. år år 5 Tilbud 22. Leverandøren skal som option i bilag 13 angive prisen pr. måned for at opretholde spørgeadgangen til data i 5 år samt fuld adgang til systemet i de første 4 måneder efter denne kontrakts udløb. Der angives en pris pr. måned for 1. år inkl. fuld adgang til systemet i de første 4 måneder samt én pris pr. måned for spørgeadgang i de næste 4 år. BILAG 1 C KRAVSPEFICIKATION SIDE 11

16 5. GENERELLE KRAV TIL LØSNINGEN 5.1 Forventninger til leverandøren Kunden forventer, at leverandøren har et indgående kendskab til økonomiopgaver og økonomistyring i en dansk kommune herunder de politiske og administrative processer, som kendetegner kommunale økonomiforhold. 5.2 Lovmæssige krav Krav 34. Den tilbudte løsning skal i hele kontraktperioden opfylde og overholde og understøtte administrationen af al relevant lovgivning mv. (mindstekrav), herunder: A. Lov om behandling af personoplysninger (Persondataloven) B. Datatilsynets sikkerhedskrav C. Arkiverings- og kassationsbestemmelser D. Forvaltningsloven E. Offentlighedsloven F. Styrelsesloven G. Bogføringsloven H. Lov om offentlige betalinger I. Lov om inddrivelse J. Budget- og regnskabssystem for kommuner K. Årsregnskabsloven L. Samt særlige opgørelser på refusionsområdet hvis de mest hensigtsmæssigt laves i økonomisystemet (f.eks. rapporten Helårspersoner) Krav 35. Tilbud 23. Systemet skal på alle områder løbende være ajour med hensyn til gældende lov og regler (mindstekrav). Leverandøren skal i bilag 10 detaljeret redegøre for løsningens egnethed i forhold til at håndtere kommunens økonomiopgaver og økonomistyring under overholdelse af aktuel, relevante lovgivning. Leverandøren skal i kontraktperioden holde den tilbudte løsning funktionalitetsmæssigt opdateret i forhold til ændrede lovgivningsmæssige og reguleringsmæssige rammer. 5.3 Åbne standarder Kunden skal overholde gældende lovgivning omkring anvendelse af åbne standarder for software, hvorfor tilbuddet skal opfylde gældende krav. Tilbud 24. Leverandøren skal i underbilag til bilag 2 redegøre for systemets opfyldelse for hver af nedenstående standarder, herunder skal leverandøren i fald en eller flere standarder helt eller delvist ikke opfyldes, for disse standarder beskrive baggrunden for leverandørens fravalg af at anvende standarden i leverandørens system. Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering (FESD) Standarder til elektroniske indkøb i det offentlige (OIOUBL) Standarder for digital signatur (OCES) Standarder for dokumentudveksling (ODF/OOXML) For yderligere information om obligatoriske, åbne standarder henvises til vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige, som kan rekvireres på BILAG 1 C KRAVSPEFICIKATION SIDE 12

17 5.4 Sikkerhed og kontroller Krav 36. Krav 37. Det er et krav, at der hvert år senest 1. marts foreligger en erklæring fra leverandørens eksterne statsautoriserede revisor om den samlede system-, data- og driftssikkerhed. For udgiftsområder, som er omfattet af statsrefusion, skal revisorerklæringen leve op til de krav, der af ministerierne stilles i den til enhver tid gældende Regnskabsbekendtgørelse (pt. BEK nr. 789 af 25/06/2014). Leverandøren skal med det samme efterkomme de anvisninger, revisor har givet. 5.5 Brugervenlighed og fleksibilitet Det er vigtigt for kunden, at systemet er brugervenligt, intuitivt og på dansk. Dette betyder også, at der skal være online hjælp f.eks. i form af elektroniske manualer/f1-assistance eller lignende, og det skal være muligt at bruge genvejstaster i stedet for mus. Disse støttefunktioner, manualer mv. skal foreligge på dansk. Herudover bør systemet være fleksibelt, således at det er enkelt for kunden selv at foretage ændringer f.eks. i rapporter, kontoplan mv. Krav 38. Krav 39. Krav 40. Det er et krav, at systemet skal være brugervenligt og fleksibelt i forhold til kundens fremtidige behov for justeringer og tilpasninger, herunder individuelle opsætning af skærmbillederne. Der ønskes et system med en intuitiv og letforståelig brugergrænseflade, som kan tilgodese behovene for brugere på mange forskellige niveauer af viden om systemet, og som reducerer behovet for oplæring til et minimum. Den enkelte bruger skal have mulighed for samtidig at have flere sessioner/skærmbilleder åbne af systemet samtidig. 5.6 Forhold vedr. it-arkitektur, integration mv. Der efterspørges et sammenhængende og fleksibelt standardsystem, som er ibrugtaget, og som således ville kunne gøres til genstand for en løsningspræsentation. Grænseflader (API er), protokoller og formater skal i størst muligt omfang være baseret på åbne standarder (de-facto og dejure) samt overholdelse af internet- og webstandarder. It-arkitektur- og softwareplatformen skal i størst mulig omfang være åben, fleksibel og velegnet til udvikling af nye funktioner. Tilbud 25. Tilbud 26. Tilbud 27. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens opbygning og modularitet, herunder den datamæssige integration og afhængigheder mellem eventuelle delmoduler og databaser. Leverandøren skal i underbilag til bilag 2 redegøre for hvilke eksterne grænseflader løsningen tilbyder. Leverandøren skal i underbilag til bilag 2 redegøre for hvilke delfunktionaliteter der umiddelbart kan gøres tilgængelige via webbrowser og/eller app på smartphone og tablet, og hvilke krav dette stiller til slutbrugerens hardware og software. BILAG 1 C KRAVSPEFICIKATION SIDE 13

18 Tilbud 28. Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan løsningen understøtter effektive arbejdsgange for decentralt placerede brugere med behov for adgang til relevante informationer med relation til arbejdet med økonomi og økonomistyring, herunder udtræk og forespørgsler. Kunden ønsker at følge og understøtte KOMBITs udvikling af en fælles rammearkitektur. Tilbud 29. Leverandøren skal i underbilag til bilag 2 redegøre for, hvorledes leverandøren og den tilbudte løsning vil understøtte og følge KOMBITs rammearkitektur Brugeradministration Af hensyn til bl.a. brugervenlighed er det for kunden vigtigt, at adgang til systemet medfører brug af færrest mulige brugernavne og adgangskoder for den enkelte medarbejder, herunder brug af single-signon. Krav 41. Tilbud 30. Det er et krav at løsningerne understøtter Kundens behov for at udarbejde funktionsopdelte brugerrettigheder. Samtlige ledere skal kunne danne rapporter/oversigter, så lederen på en let og overskuelig måde kan vurdere om medarbejdere har korrekte rettigheder Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan brugeradgang til løsningen fremstår for brugeren, og hvordan den administreres. Det skal beskrives, hvilke muligheder kunden har for frit at tildele brugernavne i løsningen, samt hvilke muligheder for dokumentation ifm. brugeradministration, som løsningen tilbyder. Kunden anvender i dag Microsoft AD til administration af brugerrettigheder, og en kommende løsning ønskes tilknyttet denne løsning. Tilbud 31. Leverandøren skal i underbilag til bilag 2 redegøre for, i hvilken udstrækning løsningens brugeradministration kan integreres med Microsoft AD, og hvilke krav løsningen evt. stiller i denne sammenhæng Integration i forhold til økonomisystemet Løsningen til økonomi skal understøtte den nødvendige datamæssige integration med en række øvrige it-løsninger, som leverer data til brug for økonomistyringen mv. Det er i Bilag 1 kravspecifikation A (fælles) angivet hvilke systemer og interessenter, hvorfra der i dag er etableret dataintegration til den eksisterende løsning til økonomisystemet Kunden forventer desuden, at der kan være behov for yderligere snitflader. Tilbud 32. Krav 42. Krav 43. Leverandøren skal i underbilag til bilag 2 beskrive de for løsningen nødvendige snitflader hos 3. part for dataoverførsel til kundens øvrige systemer. Kunden forestår selv købet af snitfladerne. Det er et krav, at kunden som en del af tilbuddet kan få udleveret dokumentation ned på feltniveau af de snitflader, som kunden skal bruge som en del af leverandørens løsning for at kunne integrere med 3. parts produkter. Det er et krav, at tilbuddet omfatter prisen på samtlige nødvendige interne snitflader i leverandørens egen løsning (både etablering og løbende drift) i den tilbudte løsning. BILAG 1 C KRAVSPEFICIKATION SIDE 14

19 5.6.3 It-sikkerhed Løsningen skal indeholde sikkerhedsfunktionalitet, som opfylder Datatilsynets sikkerhedskrav. Tilbud 33. Tilbud 34. Leverandøren skal i underbilag til bilag 2 redegøre for, hvordan systemet og driftsmiljøet er sikret mod uautoriseret adgang fra tredjemand samt for, hvordan kommunen sikres mod diverse vira o.l., når økonomisystemet i øvrigt anvendes. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens logningsfunktionalitet, herunder overholdelse af krav til revisionsspor. I de tilfælde, hvor der er brud i revisionsporet, fx ved overførsel af data fra et system til et andet, vil der være behov for at kunne afstemme konti. Krav 44. Tilbud 35. Det er et krav, at løsningen indeholder en beskrivelse af hvorledes konti afstemmes ved brud i revisionssporet. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for hvor der er overførsel af data mellem to systemer, og derfor behov for afstemning af systemkonti It-arkivering De tilbudte løsninger skal leve op til arkivlovens bestemmelser omkring elektronisk aflevering. I forhold til aflevering til et offentligt arkiv gælder det, at den efterspurgte løsning skal leve op til bestemmelserne i Arkivloven og Bekendtgørelse 1007 af 20. august 2010 eller den til enhver tid gældende bekendtgørelse. Krav 45. Leverandøren skal, som en del af den elektroniske aflevering af data, levere den tekniske dokumentation af systemet, der skal indgå i arkiveringsversionen. Den tekniske dokumentation skal bl.a. indeholde tabel- og feltbeskrivelser og E/R-diagram. Leverandøren skal i sit tilbud tage udgangspunkt i et krav om årlig arkivering og fremstilling af en arkiveringsversion, selvom Kunden i dag har en aftale om aflevering af data hvert 2. år. 5.7 Data til Fælleskommunalt Ledelsesinformationssystem (FLIS) Den kommende løsning forventes at kunne levere data til FLIS. Tilbud 36. Leverandøren skal i underbilag til bilag 2 beskrive, hvordan og i hvilket omfang løsningen vil aflevere data til FLIS. Krav 46. Den beskrevne funktionalitet skal være indregnet i prisen i bilag Data til ledelsesinformation generelt (option) Kunden ønsker direkte adgang til alle data registreret i løsningen (ned til mindste registrerede enhed, f.eks. cpr-nr.). Data stilles til rådighed via datawarehouse, således at kunden herfra kan læse data til eget ledelsesinformationssystem. Adgangen skal udformes således, at data automatisk kan indlæses af gængse løsninger til dataanalyse og datakonsolidering. Overførsel af aktuelle data skal ske mindst en gang pr. måned. BILAG 1 C KRAVSPEFICIKATION SIDE 15

20 Tilbud 37. Leverandøren skal i bilag 13 som option specifik angive det månedlige faste vederlag for systemadgang til data i datawarehouse. Den oplyste pris vil samtidig udgøre vederlagsreduktionen ved eventuelt bortfald af denne opgave. 5.9 Data til complianceanalyser (option) I dag anvender kunden et system fra BuboBubo til complianceanalyser. Kunden forventer, at der også fremover hos kunden vil være stor fokus på complianceanalyser for bl.a. at følge op på brugen af indkøbsaftalerne og lave prisanalyser. Derfor ønsker kunden mulighed for et dagligt og/eller månedligt udtræk af data (fakturalinjer mv.) fra bogførte e-bilag til brug i et indkøbsanalysesystem. Tilbud 38. Tilbud 39. Leverandøren skal i underbilag til bilag 2 beskrive, det tilbudte systems mulighed for at levere data til complianceanalyser. Leverandøren skal i bilag 13 som option specifik angive det månedlige faste vederlag for systemadgang til data til compliance-analyserne. Priserne skal angives med månedlig udtræk Dataudtræk Kunden benytter i høj grad ad hoc dataudtræk fra systemer i den daglige produktion. Anvendelsen og omfanget af disse data er meget varierende og skal understøttes på flere niveauer. Kunden ønsker at kunne analysere alle data i løsningen via fleksible dataudtræksmuligheder. Brugere kan vælge at udtrække valgte data til manuel eller maskinel behandling i andre systemer, herunder til gængse regnearks- og tekstbehandlingsformater, så data kan viderebearbejdes (fx skal der kunne regnes på tal) Brugere kan opstille og gemme egne standardrapporter, eller redigere i foruddefinerede standardrapporter. Rapporterne skal kunne udskrives eller eksporteres. Tilbud 40. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til dataudtræk til ad hoc brug samt den tilbudte validitet og aktualitet af tilgængelige data. Kunden ønsker fra regneark at kunne foretage direkte opslag og trække data (f.eks. budget- og forbrugstal) fra Økonomisystem via forprogrammerede makroer. Tilsvarende makrobaseret funktionalitet benyttes til at tilbageinddatere de i regneark bearbejdede data til Økonomisystemet. Tilbud 41. Leverandøren skal i underbilag til bilag 2 redegøre for, hvorledes løsningen fra regneark håndterer direkte opslag og datatræk (f.eks. budgettal) fra Økonomisystem via forprogrammerede makroer. Tilsvarende skal redegøres for den tilsvarende tilbageinddateringsfunktion. Kunden ønsker at sikre uafhængighed af enkelte systempakker, hvorfor dataudtræk i gængse regnearks- og tekstbehandlingsformater skal, indbefatte formater baseret på åbne standarder. Kunden benytter i dag Microsoft Office 2013, og løsningen skal understøtte formater der kan anvendes med denne programpakke, og alle senere versioner af Microsoft Office. Tilbud 42. Leverandøren skal i underbilag til bilag 2 redegøre for løsningens anvendelse af filtyper i forbindelse med dataudtræk, og hvorvidt disse opfylder ovenstående ønsker til understøttelse af nævnte kontorpakke. BILAG 1 C KRAVSPEFICIKATION SIDE 16

21 5.11 Metadata og søgbarhed Kunden ønsker, at kunne knytte ad hoc kommentarer og filer (docx, xlsx, pdf m.fl.) til data alle steder i Økonomisystemet. Funktionaliteten ønskes anvendt til dokumentationsformål gennem tilknytning af originaldokumenter til data. I tilknytning hertil ønsker kunden mulighed for at tilknytte og tilgå dokumenter direkte i Kundens ESDH-system. Tilbud 43. Tilbud 44. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold hertil, herunder til hvilke typer af poster der evt. ikke kan tilknyttes kommentarer og vedhæftes filer. Leverandøren skal i underbilag til bilag 2 endvidere redegøre for den tilbudte løsnings søgefunktionalitet herunder søgefunktionalitetens brugerinterface og resultatpræsentation samt muligheder for at tilpasse visningen af søgeresultater gennem applikation af filtre, sorteringer etc Programmering af batchjobs Krav 47. Krav 48. Krav 49. Løsningen skal indeholde funktionalitet til at afvikle periodiske jobs (batchjobs) f.eks. i forbindelse med inddatering via overførsel eller udskrivning af data, rapportering, ad hoc-analyser eller andet. Løsningen skal kunne afvikle periodiske og tidsforskudte jobs (batchjobs) f.eks. udenfor arbejdstiden i forbindelse med inddatering og overførsler. I forbindelse med implementering skal leverandøren proaktivt sikre, at batchjobs opsættes korrekt og overvåges løbende i.f.t. kundens ønskede arbejdsgange. Der ønskes et udskriftsarkiv, hvortil udskrifter/rapporter kan fremsendes både via batchjob og ved direkte udskrivning Krav til driftsplaner Krav 50. Leverandøren skal i henhold til kontrakten udarbejde egentlige driftsplaner på baggrund af ydelsesbeskrivelserne i bilag 1 og leverandørens løsningsbeskrivelse i bilag 2. Det er et krav til indholdet, at driftsplanerne beskriver rutiner og er egnede som styringsværktøj for den daglige drift. Driftsplanen kan udgøre en detaljering af leverandørens løsningsbeskrivelse. Driftsplanerne skal sikre, at der sker en videnoverførelse og forventningsafklaring parterne imellem, og at der identificeres præcise målepunkter og opfølgningsinstrumenter for de enkelte opgaver. Endelig skal driftsplanerne indeholde en beskrivelse af procedurer, kontaktnumre mv. i forbindelse med den daglige opgavevaretagelse. Indholdet af driftsplanerne drøftes og fastlægges endeligt efter kontraktindgåelse. Tilbud 45. Leverandøren skal i underbilag til bilag 2 medtage udkast til driftsplaner. BILAG 1 C KRAVSPEFICIKATION SIDE 17

22 5.14 Svartider, oppetider mv. I en række af kundens opgaver og processer er tidsaspektet afgørende, og systemets oppetider og svartider er derfor vigtige. Krav 51. Systemet skal overholde de i bilag 9 aftalte svartider, oppetider mv Offentlig Digitalisering Den offentlige sektor er inde i en udvikling, hvor der i stigende grad satses på, at borgerne skal gøre brug af digitale selvbetjeningsløsninger placeret på borger.dk. Herunder har der i flere omgange været talt om, at borgerne skal have mulighed for at have adgang til egen sag. Krav 52. Krav 53. Tilbud 46. Systemet skal hurtigst muligt efter statslige eller KL krav i form af fællesoffentlige digitaliseringsstrategier, e-dage mv. fremsættes, og senest, når kommunen skal have kravene implementeret, overholde disse. Systemet skal, hvis det bliver et krav, kunne udstille dette via borger.dk. Leverandøren skal i underbilag til bilag 2 redegøre for, hvorledes leverandøren vil leve op til den offentlige digitaliseringsstrategi. BILAG 1 C KRAVSPEFICIKATION SIDE 18

23 6. BESKRIVELSE AF OPGAVEOMRÅDER OG PROCESSER Afsnittet indeholder detaljerede beskrivelser af et antal opgaveområder og processer som forventes understøttet af den udbudte løsning. For hvert opgaveområde beskrives følgende forhold: Navn for opgaveområdet/processen Formål og overordne krav til opgaveområdet/processen Beskrivelse af opgaveområdet/processen og dens kritiske delprocesser Specifikke krav (overordnet) til IT-understøttelse af opgaveområdet/processen Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen Leverandøren bedes detaljeret redegøre for, hvorledes den tilbudte løsning kan anvendes til at løse de opgaver og arbejdsgange som er beskrevet. Leverandøren skal tilstræbe et detaljeringsniveau som muliggør at udbudsgiver ved gennemgang af løsningsbeskrivelsen kan danne sig et indtryk af den tilbudte løsnings egnethed til at understøtte de beskrevne processer og arbejdsgange samt løsningen af de beskrevne opgaver. Der er beskrevet procescases inden for områderne: Kontoplan Budget og budgetopfølgning Debitor Ressourcestyring Indkøb og e-handel Anlægsstyring og anlægsregnskab Betaling (bank, kasse og E-fakturaer) og kreditor Rapportering og analyse Økonomi og regnskab, herunder årsafslutning og omkostningsregnskab Likviditetsstyring Boliglån Mellemkommunale opkrævninger/udbetalinger BILAG 1 C KRAVSPEFICIKATION SIDE 19

24 6.1 Kontoplan Tilbud 47. Tilbud 48. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående kontoplan. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Kontoplan Formål og overordnede krav Det skal være muligt at opbygge og vedligeholde en standardkontoplan, der understøtter kundens krav til økonomistyring og rapportering. Der lægges vægt på en løsning som både tilgodeser krav fra det politiske niveau samt det administrative behov for økonomistyring. Kontoplanen skal give mulighed for en tværgående økonomistyring i hele kommunen eksempelvis ved brug af gennemgående konteringsdimensioner/registreringsniveauer. Der skal være mulighed for at understøtte forskellige decentrale styringsbehov med valgfri opbygning af registreringsniveauer i forhold til specifikke lokale styringsbehov Kundens kontoplan skal afspejle Den politiske kontoplan der fastlægger, hvem der er ansvarlig for bevillingerne og Den administrative kontoplan, der angiver hvem der har ret til at anvise/afholde udgifter og oppebære indtægter. I forhold til styringsbehovene hos de decentrale økonomifunktioner er det målet, at økonomisystemet kan dække alle behovene bl.a. også til styring af disponeringer, således at behovet for regnearksløsninger kan elimineres. Kundens kontoplan skal opbygges i overensstemmelse med den autoriserede kommunale kontoplan. Leverandøren skal sikre, at kontoplanen altid aktuelt kan leve op til de gældende regler i forhold til den af Økonomi- og Indenrigsministeriet autoriserede kontoplan. Beskrivelse af forretningsprocessen og dens kritiske processer Kontoplanen vedligeholdes centralt. Ved behov for nye konti, henvender institutionen sig til den centrale regnskabsfunktion, som herefter opretter kontiene. De kontoplanansvarlige validerer oplysningerne inden konti oprettes. Nogle decentrale økonomifunktioner opretter og anvender efter eget ønske yderligere registreringsniveauer eksempelvis bærere/projektkoder/egen dimension. Systemet skal understøtte organisatoriske ændringer og flytning af opgaver og budgetansvar til andre enheder. Specifikke krav til it-løsning Kontoplanstrukturen skal opbygges således at det er muligt at hente oplysninger på tværs af alle registreringsniveauer. Der skal være mulighed for at gøre dette på et antal niveauer, som ikke må være mindre end 16. Registreringsmulighederne skal kunne findes på flere niveauer, eksempelvis: Nogle registreringskrav vil være gennemgående for hele kommunen, således at der på tværs kan foretages økonomianalyser af bestemte omkostningsarter, eksempelvis bygninger/kurser/konsulentydelser mv. Nogle registreringskrav skal kunne fastlægges for en gruppe af enheder/institutioner (f.eks. for skoler). BILAG 1 C KRAVSPEFICIKATION SIDE 20

25 Navn for processen Kontoplan Andre registreringsmuligheder skal være til fri benyttelse decentralt. Det skal være muligt at opsætte systemet, så der kan fastlægges udvalgte registreringsdimensioner. Teksten skal kunne låses i forhold til den værdi, der registreres. Systemet skal kunne håndtere afløftning af delvis moms, på baggrund af den af leverandøren vedligeholdte positivliste. Systemet skal kunne håndtere splitmoms, dvs. afløftning til både købsmoms og skatmoms samt pr. automatik knytte momskoder til kontoen. Systemet bør kunne give advis (via ) til udvalgte medarbejdere hos decentrale økonomifunktioner, hvis der oprettes/nedlægges konti eller foretages budget- eller udgifts-/ indtægtsændringer. Systemet skal gennem validering sikre, at der er en entydig sammenhæng mellem kontoplan i økonomisystem, lønsystem og fagsystemer. Øvrige forhold vedrørende kontoplan Kunden har i øvrigt i forbindelse med kontoplanen fokus på: At kontoplanen er logisk og intuitivt opbygget med genkendelige termer. At der kan foretages omplaceringer decentralt, og at disse automatisk henføres til den overordnede centrale kontoplan, således at det decentrale budget altid stemmer overens med det overordnede budget. Således må der f.eks. ikke overflyttes midler fra det rammebelagte område til det takstfinansierede område, mellem budgetområder o.lign.. At der er mulighed for andre tværgående udtræk end politisk og administrativ struktur (defineret af kunden) At der er mulighed for at oprette decentrale kontoplaner målrettet institutionens styringsopgave. At der er mulighed for at følge op på data på en enhed uden for det formelle administrative hierarki (Eks. Skolelederen er formel administrativ ansvarlig for SFO en, men SFO-lederen skal også selv kunne følge op på egne data. Administrativ medarbejder i et administrativtfællesskab skal kunne følge op på samtlige administrerede enheder) At konti, dimensioner mv. kan styres på dato og år. Systemet skal kunne styre (periodisere) de autoriserede kontotekster, politiske og administrative tilhørsforhold mv. At det er muligt at slette kontonumre, kontotekster mv. som ikke benyttes længere At det fremgår, når en konto er lukket. Det skal dog være muligt at lukke en konto for bogføring, selvom der er budget og/eller forbrug på. Budgettet og forbruget skal dog fortsat fremgå af indeværende års rapporter.. At det er muligt at nedlægge gamle konti og tilhørende tekster, der ikke har været i brug i flere år. BILAG 1 C KRAVSPEFICIKATION SIDE 21

26 Navn for processen Kontoplan At der kun kan bogføres på oprettede konti At der kan søges uafhængigt på alle dimensioner i kontoplanen At kontoplanen benytter genkendelig og let forståelig terminologi At kontotekster har en længde, der som minimum kan rumme tekstlængden i den autoriserede kontoplan At der kan vedhæftes dokumenter som dokumentation for ændringer (f.eks. mails, Worddokumenter, pdf, hyperlinks mv.) At det er muligt fra et oversigtsbillede at se hvorvidt, der er dokumentation vedhæftet. At det for alle brugere er muligt at se den aktuelle kontoplan. At kontoplanen kan skrives ud og overføres til regneark. At kontoplanen kan kopieres, og nye dannes ud fra en vedligeholdt skabelon At der kan foretages masseændringer. At alle ændringer logges og opslag skal være lettilgængelige, brugervenlige og forståelige. Ved flytninger af kontonr., enheder o.l. er det vigtigt at historik bevares af hensyn til udtræk. At eksisterende konti kan ændre strukturmæssige dimensioner mv. pr. en given dato og dermed beholde historik for ændringsdatoen. At ændringer til den autoriserede kontoplan ajourføres pr. automatik, herunder positivlisten. At konti hvor budgettet er nulstillet kan lukkes i indeværende år således at de ikke skal vente med at udgå af kontoplanen til efter de tre overslagsår. Det er et krav, at der kan oprettes konti, der ligger uden for de autoriserede funktioner (eksterne konti). Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kontoplanen har snitflader og berøring til en lang række systemer, hvoraf lønsystemet må karakteriseres som det mest kritiske. Når der fra andre systemer dannes bogføringsposteringer, skal der i disse systemer ske en automatisk validering af den konto, der bogføres på. Det skal på kontoen kunne anføres, om der er krav om registrantbogføring. Ved krav om registrantbogføring, skal systemet ved indberetningen validere at registrant angives. Dette gælder også for bogføringer i lønsystemet på registrantbærende konti. Ved bogføring af e-bilag skal der valideres for momsafvigelser. Systemet skal understøtte oprydning og lukning af ikke brugte konti herunder også tekster. BILAG 1 C KRAVSPEFICIKATION SIDE 22

27 Navn for processen Kontoplan Kvantitative forhold ved processen Kunden har i dag ca aktive konti og i alt BILAG 1 C KRAVSPEFICIKATION SIDE 23

28 6.2 Budget og budgetopfølgning Tilbud 49. Tilbud 50. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående økonomi og budget. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Budget og budgetopfølgning Formål og overordnede krav Kunden ønsker et system, der effektivt understøtter udarbejdelse af budgetter og den løbende opfølgning på budgetoverholdelsen samt overblik over forventet regnskab. Kunden skal være i stand til at arbejde med budgetter på mange niveauer med henblik på politisk vedtagelse af et budget i balance. Desuden skal budgettet løbende udgøre et opdateret styringsgrundlag for økonomistyring herunder budgetopfølgning og budgettilpasning. Kunden skal kunne udarbejde budgetter, der kan anvendes til styring i forhold til det politiske niveau samt i forhold til de administrative behov på forskellige niveauer. Kunden ønsker at kunne arbejde med forskellige budgetversioner og klart at kunne skelne mellem disse. Der ønskes et ubegrænset antal versionsmuligheder eks. Budgetudkast 1, budgetændringer, vedtaget budget. Budgetversioner skal kunne kombineres på tværs og sammensættes efter eget ønske. I vedtaget budget skal der efterfølgende kunne indberettes tillægsbevillinger, omplaceringer og overførsler mv. Kunden ønsker, at økonomisystemet indeholder funktioner til budgetsimulering og op- og nedskrivninger af budgettal, PL-regulering både i forhold til den centrale budgetfunktion samt decentrale økonomifunktioner. Kunden ønsker, at systemet understøtter udviklingen af kundens arbejdsgange til at være mindre manuelle og mere systemunderstøttede, for derved at øge effektiviteten og kvaliteten. Beskrivelse af forretningsprocessen Den årlige budgetlægning i kommunen udgøres overordnet af følgende aktiviteter: Tidsplanlægning af budgetprocessen. Budgetfremskrivning baseret på budget for overslagsårene (4 år) og fremskrivninger (prisog lønfremskrivninger etc.) Budgetrammer sendes til fagudvalg og decentrale enheder. Fagudvalgene udarbejder forslag til budget. Fagudvalgenes budgetforslag samles til et budget. Budgetopfølgningens delprocesser udgøres af: Løbende budgetopfølgning med detaljeret rapportering på alle niveauer. BILAG 1 C KRAVSPEFICIKATION SIDE 24

29 Løbende kommunikation og formidling af budgetstatus på alle niveauer og for alle perioder. Håndtering af dokumentation og bemærkninger til budgetopfølgning, herunder forventet regnskab. Håndtering af tillægsbevillinger. Omplacering af budgetposter, herunder detaljeret udmøntning. Kunden ønsker budgetopfølgningen integreret i økonomisystemet eller en højere grad af automatisering af processen, gerne både decentralt og centralt i Økonomistaben Både ved budgetlægning og budgetopfølgning er der i dag i høj grad tale om manuelle arbejdsgange. Specifikke krav til it-løsning Dannelse af budget Hver budgetversion skal kunne påføres et versionsnummer og en dato for dets dannelse. Desuden skal det til hver version kunne knyttes en tekst med forklaring til budgetversionen. Nye budgetversioner skal kunne dannes ved kopiering fra andre budgetversioner (f.eks. vedtagne budgetversioner fra tidligere år). Der skal være mulighed for at tilknytte mængder, normer og aktiviteter til budgetbeløbet med mulighed for automatisk justering af budgettet. Ændringen skal slå igennem i budgetbemærkningen. Effekten af ændringen skal fremgå direkte (online). Ordinære budgetposter samt tillægsbevillinger, omplaceringer og overførsler skal hver registreres med en særlig type og en registreringsdato, så der kan laves udtræk på den enkelte type. Kunden ønsker mulighed for selv at oprette/navngive et ubegrænset antal typer. Det skal være muligt at kunne følge mellem hvilke konti en eventuel omplacering/ompostering foretages. Der skal ske registrering af, hvem der har indtastet budgetposter og af tidspunkt for posteringen. Desuden skal der kunne tilknyttes en forklarende tekst, gerne i ubegrænset længde. Det skal på en simpel måde kunne kontrolleres, om indberetninger er i balance. Ved rammeudmeldinger til institutioner skal den enkelte enhed have mulighed for at lave omplaceringer inden for rammen. Omplaceringerne skal slå igennem til overordnet samlet budgetversion. Der ønskes mulighed for at markere/sammenkoble relaterede poster f.eks. vedrørende refusioner, hvor der ved ændringer er sammenhænge mellem forskellige kontonumre men med forskellig effekt (f.eks. 100 % effekt på en konto og 60 % effekt på en anden konto). Periodisering af budgettet skal kunne understøttes både centralt og decentralt. Periodisering skal understøtte både 1/12, forskellige procentfordelinger på poster samt valgfri periodisering af budgettet, og der skal kunne overføres historik fra tidligere år. Der ønskes mulighed for at påføre en uddybende tekst samt vedhæfte diverse dokumenter til budgetter og budgetposter. F.eks. ønskes mulighed for at vedhæfte dokumenter (regneark, Word, PDF mv.)/linke til dokumentation i kundens ESDH-System af takstmodeller, BUM, demografimodeller osv. på en let måde. Der tilknyttes metadata til sagen (DUT-sag, 0-sag, mængde justeringer mv.) Der ønskes i forbindelse med budgetfunktionen en mulighed for via systemet at sende ADVIS BILAG 1 C KRAVSPEFICIKATION SIDE 25

30 til udvalgte nøglebrugere, f.eks. hvis der centralt indtastes budgetposter med decentral virkning. Tilsvarende ønskes der mulighed for automatisk at sende ADVIS til udvalgte nøglemedarbejdere ved centrale bogføringer og omposteringer på decentrale konti. Udtræk af information/rapporter I forbindelse med standardrapporter vedrørende forbrug og budget skal systemet default anvende gældende budgetversion. Der skal være mulighed for i forbindelse med ad hoc rapporter at kunne vælge, hvilken budgettype og version, der skal anvendes. I den almindelige rapportering skal man kunne angive, om man ønsker overførsler, omplaceringer og tillægsbevillinger medtaget eller ej, og der skal være mulighed for at se alle typer i samme rapport i hver sin kolonne. Desuden skal man kunne anføre en dato for, hvilke tillægsbevillinger og omplaceringer, der skal tages med i budgettet. De nævnte valg skal fremgå at rapporteringen. Der skal kunne udtrækkes på typer. Efter at alle korrektioner er indarbejdet, skal det være muligt at lave et udtræk over de korrektioner, der er foretaget. Eventuelt skal der indarbejdes en automatisk kontrol for godkendelse af korrektioner inden korrektionerne får effekt. I forbindelse med udtræk af rapporter skal der være fleksibilitet i forhold til hvor mange informationer, der kan ses, f.eks. ønskes mulighed for at lave udtræk med flere kommentarkolonner på skærmen samtidig. Herunder skal der være mulighed for at udtrække en budgetrapport med tilhørende indberettede budgetkommentarer. Det ønskes tillige mulighed for at lave et samlet udtræk over givne tillægsbevillinger inden for et nærmere udvalgt område med tilhørende indberettede budgetkommentarer. Det ønskes at systemet indeholder funktionaliteter, der understøtter kundens behov for at danne forventet årsregnskab på alle niveauer. Endvidere ønskes der et brugervenligt system, der er overskueligt og nemt at arbejde med og som samtidig indeholder avancerede simulerings- og rapporteringsværktøjer. Der ønskes mulighed for at udtrække data i både faste og løbende priser for valgfrit år. Budgetopfølgning/Ledelsestilsyn De budgetansvarlige centerchefer og institutionsledere skal foretage månedlig opfølgning på deres budget og forbrug, samt foretage bilagskontrol på minimum 2 % af de bogførte bilag. Økonomisystemet skal give mulighed for at understøtte denne opgave, samt give mulighed for at dokumentere udførelsen og centralt at overvåge at alle udfører opgaven. Kunden ønsker at de budgetansvarlige har adgang til at arbejde med deres kontoområde, så de kan starte på et overordnet niveau og dykke længere ned i detaljerne efter behov. Kundens principper for ledelsestilsyn er følgende: Der skal centralt kunne opsættes og målrettes en eller flere månedlige rapporter til lederen. Lederen skal elektronisk kunne anvise denne/disse rapporter og påføre kommentarer. Samme sted som lederen påfører sine kommentarer ønsker kunden mulighed for at opsætte f.eks. afkrydsningsfelter som lederen kan markere for elektronisk at bekræfte at tilsynet er udført på specifikke områder (f.eks. at løn og medarbejderdata er kontrolleret). Disse felter skal kunne defineres af kunden. Lederen skal via rapporten have adgang til alle posteringer og elektroniske bilag og skal elektronisk kunne bekræfte, at udvalgte posteringer er kontrolleret. Der skal være brugervenlige søgemuligheder i rapporten samt integration til lønsystem. Der skal kunne adviseres og rykkes for BILAG 1 C KRAVSPEFICIKATION SIDE 26

31 manglende anvisning på mail. Der skal kunne udskrives en rapport over de ledere der ikke har udført deres tilsyn i en given periode. Øvrige krav: At der er mulighed for detaljeret tilpasning af brugeradgangen for den enkelte decentrale bruger (både funktionalitets- og dataadgang). At der er mulighed for at styre brugeradgangen til budgetmodellerne. At decentrale enheder inden for gældende rammer selv kan omplacere budgettet. Således må der f.eks. ikke overflyttes midler fra det rammebelagte område til det takstfinansierede område. At løsningen kan understøtte automatisk udrulning af rammebesparelser. At der er adgang til en veludbygget dynamisk to-vejs integration til regneark i foruddefinerede skabeloner, således at data nemt kan trækkes ud for manuel behandling (f.eks. udmøntning af budgetposter), behandles i regneark og nemt genindlæses/opdateres i økonomiløsningen. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 27

32 6.3 Debitor Tilbud 51. Tilbud 52. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående debitor. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Debitor Formål og overordnede krav Kunden ønsker, som en del af økonomisystemet, et debitorsystem, der dels kan modtage transaktioner fra diverse modersystemer, udskrive FIK-kort samt danne fakturaer fra kommunens øvrige fagområder og dels kan håndtere funktioner vedr. betalingskontrol, restancer mv. Kundens arbejdsgange omkring udsendelsen af FIK-kort, fakturaudskrivning og betalingskontrol håndteres i dag gennem forskellige systemer. Der ønskes en fremtidig løsning hvor alle debitoropgaver løses i et og samme system. Kunden ønsker, at al registrering i systemet sker on-line, således at der til hver en tid er adgang til ajourførte data, uden at der skal ventes på særlige kørsler. Fra modersystemer ønskes en daglig opdatering. Beskrivelse af forretningsprocessen Krav oprettes i fagsystemerne, hvorefter data overføres til debitormodulet. Det skal være muligt at vælge om faktura udskrives fra fagsystemet eller fra debitormodulet og udsendes til debitor. Kontering foretages samtidig. Det vil være ønskeligt, at påligninger kan føres tilbage. Debitormodulet anvendes til opkrævning af krav, der ikke opkræves via fagsystemer. Når et krav er oprettet i debitormodulet udskrives faktura. Kontering foretages samtidig i økonomisystemet. Tilgodehavender kan også indberettes manuelt i debitormodulet, som konteres automatisk i økonomisystemet. Indbetalinger bogføres via, bank og BS. Det skal i debitormodulet være muligt manuelt at ompostere og bogføre modtagne indbetalinger. Det skal på posteringen være synligt, hvorfra indbetalingen kommer. I forhold til betalingskontrol køres der rykkerkørsler, og rykkerskrivelser udsendes til modtagerne. Restancer, som ikke umiddelbart betales, håndteres i en særlig sagsbehandling. Der skal være mulighed for midlertidig stop af rykning for en enkelt borger samt en betalingsart. Det vil være ønskeligt at rykkerkørsler kan føres tilbage. I forbindelse med rykkere pålignes gebyr og renter. Renten skal kunne beregnes på den enkelte art og det enkelte krav. Der skal kunne udskrives restancelister, påligningslister, beholdningsoversigt, RGA-lister og indbetalingslister. Fordringer sendes til modregning via SKAT. Særlige forhold vedr. restancer håndteres i form af afdragsordninger samt overdragelse af BILAG 1 C KRAVSPEFICIKATION SIDE 28

33 restancer til SKAT. Specifikke krav til it-løsning Generelle krav til debitormodulet Debitormodulet skal understøtte alle former for regninger/fik-kort som anvendes i offentlige institutioner, herunder papirbaserede regninger, BS-regninger og e-fakturaer. Der skal kunne tilmeldes Betalingsservice både via betalingsarter og betalingsaftaler. Kopier af fakturaer/kreditnotaer skal kunne lagres elektronisk og genudskrives. Fakturaer/kreditnotaer skal kunne sendes/gensendes elektronisk. Via debitormodulet skal der kunne oprettes fakturaer/kreditnotaer. Disse skal også kunne fremsendes elektronisk. Via debitormodulet skal det være muligt at oprette flergangsfakturaer der automatisk udsendes med valgte intervaller (eks. månedsvis, kvartalsvis, halvårligt, årligt). Det skal være muligt at oprette skabeloner til udskrivning af faktura til flere personer f.eks. via fletning fra datafil (eks. i Excel og Word). Det skal være muligt at oprette et tekstregister der kan anvendes i forbindelse med dannelse af fakturaer/kreditnotaer, rykker og opkrævningstekst i debitormodulet. Der skal være gode søgemuligheder, så det er nemt at finde frem til fakturaer der er dannet i debitormodulet f.eks. via CPR-nr./fakturanr., navn mv. Når fakturaer er fundet frem skal man direkte derfra kunne danne en kreditnota. Fakturaer skal kunne sendes til digital postkasse. Debitormodulet skal kunne håndtere løbende periodisk opkrævning f.eks. for opkrævning for daginstitution. Der skal være mulighed for at henlægge sagen i en periode. Der skal kunne tilføjes afdragsaftaler. Der skal kunne registreres ejerskifte. Der skal være mulighed for at redigere allerede udlignede poster. Det er kommunens ønske selv at kunne foretage straks-udskrivning af fakturaer, herunder afgørelser om tilbagebetaling af kontanthjælp. Sagsbehandlerbilledet skal på en overskuelig måde vise alle restancer. Der skal være mulighed for at definere og opsætte hvilke informationer, der ønskes vist på skærmbilledet. Restancer skal kunne vises i både klar tekst og betalingsarter. Det skal være muligt at se historiske krav, som er arkiverede. Det skal være muligt selv at definere minimumsgrænsen for rykkerkørsler. BILAG 1 C KRAVSPEFICIKATION SIDE 29

34 Alle ændringer i kommunens krav, betaling/påligning, rentetilskrivning etc. skal ajourføres automatisk i EFI. Betalingskontrol Indbetalinger udligner vha. betalingsidenten i videst muligt omfang de pålignede krav. Der skal automatisk kunne pålignes gebyrer og renter i forbindelse med rykning ved manglende indbetaling. Størrelsen af gebyret skal kunne bestemmes ud fra størrelsen på det skyldige beløb/kravstype. Der skal være adgang til en advis-funktion, der kan opsættes efter forskellige hændelser i systemet samt mulighed for individuelle advis indberetninger. Restancer skal kunne nedskrives/opskrives. Systemet skal indeholde en journalfunktion, hvori alle hændelser i systemet registreres i forhold til den enkelte borger. Herunder omkonteringer, korrektioner, rateændringer og meddelelser fra EFI. Der skal desuden være et notatfelt. Endvidere skal være mulighed for vedhæftning af filer eksempelvis notater, tilbagebetalings-afgørelser, beregninger mv. (Office og PDF) Alle dokumenterne skal kunne tilgås fra debitormodulet. Der skal fra debitormodulet kunne dannes og udsendes valgfri skrivelser til borgeren. Alternative adresser skal kunne registreres og anvendes. Øvrige forhold Omkonteringer i debitor skal kunne ses straks. Alle hændelser skal gemmes i en journal i systemet og der skal være mulighed for manuelt at vedligeholde et notatfelt. Systemet skal understøtte kundens behov for ledelsesinformation, herunder opsætning af standardudtræk og udtræk af statistiske opgørelser, eksempelvis i forhold til antal sager, kr. og arter og restancer hos SKAT. I forhold til den daglige anvendelse af systemet skal der være udbyggede søgemuligheder og udtræksmuligheder. Det er et ønske fra kommunen, at bogføring kan ses med det samme efter registreret indbetaling. Dette vil mindske antallet af fejludsendte rykkere. Systemet skal kunne udskrive en log over ned-/afskrivninger. Mulighed for borgeradgang til overblik over udeståender hos kommunen via borger.dk. Systemet skal understøtte muligheden for at kunden kan lave selvbetjeningsløsninger via borger.dk. Der skal være mulighed for under hver restanceart at vedhæfte dokumentation for kravet f.eks. tilbagebetalingspligterklæringer fra KMD-aktiv osv. Udbetalinger til debitor skal kunne ske direkte fra debitormodulet til debitorens NemKonto. Indberetning til modregning ved SKAT skal ske automatisk. BILAG 1 C KRAVSPEFICIKATION SIDE 30

35 Rentesatser skal indberettes overordnet. Bestilling af opkrævnings- og FIK-kort skal ske automatisk Afskrivning med automatisk bogføring og mulighed for udtræk af rapport til dokumentation. Rapporten skal kunne vise fra samlet afskrivning helt ned til betalingsart og CPR- og CVR niveau. Der skal ske automatisk oprydning af færdigbetalte krav. Alle passive forhold skal ligge i et tilgængeligt elektronisk arkiv, hvorfra der kan printes. Fik-kort, rykkerskrivelser, diverse skrivelser skal kunne arkiveres Bogføring og afstemning skal kunne foretages ved anvendelse af restance- og mellemregningskonti. Det skal være muligt at kunne køre og ændre batchjob efter behov, f.eks. PBS. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Nets (PBS) fakturering og indbetaling skal kunne ske via PBS NemKonto beløb skal automatisk kunne overføres til NemKonto Digital postkasse SKAT der skal være en snitflade for overførsel af restancer til SKAT/EFI/Borger.dk. SKAT modregningsmodul til overskydende skat/moms mv. CPR/CVR. Indlæsning af påligninger fra Microsoft Excel Diverse fagsystemer/3. partssystemer MS Office, KMD Aktiv, KMD ESR struktura, KMDbyggesag, Boliglånssystem, SpeedAdmin, KMD Institution, Affaldsweb fritagelsessystem. Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 31

36 6.4 Ressourcestyring Tilbud 53. Tilbud 54. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående ressourcestyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Ressourcestyring Formål og overordnede krav Kunden ønsker et økonomisystem, der understøtter kommunens behov for ressourcestyring i forhold til opgaver i kommunens Center for Teknik & Miljø. Kunden skal, hvor det er relevant, kunne detailstyre ressourceforbruget (f.eks. ved indberetning af timer på projekter etc.) på effektiv og professionel vis, og de forbrugte ressourcer skal afspejles i økonomisystemet. Der skal være mulighed for regulering af priser på de enkelte projekter. Ressourcestyring udgør den primære styringsmetode for en stor del af kommunens aktiviteter på det tekniske område, hvorfor en brugervenlig og fleksibel løsning som lader sig skalere/tilpasse til kommunens specifikke aktiviteter på det område er essentiel for effektive arbejdsgange. Beskrivelse af forretningsprocessen Ressourcestyringen og økonomistyringen forgår i dag i MicrosoftDynamics2009. Medarbejderne i Teknik & Miljø benytter i dag ressourcestyringen til at registrere forbrug på projekter og fra det registrerede forbrug fakturere for ydelsen. Delprocesser vedrørende ressourcestyring udgøres overordnet af: Oprettelse og vedligeholdelse af ressourcer og projekter Tidsregistrering på projekter Rapporter over tidsforbrug pr. medarbejder eller pr. opgave mv. Div. rapporter, herunder tværgående rapporter på Hoved og Underaktiviteter. Ekstern fakturering massedannelse af fakturaer Intern afregning (intern fakturering) Udlæsning og bearbejdning af data på tværs i EXCEL Specifikke krav til it-løsning Der lægges vægt på den tilbudte løsnings understøttelse af de nævnte delopgaver og delprocesser i forbindelse med ressourcestyring og projektstyring. Løsningen anvendes udelukkende inden for det tekniske område, men en fremtidig løsning skal give mulighed for en potentiel udbredelse til yderligere områder. Der ønskes en ressourcestyringsløsning, som er integreret med økonomisystemet, således at bogføring af økonomiposter sker automatisk, baseret på ressourcestyringsdata. Det er væsentligt, at der kan foretages detaljeret, tværgående rapportering på basis af de data i økonomisystemet, som hidrører fra ressourcestyringen. Desuden ønskes: Dataudtræk på tværs af systemet og med mulighed for opslag fra dataudtrækket direkte i systemet. BILAG 1 C KRAVSPEFICIKATION SIDE 32

37 Adgang til historiske data Tekstfelt til præcisering på hvert enkelt projekt Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Integration til lønsystemet og økonomisystemet, herunder debitorsystem Yderligere integrationer, se generelt afsnit desangående Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 33

38 6.5 Indkøb og e-handel Tilbud 55. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående indkøb og e- handel. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Tilbud 56. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Indkøb og e-handel Formål og overordnede krav Kunden ønsker at sikre, at indkøb sker økonomisk mest fordelagtigt. Dette kræver adgang til et system, som understøtter indkøbsprocessen fuldt ud gennem alle dens aktiviteter. Kundens indkøbere skal nemt og effektivt kunne orientere sig om kommunens indkøbsaftaler for varer og tjenesteydelser, merkantile forhold samt nemt og effektivt foretage deres indkøb af varer elektronisk. Kundens arbejdsflow omkring bestilling af varer, varemodtagelse, godkendelse, fakturagodkendelse og kontering skal køre effektivt og digitaliseres i størst muligt omfang. Kunden lægger vægt på, at indkøbssystemet er fuldt integreret i økonomisystemet, så dobbeltregistreringer undgås, og så der er fuldt overblik fra økonomisystemet over igangværende og afsluttede indkøb. Kundens indkøbssystem skal understøtte ønsket om at øge anvendelsen af de indkøbsaftaler, kommunen har indgået. Kunden lægger vægt på, at systemet understøtter løbende opfølgning på indkøb, herunder at brugerne handler elektronisk når der er mulighed for det. Kunden ønsker, at decentrale brugere, som ikke har direkte adgang til kommunens administrative netværk, får adgang til at e-handle gennem indkøbssystemet som kan tilgås via internettet. Beskrivelse af forretningsprocessen Der indgås indkøbsaftaler for hele kommunen. Aftalerne kan være indgået via FusUdbud, SKI, og egne udbud (evt. i samarbejde med én eller flere kommuner). Aftalerne placeres tilgængeligt for kommunens medarbejdere, og de relevante medarbejdere orienteres om nye aftaler eller ændringer i eksisterende aftaler. Der foretages lejlighedsvis compliance-analyser (via BuboBubo indkøbsanalysesystem) for at følge op på brugen af indkøbsaftalerne. Kommunen anvender i dag et indkøbssystem, som er en integreret del af Økonomisystemet. Brugere på alle decentrale niveauer foretager deres indkøb via E-handel hvor det er muligt og hensigtsmæssigt for dem. Kommunen anvender Indkøbssystemet til varemodtagelse og kontering leverandørfakturaen. Specifikke krav til it-løsning Kunden ønsker, at følgende delprocesser understøttes af IT-systemet: Etablering og vedligeholdelse af indkøbsaftaler BILAG 1 C KRAVSPEFICIKATION SIDE 34

39 Ved opdatering og administration af elektroniske varekataloger, automatisk markering af varer der ikke er omfattet af aftalen. Mulighed for at kontrollere varekatalog ud fra indlæst tilbudsliste. Mulighed for at genbehandle et katalog uden involvering af leverandør. Mulighed for at godkende et katalog med fremtidig eller bagudrettet dato. Mulighed for at søge efter varekatalog via leverandøren. Ved indlæsning af elektronisk varekatalog, skal der med afsæt i en given aftalt prisstigning være mulighed for nemt at foretage et pristjek af fortsættende og nye varer inden varekataloget indlæses. Bl.a. ved kun at udfærdige rapport med prisstigninger, der er over den givne prisstigning. Ved indlæsning af elektronisk varekatalog skal der kunne udfærdiges en rapport med nye/og uønskede varer. Favoritsider, favoritliste og standardordrer (på alle niveauer) Nyhedsformidling vedr. indkøb og indkøbsaftaler mv., herunder mulighed for at målrette information til bestemte brugere/afdelinger. Ad hoc opfølgning på indkøb (Statistikker på brugerniveau, institutionsniveau mv. med mulighed for udtræk til Excel) Mulighed for at kategorisere fakturalinjer ud fra UNSPC. Faste udtræk efter fast defineret skabelon, f.eks. månedlige udtræk Fuld integration til Excel. Mulighed for at udskrive indkøbslister, standardlister mv. IT-løsningen skal understøtte følgende enkelte delprocesser vedrørende elektroniske indkøb: Udvidet søgning og visning af varer eller søgning efter indkøbsaftale Bestilling af varer Varemodtagelse, afstemning af leverancer og følgesedler og håndtering af restordrer Fakturamodtagelse, anvisning, attestering og kontering af fakturaer, match af priser mellem faktura, ordre og indkøbsaftale og automatisk betaling ved match af ordre og faktura så processerne er så effektive som muligt så dobbeltkontrol undgås. Kreditnotater på fakturaer med fejl, fejlleverancer mv. Der lægges vægt på følgende specifikke forhold ved It-løsningen Der skal være oversigt over indlæste kataloger med mulighed for at bladre igennem et varekatalog. Der skal i indkøbssystemet være mulighed for at finde alle fakturaer og kreditnotaer via forskellige søgemuligheder, eksempelvis at søge på bestemte typer oplysninger og foretage tværgående søgning på alle oplysninger. Det skal være muligt at søge alle fakturaer og kreditnotaer frem i indkøbssystemet uanset om de ligger på samme ordre (via fakturaoplysningerne). Ved visning af varer, skal visning ske med en linje pr. vare i et oversigtsbillede. Liste over udsøgte varer skal kunne udskrives Mouse over funktion, så f.eks. billede, varebeskrivelse mv. vises (og brugernavn de steder hvor brugernr. er vist). Ved e-handlede ordrer skal der være fakturamatch. Fakturabehandling skal ske i Økonomisystemet BILAG 1 C KRAVSPEFICIKATION SIDE 35

40 Ved varedifference skal det tydeligt vises (ved markering e.l.), hvilke varer der udgør differencen. Dette uanset om differencen skyldes prisdifference, eller fordi der er difference i vareantal mv. Ud fra listen over varer skal man kunne få adgang til mere detaljerede oplysninger om den enkelte vare f.eks. ved klik på varelinjen, hvis vareleverandøren har medsendt disse oplysninger. Beskrivelse af varen skal indeholde billede og mulighed for mærkning, f.eks. miljømærke og energimærke mv. Mulighed for markering af tilbudsvarer, øvrigt varesortiment m.v. Hvis en vare på en standard/favoritliste udgår af katalog skal listen og varen på listen markeres så dette fremgår tydeligt. Hvis der er foreslået en erstatningsvare skal systemet give brugeren mulighed for at udskifte varen. Når en vare er fundet i kataloget, skal den både kunne bestilles og i samme arbejdsgang kunne tilføjes til en eller flere standard-/favoritlister. Kunden ønsker mulighed for selv at tilføje søgeord på vareniveau, der ikke overskrives ved indlæsning af nye varekataloger. Mulighed for at søge på varer der bærer diverse markeringer (f.eks. økologimærke, svanemærke, mærke for specielle tilbud) Mulighed for at arbejde med flere varekurve samtidig. Mulighed for at faktura der ikke er e-handlet bliver vist med en markering i brugerens fakturaoversigt, hvis der er handlet med en leverandør hvor det er muligt at e-handle. Kunden skal selv tilvælge denne funktion på udvalgte leverandører. Ved bestilling af varer skal der være mulighed for at slette eller tilføje varelinjer Ved bestilling af varer skal der være mulighed for indtastning af kontonummer, som efterfølgende påføres faktura. Det skal være muligt på enkelte udvalgte leverandører og afdelinger at opsætte konteringsregler der gør det muligt at systemet automatisk varemodtager og bogfører en faktura når der er påført kontostreng. Uanset hvilken type kontoplan kunden har, skal det være muligt at aflevere kontostreng, så den er påført faktura når denne modtages. Der ønskes mulighed for at EAN-nr., leverings- og faktureringsadresse er tilknyttet den enkelte bruger som default værdi. Leveringsadressen skal kunne ændres eksempelvis steder hvor en medarbejder på områdekontoret bestiller varer for flere institutioner, til levering og betaling decentralt. Det skal være muligt at lægge de oftest anvendte konteringsoplysninger ind for hver bruger, så kan vælges på bestillingsoversigten når der bestilles. Det skal være muligt at generere betalingsoversigter og statistik på alle data på baggrund af såvel afsluttede som ikke afsluttede ordrer. Statistik skal kunne udtrækkes i forhold til alle BILAG 1 C KRAVSPEFICIKATION SIDE 36

41 følgende nævnte dimensioner leverandører, sted/bruger, tid og varer (herunder på fri tekst og/eller på UNSPC-koder). Der skal kunne udtrækkes ledelsesinformation i form af rapporter med compliance-analyser som kan videreformidles pr. mail i vedhæftet fil direkte fra systemet. Øvrige krav: Mulighed for et aftalemodul, hvor samtlige indkøbsaftaler lægges ind og som minimum giver automatisk besked ved aftaleudløb. Aftalerne skal kunne indgå i diverse analyser, udtrækkes til f.eks. regneark mv. Eventuel besked ved udløb inden for et af kunden valgt interval inden aftaleudløb afhængig af, hvad der efterfølgende skal ske. Aftaleperioderne skal kunne reguleres manuelt både start og slutdato. Mulighed for udsøgning af indkøbsaftaler alfabetisk efter leverandør og efter produktgruppe. Mulighed for et modul hvor der kan lægges indkøbstekniske oplysninger, nyheder, brugervejledninger ind. Der skal være mulighed for at opdatere leverandørregistret ud fra oplysninger i CVRregistret. Mulighed for lagerstyring eller fastsættelse af regelmæssige leverancer til f.eks. institutioner. Det skal være muligt at kunne varemodtage uden at kunne bogføre. Det skal være let for brugere at kunne varemodtage egne fakturaer uden i øvrigt at have et større kendskab til systemet. Der skal være mulighed for konteringsoplysninger i form af kontonummer og egen posteringstekst på varelineniveau, f.eks. IT-ordrereference eller initialer. Der skal være mulighed for ved fakturabehandlingen at fordele fakturabeløb på varelinieniveau på flere konti. Der skal være mulighed for at samle flere varelinjer/fakturalinjer til en konteringslinje. Mulighed for at hente fakturalinjer til kontering. Der skal på en leverandør kunne indsættes oplysninger om forskellige betalingsformer og betalingsvilkår. Betalingsvilkår fra leverandørregistret skal automatisk anvendes ved indkøb. Afgivne ordre bør i systemet medtages som disponeringer ved beregning af råderum. Ved betaling skal disponeringen modregnes. Det skal være muligt at lave intern elektronisk afregning via e-bilag. Til brug ved indkøbskontrol, skal der kunne udskrives afdelingsrapporter over indkøb samt en rapport til brug ved stikprøvekontrol af indkøb, hvor der udtrækkes alle indkøb til kontrol på tilfældige datoer. Ved delleverance ønskes der mulighed for at delfakturere, og mulighed for at den efterfølgende restfaktura rammer den oprindelige ordre så der stadig er pristjek. BILAG 1 C KRAVSPEFICIKATION SIDE 37

42 Der ønskes online opdatering af økonomisystemet ved bogføring af blandt andet e-fakturaer. Der ønskes en webbaseret adgang til indkøbsmodulet. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Indkøb foretaget via e-handel skal kunne lagerføres i ressourcestyringssystemet i forbindelse med fakturagodkendelse. Det skal være muligt at oprette snitflader til eksterne leverandørers kataloghåndtering. Kvantitative forhold ved processen Vi modtager og behandler elektroniske fakturaer dagligt. Vi har ca. 650 brugere der anvender systemet til E-handel og/eller behandler e-fakturaer. BILAG 1 C KRAVSPEFICIKATION SIDE 38

43 6.6 Anlægsstyring og anlægsregnskab Tilbud 57. Tilbud 58. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående anlægsstyring og anlægsregnskab. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Anlægsstyring og anlægsregnskab Formål og overordnede krav Kunden skal kunne styre og udarbejde korrekte anlægsregnskaber for anlægsprojekter til brug for daglig drift samt politisk behandling mv. Kunden ønsker mulighed for i økonomisystemet at kunne styre anlægsprojekter, og at der i forbindelse hermed sker en automatisk overførsel af oplysninger om igangværende og afsluttede anlægsprojekter til anlægskartoteket (anlægsaktiver). Til disse styringsopgaver hører: Mulighed for at styre flerårige anlægsprojekter med en samlet anlægsbevilling fordelt over årlige rådighedsbeløb. Bevilling og rådighedsbeløb skal sammenholdes med forbruget. Mulighed for at synliggøre, hvordan kommunens årlige råderum og likviditet påvirkes, hvis anlægsprojekter gennemføres med en anden tidsmæssig profil end forudsat ved budgetlægningen. Mulighed for at tilgodese kommunalbestyrelsens krav om et overskueligt anlægsregnskab. Registrering af anlægsaktiver i et anlægskartotek, der som minimum tilgodeser de lovmæssige krav samt mulighed for at kunne vedligeholde et kartotek over alle kommunens aktiver med beskrivelse af aktivet og dets afskrivningsprofil, samt mulighed for at kunne udarbejde regnskab over anlægsaktiver. Beskrivelse af forretningsprocessen Den overordnede proces vedrørende anlægsstyring og udarbejdelse af anlægsregnskab indeholder følgende aktiviteter: Budgettering af udgifterne, godkendelse af anlægsbevilling, frigivelse af rådighedsbeløb, budgetjusteringer, forbrug fordelt på regnskabsår og på artsniveau, løbende opfølgning på forbrug pr projekt/anlægsbevilling samt afslutning og udarbejdelse af anlægsregnskab. Anlægsstyring indeholder delprocesser vedrørende: Fleksible forespørgsler og opfølgning på anlægsbevillinger, rådighedsbeløb og forbrug. Salg af anlægsaktiver med tilhørende nedskrivning af værdien af anlægsaktiverne. Rapportering på forbrug og disponering. Anlægsregnskaber indeholder delprocesser vedrørende: Udarbejdelse af anlægsregnskaber ved anlægsprojekters afslutning og ved årsafslutninger, indeholdende budget, rådighedsbeløb, forbrug og forventet forbrug resten af regnskabsåret og resten af anlægsperioden (dispositionsregnskabet). Udarbejdelse af anlægsoversigter. Rapportering til udvalg m.fl. vedrørende anlægsregnskaber. Processen er i dag meget manuel med anvendelse af kommunens Økonomisystem suppleret med BILAG 1 C KRAVSPEFICIKATION SIDE 39

44 Navn for processen Anlægsstyring og anlægsregnskab regneark. Specifikke Krav til it-løsning Der lægges vægt på den tilbudte løsnings understøttelse af de nævnte delopgaver og delprocesser i forbindelse med anlægsstyring og anlægsregnskaber. Der ønskes mulighed for at registrere forskellige baggrundsoplysninger vedr. anlægsprojekter, herunder bl.a. bevillingsdato, status, dato for regnskabsgodkendelse, samt hvem der er administrativt ansvarlig for den givne anlægsbevilling. Mulighed for at tilknytte filer eller anden dokumentation til et anlægsprojekt. Anlægsprojekter skal kunne nedbrydes i delprojekter. Der skal valgfrit kunne opbygges en kontoplan pr. projekt/delprojekt. Der ønskes mulighed for at anvende dispositionsbogføring bl.a. ved integration til indkøbsmodulet, som skal indgå i opfølgningen på anlægsprojekterne. Det ønskes at bogføring af forbrug i økonomisystem og anlægskartoteket skal ske som en integreret proces uden dobbeltregistrering. Der ønskes mulighed for løbende at overføre oplysninger vedr. igangværende anlægsprojekter til Økonomisystemets anlægskartotek (anlægsaktiver). Byggemodningsprojekter områdeopdelte skal kunne håndteres i Økonomisystemets anlægskartotek. Der ønskes mulighed for en kobling af anlægsprojekter til finansdel (lån, deponering mv.) samt kobling til afledte driftsudgifter/-besparelser. Der lægges vægt på, at der kan udskrives rapporter over anlægsprojekterne både detailrapporter og summariske rapporter til kommunalbestyrelsen, hvor anlægsregnskabet vises overskueligt hvis muligt på en side. Der ønskes mulighed for fra økonomisystemet at generere en standardrapport til opfølgning på anlægsudgifter, som for hvert anlægsprojekt kan vise følgende oplysninger: Projektnavn (der skal være mindst 200 tegn, så det fulde projektnavn fremgår). Bevillingsdato Samlet bevilling Årets rådighedsbeløb Vedtagne tillæg til årets rådighedsbeløb Overførsel fra foregående år Samlet rådighedsbeløb for året Forbrug før indeværende år Forbrug år til dato i indeværende år Samlet forbrug Rest til rådighed i indeværende år Resterende bevilling Evt. dato for godkendelse af anlægsregnskab Samlet bevilling pr. historisk dato så vi kan se hvad vi har haft af anlægsbevilling på en bestemt dato, eksempelvis 31/ , uden at billedet forstyrres af 2012 anlægsbevillinger. Bemærkninger BILAG 1 C KRAVSPEFICIKATION SIDE 40

45 Navn for processen Anlægsstyring og anlægsregnskab Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Der skal etableres en sammenhæng mellem anlægsregistret og anlægskartoteket i økonomisystemet, således at anlægskartoteket automatisk kan opdateres, herunder dannelse af anlægsnote. Kvantitative forhold ved processen Kunden har årligt ca. 100 anlægsregnskaber. BILAG 1 C KRAVSPEFICIKATION SIDE 41

46 6.7 Betaling, bogføring og kreditor Tilbud 59. Tilbud 60. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående Betaling (bank, kasse og e-faktura) og kreditor. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er til stede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Betaling (bank, kasse og e-faktura) og kreditor Formål og overordnede krav Kunden ønsker at sikre en korrekt håndtering af ind- og udbetalinger med så meget automatik og systemunderstøttelse som muligt. Kunden ønsker desuden at systemet giver effektive og fleksible muligheder for at anvende indbyggede forebyggende kontroller mod fejlagtige udbetalinger og svig. Det er væsentligt at systemet er fremtidssikret så kommunen løbende kan implementere nye løsninger til håndtering af betalingsflows. (a la SafePay, NFC etc.) Beskrivelse af forretningsprocessen Kontantkasser Kommunen har en hovedkasse samt ca. 30 kontantkasser på institutionerne, klubber, skoler mv. I Hovedkassen og enkelte kontantkasser modtages indbetalinger fra borgere enten kontant eller via Dankort. Hovedkassen opgøres dagligt, mens institutionernes kasser opgøres med forskellig hyppighed. Betaling for pas og kørekort foregår i dag via kontantbetaling eller Dankort hos Borgerservice. Betaling via hjemmeside Forskellige ydelser f.eks. sundhedskort, adresseforespørgsler kan betales direkte via kommunens hjemmeside via betalingskort. Bank Ud over kundens centrale bankkonti har kunden ca. 65 bankkonti på decentralt niveau. Indbetalinger med angivelse af kortart 71 bogføres i økonomisystem, debitor og bank. For øvrige indbetalinger undersøger regnskabsteamet manuelt, hvor i debitormodulet/ Økonomisystemet indbetalingen skal bogføres. Kreditnota Kreditnotaer modtages elektronisk og modregnes automatisk i hængende fakturaer. Overfor enkelte kreditorer har regnskabsteamet fravalgt automatisk modregning af kreditnotaer. I de tilfælde hvor kreditor indsætter penge vedrørende kreditnotaer på kommunens hovedkonto udlignes disse manuelt. Udligning Der sker automatisk udligning af det skyldige beløb, hvis indbetalingerne er foretaget på baggrund af udskrevne regninger fra Greve Kommune. E-faktura E-fakturaer modtages i Økonomisystemet og behandles på alle niveauer i organisationen. Kreditorer BILAG 1 C KRAVSPEFICIKATION SIDE 42

47 Kreditorbetalinger anvises automatisk til betaling på den anførte betalingsdato via kundens bankforbindelse. Anvisningen er elektronisk. Betaling til anden konto end Nemkonto Når der i kreditorregistret oprettes alternative kontooplysninger for en kreditor, foretages centralt i kommunen validering af kontonummeret og vedhæftes dokumentation på kreditoren, inden der kan foretages udbetaling til kontonummeret. Godkendelse af betalinger Som hovedregel foretages udbetaling til kreditor efter én persons godkendelse af fakturaen. I den centrale supportfunktion udsøges og valideres alle betalinger over 2 mio. kr. inden udbetalingsfilen godkendes. Specifikke krav til it-løsning Systemet skal understøtte behovet for at styre og afstemme kommunens bank- og mellemregningskonti. Der ønskes mest muligt automatik og it-understøttelse af afstemningerne. Desuden ønskes automatisk dannelse af kassekladde (elektronisk godkendelse af transaktioner). Der ønskes mulighed for at kunne foretage udsøgninger på åbne poster, så der nemmere kan ske en afstemning af disse, uden at skulle frasortere poster, der allerede er udlignet. Kunden ønsker en løsning til sikring af, at der ikke kan laves ét-benede posteringer. Det skal være muligt at flere brugere konterer på samme bilag/kladde, f.eks. ved interne posteringer mellem forskellige enheder/brugere eller ved betaling af E-fakturaer. Kunden ønsker en fleksibel løsning til håndtering af relationerne mellem konti i økonomisystem og konti i fagsystemer. Én- til én relation mellem konti mindsker muligheden for fejl, men begrænser muligheden for decentrale kontoplaner til understøttelse af den decentrale økonomistyring. Der efterspørges en løsning, hvor der i størst muligt omfang kan benyttes webadgang til såvel bogføringsmæssige som til ledelsestilsynsmæssige opgaver i dagligdagen. Der ønskes en løsning, der indeholder mulighed for automatisk f.eks. via at give decentrale økonomifunktioner besked om overskredne betalingsdatoer mv. Funktionaliteten skal kunne inaktiveres ved en henstandsmarkering. Kreditorer Det skal være muligt at oprette kreditorer manuelt samt automatisk på baggrund af kreditorens CVR. nr. eller CPR. nr. Der skal være automatisk validering i forhold til CVR register og check af at kreditorer ikke oprettes flere gange. Der skal kunne laves udtræk på oprettelse af specifikke konti. Det skal være muligt at validere specifikke kontooplysninger inden betalingen foretages (ved udbetaling til anden konto end Nemkonto) og at vedhæfte relevant dokumentation. På kreditoren skal man kunne anføre de aftalte samhandelsforhold, f.eks. betalingsbetingelse. Der ønskes fra kreditormodulet mulighed for opfølgning på kreditorforhold, herunder opfølgning på enkelt bilag. Modtagne fakturaer/kreditnotaer skal lagres elektronisk, kunne fremfindes og genudskrives. Elektronisk vedhæftning af diverse dokumenter på bilag skal være mulig. BILAG 1 C KRAVSPEFICIKATION SIDE 43

48 Betalingsbehandling og-kontrol Betalinger skal automatisk modregnes kreditnotaer uden at kommunen selv aktivt skal gøre noget. Det skal på den enkelte kreditor være muligt at fravælge modregning i kreditnotaer. Det skal være muligt at tilbageholde/spærre udbetalinger til den enkelte kreditor. Denne tilbageholdelse/spærring skal kunne tidsbegrænses. Det skal være muligt at tilbagekalde ikke betalte fakturaer og genoplive den som ikke betalt E-faktura. Det skal være muligt på en faktura at anføre, at fakturaen er uafklaret. Der ønskes mulighed for ved opslag på kreditorens saldo at se overordnet saldo for hvert CPR. nr., CVR nr. Det skal være muligt for brugerne at forespørge på et bilag Det skal ikke være muligt at udbetale til eget CPR-nr., heller ikke hvis man er systemadministrator. Systemet skal kunne tilbyde automatisk og maskinel validering og sikre transaktionsspor. Øvrige forhold og ønsker Administrativ medarbejder i en administrativt-fællesskab skal kunne modtage og bogføre på samtlige administrerede enheder. Posteringer fra andre fagsystemer skal kunne overføres til økonomisystemet dagligt. Der ønskes kassekladde til bogføring som skal kunne deles af flere. Betaling skal ske ved lette processer, størst mulig gennemskuelighed og brugervenlighed. Der skal være integration til Excel. Systemet skal kunne håndtere fakturaer og afregning i euro og andre valutaer. Der skal kunne udskrives fakturaer/kvittering direkte fra systemet. Det skal være muligt at anvise manuelle købsbilag (udlæg) til betaling (NemKonto/CVR-nr.). Det skal være muligt at foretage udbetalinger i fremmed valuta samt overføre beløb til udenlandske banker ved angivelse af IBAN og SWIFT. NR. Det skal være muligt i fremtiden også at kunne håndtere elektroniske betalingskort (kantinekort) Det skal være muligt at massebogføre fra Excel. Der skal være en automatisk spærring så det ikke er muligt at bogføre dubletter. Det skal være muligt at korrigere konteringen af bilag direkte fra bilaget (med revisionsspor og vedhæftet dokumentation holdes intakt) Der ønskes mulighed for på afgrænsede kontoområder og/eller bestemte kreditorer at sætte BILAG 1 C KRAVSPEFICIKATION SIDE 44

49 krav om at fakturaer anvises (2. godkender) inden betaling. Det skal være muligt at betale fakturaer over BS (betalingsservice) Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Fagsystemer. De fleste ind- og udbetalinger sker via fagsystemer. NEM-systemet. Bank. Elektroniske betalingskort og evt. SafePay. Nets Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 45

50 6.8 Rapportering og analyse Tilbud 61. Tilbud 62. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående rapportering og analyse. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er til stede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Rapportering og analyse Formål og overordnede krav Kunden ønsker fleksible og omfattende rapporterings- og uddatafunktionaliteter, da det er afgørende for kundens styring og prioriteringsgrundlag. Kundens rapportering skal sikre at budgetkontrol og årsafslutning kan foretages på et præcist, sikkert og overskueligt grundlag. Kundens brugere af økonomisystemet skal have nem adgang til alle relevante informationer i form af rapporter og velstruktureret økonomiinformation for ledere, som kan sikre det bedst mulige styringsgrundlag. Rapportering skal kunne ske på alle niveauer i Organisationen. Kunden ønsker desuden, at decentrale brugere kan løse rapporteringsbehov via Web-løsning. Kunden stiller krav om, at systemet giver brugerne adgang til information om alle relevante økonomiske forhold samt forhold herunder budgetforudsætninger (mængder/tekst), jvf. procescase 6.2. Adgangen til løn- og personalestatistik skal kunne ske nemt og enkelt uden ekstra login og med få klik. Kunden ønsker fleksibel mulighed for rapportering direkte fra økonomisystemet. Der lægges vægt på både at have faste skabeloner/rapporter, der kan genbruges og mulighed for frit selv at definere og sammensætte rapporter og udtræk. Der skal desuden kunne oprettes grupper, som indeholder forskellige afgrænsninger/registreringsniveauer på tværs af kontoplanen. Kundens informationer skal kunne hentes online med fleksible og valgfri muligheder for afgrænsninger på alle dimensioner, konti, baggrundsdata (f.eks. leverandørnavn, -adresse, cvr-nr. cpr-nr./registrant) med mulighed for periodeafgrænsninger, valg af dimensioner samt rækkefølge deraf, sortering og sumangivelser. Kundens lønomkostninger udgør en stor andel af kommunens samlede budget, og derfor er der særligt fokus på, at sikre en ledelsesinformation, der giver en sammenhængende information og analysemulighed fra økonomi- og lønsystemet. Det ønskes at man kan starte analysen på et aggregeret niveau og slutte med oplysninger om, hvilke medarbejderes lønandele eller timer, der ligger bag det aggregerede tal. Beskrivelse af forretningsprocessen Budgetopfølgning foretages af de enkelte budgetansvarlige. Herunder foretages i kommunens enheder opfølgning på fravær og øvrige personaleforhold på alle niveauer i Organisationen herunder de decentrale økonomifunktioner. Analyserne foretages til brug for både det administrative og det politiske niveau. Kunden foretager kontrol af gennemførte betalinger (integreret anvisning) som en del af de budgetansvarliges ledelsestilsyn/budgetopfølgning. Også her sker opfølgning på decentralt niveau webbaseret. BILAG 1 C KRAVSPEFICIKATION SIDE 46

51 Specifikke krav til it-løsning Overordnede krav Kunden ønsker en it-løsning der understøtter formålet om at skabe fleksible og omfattende rapporteringer, til brug for kundens styring og prioriteringsgrundlag for politikere og den administrative organisation. Ud over den faste budgetopfølgning er der løbende behov for at foretage ad hoc prægede analyser af økonomi og af forhold vedr. løn og personale. I sådanne analyser starter man typisk analysen på et overordnet niveau og har derefter brug for at gå i yderligere detaljer og at foretage filtreringer og sorteringer i forhold til kontoplanens dimensioner. Der skal i rapporteringen generelt være sporbarhed, således at det på enkel vis er muligt at få vist, hvilke posteringer/regninger der ligger til grund for de tal, der vises i rapporterne. Dette gælder også når specifikation af tallene i økonomisystemet skal findes i andre systemer. Som eksempel på dette ønskes der i rapporteringen en let adgang til at se de relevante grundbilag for de posteringer i økonomisystemet, der dannes på baggrund af lønkørsler. Specifikationen ønskes her i forhold til de medarbejdere, som lønkørslen har omfattet og i forhold til lønnens enkelte bestanddele/de enkelte lønlinjer. Tilsvarende ønskes der nem adgang til den fulde specifikation vedrørende personaleforhold som f.eks. fravær og sygdom, personalesammensætning (på køn og alder). Rapporter skal kunne trækkes på tværs af regnskabsår, og der skal være adgang til rapportering vedr. budgetoverslagsårene. Der skal i rapporteringen kunne skelnes mellem forskellige typer budgetter/bevillingstyper, eksempelvis vedtaget budget mv. Det skal være muligt frit at periodeafgrænse både budget og forbrug i rapporter. Der ønskes mulighed for at udsøge alle bogførte fakturaer pr. leverandør og kunne åbne originalfaktura og alt underliggende dokumentation (notater og filer). Der ønskes en løsning, så kunden på alle niveauer centralt og decentralt, kan udføre ledelsestilsyn/budgetopfølgning og herigennem også foretage kontrol af gennemførte betalinger (integreret anvisning). Beskrevet i procescase 6.2. Der ønskes mulighed for på alle niveauer at få søgeresultat vist/udskrevet i en brugervenlig rapport, hvor kunden selv definerer indhold (f.eks. hvilke kolonner vises og med mulighed for sammentællinger på forskelligt niveau). Systemmæssige krav Ved analyser skal systemet understøtte, at der kan udtrækkes og overføres informationer fra økonomisystemet til regneark for videre bearbejdning her. Yderligere skal kunne udtrækkes og opdateres data fra økonomisystemet via regneark, således at opsætning i regneark fastholdes, og opdatering kan ske efter behov, uden at opsætning ændres. Brugergrænsefladen for rapportering og analyse skal være intuitiv og let anvendelig for forskellige brugergrupper med forskellige forudsætninger. Til brug ved ad hoc prægede analyser ønskes adgang til en overskuelig brugergrænseflade, hvorfra man kan udvælge informationer i forhold til enkelte dimensioner eller til intervaller af dimensioner. Der ønskes mulighed for at kunne foretage drill down i rapporterne online, så ana- BILAG 1 C KRAVSPEFICIKATION SIDE 47

52 lyser på et mere konkret niveau kan foretages straks og via samme skærmbillede, uden at man skal afvente at rapporter genereres. Det skal sikres, at medarbejdere kun kan bede om rapporter med data, som de har adgangsrettigheder til. For oplysninger om løn og personale vil lederen som udgangspunkt kun skulle gives adgang til oplysninger om egne medarbejdere. Ved rapportering skal som minimum kunne vælges mellem følgende muligheder: Udtræk til skærm, papir, pdf, regneark og flade filer (f.eks. semikolonseparerede filer). Udtrækkene skal kunne videresendes pr. mail. Skabeloner Den faste, periodiske økonomirapportering til brug ved budgetopfølgning skal kunne udformes efter en fælles skabelon. Der skal desuden kunne udformes særlige rapporter til understøttelse af de enkelte områder og enheders særlige styringsbehov. Kunden stiller krav om, at systemet indeholder opdaterede autoriserede rapporter. Generelt skal systemet understøtte de obligatoriske økonomirapporter i forbindelse med regnskabsaflæggelse, budgetvedtagelsen og øvrig rapportering til ministeriet og andre offentlige myndigheder. De faste rapporter, som kommunen skal aflevere til eksterne myndigheder som f.eks. Danmarks Statistik, KL og Ministerier/myndigheder skal kunne dannes og overføres elektronisk til modtageren. Zipfil skal kunne generes. Systemet skal kunne generere en rapport, som svarer til den autoriserede rapportering ved årsafslutning, herunder indeholdende både udgiftsregnskab, omkostningsregnskab mv.. Understøttelse af obligatoriske indberetninger til myndigheder og KL via standardrapporter bl.a. på følgende områder: Specifikationer til regnskab Serviceudgifter Overførselsudgifter Gennemsnitslikviditet (til Økonomi- og Indenrigsministeriet) Halvårsregnskab Kontanthjælpsrapport ØIM momsrapport B-skattepligtige oplysninger M.fl. Øvrige forhold i relation til rapportering I forhold til rapportering forudsætter kunden: At rapporteringen understøtter både den autoriserede kontoplan, kommunens politiske organisation, politikområder og den organisatoriske opbygning. Der skal være let og fleksibel adgang til at kunne søge på alle kontoplan- og bogføringselementer, herunder også kreditoroplysninger og posteringsoplysninger i EN søgning. At kunne rapportere både på indtægter og udgifter både brutto- og nettobeløb. Både budgetter og regnskaber. At kunne rapportere både inkl. og ekskl. moms. Både budgetter og regnskaber. BILAG 1 C KRAVSPEFICIKATION SIDE 48

53 At rapportere på udvalgte dimensioner uden krav om angivelse af andre dimensioner (overspring af f.eks. grupperings første niveau). At benytte foruddefinerede rapporter til standardopgørelser f.eks. af refusion, moms mv. At udarbejde skabeloner til standardrapporter til brug bredt i kommunen eller for et område eller en enkelt bruger, men at brugerne også selv på fleksibelt vis kan definere udtræk og rapporter. Personlige rapporter må ikke kunne ændres af andre, alene bruges af andre. At gemme brugte rapportafgrænsninger til senere brug. At foruddefinere nøgletal til udtræk af økonomisystemet. At kunne definere regler og kriterier for udtræk, f.eks. posteringer for årige på en given funktion. At der kan udregnes forbrugsprocenter. At kunne generere automatiske rapporteringer, der tilgår modtageren elektronisk. At foruddefinerede rapporter har genkendelige og letforståelige navne. At tid, dato og afgrænsninger (f.eks. prisniveau og beløbsniveau) skal kunne fremgå af alle rapporter. At data kan præsenteres numerisk og grafisk efter kundens ønske. At der ikke er begrænsninger på mængden af data, der trækkes ud via rapporter. At nogle brugere (evt. alle) kan gemme rapporter hos andre brugere. Ved budgetopfølgningen skal det være muligt frit at sammenstille regnskabs- og budgettal. En budgetopfølgning i 2014 kan f.eks. indeholde regnskab 2013, korrigeret 2014 samt budgetforslag 2015 samt overslagsårene alle i 2015-priser) regnskab 2013 i 2013-priser sammenhold med regnskab 2012 i 2012-priser og overslagsårene i 2013-priser) Ved budgetopfølgningen skal det være muligt at beregne disponibelt beløb ved at sammenstille budget, forbrug og disponerede udgifter (f.eks. løn, indkøb, indgåede aftaler) Ved budgetopfølgningen skal det være muligt at følge op på kvantitative budgetforudsætninger (mængder/aktiviteter), f.eks. antal kontanthjælpsmodtagere. Se case 6.2. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 49

54 6.9 Økonomi og regnskab herunder årsregnskab og omkostningsregnskab Tilbud 63. Tilbud 64. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående Økonomi og regnskab, herunder årsregnskab og omkostningsregnskab. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er til stede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Økonomi og regnskab herunder årsregnskab og omkostningsregnskab Formål og overordnede krav Kunden skal hurtigst muligt efter årsskiftet effektivt kunne producere et retvisende årsregnskab såvel et udgiftsregnskab som et omkostningsregnskab, under overholdelse af gældende regler. Kunden aktiverer anlægsaktiver til værdi af over kr. og vedligeholder et anlægskartoteket med værdiansættelse, afskrivningsprofiler, kategoriseringer mv. Kunden ønsker at systemet understøtter og i videst muligt omfang har indbygget automatiske kontroller til sikring af at regnskabet er korrekt. Kunden ønsker en løsning: Der understøtter processer til sikring og kontrol af, at udgifter og indtægter bogføres på korrekt regnskabsår. Der giver mulighed for at afstemme statuskonti (hovedkonto 9) og at afstemningen dokumenteres i systemet. Der understøtter processer til sikring og kontrol af, at der er foretaget korrekt momsafløftning. Beskrivelse af forretningsprocessen Processen vedrørende årsregnskab udgøres overordnet af: I efteråret udarbejdes tids- og aktivitetsplan for regnskabsafslutning. Pr. 1/12 åbnes for postering i forsupplementsperiode for næste år. Den 15. januar lukkes for generel bogføring og remittering vedr. gammelt år, men omkontering er mulig indtil ultimo januar. Der skal dog være mulighed for at udvalgte medarbejdere kan bogføre længere. Udgiftsregnskab med tilhørende obligatoriske oversigter mv. udarbejdes herefter. Regnskab aflægges overordnet samt på udvalgsniveau. I forbindelse med at omkostningsregnskabet foretages følgende: Anlægskartoteket (i økonomisystemets aktivmodul) ajourføres med årets til- og afgang, og der foretages afskrivninger. Der håndteres skyldige feriepenge, forpligtigelser og hensættelser til tjenestemandspensioner m.m. Herefter forestår revisionen af regnskabet samt fremsendelse af rapporter til Danmarks Statistik og Ministeriet. Statusafstemning af kommunens konti foretages decentralt. Kunden har en central funktion til BILAG 1 C KRAVSPEFICIKATION SIDE 50

55 opfølgning på at alle afstemninger foretages og har den rette kvalitet. Der foretages systemafstemning ved årsafslutning af de systemansvarlige. Der foretages generel screening for om konteringerne er korrekte herunder korrekt momsafløftning. Central opfølgning på om fakturaer i indeværende år er betalt. Specifikke krav til it-løsning Der lægges vægt på den tilbudte løsnings understøttelse af de nævnte delopgaver og processer i forbindelse med årsregnskab. I forbindelse med udarbejdelse af årsregnskaber gennemføres i dag en række kontroller. Der kontrolleres bl.a. for at Art 0 = stemmer, Fejlkontoen = 0, at regnskabet balancerer mv. Processer vedrørende årsregnskab er meget manuelle. Processerne ønskes digitaliseret/automatiseret. Der lægges vægt på følgende specifikke forhold vedrørende løsningen: At der kan ske en differentieret lukning for bogføring og posteringer, som kun gælder visse brugergrupper og visse posteringstyper (bogføring, omplaceringer, debitorposter). Regnskabskommentarer skal kunne indsættes på kontoen eller kunne vedhæftes i dokument Der ønskes mulighed for en advarsel (tilvalg/fravalg) ved bogføring omkring årsskiftet, så medarbejderen tager aktivt stilling til, hvilket regnskabsår, der skal bogføres i (f.eks. fra den til den 15.1) Der skal automatisk kunne udarbejdes samlede regnskabsrapporter med diverse bilag i henhold til myndighedskravene herunder anlægsoversigt, skyldige feriepenge og pension mv. Økonomisystemet skal således kunne danne forslag til de oversigter, der er autoriseret jf. de gældende konteringsregler, herunder personaleoversigten. Rapporter til Danmarks Statistik og Ministeriet skal automatisk kunne udtrækkes ( flade filer ). Rapporterne ønskes opdateret løbende af leverandøren, så de er ajourført mht. ændringer i den autoriserede kontoplan Automatisk dannelse af momsrapporter vedrørende udligningsmoms. Der skal let kunne foretages et samlet udtræk af regnskabsdatabasen til kommunens revision til regnskabsanalyser. Anlægsnoter med information om primo-saldo, af- og tilgange, herunder salg, vedrørende anlægget samt afskrivninger skal kunne udarbejdes automatisk. Simple og brugervenlige udtræksmuligheder til anvendelse f.eks. på det decentrale niveau. Udtræksmuligheder vedrørende afvigelser mellem budget og regnskab. Det skal være muligt at kunne danne regnskab på f.eks. politikområder. Afstemning af statuskonti: Det er et krav, at der kan indlæses bankposter automatisk fra pengeinstitut på udvalgte kon- BILAG 1 C KRAVSPEFICIKATION SIDE 51

56 ti. Der ønskes en løsning, hvor man på samme billede kan se/udligne poster fra Pengeinstitut og finansposter. Der ønskes arkivfunktion så tidligere afstemninger kan søges frem, f.eks. de afstemninger der knytter sig til halv- og helårsregnskab. Der ønskes mulighed for at indlæse poster fra eksterne systemer. Mulighed for altid at vise seneste afstemning. Der skal kunne indberettes en startdato for afstemning på de enkelte konti. Der skal være mulighed for at opløse eller annullere tidligere udlignede enkeltposteringer. Der skal være mulighed for at korrigere poster direkte i forbindelse med afstemningen. Der skal være mulighed for automatisk opfølgning / rykning omkring ikke afstemte konti. Integration til Officepakken og nemme og brugervenlige søge- og udligningsfunktioner. Mulighed for at vedhæfte dokumentation. Kontrol af momskontering Det er et krav at kunden kan afgrænse via egne opsatte afgrænsninger (kontoplanstruktur, datointervaller mv.). Der ønskes mulighed for at foretage samlet afgrænsning af udenfor/indenfor positivlisten. Der skal være mulighed for at ompostere et bilag direkte fra resultatbilledet eller ved få klik. Det oprindelige bilagsnr. skal bibeholdes og det skal være synligt, at omposteringen stammer fra løsningen (momskontrol). Det skal være muligt direkte fra resultatbilledet at tilknytte en kommentar eller tekst til det konkrete bilag. Der skal i resultatbilledet være markering af, om et bilag er bogført på en funktion og art som er omfattet af positivlisten. Der ønskes mulighed for at holde definerede kreditorer udenfor udsøgningen. Mulighed for forskellige former for rapportering. Mulighed for at der kan laves grafisk materiale/visning. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Rapportudtræk til Danmarks Statistik, KL og Ministeriet. Regnskabsudtræk til kommunens revision. Regnskabsudtræk til kommunen. Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 52

57 BILAG 1 C KRAVSPEFICIKATION SIDE 53

58 6.10 Likviditetsstyring (option) Tilbud 65. Tilbud 66. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående likviditetsstyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er til stede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Likviditetsstyring Formål og overordnede krav Kunden har brug for løbende at kende aktuel kassebeholdning samt historisk og forventet fremtidig kassebeholdning. Desuden skal der være adgang til likviditetsdata til analyseformål. Beskrivelse af forretningsprocessen Opgørelse over udviklingen i Kommunens Likviditet udarbejdes i regneark. Kunden baserer sine daglige estimater af likviditeten på bank-information. Kunden har en række konti ( ), der tilsammen afspejler information om kundens likviditet. Kundens proces er manuel og udfordres af manglende prognosefaciliteter. Kunden anvender information om likviditet til at følge udviklingen til dags dato samt estimere forventet likviditetsudvikling for resten af regnskabsåret. Kunden beregner endvidere likviditet opgjort efter kassekreditreglen samt opgør likviditet for valgte periode eks. dag/måned. Specifikke krav til it-løsning Kunden ønsker en it-løsning, der understøtter kundens behov for information om kommunens likviditet, både i forhold til gennemsnitlig likviditet, et øjebliksbillede samt estimat over udvikling for den resterende del af regnskabsåret/kommende budgetår. Der ønskes prognoser, som kan anvendes til opfølgning. Likviditetsmodulet skal være en integreret del af det samlede økonomisystem. Der skal kunne foretages pengestrømsanalyser og opgørelse af kommunens likviditet på dagbasis, der tager højde for kassekreditter og byggekreditter og deponerede midler. Analyserne skal kunne præsenteres numerisk og grafisk, og der skal være mulighed for udtræk til Excel. Det skal være muligt at medtage forventede indtægter (herunder 1/12-dels afregninger fra staten) samt udbetaling af skat, sociale pensioner, løn mv. i likviditetsstyringen. Kunden ønsker en løsning, der kan generere en rapport over afvigelser mellem forventet likviditet og faktisk likviditet på f.eks. funktionsniveau. Rapporterne skal understøtte de formelle krav til indberetning til ØIM. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes BILAG 1 C KRAVSPEFICIKATION SIDE 54

59 Kvantitative forhold ved processen BILAG 1 C KRAVSPEFICIKATION SIDE 55

60 6.11 Boliglån Tilbud 67. Tilbud 68. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående boliglån. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Boliglån Formål og overordnede krav Kommunen ønsker, som en del af økonomisystemet, et modul der kan foretage registrering, udbetaling og opkrævning af beboerindskud og depositum, som Kommunen administrerer i.h.t. lov om individuel boligstøtte og i.h.t. 74 i lov om almene boliger. Beskrivelse af forretningsprocessen Kunden anvender i dag KMD Boliglån. Lånet oprettes i systemet og der udskrives bevillingsskrivelse til borgeren samt andre relevante skrivelser. Skrivelser er oprettet i systemet og udskrives derfra. Indskud udbetales og bogføres herefter gennem økonomisystemet. Kravet kan herefter ses i debitormodulet. Ved overførslen til debitormodulet skal det via betalingsarten kunne ses om kravet er en frivillig aftale eller ej. Frivillige/tvungne afdragsordninger indberettes i boliglånesystemet og afdrag trækkes via boligforeningen eller via PBS. Dette sker også via indberetning i boliglånesystemet. Ved indberetning dannes automatisk en betalingskladde i debitormodulet som bogføres når pengene er modtaget. Ved fraflytning/dødsfald modtages flytteafregning fra boligforeningen. Herefter indberettes restlånet til forfald og et brev + faktura dannes i debitor og sendes til borgeren/boet. Der modtages i visse situationer ekstraordinære afdrag som indberettes til systemet. Ved kautionslån indberettes lånet i systemet (der sker ingen udbetaling). Ved misligholdelse udbetales restkautionsbeløb til banken og kravet oprettes i debitor. Specifikke krav til it-løsning Mulighed for at indberette alle stamdata herunder indflytningsdato, afdragstid, BBRoplysninger, boligforening, bolignr., pengeinstitut, opholdsdato, medhæfter. Mulighed for at registrere alle de forskellige lånetyper som kommune administrerer. Mulighed for at danne og udskrive de skrivelser der skal sendes til alle de forskellige parter efter registrering. Der skal være mulighed for individuelle tilrettelser, hvor kunden ønsker det. Der skal automatisk kunne foretages de månedlige/halvårlige og årlige kørsler som er nødvendige eller lovpligtige (f.eks. afstemningsmateriale, skema til finansstyrelsen, rentekontrolliste, indberetning til Skat, rentebreve til borgerne, årlig kontrol af kautionsforpligtelser mv.). Månedlig dannelse af liste/fil til boligselskaberne med oversigt over de borgere der skal trækkes til deres lån. Samtidig dannes i debitor betalingskladde som kan bogføres når pengene er modtaget. Der skal være mulighed for at rette i den dannede betalingskladde indtil den er bogført. Online registrering i debitor. BILAG 1 C KRAVSPEFICIKATION SIDE 56

61 Afsluttede sager slettes efter 3 år. Mulighed for at der kan udtrækkes årlig indkomstkontrolliste baseret på skats oplysninger. Mulighed for at udtrække rapporter med valgfrie oplysninger fra systemet. Mulighed for i lånesystemet at søge på medhæfter (CPR-nr.). Kautionssager skal kunne afsluttes af kunden når lånet er indfriet i pengeinstitut. Mulighed for at korrigere tidligere indberetninger uden at sagen skal slettes. Mulighed for at ændre status på en lånesag f.eks. fra afslået til bevilget. Mulighed for at indsætte advisdato + advistekst på en sag. Advis efter 5 år når afdragsfrihed ophører og der skal automatisk dannes skrivelse til borgeren. Efter kundens behov skal der være mulighed for advis når en hændelse sker (f.eks. lån indfriet, saldo under et vist beløb f.eks. +/- 50 kr.). Mulighed for at søge digitalt via borger.dk Mulighed for at oprette standardoplysninger overordnet. F.eks. på banker (reg.nr., adresse mv.), på boligforeninger (ID-nr., adresse mv.) så oplysninger automatisk hentes ind til blandt andet breve og i indberetningssituationer. Adgang til et brugerregister med oplysninger om bl.a. gældende satser, CVR-nr./SE-nr. til SKAT omkring boliglån. Mulighed for at korrigere renter f.eks. ved besked fra SKAT omkring sletning af renter bagud. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes CPR-data BBR-register. Indberetning af renter til SKAT. Evt. kommende landsdækkende huslejeregister. Kvantitative forhold ved processen Ca låne- og garantisager i alt. BILAG 1 C KRAVSPEFICIKATION SIDE 57

62 6.12 Mellemkommunale opkrævninger/udbetalinger (option) Tilbud 69. Tilbud 70. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer mv. angående mellemkommunale opkrævninger/udbetalinger af løbende ydelser. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Leverandøren skal i underbilag til bilag 2 redegøre for, hvis procescasen beskriver funktionalitet, som ikke tilbydes. Navn for processen Mellemkommunale opkrævninger/udbetalinger af løbende ydelser Formål og overordnede krav Kunden ønsker som en del af økonomisystemet et modul, der kan anvendes til styring af området for mellemkommunale afregninger på tværs i kommunen og som kan håndtere dannelse af mellemkommunale opkrævninger gennem kundens debitorsystem. Beskrivelse af forretningsprocessen Opkrævning og betaling af mellemkommunale afregninger/refusioner foregår i kundens enkelte fagcentre. Området er præget af manuelle processer, hvor hvert fagcenter vedligeholder et regneark med de borgere, der skal opkræves eller betales for. Specifikke krav til it-løsning Kunden ønsker et kartotek med cpr. numre, for hvilke der er givet betalingstilsagn. For borgere hvor kunden skal foretage betaling til anden kommune: Løsningen skal understøtte kontrol af, at der ikke betales fakturaer hvor kunden ikke længere er betalingspligtig (anden boligform, adresseændring) For borgere hvor kunden skal foretage opkrævning hos anden kommune: Løsningen skal understøtte kontrol af at der foretages opkrævning for alle borgere hvor det er muligt, herunder for borgere hvor betalingstilsagn er modtaget Løsningen skal understøtte kontrol af at alle relevante udgifter medtages i opkrævningen Løsningen skal kunne danne forslag til opkrævninger ud fra bogførte udgifter på cpr. nummeret. Det skal være muligt at fjerne poster fra forslaget og manuelt at tilføje nye. Kunden skal kunne vælge om der skal opkræves alt vedr. ét cpr.nr., eller opkrævning pr. center pr. cpr.nr. Opkrævningerne skal automatisk foretages via debitorsystemet. Opkrævningen skal kunne foretages måneds-, kvartals- eller årsvis. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Debitorsystem Kvantitative forhold ved processen I 2013 har Greve Kommune foretaget opkrævning hos andre kommuner for 165 mio. kr. BILAG 1 C KRAVSPEFICIKATION SIDE 58