BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM

Transkript

1 BILAG 1 KRAVSPECIFIKATION ØKONOMISYSTEM

2 VEJLEDNING Denne kravspecifikation er en del af kravspecifikationen af økonomi. 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 ø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 Konvertering (option) Implementeringsbistand Test Uddannelse (option) Dokumentation Dokumentation af analysefasen Dokumentation af løsningen Brugersupport Udviklingsplaner Projektmodel Bemanding Involvering af kundens medarbejdere Kundens udviklingsprojekter Leverandørens bistand til realisering af effektiviseringspotentiale (option) Regnskabsafslutning og læseadgang historiske data (option) Generelle krav til løsningen Forventninger til leverandøren Lovmæssige krav Åbne standarder Krav vedrørende økonomistyring for selvstændige virksomheder Brugervenlighed og fleksibilitet Forhold vedr. it-arkitektur, integration m.v 12

4 5.6.1 Brugeradministration Integration i forhold til økonomisystemet It-sikkerhed It-arkivering Data til Fælleskommunalt Ledelsesinformationssystem (FLIS) Data til ledelsesinformation (option) Dataudtræk Metadata og søgbarhed Programmering af batchjobs Krav til driftsplaner Svartider, oppetider mv Beskrivelse af opgaveområder og processer Kontoplan Økonomi og budget Debitor Ressourcestyring Indkøb og E-handel (option) Anlægsstyring og anlægsregnskab Betaling (bank, kasse og e-faktura) og kreditor Rapportering og analyse Økonomi og regnskab, herunder årsregnskab, omkostningsregnskab Likviditetsstyring 45

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. For alle brugeres vedkommende anvendes i forbindelse med den eksisterende økonomiløsning en portaladgang. Kunden anslår antallet af brugere på den nuværende økonomiløsning til at være som følger: Kategorier Brugere Administratorer Ca. 3 Superbrugere Ca. 25 Brugere* Ca Portalbrugere Ca. 200 Indeholdt i ovenstående Brugere af indkøbsløsning** Ca. 850 Brugere af ressourcestyring Ca. 5 1 *indeholder også ca brugere, der kun er oprettet som Prismebrugere, for at kunne bruge e-handelssystemet. ** heraf ca. 20 superbrugere / administratorer Krav 1. Leverandøren skal afgive tilbud med udgangspunkt i det nuværende antal brugere. 1 Antallet illustrere det brug af systemet. Kunden forventer en kraftigere brug fremover. BILAG 1 C - KRAVSPEFICIKATION SIDE 2

7 3. UDBUDDETS OMFANG Opgaven omfatter anskaffelse, drift og vedligeholdelse af et standard økonomisystem. 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. Tilbud på regnskabsafslutning og læseadgang til historiske data, uddannelse, e-læring, konvertering af data, tilgængeliggørelse af ikke konverterede data, data til ledelsesinformation, bistand til realisering af effektiviseringspotentiale samt indkøb og E-handel skal medtages som optioner. Hermed forstås, at leverandørens tilbud inden for disse områder skal prissættes separat, således kunden har mulighed for at fravælge områderne. 4.1 Basiskrav Krav 3. Krav 4. Krav 5. Tilbud 1. 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 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. 4.2 Hovedtidsplan Krav 6. Det er et krav, at det nye økonomisystem den 1. oktober 2012 skal være klar til indberetning af budgettet for Den 1. december 2012 skal økonomisystemet være klar til at varetage samtlige opgaver af hensyn til håndtering af forsupplementsperioden. Den 1. januar 2013 skal økonomisystemet være klar til drift i hele kommunen (mindstekrav). 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 2. Tilbud 3. Tilbud 4. 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 Konvertering (option) BILAG 1 C - KRAVSPEFICIKATION SIDE 4

9 Implementeringsbistand Testplanlægning og afprøvning Uddannelse (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 7. Det er et krav, at tilbuddet medtager samtlige den til gennemførelsen af projektet nødvendige projektledelse fra leverandørens side (mindstekrav). 4.4 Opsætning og konfigurering Krav 8. 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 Konvertering (option) Kunden ønsker at sikre en så let overgang til det nye system som muligt. Data ønskes konverteret, således at eksisterende data tilbage til 1/ bliver tilgængelige i det nye system. Krav 9. Tilbud 5. Krav 10. Tilbud 6. Tilbud 7. Det er et krav, at leverandøren i tilbuddet medtager forslag til konvertering af data eller alternativt anden lagring af historiske data. Der kan tilbydes alternative konverteringsforslag. I det omfang datakonvertering forudsætter involvering af tredjepart, skal dette angives. Leverandøren skal i bilag 13 medtage konverteringen som option, og den konkrete konverteringsopgave fastlægges som en del af analyse- og designfasen. Data, der ikke kan konverteres og gøres tilgængelige i det tilbudte system, skal på anden vis gøres tilgængelige og søgbare i hele kontraktperioden. Leverandøren skal i underbilag til bilag 2 beskrive, hvorledes ikke-konverterede data gøres tilgængelige. Tilgængeliggørelsen af ikke-konverterede data aftales som en del af analyse- og designfasen. Leverandøren skal i bilag 13 medtage pris for tilgængeliggørelse af ikke-konverterede data som option. 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 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). BILAG 1 C - KRAVSPEFICIKATION SIDE 5

10 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. 4.8 Uddannelse (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. 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. 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. Krav 13. Krav 14. Leverandøren skal tilbyde uddannelse af kundens brugere i hele kontraktperioden. Leverandøren skal, som en del af tilbuddet, tilbyde uddannelse af følgende økonomi, debitor og indkøbsmedarbejdere: Administratorer (ca. 8 økonomiadministratorer fordelt på 3 økonomi, 3 debitor og 2 indkøb): 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. Superbrugere (ca.25 ø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 administrator af systemet. Superbrugere (ca. 4 debitorkonsulenter): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne vejlede øvrige brugere og klæde superbrugerne på til at løse komplekse fagspecifikke problemer samt de basale elementer i brugerhåndtering. Uddannelsen skal give en udførlig indføring i anvendelse af økonomisystemet. Superbrugere (ca. 3 indkøbskonsulenter): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne vejlede øvrige brugere og klæde superbrugerne på til at løse komplekse fagspecifikke problemer samt de basale elementer i brugerhåndtering. Uddannelsen skal give en udførlig indføring i anvendelse af økonomisystemet. Superbrugere (ca. 2 ressourcestyring): Uddannelsen skal være på et niveau og med en tilgang, der giver dem tilstrækkelige kvalifikationer til at kunne vejlede øvrige brugere og klæde superbrugerne på til at løse komplekse fagspecifikke BILAG 1 C - KRAVSPEFICIKATION SIDE 6

11 problemer samt de basale elementer i brugerhåndtering. Uddannelsen skal give en udførlig indføring i anvendelse af økonomisystemet. Krav 15. Krav 16. Krav 17. Krav 18. Tilbud 8. Uddannelsen af superbrugere skal være af ensartet kvalitet, og skal derfor forestås af leverandøren. Leverandøren skal i optionen give forslag til anvendelse af superbrugere i undervisningen af de øvrige brugere i kommunen. 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 superbrugere koordineres tidsmæssigt med implementeringsforløbet, således at uddannelse i brugen af økonomisystemets moduler er koordineret med implementeringen af disse, så medarbejderne er parate til at løse opgaverne i den nye løsning på tidspunktet for dennes driftsstart. Leverandøren skal i bilag 3 afgive 3 alternative tilbud på uddannelsesaktiviteterne af brugerne - Det minimale uddannelsesforløb - Den anbefalede uddannelsesforløb Kunden finder, at det kan være relevant at uddanne egne brugere ved hjælp af et af leverandøren udviklet e-læringssystem. Dette er særligt relevant i forbindelse med den løbende uddannelse af brugere efter idriftssættelsen. Tilbud 9. Tilbud 10. Leverandøren skal i underbilag til bilag 2 beskrives leverandørens eventuelle tilbud i forhold til e-læring. Leverandøren skal i bilag 13 som option medtage pris pr. måned for at stille det beskrevne e-læringssystem til rådighed for kundens brugere. 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 19. Resultatet af analyse- og designfasen skal dokumenteres i en løsningsbeskrivelse, som vil indgå i kontraktens bilag 2 (mindstekrav). BILAG 1 C - KRAVSPEFICIKATION SIDE 7

12 4.9.2 Dokumentation af løsningen Leverandøren skal som en del af løsningen levere: Brugerdokumentation (fx. manualer, online hjælp) Systemdokumentation (løsningsarkitektur, modulbeskrivelser, datamodel, opsætning) Vedligeholdelses- og driftsdokumentation (fx. installations- og system, fejlhåndtering) Kursusmateriale Krav 20. Krav 21. Krav 22. Tilbud 11. Al brugerrettet dokumentation skal foreligge på dansk. Tilbuddet skal omfatte tilstrækkeligt dokumentation til at understøtte brug af systemet. Dokumentation skal leveres samtidigt med programmellet og godkendes som en del af overtagelsesprøven. 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 12. Leverandøren skal i bilag 10 beskrive omfanget og karakteren af den tilbudte brugersupport, samt beskrive eventuelle valgmuligheder for serviceniveau i forhold til brugersupport Udviklingsplaner Tilbud 13. 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ør skal endvidere angive om dele af den tilbudte løsning vil blive erstattet af nye delløsninger i kontraktperioden (vedligeholdelsesperioden). Kunden ønsker mulighed for at kunne påvirke udviklingsplaner og fremtidige initiativer i forhold til den tilbudte løsning. Tilbud 14. 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 15. 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. BILAG 1 C - KRAVSPEFICIKATION SIDE 8

13 4.13 Bemanding Tilbud 16. 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 17. 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 Kundens udviklingsprojekter Tilbud 18. Leverandøren skal i underbilag til bilag 2 beskrive, hvorledes leverandøren stiller sig i forhold til løbende at indgå i kundens udviklingsprojekter og mod vederlag at stille ressourcer og kompetencer til rådighed herfor Leverandørens bistand til realisering af effektiviseringspotentiale (option) Kunden er underlagt krav om løbende effektivisering af administrationen. Kunden har en forventning om, at de administrative processer i større grad kan digitaliseres og derved effektiviseres ved ibrugtagning af et nyt tidssvarende system. Derfor ønsker kunden effektiviseringsperspektivet medtaget i udbuddet af kommunens løn- og økonomisystem. Det er kundens erfaring, at det er lettere at realisere en effektivisering, hvis effektiviseringspotentialet på forhånd er belyst af relevant viden, fx præcist beskrevet af en ekstern part i form af optimale arbejdsprocesser. Kunden ønsker at leverandøren som option angiver, hvorledes leverandøren kan medvirke til at realisere effektiviseringspotentialet. Det indebærer, at leverandøren i tilbuddet skal anføre prisen for at udarbejde en konkret handlingsplan for at igangsætte effektiviseringer hos kunden. Kunden er interesseret i effektiviseringer, der kan give en direkte økonomisk effekt for kunden. Leverandøren skal ligeledes angive det forventede effektiviseringspotentiale. Kunden er interesseret i at arbejdet med realisering af gevinster indarbejdes og igangsættes allerede i år 2013 og integreres i hele driftsperioden. Kunden er ligeledes meget interesseret i at gevinsterne står mål med omkostninger til effektiviseringsindsatsen. Tilbud 19. Tilbud 20. Leverandøren skal i bilag 2 beskrive, ved hvilke af de beskrevne processer, der forventes at kunne realiseres et effektiviseringspotentiale. Leverandøren skal angive det forventede effektiviseringspotentiale for hver enkelt proces, der foreslås effektiviseret. Effekten angives for det første hele år efter implementeringen af effektiviseringsforslagene. Leverandøren skal beskrive hvilken metode der vil blive anvendt til identifikation af effektiviseringspotentialet. Leverandøren skal beskrive hvorledes effektiviseringspotentialet kan realiseres og hvorledes effektiviseringspotentialet kan dokumenteres. Leverandøren skal som option i bilag 13 medtage bistand til realisering af effektiviseringspotentiale. Prisen angives pr. proces, som leverandøren foreslår effektiviseret. Prisen for bistanden skal fastsættes ud fra det princip, at betalingen er afhængig af, om det beskrevne potentiale opnås, således at betalingen reduceres forholdsmæssigt BILAG 1 C - KRAVSPEFICIKATION SIDE 9

14 med en eventuel manglende indfrielse. Opnås kun 80 % af det anslåede potentiale, udbetales kun 80 % af honoraret Regnskabsafslutning og læseadgang 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. 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. Tilbud 21. 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. Det forventes, at læseadgangen i år 1 skal omfatte ca. 25 licenser, samt et begrænset antal brugere med fuld adgang til systemet (4). Læseadgangen i de resterende år skal omfatte ca. 5 licenser. Priserne angives som en %-sats af det ved kontraktudløb gældende faste månedlige vederlag for brugsret, drift og vedligeholdelse. BILAG 1 C - KRAVSPEFICIKATION SIDE 10

15 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 23. Den tilbudte løsning skal i hele kontraktperioden opfylde og overholde og understøtte administrationen af al relevant lovgivning m.v. (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. Budget- og regnskabssystemet ( den gule mappe ) J. Årsregnskabsloven Krav 24. Tilbud 22. 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 forventes i kontraktperioden at 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 23. 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 11

16 5.4 Krav vedrørende økonomistyring for selvstændige virksomheder Den nuværende løsning benyttes til økonomistyring for et antal af kommunens samarbejdspartnere (fx selvejende institutioner), der har adgang til separate virksomhedsopsætninger, som dog ikke er integreret med økonomisystemet. Tilbud 24. Tilbud 25. Leverandøren skal i underbilag til bilag 2 redegøre for løsningens evne til at håndtere multiple, uafhængige virksomheder med egen kontoplan, bankkonti etc. Omkostningerne til at håndtere flere regnskaber skal være indregnet i prisen i bilag Brugervenlighed og fleksibilitet Det er vigtigt for kunden, at systemet er brugervenligt og intuitivt. Dette betyder også, at der skal være online hjælp fx. 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 m.v. skal foreligge på dansk. Herudover bør systemet være fleksibelt, således at det er enkelt for kunden selv at foretage ændringer fx. i rapporter, kontoplan m.v. Krav 25. Krav 26. Krav 27. Det er et krav, at systemet skal være brugervenligt og fleksibelt i forhold til kundens fremtidige behov for justeringer og tilpasninger. 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 m.v Der efterspørges et sammenhængende og fleksibelt standardsystem. 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 26. Tilbud 27. Tilbud 28. Tilbud 29. 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 under hvilke forudsætninger dette kan ske. 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. BILAG 1 C - KRAVSPEFICIKATION SIDE 12

17 5.6.1 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. Tilbud 30. 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. Fredericia Kommune anvender i dag Novell Identity Manager 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 Novell Identity Manager 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 lønberegning m.v. 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 løn- og personaleadministration samt vagtplanlægning. Kunden forventer desuden, at der kan være behov for yderligere snitflader. Tilbud 32. Krav 28. 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 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 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 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 342 af 11. marts 2004 eller den til enhver tid gældende bekendtgørelse. BILAG 1 C - KRAVSPEFICIKATION SIDE 13

18 Krav 29. Leverandøren skal, som en del af den elektroniske aflevering af data, levere den tekniske dokumentation af systemet der afleveres ved afleveringsforhandling. Den tekniske dokumentation bør indeholde en tabeloversigt og et struktur-diagram. Der skal fra leverandørens side foreligge et tilbud der indeholder arkivering og fremstilling af en arkiveringsversion. (forudsætning om en årlig arkivering). 5.7 Data til Fælleskommunalt Ledelsesinformationssystem (FLIS) Kunden ønsker at anvende FLIS som ledelsesinformationssystem, hvorfor den kommende løsning forventes at kunne levere data til FLIS, således at kundens data kan analyseres via FLIS. Tilbud 35. Leverandøren skal i underbilag til bilag 2 beskrive, hvordan og i hvilket omfang løsningen vil aflevere data til FLIS. Krav 30. Den beskrevne funktionalitet skal være indregnet i prisen i bilag Data til ledelsesinformation (option) Kunden ønsker direkte adgang til alle data registreret i løsningen (ned til mindste registrerede enhed, fx cpr-nr), således at disse kan indlæses i kundens eget ledelsesinformationssystem. 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. Tilbud 36. 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 Dataudtræk Kunden benytter i høj grad ad hoc dataudtræk fra systemer til løn- og personaleadministration samt vagtplanlægning i den daglige produktion. Anvendelsen og omfanget af disse data er meget varierende og skal understøttes på flere niveauer: Niveau 1: Kunden ønsker at kunne analysere alle data i løsningen via en specialiseret brugerflade, der leveres som en del af tilbudsgivers løsning. Niveau 2: Brugere kan vælge at udtrække valgte data, eller data behandlet i niveau 1 til manuel eller maskinel behandling i andre systemer, herunder til gængse regnearks- og tekstbehandlingsformater. Niveau 3: Brugere kan opstille og gemme egne standardrapporter, eller redigere i foruddefinerede standardrapporter. Rapporterne skal kunne udskrives eller eksporteres jf. niveau 2. Tilbud 37. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til dataudtræk på de beskrevne niveauer, samt den tilbudte validitet og aktualitet af tilgængelige data inden for hvert af de 3 trin. Kunden ønsker fra regneark at kunne foretage direkte opslag og trække data (fx budgettal) fra Økonomisystem via forprogrammerede makroer. Tilsvarende makrobaseret funktionalitet benyttes til at tilbageinddatere de i regneark bearbejdede data til Økonomisystemet. Tilbud 38. Leverandøren skal i underbilag til bilag 2 redegøre for, hvorledes løsningen fra regneark håndterer direkte opslag og datatræk (fx budgettal) fra Økonomisystem via for- BILAG 1 C - KRAVSPEFICIKATION SIDE 14

19 programmerede 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 2003, og løsningen skal understøtte formater der kan anvendes med denne programpakke, og alle senere versioner af Microsoft Office. Kunden ønsker mulighed for at kunne anvende Open Office, hvorfor den tilbudte løsning bør understøtte formater der kan anvendes med denne programpakke. Tilbud 39. Leverandøren skal i underbilag til bilag 2 redegøre for løsningens anvendelse af filtyper i forbindelse med dataudtræk, og hvorvidt disse opfylde ovenstående ønsker til understøttelse af nævnte kontorpakker Metadata og søgbarhed Kunden ønsker fortsat at kunne benytte den nuværende løsnings funktionalitet i forhold til at knytte ad hoc kommentarer til poster, herunder tilknytte filer. Denne funktionalitet har stor betydning i forhold til især decentrale brugeres anvendelse af økonomisystemet. Funktionaliteten ønskes anvendt til dokumentationsformål gennem tilknytning af originaldokumenter til poster. Tilbud 40. Tilbud 41. 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 31. Løsningen skal indeholde funktionalitet til at afvikle periodiske jobs (batchjobs), fx i forbindelse med inddatering via overførsel eller udskrivning af data, rapportering, ad hocanalyser eller andet. Løsningen skal kunne afvikle periodiske og tidsforskudte jobs (batchjobs), fx udenfor arbejdstiden i forbindelse med inddatering og overførsler Krav til driftsplaner Krav 32. 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 vidensoverfø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 42. Leverandøren skal i underbilag til bilag 2 medtage udkast til driftsplaner. BILAG 1 C - KRAVSPEFICIKATION SIDE 15

20 5.13 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 33. Systemet skal overholde de i bilag 9 aftalte svartider, oppetider mv. BILAG 1 C - KRAVSPEFICIKATION SIDE 16

21 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 Økonomi og budget Debitorområdet Ressourcestyring Indkøb og E-handel Anlægsstyring og anlægsregnskab Betalinger (bank, kasse og E-fakturaer) Rapportering og ledelsesinformation Årsafslutning og aflæggelse af årsregnskab BILAG 1 C - KRAVSPEFICIKATION SIDE 17

22 6.1 Kontoplan Tilbud 43. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående kontoplan. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen 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 indebære mulighed for en tværgående økonomistyring i hele kommunens brug af gennemgående konteringsdimensioner. Desuden skal der være mulighed for at understøtte forskellige decentrale styringsbehov med valgfri opbygning af registreringsdimensioner i forhold til specifikke styringsbehov lokalt. 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. I forhold til styringsbehovene i fagafdelingerne/stabene og på institutionsniveau 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 løbende lever op til de gældende regler i forhold til den af Indenrigsministeriet autoriserede kontoplan. Beskrivelse af forretningsprocessen og dens kritiske processer Kontoplanen vedligeholdes centralt. Ved behov for nye konti, udfylder kommunens enkelte enheder en formular, som indeholder alle nødvendige oplysninger. Den kontoplanansvarlige validerer oplysningerne inden konti oprettes. Institutionerne laver decentrale konti ved anvendelse af projektkoder, som institutionerne selv kan oprette. Systemet skal understøtte organisatoriske ændringer og flytning af opgaver og budgetansvar til andre enheder, herunder Oprettelse af helt nye organisatoriske enheder Flytning af eksisterende enheder til anden del af organisationen Oprettelse af enheder (fx daginstitutioner), hvor der i forvejen findes tilsvarende enheder Masseoprettelser og masseændringer Specifikke krav til it-løsning Kontoplanen skal opbygges som en multidimensional kontoplan. Brugen af registreringsdimensionerne skal kunne styres på flere niveauer, eksempelvis: Nogle af dimensionerne skal være gennemgående for hele kommunen, således at der på tværs kan foretages økonomianalyser af bestemte omkostningsarter, eksempelvis bygninger. Nogle registreringsdimensioner skal kunne fastlægges for en gruppen af enhe- BILAG 1 C - KRAVSPEFICIKATION SIDE 18

23 Navn for processen Kontoplan der/institutioner (fx for skoler). Andre dimensioner skal frit kunne benyttes decentralt til særlige styringsformål. Det skal være muligt at opsætte systemet, så det er krævet at udfylde udvalgte registreringsdimensioner. Dimensionstekster skal kunne låses i forhold til den værdi, der registreres på en dimension. Systemet skal have en elektronisk formular til brug for ansøgning om oprettelse af ny konto. Systemet skal kunne give advis (via ) til udvalgte medarbejdere i fagafdelingerne/stabene og decentrale institutioner, 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 og lønsystem. Ø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. At konti, dimensioner mv. kan styres på dato og år. Systemet skal kunne styre (periodisere) de autoriserede kontotekster mv. 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å. At det er muligt at nedlægge gamle konti, der ikke har været i brug i flere år. 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 kan rumme tekstlængden i den autoriserede kontoplan At der kan vedhæftes dokumenter som dokumentation for ændringer (fx mails, worddokumenter, hyperlinks m.v.) 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 BILAG 1 C - KRAVSPEFICIKATION SIDE 19

24 Navn for processen Kontoplan 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. Tilsvarende skal pensionskoder, som bliver brugt i pensionssystemet, registreres og data overføres til pensionssystemet. Ved bogføring af e-bilag skal der valideres for momsafvigelser. Systemet skal understøtte oprydning og lukning af ikke brugte konti. Kvantitative forhold ved processen Kunden har i dag ca konti, heraf ca konti er aktive. Kunden ønsker, at kontohistorik kan ses i det nye system fra år Kommunen har i det nuværende økonomisystem godt brugere oprettet, hvortil kommer systemtekniske brugere, såsom kasser, og fiktive brugere til brug for systemadministration og undervisning. BILAG 1 C - KRAVSPEFICIKATION SIDE 20

25 6.2 Økonomi og budget Tilbud 44. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Økonomi og budget. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Økonomi og budget 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 samt 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 skal have let adgang til information om budgetstatus og relevante budgetposteringer for brugere på alle niveauer af organisationen. Kunden skal ved udarbejdelse af budget klart kunne skelnes mellem status for budgetter. Der ønskes et ubegrænset antal statusmuligheder, som kunden selv navngiver, eksempelvis: Budgetønsker og vedtaget budget. I vedtaget budget skal der efterfølgende kunne indberettes tillægsbevillinger, omplaceringer, budgetopfølgning 1, budgetopfølgning 2, budgetopfølgning 3 og overførsler m.v. Kunden ønsker, at økonomisystemet indeholder funktioner til budgetsimulering og op- og nedskrivninger af budgettal både i forhold til den centrale budgetfunktion samt fagafdelinger/ stabe og institutioner, der kun skal arbejde på et udsnit af budgetterne. 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 tilføjet diverse reguleringer i form af tekniske korrektioner og fremskrivninger (pris- og lønfremskrivninger etc.) Budgettet gøres tilgængeligt for fagafdelinger, stabe og institutioner. Budgettet samles. Politisk budget. Budgetopfølgningens delprocesser udgøres af: Løbende budgetopfølgninger med detaljeret rapportering på alle niveauer BILAG 1 C - KRAVSPEFICIKATION SIDE 21

26 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. Omplacering af budgetposter, herunder detaljeret udmøntning. Håndtering af tillægsbevillinger, herunder detaljeret decentral udmøntning. 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. Ordinære budgetposter samt tillægsbevillinger, omposteringer og overførsler skal hver registreres med en særlig type og en registreringsdato. Det skal være muligt at kunne følge mellem hvilke konti en eventuel omplacering/ompostering foretages. Der skal ske logning 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. Ved rammeudmeldinger skal den enkelte enhed have mulighed for at lave omplaceringer inden for rammen. Der ønskes mulighed for at sammenkoble relaterede budgetposter, fx relaterede tillægsbevillinger eller relaterede omplaceringer, så det bl.a. er let at finde eventuelle modposteringer til en given budgetpost. Sammenkædningen kan fx ske ved at sammenkoble relaterede budgetposter med ét bilagsnummer. Der ønskes mulighed for at markere/sammenkoble relaterede poster fx vedrørende refusioner, hvor der ved ændringer er sammenhænge mellem forskellige kontonumre men med forskellig effekt (fx 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. Fx ønskes mulighed for at vedhæfte/linke til dokumentation af takstmodeller, BUM, demografimodeller osv. på en let måde. Der tilknyttes metadata til sagen (DUT-sag, 0-sag, mængde justeringer mv.) Tillægsbevillinger og omplaceringer skal registreres med en valørdato, så man kan opgøre det korrigerede budget pr. en given dato. Der ønskes i forbindelse med budgetfunktionen en mulighed for via systemet at sende ADVIS til udvalgte nøglebrugere, fx hvis der centralt indtastes budgetposter med decentral virkning, eller hvis en given budgetændring betyder, at den samlede ramme overskrides. BILAG 1 C - KRAVSPEFICIKATION SIDE 22

27 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. 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, fx ønskes mulighed for at lave udtræk med flere kommentarkolonner på skærmen samtidig. At systemet indeholder funktionaliteter, der understøtter kundens behov for at danne forventet årsregnskab. Der ønskes mulighed for at udtrække data i både faste og løbende priser for valgfrit år (eksempelvis regnskab 2009, korrigeret 2010 samt budgetforslag 2011 samt overslagsårene alle i 2011-priser). Endvidere ønskes der et brugervenligt system, der er overskueligt og nemt at arbejde med og som samtidig indeholder avancerede simulerings- og rapporteringsværktøjer. Ø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 At løsningen kan understøtte automatisk udrulning af rammebesparelser, fx på skoler og daginstitutioner. At der er adgang til en veludbygget dynamisk to-vejs integration til regneark, således at data nemt kan trækkes ud for manuel behandling (fx 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 23

28 6.3 Debitor Tilbud 45. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Debitor. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Debitor Formål og overordnede krav Kunden ønsker, som en del af økonomisystemet, et debitormodul, der dels kan modtage transaktioner fra diverse modersystemer og udskrive girokort samt danne fakturaer fra kommunens øvrige fagafdelinger/stabe og institutioner, og dels kan håndtere funktioner vedr. betalingskontrol, restancer m.v. 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 debitorsystemet. Faktura udskrives og udsendes til debitor. Kontering foretages samtidig Regningsdebitor-modulet anvendes til opkrævning af krav, der ikke opkræves via fagsystemer Når et krav er oprettet i regningsdebitor udskrives faktura og kravet overføres til opfølgning i KMD Debitor. Kontering foretages samtidig. Regninger udsendes via Doc-2-Mail til borgeren Tilgodehavender kan også indberettes manuelt i debitorsystemet, som konteres automatisk i økonomisystemet. Indbetalinger bogføres gennem kasse, bank og PBS. 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. I forbindelse med rykkere pålignes gebyr og renter. Fordringer sendes til CFR. Særlige forhold vedr. restancer håndteres i form af afdragsordninger samt overdragelse af restancer til SKAT. Efter 1. rykker oversendes fordringen til inddrivelse hos SKAT. Til opkrævning af mellemkommunale refusioner og serviceydelser på sociale tilbud anvendes regnings-debitormodulet. BILAG 1 C - KRAVSPEFICIKATION SIDE 24

29 Specifikke krav til it-løsning Faktura- og FIK-kort udskrivning Debitormodulet skal understøtte alle former for regninger/fik-kort som anvendes i offentlige institutioner, herunder papirbaserede regninger, PBS-regninger og e-fakturaer Kopier af fakturaer/kreditnotaer skal kunne lagres elektronisk og genudskrives. Fakturaer/kreditnotaer skal kunne sendes elektronisk. Fakturaer skal kunne sendes til E-boks. Debitormodulet skal kunne håndtere løbende periodisk opkrævning fx for opkrævning for daginstitution. Der skal være mulighed for at henlægge sagen i en periode. Der skal kunne tilføjes afdragsaftaler. Det er kommunens ønske selv at kunne foretage straks-udskrivning af fakturaer, herunder afgørelser om tilbagebetaling af kontanthjælp (så vi slipper for papir). Der ønskes fra debitormodulet læseadgang til: o o o Boligsikringskrav Regulering af daginstitution Underholdsbidrag 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. Der ønskes mulighed for ved opslag på debitorens saldo at se overordnet restancesaldo for hvert cpr. nr., CVR-nr./SE-nr. Når en person indgår i en virksomhed, hvor pågældende personligt hæfter for virksomhedens restance, skal det fremgå under pågældendes cpr.nr., at der også er gæld vedrørende virksomhedens forhold. Restancer skal kunne nedskrives/opskrives og betalingsaftaler skal kunne indgås og administreres. Systemet skal indeholde en journalfunktion, hvori alle hændelser i systemet registreres i forhold til den enkelte borger. Der skal desuden være et notatfelt. Endvidere skal være mulighed for vedhæftning af filer eksempelvis notater, tilbagebetalings-afgørelser, beregninger m.v. 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, ligesom opkrævning skal kunne foregå til personer uden gyldigt CPR-nr. BILAG 1 C - KRAVSPEFICIKATION SIDE 25

30 Oversendelse af ikke betalte ydelser til SKAT skal parameterstyres, så brugeren selv afgør hvad der medsendes. Data oversendes elektronisk. Øvrige forhold 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 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 hjemmesiden (med NEMID). Systemet skal understøtte muligheden for at kunden kan lave selvbetjeningsløsninger på 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. 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 E-indkomst ved udbetaling af visse beløb skal der ske en registrering i E-indkomst E-boks til fakturaer SKAT der skal være en snitflade for overførsel af restancer til SKAT/Rekvirent Borger.dk SKAT modregningsmodul til overskydende skat SKAT skal have læseadgang CPR Diverse fagsystemer Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 26

31 6.4 Ressourcestyring Tilbud 46. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Ressourcestyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen 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 drift- og anlægsområde, bygningsservice mv. Kunden skal, hvor det er relevant, kunne detailstyre ressourceforbruget (fx mandetimer, maskintimer, materialer, underentreprenører etc.) på effektiv og professionel vis, og de forbrugte ressourcer skal afspejles i økonomisystemet. 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 Delprocesser vedrørende ressourcestyring udgøres overordnet af: Budgettering og timeregistrering på sager, med hoved- og underaktivitets-niveau (tværgående) for ressourcer, maskiner og for værkstedspersonale. Registrering/styring af ferie, afspadsering, mer- og overarb.timer samt flex Budgettering og timeregistrering på ressourcer og maskiner. Godkendelse af timeregistrering (af formænd og administrativt personale). Automatisk overførsel til af lønbærende informationer til lønsystem. Vedligeholdelse af kost- og salgspriser på ressourcer til fakturering (styring af mandskabsog maskinpriser) Plejeplaner (vedligehold af grønne områder, græs, træer, bede mv.) Ledelsesinformation/styringsværktøj (tidsforbrug på opgaver) Rapporter over tidsforbrug pr. medarbejder eller pr. opgave mv. Div. rapporter, herunder tværgående rapporter på Hoved og Underaktiviteter. Tankanlæg (brændstof Driftsafdelingen) Lagerstyring Intern afregning (intern fakturering) Ressourcestyringen forgår i dag i Prisme. Medarbejderne hos entreprenørafdelingen registrerer deres tid på ugesedler, som inddateres. Godkendelsen af registreret tid foregår ligeledes i Prisme. Medarbejdere i fagafdelingerne Vej & Park, Plan & Byg samt Natur & Miljø registrere timerne i Projektportalen, der er et projektstyringssystem udviklet til Fredericia Kommune. Projektportalen bruges til projektorganisering, projektstyring samt deling af projektdokumenter. 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. Løsningen anvendes udelukkende inden for det tekniske område, men en fremtidig løsning tænkes potentielt udbredt til yderligere områder, fx projekter, det sociale område, skoler og daginstitutioner. BILAG 1 C - KRAVSPEFICIKATION SIDE 27

32 Der lægges vægt på brugervenligheden af registreringsflowet i forbindelse med timeregistrering m.m., da en stor andel af brugerne ikke anvender øvrig it i forbindelse med deres arbejde. 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. Der lægges vægt på, at ressourcestyringsløsningen er velegnet til håndtering af bevillingsmæssige forhold (budgetter), som de kommer til udtryk i en dansk kommune, herunder på løsningens funktionalitet i forhold til opfølgning af rapportering på sager/projekter i forhold til bevillinger, herunder krav til dokumentation af forbrug på områder/delaktiviteter. Desuden ønskes: Elektronisk rekvisition/ordrestyring med disponering (med vedhæftning af filer med kort, foto eller tegninger) Budgettering (rådighedsbeløb og bevillingsbeløb, et-årig og flerårig) Kalkulationer (sager, mandskab og på maskiner) Integration til GIS og plejeplaner Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Integration til økonomisystem, i det omfang der ikke er tale om ressourcestyring som en integreret del af dette. Integration til lønsystem Yderligere integrationer, se generelt afsnit desangående Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 28

33 6.5 Indkøb og E-handel (option) Tilbud 47. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Indkøb. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Indkøb 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øbsansvarlige skal nemt og effektivt kunne orientere sig om kommunens indkøbsaftaler for varer og tjenesteydelser, merkantile forhold samt 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. Beskrivelse af forretningsprocessen Der indgås indkøbsaftaler for hele kommunen. 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 for at følge op på brugen af indkøbsaftalerne. Analyserne, fx prisanalyser, foretages i SAS som udtrækker varelinjer og vareordre fra Prisme. Kunden anvender i dag et indkøbssystem fra Truelink. Efter varemodtagelse med kontrol af mængder og priser, overføres bilaget til Prisme til automatisk bogføring og betaling. Specifikke krav til it-løsning Kunden ønsker, at følgende delprocesser understøttes af IT-systemet: Etablering og vedligeholdelse af indkøbsaftaler Opdeling i "kan-aftaler" og "skal-aftaler" Opdatering og administration af elektroniske varekataloger, herunder priskontrol. Varer som ikke er omfattet af aftalen overgår til manuel kontrol. Ved indlæsning af elektronisk varekatalog, skal der med afsæt i en given aftalt prisstigning være mulighed for 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. Favoritsider og standardordrer (pr. bruger) Nyhedsformidling vedr. indkøb og indkøbsaftaler IT-løsningen skal understøtte følgende enkelte delprocesser vedrørende elektroniske indkøb: BILAG 1 C - KRAVSPEFICIKATION SIDE 29

34 Søgning og visning af varer eller søgning efter indkøbsaftale. Bestilling af varer, hvor ekspeditionsgebyrer, fragt mv. skal være synlige for bestilleren. 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. 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. Kataloget skal kunne sorteres alfabetisk og i forhold til pris. Der skal være mulighed for at anvende flere indgange til søgning, eksempelvis at søge på bestemte typer oplysninger og foretage tværgående søgning på alle oplysninger. Ved visning af varer, skal visning ske med en linje pr. vare i et oversigtsbillede. Liste over udsøgte varer skal kunne udskrives Ud fra listen over varer skal man kunne få adgang til mere detaljerede oplysninger om den enkelte vare fx 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 Mulighed for oprettelse af favoritliste pr. bruger Ved bestilling af varer skal der være mulighed for at slette eller tilføje varelinjer Ved bestilling af varer skal der angives kontonummer, som efterfølgende påføres faktura. Ved varemodtagelse skal varemodtagelsen kunne foretages for ordren som helhed og på varelinjeniveau. Der skal tages stilling til, om manglende levering skal optages som restordre. 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å disse foreslås på bestillingsoversigten, når der bestilles. Det skal være muligt at genere statistik på alle data på baggrund af såvel afsluttede som ikke afsluttede ordrer. Statistik skal kunne udtrækkes i forhold til alle følgende nævnte dimensioner leverandører, sted/bruger, tid og varer (gerne på unspec-koder). Der skal kunne generes indkøbsstatistiker på brugerniveau, institutionsniveau, kommuneniveau, ordre, leverandør periode mv. Data skal kunne overføres til Excel. Der skal kunne udtrækkes ledelsesinformation i form af rapporter med compliance-analyser. Øvrige krav: Mulighed for et aftalemodul, hvor samtlige indkøbsaftaler lægges ind og som minimum giver BILAG 1 C - KRAVSPEFICIKATION SIDE 30

35 automatisk besked ved aftaleudløb. Mulighed for udsøgning af indkøbsaftaler alfabetisk og efter produktgruppe. Mulighed for et modul hvor der kan lægges indkøbstekniske oplysninger, nyheder, brugervejledninger ind. Mulighed for at bruge indkøbssystemet som disponeringsværktøj og styringssystem på bl.a. det specialiserede område, ved at oprette indgåede aftale i indkøbsmodulet, så råderummet kan følge ved aftalernes indgåelse. 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 fx institutioner. Der skal være mulighed for konteringsoplysninger i form af kontonummer og egen posteringstekst på ordre- og varelineniveau. Der skal være mulighed for ved fakturabehandlingen at fordele fakturabeløb på varelinjeniveau på flere konti. 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 indløb. Afgivne ordre bør i økonomisystemet medtages som disponeringer ved beregning af råderum. Ved betaling skal disponeringen modregnes. Forud for betaling af en faktura ønskes, at systemet foretager en søgning efter eventuelle kreditfakturaer på samme ordrenummer. I givet fald ønskes en bemærkning om, at udligning af de to fakturaer skal ske. Økonomisystemet skal kunne udskrive anmærkningslister over udeståender, der ikke kan udlignes. Økonomisystemet skal kunne udskrive betalingsoversigt og diverse statistik. 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. Indtastning af posteringstekst skal kunne gøres obligatorisk og den skal kunne ses på den enkelte postering i økonomisystemet. Der skal foregå automatisk opdatering af oplysninger mellem indkøbssystem og økonomisystem, herunder også ved opdatering af kontoplanen. Der ønskes øjeblikkelig opdatering af økonomisystemet ved bogføring af blandt andet e- fakturaer. BILAG 1 C - KRAVSPEFICIKATION SIDE 31

36 Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 32

37 6.6 Anlægsstyring og anlægsregnskab Tilbud 48. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående anlægsstyring og anlægsregnskab. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen 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 m.v. 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 kunne 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 byrådets krav om et overskueligt anlægsregnskab (regnskaber på en side efter en fast skabelon). 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 omkostningerne, godkendelse af anlægsprojekt, frigivelse af rådighedsbeløb, budgetjusteringer, forbrug fordelt på regnskabsår og på artsniveau, løbende opfølgning på forbrug på projektet 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 og forbrug. Udarbejdelse af anlægsoversigter. Rapportering til udvalg m.fl. vedrørende anlægsregnskaber. I dag anvender kommunen Prisme til styring af - og rapportering vedr. anlægsprojekter. Bygningsdriften styres i Caretaker, som er integreret til Prisme. BILAG 1 C - KRAVSPEFICIKATION SIDE 33

38 Navn for processen Anlægsstyring og anlægsregnskab 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). Der ønskes mulighed for en kobling af anlægsprojekter til finansdel (lån, deponering m.v.) 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 byrådet, hvor anlægsregnskabet vises overskueligt gerne på én side, hvis muligt. Der ønskes mulighed for fra økonomisystem at generere en standardrapport til opfølgning på anlægsudgifter, som for hvert anlægsprojekt kan vise følgende oplysninger: 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 2011 anlægsbevillinger. 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. BILAG 1 C - KRAVSPEFICIKATION SIDE 34

39 Navn for processen Anlægsstyring og anlægsregnskab Der ønskes etableret integration til Caretaker, så der opnås en sammenhængende styringssystem med optimale processer. Kvantitative forhold ved processen Årligt afsættes der i kommunen i størrelsesordenen 75 mio. kr. netto til anlægsprojekter. BILAG 1 C - KRAVSPEFICIKATION SIDE 35

40 6.7 Betaling (bank, kasse og e-faktura) og kreditor Tilbud 49. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Betaling (bank, giro og kasse). Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Betaling (bank, giro og kasse) 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. Beskrivelse af forretningsprocessen Kontantkasser Kommunen har en hovedkasse samt ca. 130 kontantkasser på institutionerne, klubber, skoler mv.. I Hovedkassen modtages indbetalinger fra borgere enten kontant eller via dankort. Hovedkassen opgøres dagligt, mens decentrale kontantkasser nogle steder kun opgøres ugentligt eller mindre hyppigt. Betaling for pas og kørekort foregår i dag via kontaktbetaling eller via Dankort hos Borgerservice. Bank Ud over kundens centrale bankkonti har kunden 150 bankkonti på decentralt niveau. Indbetalinger med angivelse af kortart 71 og 04 bogføres direkte ind i økonomisystem og bank. For øvrige indbetalinger undersøger opkrævningsafdelingen manuelt, hvor i debitorsystemet/konti indbetalingen skal hen. Kreditnota Kreditnotaer modtages elektronisk og modregnes i hængende fakturaer. Udligning Der sker automatisk udligning af det skyldige beløb, hvis indbetalingerne er foretaget på baggrund af udskrevne regninger fra regningsdebitormodulet. E-faktura E-fakturaer modtages i Prisme og behandles på alle niveauer i organisationen. Kontrolfunktioner i forbindelse med elektronisk bilagsbehandling Kreditorer Kreditorregistret vedligeholdes centralt. Kreditnotaer modtages elektronisk og modregnes i hængende fakturaer. Kreditorbetalinger anvises centralt til betaling på den anførte betalingsdato via kundens bankforbindelse. Anvisningen er elektronisk. 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. F.eks. øn- BILAG 1 C - KRAVSPEFICIKATION SIDE 36

41 skes en matchning af f.eks. sygedagpenge, der skal trækkes tilbage (efter raskmelding), så posterne automatisk går i nul, når de for meget udbetalte sygedagpenge er tilbagebetalt. Desuden ønskes automatisk dannelse af kassekladde (elektronisk godkendelse af transaktioner). Der ønskes mulighed for at kunne foretage udsøgninger på kun åbne poster, så der nemmere kan ske en afstemning af disse, uden at skulle frasortere poster, der allerede er udlignet, herunder fakturaer, der f.eks. er mere end 3 uger gamle. Kunden ønsker en løsning til sikring af, at der ikke laves ét-benede posteringer f.eks. en advarsel, hvis man laver én-benede posteringer eller en begrænsning, så der ikke kan laves disse ved omposteringer (ved interne afregninger skal en anden part lave modposten). 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 fx via at give fagafdelinger/stabe besked om overskredne betalingsdatoer m.v. Kreditorer Det skal være muligt at oprette kreditorer manuelt samt automatisk på baggrund af kreditorens CVR.nr./ SE nr. eller cpr. nr. På kreditoren skal man kunne anføre de aftalte samhandelsforhold, fx betalingsbetingelse. Der ønskes fra kreditormodulet med 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 Betalingskontrol Betalinger i videst muligt omfang udligne eventuelle tilgodehavender 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. Der ønskes mulighed for ved opslag på kreditorens saldo at se overordnet saldo for hvert cpr. nr., CVR-nr./SE-nr. Det skal være muligt at udskrive saldolister, betalingsforslag mv. Øvrige forhold og ønsker Posteringer fra andre fagsystemer skal kunne overføres til økonomisystemet dagligt. Betaling for pas og kørekort skal understøttes af det nye system. Der ønskes kassekladde til bogføring. BILAG 1 C - KRAVSPEFICIKATION SIDE 37

42 Betaling skal ske ved lette processer, størst mulig gennemskuelighed og brugervenlighed. Integration til Excel er et krav. Systemet skal kunne håndtere fakturaer og afregning i euro og andre valutaer. Der skal kunne udskrives fakturaer direkte fra systemet og der skal kunne udskrives kvitteringer fra systemet. Det skal være muligt at anvise manuelle købsbilag til betaling. 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. Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 38

43 6.8 Rapportering og analyse Tilbud 50. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Rapportering og analyse. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Regnskab 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 ledelsesinformation, som kan sikre det bedst mulige styringsgrundlag. Der ønskes en rapportering, hvor systemet foreslår en rapporteringsform efter hvilken rolle brugeren indtager. Kunden stiller krav om, at systemet giver brugerne adgang til information om alle relevante økonomiske forhold samt forhold vedr. løn og personale. 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 selv at definere rapporter og udtræk. Dette inkluderer kodning af udvalgte konti og posteringer, så der kan følges op på specifikke områder på tværs af kontoplanen og bogføringselementer. Kundens informationer skal kunne hentes online med fleksible og valgfri muligheder for afgrænsninger på alle dimensioner, konti, baggrundsdata (fx 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. Tilsvarende foretages i kommunens enheder opfølgning på fravær og øvrige personaleforhold. Analyserne foretages til brug for både det administrative og det politiske niveau. Til analyser af forbrugs- og budgettal udtrækkes informationer fra økonomisystemet i form af budgetrapporter. Analysernes kompleksitet kræver ofte at data viderebearbejdes, hvilket i høj grad foregår I FIE, OLAP og Targit. I hjemmeplejen og på arbejdsmarkedsområdet samles data i Targit, hvor budgetrapporterne dannes. BILAG 1 C - KRAVSPEFICIKATION SIDE 39

44 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 fx 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. det p.t. gældende budget for kommende år. Der skal i rapporteringen kunne skelnes mellem forskellige typer bevillinger: vedtaget budget, tillægsbevillinger, omplaceringer, overførsler og korrigeret budget. 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. 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, evt. som anført tidligere. 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å analyser på et mere konkret niveau kan foretages straks, 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. Mediet for rapportering skal som minimum kunne vælges mellem følgende muligheder: Udtræk til skærm, papir, pdf, regneark og flade filer (kommaseparerede filer). Udtrækkene skal kunne videresendes pr. mail. BILAG 1 C - KRAVSPEFICIKATION SIDE 40

45 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. I forlængelse af analyserne skal man kunne foretage simuleringer/estimeringer fx af, hvordan årsresultatet forventes at blive for det udvalgte område. Rapporten skal kunne gemmes. Generelt skal systemet understøtte de obligatoriske økonomirapporter i forbindelse med regnskabsaflæggelse og øvrig rapportering til ministeriet og andre offentlige myndigheder. De faste rapporter, som kommunen skal aflevere til eksterne myndigheder som fx DS, KL og Ministeriet skal kunne dannes og overføres elektronisk til modtageren. 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: Ligestillingsrapport med data fra lønsystemet Serviceudgifter Overførselsudgifter Gennemsnitslikviditet (til Indenrigs- og Socialministeriet) Halvårsregnskab Kvartalsvise indrapporteringer på det specialiserede socialområde M.fl. Øvrige forhold i relation til rapportering I forhold til rapportering lægger kunden desuden vægt på: At rapporteringen understøtter både den autoriserede kontoplan, kommunens politiske organisation, politikområder og den organisatoriske opbygning. At kunne søge på alle kontoplan- og bogføringselementer. At rapportere både på indtægter og udgifter både brutto- og nettobeløb. At benytte foruddefinerede rapporter til standardopgørelser fx. af refusion, moms m.v. 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. At gemme brugte rapportafgrænsninger til senere brug. At foruddefinere nøgletal til udtræk af økonomisystemet. At der kan udregnes forbrugsprocenter. At kunne generere automatiske rapporteringer, der tilgår modtageren elektronisk, fx gennem Sharepoint. At foruddefinerede rapporter har genkendelige og letforståelige navne. BILAG 1 C - KRAVSPEFICIKATION SIDE 41

46 At tid, dato og afgrænsninger (fx prisniveau og beløbsniveau) skal 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 2010 kan fx indeholde regnskab 2008, regnskab 2009, budget 2010 samt budget Budgetopfølgningen skal kunne foretages i løbende priser og faste priser. I eksemplet skal alle tal kunne omregnes til 2010-priser. Ved budgetopfølgningen skal det være muligt at beregne disponibelt beløb ved at sammenstille budget, forbrug og disponerede omkostninger (fx løn, indkøb, indgåede aftaler) Ved budgetopfølgningen skal det være muligt at følge op på bestande /aktivitetstal, f.eks. antal kontanthjælpsmodtagere. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Det ønskes oplyst, hvordan de tilbudte systemer kan levere data til Datawarhouse-løsninger og Business Intelligens-værktøjer. Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 42

47 6.9 Økonomi og regnskab, herunder årsregnskab, omkostningsregnskab Tilbud 51. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Økonomi og regnskab, herunder årsregnskab, omkostningsregnskab og likviditetsstyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen 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 m.v. Beskrivelse af forretningsprocessen Processen vedrørende årsregnskab udgøres overordnet af: I oktober måned 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 remitering vedr. gammelt år, men omkontering er mulig indtil ultimo februar. Ultimo januar udarbejdes delregnskaber/budgetopfølgningsrapporter. 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 mm. Kunden har valgt alene at opfylde minimumskravene til omkostningsregnskab. Herefter forestår revisionen af regnskab samt fremsendelse af rapporter til DS og Ministeriet. 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). BILAG 1 C - KRAVSPEFICIKATION SIDE 43

48 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 (fx 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 m.v. Rapporter til DS 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 Der skal 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 fx på det decentrale niveau. Udtræksmuligheder vedrørende afvigelser mellem budget og regnskab. Økonomisystemet skal kunne danne forslag til de oversigter, der er autoriseret jf. de gældende konteringsregler. Det skal være muligt at kunne danne regnskab på f.eks. udvalgsniveau. Relationer og snitflader (til andre systemer, til eksterne parter mv.) som skal understøttes Rapportudtræk til DS, KL og Ministeriet Regnskabsudtræk til kommunens revision Regnskabsudtræk til kommunen Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 44

49 6.10 Likviditetsstyring Tilbud 52. Leverandøren skal i underbilag til bilag 2 detaljeret redegøre for løsningens funktionalitet i forhold til de beskrevne opgaver, processer m.v. angående Likviditetsstyring. Det skal af redegørelsen fremgå om den tilbudte funktionalitet er tilstede på tilbudstidspunktet eller overtagelsestidspunktet. Det skal tillige af redegørelsen fremgå, hvis processen beskriver funktionalitet, som ikke tilbydes. Navn for processen Likviditetsstyring Formål og overordnede krav Kunden har brug for løbende at danne sig et overblik over kassebeholdningen til analyse og besvarelse af spørgsmål fx fra Byrådet Beskrivelse af forretningsprocessen Kunden har Prismes likviditetsmodul, som anvendes i begrænset omfang. Reelt styres likviditeten i et sidesystem. Kunden baserer sine daglige estimater af likviditeten på bank-information. Kunden har 6-7 konti, der tilsammen afspejler bankens information om kundens likviditet. Kundens proces er manuel og udfordres af datakvaliteten. 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 den gennemsnitlige likviditet pr. dag. 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. Der ønskes sikre prognoser, som kan anvendes af budgetlæggere mv. til opfølgning. Likviditetsmodulet skal være et integreret del af det samlede økonomisystem. Der skal kunne foretages pengestrømsanalyser og opgørelse af kommunens likviditets 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 i Excel. Det skal være muligt at medtage forventede indtægter og statsoverførsler 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 Kvantitative forhold ved processen BILAG 1 C - KRAVSPEFICIKATION SIDE 45