2A Kravspecifikation

Transkript

1 2A Kravspecifikation

2 2A KRAVSPECIFIKATION 1 2A.1 INTRODUKTION TIL DET ØNSKEDE SYSTEM 4 2A.1.1 Arbejdsgange i administrationen af rejser og udgifter 5 2A.1.2 Introduktion til integrationer 8 2A.1.3 Læsevejledning 9 2A.2 OVERORDNEDE KRAV 10 2A.2.2 Regelgrundlag 11 2A.3 FUNKTIONELLE KRAV 11 2A.3.1 Koncernstruktur og administrative fællesskaber 12 2A.3.2 Brugere, roller og rettigheder 13 2A Stedfortrædere 17 2A.3.3 Generelt om dokumenter i STRUHS 18 2A Opdeling af dokumenter i rejsetype 20 2A.3.4 Forhåndsgodkendelsesdokumenter og rejsebestilling 21 2A.3.5 Afregningsdokumenter 24 2A.3.6 Registrering og beregning af godtgørelser 25 2A Rejsedage og rejsegodtgørelser 25 2A Kørsler og kørselsgodtgørelser 27 2A Generelt om godtgørelser og indberetning til SKAT 28 2A.3.7 Registrering af omkostninger 29 2A.3.8 Kontering og dimensionering 31 2A Tildeling af finanskonti 31 2A Tildeling af dimensionsværdier 32 2A Særligt om Alias 33 2A Særligt om momshåndtering 34 2A.3.9 Dokumentflow 35 2A Opsætning af dokumentflow 35 2A Dokumenter i dokumentflow 36 2A.3.10 Andre krav til STRUHS 37 2A Sammenkobling af dokumenter 37 2A Kopiering af dokumenter og skabelonopsætning 38 2A Samtidige adgange til et dokument 39 2A Dokumentationsbilag 40 2A Posterings-, konterings- og dimensioneringsoversigt 41 2A Historik og logning af ændringer 42 2A Udskrift af dokumenter 42 2A Valutahåndtering 43 2A Sproglag 44 2A Udbetaling og afregning af forskud 45 2A EU-rådsrejser 45 2A Søgefunktion og dokumentoversigter 47 2A Rapportering og statistik 49 2A Informations- og fejlmeddelelser 50 2A Adviseringer 51 2A.3.11 Understøttelse af mobile platforme 52 2A.3.12 Systemkonfiguration 54 Side 2 af 79

3 2A Brugeroprettelser og -administration 55 2A.4 IKKE-FUNKTIONELLE KRAV 57 2A.4.1 Struktur, fleksibilitet og Platform 57 2A.4.2 Log ind og adgangsforhold 58 2A.4.3 Integrationer 59 2A Navision Stat 60 2A SKAT 64 2A Banker 66 2A Taxaselskab 67 2A Kørebog 69 2A Rejsebureau 70 2A ØSLDV 73 2A Rejsekort 73 2A.4.4 Myndighedskrav 75 2A Persondataloven og klassificering af data 75 2A Arkivloven 76 2A Cookiebekendtgørelsen 76 2A Regnskabsbekendtgørelsen 76 2A Statens standarder for it-sikkerhed 77 2A.4.5 Performance, servicemål og vedligeholdelse 77 2A.4.6 Historik og logning 78 2A.4.7 Brugermanualer 78 Side 3 af 79

4 2A.1 Introduktion til det ønskede system Moderniseringsstyrelsen ønsker at stille et rejse- og udlægshåndteringssystem til rådighed for understøttelse af de statslige myndigheder og statslige selvejende institutioners administration af rejser og udlæg. Systemet skal erstatte Moderniseringsstyrelsens nuværende RejsUd-løsning, der anvendes af 155 statslige myndigheder og statslige selvejende institutioner. I udbudsmaterialet benævnes systemet STRUHS for Statens Rejse- og UdlægsHåndteringsSystem. Dette bilag indeholder Kundens specifikation af krav til STRUHS funktion og virkemåde. Kravspecifikationen er udarbejdet i samarbejde med en tværstatslig referencegruppe, med repræsentanter fra ministeransvarsområderne, og dækker dermed de kendte forretningsmæssige behov hos de statslige myndigheder. Der efterspørges et etableret moderne standardsystem, der løbende vedligeholdes og udvikles i takt med standarder og best practice på markedet. Løsningen skal være en samlet koncernløsning til Staten, der understøtter tværgående konsolidering af administrative funktioner (fx i administrative fællesskaber), og tværgående processer på tværs af organisatoriske enheder både inden for det enkelte ministeransvarsområde og på tværs af ministeransvarsområder. STRUHS formål er at forenkle og digitalisere de administrative arbejdsgange forbundet med forhåndsgodkendelse af tjenesterejser/udlæg, bestilling af tjenesterejser, og den efterfølgende afregning af tjenesterejser, -udlæg, og andre udgifter afholdt i tjenesteøjemed. STRUHS skal understøtte regelsættet i Statens Rejsecirkulære, arbejdsgangene defineret som best practice for rejseadministration i staten, samt overholdelsen af gældende lovgivning om fx skatteindberetning for offentlige arbejdsgivere. Det kræves, at STRUHS: Understøtter forhåndsgodkendelse af udlæg/rejser og afsendelse af rejsebestillinger. Understøtter afregning af rejser (inkl. automatisk beregning af godtgørelser), udlæg og andre udgifter afholdt i tjenesteøjemed, herunder befordring. Understøtter et effektiv kontrol- og godkendelsesflow. Hjælper medarbejderne og ledelse med at skabe overblik over egne og organisationens rejseaktiviteter og omkostninger. Side 4 af 79

5 Er webbaseret, og kan tilgås af smartphones og tablets via brugergrænseflader beregnet til mobile enheder. Understøtter effektiv organisering i administrative fællesskaber såvel inden for ministerområder som på tværs af ministerområder. Integreres med en række eksterne systemer. STRUHS skal integreres med Navision Stat for opdatering af stamdata og bogføring/udbetaling af de oprettede afregninger. En række integrationer til banker, rejsebureau, taxaselskab og kørebog sikrer bl.a. overførsel af kreditkorttransaktioner, rejsekontotransaktioner, kørsler, rejsebestillinger og rejseplaner, med det formål at gøre håndtering af tjenesterejser og -udgifter så brugervenlig og automatiseret som muligt. Foruden skal der opsættes integrationer til eksport af godtgørelsesinformationer til SKAT, og data til statens datavarehus, ØSLDV. Det anbefales at læse Best Practice for Rejseadministration i Staten inden besvarelse af kravspecifikationen, da kravene til STRUHS tager udgangspunkt i de forretningsmæssige mål med at digitalisere rejsereglerne og giver en grundlæggende forståelse for Kundens ønsker og behov. Best Practice er vedlagt i underbilag XX, eller kan findes her: XXX. 2A.1.1 Arbejdsgange i administrationen af rejser og udgifter STRUHS skal kunne understøtte forhåndsgodkendelse af rejser og tjenesteudgifter, afsendelse af rejsebestilling og afregning af rejser og tjenesteudgifter: Forhåndsgodkendelse og afsendelse af bestilling: Afholdelse af tjenesterejser over 24 timer omfatter typisk forhåndsgodkendelse af selve rejseafholdelsen og de forventede udgifter, inden køb af rejsen gennemføres. Ligeledes kan større udlæg kræve forhåndsgodkendelse. Forhåndsgodkendelsen af både rejser og udlæg skal kunne ske i STRUHS (men vil ofte også ske via mere uformelle kanaler, fx mundtlig godkendelse eller pr. mail). Når en rejse forhåndsgodkendes i STRUHS, skal der automatisk kunne genereres en rejsebestilling, der digitalt sendes videre med henblik på køb af rejsen, oftest via Statens rejsebureau. Afregning af rejser og tjenesteudgifter: Ved rejseafholdelse skal den rejsende lave en rejseafregning i STRUHS, hvilket indebærer registrering, kontering og dokumentation af diverse udlæg, befordring og andre udgifter afholdt under rejsen, samt registrering af diæter. Ligeledes skal en medarbejder kunne lave en udgiftsafregning for øvrige udgifter, eller for udgifter der er afholdt i forbindelse med en rejser under 24 timer. Det kan fx være udgifter til fx mødeforplejning, Side 5 af 79

6 befordring, eller repræsentation. For både udgifts- og rejseafregninger gælder, at afregningerne skal sendes igennem et dokumentflow til kontrol og/eller godkendelse inden afregningen overføres til bogføring i Navision. I figur 1 er illustreret, at indeværende udbud ikke omfatter alle dele af processen for administration af rejser og udlæg: Udbuddet og kravspecifikationen omfatter kun forhåndsgodkendelsen af rejser/udlæg og afsendelse af bestilling, samt den efterfølgende afregning tjenesteudgifterne, hvilket også indebærer at sende afregningen til kontrol/godkendelse. Selve købet af rejsen foregår typisk hos Statens rejsebureau, alt imens bogføring og betaling sker i Navision Stat: FIGUR 1: Proces for forhåndsgodkendelse/bestilling og afregning Registrering af forventede rejser/udlæg Forhåndsgodkendelse af rejser/udlæg Afsendelse af rejsebestilling Køb af rejse STRUHS Forhåndsgodkendelse/bestilling Rejse-/ udgiftsafholdelse Afregning af rejse/udlæg Kontrol og godkendelse Bøgføring og betaling STRUHS Det bemærkes, at processerne for forhåndsgodkendelse og afregning af rejser og udlæg er separate, og at mange afregninger vil ske uden en foregående forhåndsgodkendelse/bestilling gennem STRUHS. Nogle institutioner vil slet ikke gøre brug af muligheden for at forhåndsgodkende gennem STRUHS, og i stedet udelukkende benytte systemet til afregningen af rejser og udlæg. I det følgende beskrives alle delarbejdsgangene i processen for administration og afholdelse af tjenesterejser og udgifter, samt hvordan de forventes understøttet af STRUHS: Forhåndsgodkendelse/bestilling Registrering af forventede rejser/udlæg Afregning For at opnå forholdsgodkendelse gennem STRUHS, opretter en bruger et forhåndsgodkendelsesdokument og angiver en forventet tjenesteudgift og/eller specifikationen på en tjenesterejse og de forventede udgifter forbundet hermed, herunder fx befordring og diæter. Side 6 af 79

7 Forhåndsgodkendelse Et forhåndsgodkendelsesdokumentet sendes til en godkender, der har til opgave at forhåndsgodkende afholdelsen af udgiften og/eller tjenesterejsen. Ved forhåndsgodkendelse af enkelte udgifter/udlæg, stopper arbejdsgangen ved godkendelsen, men ved forhåndsgodkendelse af rejser, skal STRUHS understøtte muligheden for at generere en rejsebestilling. Afsendelse af bestilling Ved forhåndsgodkendelse af tjenesterejser skal STRUHS kunne understøtte afsendelse af rejsebestilling med henblik på køb af rejsen. STRUHS skal både kunne sende en rejsebestilling direkte til Statens rejsebureau s bookingssystem, og kunne sende en rejsebestilling pr. mail til fx en sekretær, som viderebehandler rejsekøbet. Brugeren skal kunne vælge helt at undlade at sende rejsebestillingen, såfremt rejsen fx allerede er blevet bestilt på anden vis. Køb af rejse Køb af rejser håndteres hos rejsebureauet på baggrund af en bestilling fra STRUHS eller anden kommunikationskanal, fx telefonisk henvendelse. Ved køb af en rejse gennem rejsebureauet genereres en fil med en rejseplan, samt en følgeseddel i PDF-format, der begge sendes til STRUHS. Selve købet af rejsen gennemføres således ikke i STRUHS, men STRUHS modtager rejseoplysninger fra alle køb i rejsebureauet med henblik på at lette brugerens efterfølgende afregning af rejsen. Afregning Rejse- og udgiftsafholdelse Under rejsen afholder medarbejderen omkostninger med institutionens firmakreditkort eller eget betalingsmiddel (udlæg), og afholder omkostninger til befordring ved fx kørsel i egen bil, tjenestebil eller taxa. Efterhånden som medarbejderen afholder udgifter, bliver så mange udgiftsdata som muligt importeret automatisk til STRUHS (fx transaktioner og kørsler). Afregning af rejser/udlæg Brugeren afregner rejsen/udlægget løbende via STRUHS mobilapplikation, ved fx at tilføje udgifter og uploade dokumentation for udlæg. Brugeren registrerer rejsedage, befordring mv., og konterer og dokumenterer alle afholdte udgifter i STRUHS. Systemet beregner eventuelle godtgørelser på baggrund af det indtastede. Brugeren sender afregningen videre i dokumentflowet til kontrol og godkendelse. Side 7 af 79

8 Kontrol- og godkendelsesled Kontrolledet i STRUHS kontrollerer, at afregningen indeholder de nødvendige oplysninger og dokumentationer, og at den lever op til institutionens og Rejsecirkulærets regler. Godkendelsesleddet godkender konteringen, udgifternes afholdelse, og den eventuelle udbetaling. Såfremt afregningen ikke kan godkendes, sendes den tilbage til forrige led med begrundelse, og kan evt. sendes igennem dokumentflowet igen efter tilretning. Først efter godkendelse i godkendelsesleddet sendes afregningen til Navision Stat til bogføring og evt. udbetaling. Bogføring og betaling I Navision Stat bogføres afregningens udgiftsposter og eventuelle godtgørelser udbetales til den rejsende. 2A.1.2 Introduktion til integrationer Det forventede dataflow i systemunderstøttelse er beskrevet i bilag XX og gengivet i figuren nedenfor. Dataflowet viser integrationen mellem STRUHS og de diverse systemer, som der sker dataoverførsel til eller fra: SKAT: STRUHS skal indberette brugernes oplysningspligtige skattefri- og skattepligtige godtgørelser til SKAT. Side 8 af 79

9 ØSLDV: Et datadump overføres til Moderniseringsstyrelsens lokale datavarehus (ØSLDV) til brug for rapportering, afstemning, etc. Navision Stat: Hver institution har egne regnskaber i Navision Stat, som er Statens regnskabssystem. STRUHS modtager stamdata fra og sender bogføringsdata til disse regnskaber. Kørselsregistrering: Fra en kørebog modtager STRUHS oplysninger om bilkørsler genereret vha. GPS-teknologi. I STRUHS allokeres kørslerne til de rette brugere. Banker: Fra banker modtages kreditkort- og rejsekontotransaktioner, som i STRUHS allokeres til de rette brugere. Fra bankerne modtages også valutakurser. Taxakørsel: Fra taxiselskaber modtages oplysninger om taxakørsler betalt med Taxakort. I STRUHS allokeres taxakørslerne til de rette brugere. Rejsebureau: STRUHS skal understøtte bestillingen af rejser hos rejsebureauet og tillade rejser at blive forhåndsgodkendt og afregnet i STRUHS. Tjenesteyder kan fremlægge forslag til flow og integrationsniveauer, og på baggrund heraf selv definere hvad der modtages og afsendes til rejsebureauet. I vurderingen lægges der vægt på brugervenlighed og simple arbejdsgange. Udgangspunktet for Kundens forslag til integrationen er, at der sendes bestillinger fra STRUHS, og modtages rejseplaner og fakturaer fra rejsebureauet til brug ved afregningen af rejsen. Der sendes ligeledes brugerstamdata fra STRUHS til rejsebureauet. Rejsekortet: STRUHS skal på sigt modtage billetdata fra Rejsekortet, men der stilles ikke krav til integrationen i kravspecifikationen. 2A.1.3 Læsevejledning Kravene i kravspecifikationen er kendetegnet ved følgende: Emneopdeling: Alle krav er emneopdelt, hvilket har til formål at forbedre læseligheden af kravene til STRUHS. Hvert emneafsnit initieres med baggrundsinformation og/eller overordnende krav til området. Det anbefales at læse disse indledende afsnit grundigt. Hvert emneafsnit indeholder et afsluttende prioriteret krav (PK), hvor det er specificeret, at Tjenesteyder skal beskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter området. Med reference til det prioriterede krav har Tjenesteyder således mulighed for at beskrive ydelser/funktioner, som der ikke er blevet stillet krav om, men som Tjenesteyder ønsker skal indgå i besvarelsen og vurderingen af systemet. Side 9 af 79

10 2A.2 Overordnede krav Alle krav vedrører funktionaliteten i en browser, medmindre andet er angivet. Alle funktionelle krav til mobilapplikationer er kravstillet i et særskilt afsnit. Der refereres løbende til, at STRUHS skal understøtte en effektiv proces, eller sikre en effektiv håndtering af XX. Med effektivt menes, at STRUHS skal understøtte området ved at gøre nemt, intuitivt og kræve et minimum af museklik for brugeren at gennemføre opgaven. I det følgende er de overordnede krav til STRUHS samt de regelsæt, der ligger til grund for kravspecifikationen. Alle overordnede krav er mindstekrav og kan have karakter af funktionelle krav eller ikke-funktionelle krav. 2A A A A A A A A A A STRUHS skal understøtte en effektiv proces forhåndsgodkendelse af tjenesterejser og tjenesteudgifter (MK). STRUHS skal understøtte afsendelse af rejsebestillinger på baggrund af forhåndsgodkendte tjenesterejser (MK). STRUHS skal understøtte en effektiv proces afregning af tjenesterejser og tjenesteudgifter (MK). STRUHS skal understøtte et dokumentflow, der understøtter interne kontrol- / og godkendelsesprocedurer (MK). STRUHS skal stilles til rådighed som en hosted løsning og skal kunne tilgås via en browser (MK). STRUHS skal understøtte grænseflader der tilgås via tablets- og smartphones (MK). STRUHS skal integreres til Navision Stat (MK). STRUHS skal være opbygget som et koncernsystem for staten, så systemet understøtter effektiv organisering i administrative fællesskaber (både inden for ministerområder og på tværs) (MK) STRUHS skal sætte brugerne i stand til at udføre deres opgaver hurtigt og effektivt, herunder ved at tilbyde beslutningsstøtte og hjælp til fejlidentifikation og fejlhåndtering i dagligdagen (MK) STRUHS skal være bruger- og arbejdsmiljøvenligt, så det ikke medfører unødig belastning af brugerne, fx ved at antallet af museklik og behov for scrolling minimeres (MK) Side 10 af 79

11 2A A.2.2 2A Systemet skal være sikkert og understøtte principperne i ISO27001 standarden (MK) Regelgrundlag STRUHS skal understøtte og bistå med at sikre overholdelsen af regelsættet I følgende regelsamlinger: Tjenesterejsecirkulæret 1. Best Practice for Rejseadministration i Staten 2. SKAT s regler for skattefri rejsegodtgørelse 3. Persondataloven. Regnskabsbekendtgørelsen. 2A A A A STRUHS skal sikre, at satser og grænseværdier fra det til enhver tid gældende satsreguleringscirkulære overholdes (MK) 4. STRUHS skal sikre, at oplysningspligtige informationer til SKAT indsamles og indberettes i henhold til skattelovgivningen for offentlige arbejdsgivere (MK). STRUHS skal sikre, at Persondataloven overholdes (MK). Systemet skal overholde gældende revisions- og regnskabsmæssige krav (MK). 2A.3 Funktionelle krav I dette afsnit specificeres de funktionelle krav til STRUHS. Indledningsvis en kravene til koncernstruktur og kravene til rolleopdelingen defineret, efterfulgt af de generelle krav til dokumentflow, forhåndsgodkendelse, bestilling og afregning i STRUHS, samt registrering og beregning af rejse- og befordringsgodtgørelse. Herefter følger kravene til underliggende processer, der er af relevans for at kunne skabe en samlet effektiv understøttelse af administrationen af rejser og udlæg i Staten. 1 Tjenesterejsecirkulæret: Findes også i bilag XX. 2 Indsæt link til best practice, når dokumentet er blevet revideret og offentliggjort 3 SKAT s regler for skattefri rejsegodtgørelse: Findes også i bilag XX 4 Satsreguleringscirkulære for 2013: lar/2012/ ashx. Findes også i bilag XX Side 11 af 79

12 Afslutningsvis er defineret de funktionelle krav til brugen af STRUHS i mobile enheder, og krav til systemkonfiguration. Det bemærkes, at der undervejs i de funktionelle krav også løbende er opsat krav til hvordan systemkonfiguration skal understøtte de beskrevne processer. Det afsluttende afsnit om systemkonfiguration ligger i forlængelse af disse. 2A.3.1 Koncernstruktur og administrative fællesskaber STRUHS skal være et koncernsystem til Staten, der gør det muligt at understøtte de stadig stigende krav til effektiv og fleksibel administration i Staten. Staten er organiseret i en række ministeransvarsområder med et centralt ministerium (departement). Hvert ministerium har hver især en række statslige institutioner og evt. selvejende institutioner under sig. Hvert ministerium og institution er en selvstændig juridisk enhed, som har et eller flere Navisionregnskaber/-bogføringskredse tilknyttet (en institution kan fx have mere end et regnskab, fordi den administrerer en tilskudsordning). Hvert regnskab kan altså betragtes som en separat organisation, der indgår i et statsligt hierarki. Det er hensigtsmæssigt, at den enkelte bruger let kan få adgang til mere end en organisation og at brugeren kan have forskellige roller i forskellige organisationer, så administrative fællesskaber kan understøttes, uden at brugeren skal oprettes mere end en gang. Endeligt gælder det, at den hierarkiske opbygning af organisationerne skal være fleksibel og kunne ændres, så man fx let kan flytte en institution fra et ministeransvarsområde til et andet i forbindelse med en ressortændring. Organisationshierarkiet i STRUHS skal kunne styres af Moderniseringsstyrelsens globale systemadministratorer, mens tildeling af brugerrettigheder også skal kunne gennemføres af en lokal systemadministrator i de dele af organisationshierarkiet, som den lokale systemadministrator har adgang til. 2A A A En global systemadministrator skal nemt kunne oprette, ændre og spærre organisationsenheder i STRUHS, således at de fx kan administrere oprettelsen af en ny institution eller sammenlægning af to institutioner (PK). En global systemadministrator skal nemt kunne opsætte og ændre den hierarkiske struktur for organisationsenhederne i STRUHS, således at de fx ved ressortændringer kan administrere flytningen af en institution til et andet ministeransvarsområde (PK). En global systemadministrator skal nemt kunne ændre brugernes tilknytning til en given organisationsenhed i STRUHS, således at de fx ved ressortændringer kan administrere flytningen af en gruppe ansatte til en anden organisationsenhed (ØK). Side 12 af 79

13 2A A A A A A A A En bruger skal nemt kunne tildeles systemroller til en, flere eller alle organisationer der er oprettet i STRUHS, på den samme brugerprofil, således at en bruger fx kan være kontrollant for alle institutioner under et givent ministeransvarsområde (ØK). En bruger skal kunne tildeles forskellige systemroller i forskellige organisationer, på den samme brugerprofil, således at en bruger fx kan være godkender i én institution og kontrollant i en anden institution (ØK). En bruger med systemroller i flere forskellige organisationsenheder skal kunne behandle data på tværs af organisationsenhederne, så en bruger fx kan trække rapporter for et helt ministeransvarsområde (ØK). Når en bruger med systemroller i flere organisationer logger sig ind, skal alle brugerens dokumenter i alle organisationer vises på brugerens forside, så brugeren fx ikke skal vælge hver enkelt organisation for at se brugerens igangværende dokumenter i den enkelte organisation (PK). Det skal være tydeligt for en bruger i hvilken organisation data er placeret, så det fx er tydeligt for brugeren, hvor brugeren er i gang med at oprette eller godkende en afregning (ØK). En bruger med tilstrækkelige rettigheder skal kunne flytte transaktionsdata fra en organisation til en anden, fx flytte kreditkorttransaktioner fra en institution til en anden, såfremt disse skulle være blevet fejlafsendt (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.2 Brugere, roller og rettigheder En brugers rettigheder i STRUHS kan inddeles i to typer af rettigheder: Adgangsrettigheder vedrører retten til at kunne tilgå en specifik organisation, fx at kunne tilgå en specifik institution eller alle Side 13 af 79

14 institutioner under et ministeransvarsområde. Adgangsrettighederne ligger i forlængelse af STRUHS som værende et koncernsystem og kravene hertil er beskrevet i forrige afsnit. Funktionsrettigheder vedrører retten til at udføre en specifik funktion, fx kontrol eller oprettelse af dokumenter, i de organisationer, brugeren kan tilgå. Funktionsrettigheder understøtter funktionsadskillelsen i administrationen af rejse og udlæg. I STRUHS skal en systemrolle danne rammen om et givet sæt af funktionsrettigheder. De to typer rettigheder skal kunne kombineres, således at en bruger fx kan tildeles en specifik rolle i en specifik organisation og en anden rolle i en anden organisation. I STRUHS skal en brugers funktionsrettigheder til at behandle dokumenter kunne afgrænses til kun at gælde for visse brugeres dokumenter, således at en godkender fx kun kan godkende dokumenter tilhørende ansatte fra en specifik afdeling. I STRUHS skal en brugers funktionsrettigheder endvidere kunne afgrænses ved en prokuragrænse. En bruger skal kunne tildeles forskellige prokuragrænser i forskellige organisationer. Nedenfor er beskrevet de funktionsroller, der i denne kravspecifikation opereres med, efterfulgt af krav til systemroller. Generelle krav til brugeradministration findes i krav XX. Global Systemadministrator Den globale systemadministrator for STRUHS er placeret i Moderniseringsstyrelsen og har adgangsrettigheder til hele STRUHS. Den globale systemadministrator har til opgave at oprette, vedligeholde og administrere organisationer og organisationshierarkiet i STRUHS, at oprette lokale administratorer og evt. at oprette, vedligeholde og administrere roller, og globale konfigurationer i STRUHS. Den globale systemadministrator skal desuden have mulighed for at supportere STRUHS jf. bilag XX Drift, vedligeholdelse og support. Lokal Systemadministrator Den lokale systemadministrator har adgang til en eller flere organisationer i STRUHS. Den lokale systemadministrator har, for de pågældende organisationer, til opgave at vedligeholde og tildele rettigheder samt at administrere lokale konfigurationer og lettere driftsopgaver. Rejsende Den rejsende er en ansat, der benytter STRUHS til at få forhåndsgodkendt og bestilt kommende tjenesterejser og udlæg. Den rejsende benytter ligeledes Side 14 af 79

15 STRUHS til at registrere, kontere og dokumentere alle afholdte tjenesterejser og -udlæg, og til at få beregnet og indberettet godtgørelser. Kontrollant Kontrollantens rolle er at kontrollere, at rejsereglerne er overholdt og at der er vedlagt nødvendig dokumentation. Kontrollants ansvar er altså at sikre, at den rejsende har lavet en rejsepolitisk rigtig rejseafregning. Derved skal den endelige godkender kun tage stilling til afholdelsen af udgiften i forhold til det aftalte budget og om konteringen er korrekt. Godkender Godkenderen har det overordnede ansvar for budgetrammen for området/institutionen. Godkenderen skal godkende udgifter og rejser i forhold til det aftalte budget og sikre, at konteringen er korrekt. Det er institutionens ansvar at sikre, at den rejseafregning, som sendes til bogføring, er rigtig, idet der i Navision Stat ikke føres kontrol før bogføring. Sekretær Selvom det er best practice, at brugerne selv bestiller/afregner i STRUHS, skal sekretærer kunne håndtere rejseadministrationen på vegne af specifikke rejsende eller alle rejsende i en institution. Bruger med læseadgang En bruger med læseadgang til STRUHS skal fx trække rapporter og gennemgå konteringen og dokumentationen af dokumenter. Læseadgangen skal kunne give adgang til alle dokumenter i systemet, både ikke-færdigbehandlede og færdigbehandlede. Typisk tildeles læseadgangen til regnskabsmedarbejdere, controllere og revisorer. STRUHS skal indeholde systemroller, som understøtter ovenstående funktionsroller. Det er ikke et krav, at systemrollerne er identiske med ovenstående funktionsroller, men det gælder, at systemrollerne skal dække funktionsrollernes arbejdsopgaver, på en måder der er i overensstemmelse med best practice, revisions- og sikkerhedshensyn. Det noteres, at globale og lokaleadministratorer fremover benævnes systemadministratorer, dvs. at der ved kravsætning til, hvad en systemadministrator skal kunne, henvises til, at globale og lokale administratorer skal kunne udføre funktionen inden for de organisatoriske enheder, de har rettigheder til at tilgå. I tilfælde af, at der henvises til kun fx globale administratorer, vil dette fremgå af kravet. 2A Der skal nemt kunne oprettes globale systemadministratorer med adgang til det samlede STRUHS (PK). Side 15 af 79

16 2A A A A A A A A A A A A Globale systemadministratorer skal nemt kunne oprette lokale systemadministratorer (PK). Systemadministratorer skal nemt kunne oprette, ændre og inaktivere brugere i systemet (MK) STRUHS skal indeholde systemroller, som understøtter funktionsrollerne beskrevet ovenfor: Global systemadministrator, lokal systemadministrator, rejsende, kontrollant, godkender, sekretær, og bruger med læseadgang (PK). STRUHS skal have rettighedsstyring på tabel og feltniveau, så forskellige systemroller fx kan have forskellige rettigheder til at redigere i specifikke felter på et dokument. Fx så en godkender-systemrolle giver adgang til foruden at godkende at ændre konteringen på et dokument, mens en anden godkendersystemrolle ikke giver adgang til at ændre i et dokuments kontering (PK). Globale administratorer skal nemt kunne oprette, slette og redigere systemroller i STRUHS, således at de fx selv kan definere, hvilken sammensætning af rettigheder der skal udgøre en systemrolle (ØK). En systemadministrator skal nemt kunne tildele en bruger systemroller til en eller flere organisationsenheder ud fra en skabelon eller tilsvarende, så en institution fx kan anvende et sæt standardiserede brugerprofiler som hver især består af specifikt sæt kombinationer af systemroller, prokuragrænser, og adgangsrettigheder til organisatoriske enheder (ØK). Systemadministratorer skal nemt kunne tildele en bruger et sæt af systemroller, som dækker en, flere eller alle forskellige funktionsroller i STRUHS (PK). En bruger skal kunne tildeles en ren læse -rolle, som kan anvendes med henblik på support eller revision (MK). Lokale systemadministratorer skal kunne opsætte prokuragrænser for godkendere, således at de ikke kan godkende dokumenter, der overstiger et bestemt beløb (ØK) Prokuragrænser skal kunne opsættes pr. organisatorisk enhed, således at en godkender, der behandler dokumenter for flere institutioner, kan operere med forskellige prokuragrænser afhængig af hvilket institution dokument tilhører (ØK). STRUHS skal understøtte gruppering af brugerprofiler inden for en organisation, således at medarbejdere kan grupperes i persongrupper efter afdeling/kontor, til brug i fx statistikudtræk og opsætning af dokumentflow (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). Side 16 af 79

17 2A yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Stedfortrædere Når en bruger er på ferie, har orlov eller er sygemeldt, kan det være nødvendigt at en anden bruger får rettigheder til at løse den første brugers opgaver i STRUHS. En sekretær vil også skulle oprette afregninger på vegne af rejsende i en institution. STRUHS skal have en stedfortræderfunktionalitet, så en brugers rettigheder og opgaver let kan håndteres af en anden bruger i en kortere eller længere periode. 2A A A A A A A STRUHS skal understøtte en stedfortræderfunktion, således at der kan gives autorisation til en bruger om at udføre en anden brugers opgaver (MK). Mens stedfortræderfunktionen er slået til, skal stedfortræderen modtage alle dokumenter og adviseringer, der sendes til den person vedkommende er stedfortræder for, og allerede allokerede dokumenter skal være tilgængelige for stedfortræderen (ØK). Det skal være tydeligt for en stedfortræder, hvornår han behandler egne dokumenter, og hvornår han behandler dokumenter på vegne af en anden bruger (PK). Den lokale systemadministrator skal nemt kunne tildele og fjerne stedfortræder rettigheder for brugere (ØK). Den lokale administrator skal nemt kunne opsætte en bruger til at være stedfortræder for en gruppe af brugere, således at fx en sekretær kan blive stedfortræder for alle ansatte i en given afdeling/kontor og oprette dokumenter på deres vegne (PK). Brugeren skal nemt kunne tildele og fjerne stedfortræderrettigheder for sig selv, således at han fx selv kan udpege sin stedfortræder (ØK). Der skal nemt kunne angives en start- og en slutdato for gyldighedsperioden for hvornår en given bruger må optræde som stedfortræder (ØK). Side 17 af 79

18 2A A A STRUHS håndtering og tildeling af stedfortræderrettigheder skal ske under hensyntagen til brugernes rettigheder (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.3 Generelt om dokumenter i STRUHS STRUHS skal understøtte institutioners administration af rejser og udlæg. Dette indebærer som tidligere beskrevet arbejdsgange forbundet med dels forhåndsgodkendelse af tjenesterejser/udlæg og dels afregningen af afholdte tjenesterejser/udlæg. Administrationen indebærer desuden arbejdsgange forbundet med at overholde kontrol- og godkendelsesprocedurer af de forventede og afholdte udgifter. STRUHS skal understøtte arbejdsgangene ved at lade brugerne oprette forhåndsgodkendelses- og afregningsdokumenter, hvori tjenesterejse- og udlægsoplysninger kan registreres. Foruden skal STRUHS understøtte et dokumentflow, som dokumenterne sendes igennem til behandling hos kontrollanter og godkendere. Det gentages, at processerne for forhåndsgodkendelse og afregning af rejser og udlæg er separate, og at mange afregninger vil ske uden en foregående forhåndsgodkendelse/bestilling gennem STRUHS. Nogle institutioner vil slet ikke gøre brug af muligheden for at forhåndsgodkende gennem STRUHS, og i stedet udelukkende benytte systemet til afregningen af rejser og udlæg. I forlængelse heraf skal en institution helt kunne fravælge muligheden for at oprette forhåndsgodkendelsesdokumenter i STRUHS. I dette afsnit er beskrevet en række generelle krav til brugeres anvendelse af dokumenter i STRUHS. I det efterfølgende afsnit specificeres de konkrete krav til hhv. forhåndsgodkendelses- og afregningsdokumenter, og til de underliggende processer, herunder beregning af godtgørelser, registrering af Side 18 af 79

19 omkostninger, kontering, mv. Afslutningsvis er beskrevet kravene til opsætning og afsendelse af dokument gennem dokumentflowet. Dokumenter tilhørende en rejsende (uanset om en anden person har oprettet dokumentet på deres vegne, og uanset type) betegnes egne dokumenter. Dokumenter er en samlet betegnelse for forhåndsgodkendelses- og afregningsdokumenter i STRUHS. 2A A A A A A A A A En institution skal kunne fravælge at benytte STRUHS til forhåndsgodkendelse/bestilling, og brugerne skal i så fald ikke kunne se eller kunne vælge at oprette forhåndsgodkendelsesdokumenter i STRUHS (PK). Dokumenter i STRUHS skal præsenteres struktureret og intuitivt, således at brugerne let kan orientere sig og navigere i systemet (PK). Kun de dokumenter, som ens brugerprofil giver adgang til, skal være synlige i STRUHS (ØK). Brugeren skal nemt kunne danne sig et overblik over alle egne dokumenter i STRUHS, både ikke-færdiggjorte dokumenter, dokumenter der befinder sig i dokumentflow, og tidligere, færdigbehandlede dokumenter (ØK). Brugeren skal nemt kunne identificere alle igangværende dokumenter, der kræver behandling af brugeren, og det skal være tydeligt for brugeren hvad handlingen skal være, fx ved visning af oversigt med dokumenter opdelt efter status, og hvilken organisationsenhed dokumentet tilhører (PK). Brugeren skal fra oversigten nemt kunne danne sig et overblik over dokumenters mest relevante indhold, således at dokumentet ikke skal åbnes uhensigtsmæssigt ofte. Fx ved at vigtigste økonomiske tal, beskrivelsesfelt, sidst skrevet kommentar i dokumentet, foruden personoplysninger, status og organisationstilknytning ses fra oversigten (ØK). Brugeren skal foretage simple funktioner i et dokument fra oversigten, fx at slette dokumentet eller få tilføjet en kommentar, således at dokumentet ikke skal åbnes uhensigtsmæssigt ofte, (ØK). Ved åbning af et eksisterende dokument skal brugeren nemt kunne danne sig et overblik over dokumentets prisforhold, herunder de samlede udgifter forbundet med rejsen, priser for godtgørelser, samlede tjenesteudgifter, og beløb til udbetaling, dokumentets indhold af omkostningsposter, hvilken bruger og hvilken institution dokumentet tilhører mv. (ØK). Ved oprettelse af et dokument skal brugeren tydeligt kunne se, hvilke funktioner der er til rådighed, og hvilke muligheder og krav til udfyldelse, der foreligger (PK). Side 19 af 79

20 2A A A Brugeren skal kun have mulighed for at vælge relevante brugerprofiler og værdier ved behandling og distribution af dokumenter i systemet, således at det fx ikke er muligt at vælge en spærret dimensionsværdi ved kontering eller at sende et dokument til godkendelse hos en bruger der enten er spærret, eller ikke har godkenderrollen, eller ikke har tilstrækkelig prokura til at godkende dokumentet (PK) Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Opdeling af dokumenter i rejsetype I håndteringen af dokumenter kan det være hensigtsmæssigt, at brugerne kan opdele rejser efter rejsetype (fx Udland, EU-rådsrejser, mfl.). Det stilles ikke krav til, at hvordan STRUHS opererer med opdelingen af dokumenter i rejsetyper, men blot at STRUHS understøtter de behov, der ligger i forlængelse af, at institutionerne skelner mellem rejsetyper, bl.a. ved opsætningen af kontering og afsendelse af dokument i dokumentflow. Opdelingen i rejsetyper kan fx ske ved at definere rejsetyperne som en dimension i institutionens dimensionskontoplan. Følge rejsetyper er standard: Indland Udland EU-rådsrejser EU-kommissionsrejser Behovet for opdeling af rejsetyper skyldes bl.a. konterings- og momsforhold, idet der ofte konteres på forskellige finanskonti ud fra om en given udgift er afholdt i Danmark eller i udlandet, eller i forbindelse med bestemte refusionsberettigede EU-rejser. I STRUHS er der således behov for, at der kan opsættes alternativ kontering, dvs. hvor konteringen af en given omkostning Side 20 af 79

21 automatisk varierer alt efter, om udgiften fx er foretaget i forbindelse med en indlandsrejse eller en EU-rådsrejse. Der stilles krav til dette i afsnit XX. Der er desuden et behov for, at rejsetypen kan påvirke, hvilke personer et dokument sendes til kontrol/godkendelse hos. Fx skal en udlandsrejse skulle kunne sendes til godkendelse hos en anden person, end en hvis der er tale om en indlandsrejse. STRUHS skal kunne imødegå dette behov om alternative dokumentflows, hvilken kravspecificeres i krav XX. Ved EU-rådsrejser er der en række ekstra krav til udfyldning og dokumentation af rejseoplysninger, jf. i krav XX. Der er derfor et behov for, at en bruger kan markere en rejse som værende en EU-rådsrejse. 2A A A A Tjenesteyder skal redegøre for, hvordan STRUHS kan understøtte opdelingen af dokumenter i rejsetyper (PK). Systemadministratorer skal kunne konfigurere rejsetyper, således at både antallet og navnene på rejsetyperne kan variere fra institution til institution (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.4 Forhåndsgodkendelsesdokumenter og rejsebestilling I dette afsnit defineres de overordnede krav til forhåndsgodkendelser og den efterfølgende rejsebestilling. Ved afholdelse af tjenesterejser er forhåndsgodkendelse af rejseafholdelsen og dertilhørende udgifter en del af best practice for rejseadministration i Staten. STRUHS skal understøtte en standardiseret og veldokumenteret arbejdsgang for forhåndsgodkendelse af rejser og udgifter, og understøtte afsendelse af en rejsebestilling på baggrund af rejsespecifikationen for en forhåndsgodkendt rejse. Side 21 af 79

22 Forhåndsgodkendelse og bestilling af en rejse sker på baggrund af den rejsendes oprettelse af et dokument i STRUHS med specificering af bl.a. formålet med en rejse, dato og tidspunkt for rejsen, destination, overnatningsforhold, specielle ønsker til rejsen og opholdet, og forventede udgifter. Rejsespecifikationen kan være mere eller mindre detaljerig, afhængig af om STRUHS fx understøtter direkte integration til rejsebureauets bookingsystem, så specifikke rejseafgange og hotelværelser kan vælges af den rejsende, således at prisen til godkendelse også bliver mere nøjagtig. Selve købet af rejsen sker uden om STRUHS. I forlængelse heraf er det nødvendigt, at STRUHS sender en rejsebestilling videre på baggrund af rejsespecifikationen for en forhåndsgodkendt rejse. Rejsebestillingen kan sendes pr. mail til fx institutionen rejseteam, og/eller sendes som XML-fil direkte ind i rejsebureauets bookingsystem til videre behandling. Det bemærkes, at kravene i dette afsnit og bilag XX om integration til rejsebureauet er baseret på Kundens forslag til flowet mellem STRUHS og rejsebureauet. Tjenesteyder kan fremlægge forslag til alternative eller udvidede integrationssnitflader og -niveauer. I vurderingen lægges der vægt på brugervenlighed og simple arbejdsgange. Se mere om registrering af rejsedage og beregning af godtgørelser i afsnit XX. 2A A A A A A A STRUHS skal understøtte en effektiv proces for forhåndsgodkendelse af forventede tjenesteudgifter og tjenesterejser (MK). STRUHS skal understøtte afsendelse af rejsebestilling med henblik på køb af rejse uden for STRUHS (MK). Brugeren skal kunne angive forventede/estimerede beløb for fremtidige udgifter, herunder eventuelle rejsedage og kørsler, således at STRUHS på baggrund heraf kan beregne de samlede udgifter forbundet med rejsen (ØK). Brugeren skal kunne angive specifikationen på en rejse, fx formålet med rejsen, dato og tidspunkt for rejsen, afrejse- og destinationsland og by, overnatningsforhold, mv., således at dokumentet danner grundlag for bestilling af en rejse (ØK). Brugeren skal kunne angive stedet for det ønskede afrejse- og ankomsttidspunkt, således at det fx kan angives, at afrejsetidspunktet er fra hjemmet eller fra lufthavnen (ØK). Systemadministratorer skal kunne opsætte forhåndsdefinerede tilvalgsparametre, som brugeren kan vælge ved bestilling af rejser, fx ønske om billettype, udlejningsbil, etc. (ØK). Brugeren skal kunne angive bonusrejseoplysninger (ledige point til bonusprogram) som sendes med bestillingen, således at der på vegne af den Side 22 af 79

23 rejsende kan bestilles bonusbilletter. Yderligere bonusprogramoplysninger (herunder navn på bonusprogram og adgangskode) bør hentes fra brugerprofilen (ØK). 2A A A A A A A A A A STRUHS skal understøtte bestilling af rundrejser, således at brugeren nemt kan angive destination og tidspunkt for flere stop i en rejse (ØK). STRUHS skal kunne understøtte bestilling af enkeltvejsrejser (dvs. uden returdato), fx ved at brugeren markerer rejsen som enkeltvejsrejse og returdatofeltet dermed deaktiveres (ØK). Ved godkendelse af et forhåndsgodkendelsesdokument, skal STRUHS kunne advisere dokumentopretteren om godkendelsen, fx ved at sende en mail, således at de bliver informeret om/får bekræftet, at rejsen er godkendt (ØK). Ved godkendelse af et forhåndsgodkendelsesdokument, skal STRUHS kunne sende en med alle indtastede og relevante rejseoplysninger til en eller flere på forhånd defineret mailadresser, således at mailen fungerer som rejsebestilling. Mailen vil typisk blive sendt til et rejseteam eller en sekretær, der håndterer den videre administration og køb af rejsen (MK). Brugeren skal kunne se og redigere de mailadresser, bestillingen bliver sendt til (ØK). Ved godkendelse af et forhåndsgodkendelsesdokument, skal STRUHS kunne sende alle indtastede og relevante rejseoplysninger til Statens rejsebureaus bookingssystem i en XML-fil, således at der kan oprettes et udkast til en rejsebooking på baggrund af rejseoplysningerne. Se bilag XX for formatbeskrivelse og yderlige information om dataoverførslen (MK). Systemadministratoren skal kunne opsætte, hvad der som standard skal ske efter godkendelse af et forhåndsgodkendelsesdokument, fx om dokumentet skal sendes som bestilling pr. mail til en given mailadresse og/eller som XMLfil til indlæsning i rejsebureauets bookingssystem (PK). Brugeren skal kunne vælge at afvige fra standardopsætningen og selv vælge, hvad der skal ske ved bestilling af en rejse. Fx skal brugeren kunne ændre hvem mailen sendes til, eller vælge slet ikke at sende bestillingen af sted, såfremt fx rejsen ad omveje allerede er blevet bestilt (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: Side 23 af 79

24 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.5 Afregningsdokumenter STRUHS skal understøtte afregningen af tjenesterejser, tjenesteudgifter og udlæg, og gøre processen så brugervenlig som muligt. Afregningen af tjenesterejser og udlæg indebærer at lade brugeren registrere alle afholdte udgifter på en rejse uanset betalingsform og registrere grundlaget for beregning af rejse- og kørselsgodtgørelser. I de efterfølgende afsnit opstilles de mere detaljerede krav til brugernes angivelse af rejsedage, kørsler, udgifter m.m. 2A A A A A A A A STRUHS skal understøtte en effektiv proces for afregning af rejser og tjenesteudgifter, herunder beregning af diæter og godtgørelser jf. Rejsecirkulæret (MK). STRUHS skal kunne oprette en rejseafregning for en bruger på baggrund af rejseoplysninger modtaget fra 3. part, således at brugeren ikke skal indtaste rejsedata ind manuelt for rejser, der fx er købt hos Statens rejsebureau (MK). Brugeren skal nemt kunne angive afholdte udgifter og rejseoplysninger, herunder eventuelle rejsedage og kørsler, således at STRUHS på baggrund heraf kan beregne de samlede udgifter og godtgørelser forbundet med rejsen (ØK). STRUHS skal understøtte afregning af rundrejser, således at brugeren kan angive destination og tidspunkt for flere stop i en rejse (ØK). STRUHS skal understøtte afregning af enkeltvejsrejer (ØK). STRUHS skal gøre det nemt for brugeren at afregne enkeltudgifter, der ikke er forbundet med rejser, fx ved at tillade en udgiftsafregning eller quick- afregning, hvor kun et minimum af felter skal udfyldes (PK). Ved godkendelse af et afregningsdokument skal der på baggrund af dokumentets posteringer sendes posteringsbilag til Navision Stat. Læs krav XX for integrationskrav til Navision Stat (MK) Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). Side 24 af 79

25 2A yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.6 Registrering og beregning af godtgørelser STRUHS skal beregne rejse- og kørselsgodtgørelser på baggrund af brugernes angivelse af rejsespecifikationerne. I dette afsnit er defineret de generelle krav til håndteringen, beregningen og indberetningen af rejse og kørselsgodtgørelser i STRUHS. 2A Rejsedage og rejsegodtgørelser I forlængelse af kravet om, at STRUHS skal håndtere tjenesterejser, stilles der krav til beregning af diæter og godtgørelser ved både forhåndsgodkendelsesog afregningsdokumenter: STRUHS skal understøtte beregning af time- /dagpenge, procentgodtgørelse og udokumenteret nattillæg på baggrund brugerens angivelse af antallet af bl.a. rejsedage, overnatningsforhold og antallet af gratis måltider på tjenesterejsen. 2A A STRUHS skal kunne håndtere udregning og afregning af rejsegodtgørelser for diæter og lignende (MK). Beregning af godtgørelse skal ske under hensyn til brugerens registrering af godtgørelsesform, måltidsfradrag på rejsen, overnatningsforhold (udokumenteret nattillæg), destination og antallet af rejsedage og -timer, samt de til enhver tid gældende godtgørelsessatser (MK). I rejsecirkulæret er defineret følgende godtgørelsesformer: Refusion mod dokumentation Refusion mod dokumentation samt ydelse af procentgodtgørelse Udbetaling af time-/dagpenge 2A Systemadministratorer skal kunne konfigurere godtgørelsesformer, således at både antallet og navnene på godtgørelsesformerne kan variere fra organisation til organisation (ØK). Side 25 af 79

26 2A A A A A A A Systemadministratorer skal kunne opsætte en standard godtgørelsesform for hver brugerprofil, således at brugeren aktivt skal vælge en anden godtgørelsesform (ØK). Systemadministratorer skal kunne ændre standardsatsen for godtgørelsesformer, fx satsen for time-/dagpenge for et givent land (PK). STRUHS skal understøtte beregning af danske og grønlandske rejseregler (PK). Brugeren skal nemt og med et minimum af museklik kunne udfylde specifikationen for rejsen, herunder dato og tidspunkt for afrejse og ankomst, afrejseland og by, destinationsland- og by (PK). Brugeren skal nemt og hurtigt kunne registrere antallet af gratis måltider og overnatningsforhold pr. rejsedag, fx ved at registrere det fra en samlet oversigt over rejsedage (ØK). STRUHS skal kunne understøtte udfyldelsen af rejsespecifikationen, fx med udgangspunkt i standardværdier fra brugerens brugerprofil, sidst benyttede værdier (favoritlister), effektive søgemekanismer, osv. (PK). STRUHS skal kunne håndtere tidsforskelle ved rejser over flere tidszoner, således at STRUHS kan beregne ud fra brugeren angivelse af afrejseankomsttidspunkter i lokale tidszoner (ØK). 2A Brugeren skal kunne få udbetalt nedsat godtgørelsesbeløb efter d. 28. tjenesterejsedag jf. de særlige regler for udstationering (MK). 2A A A A A Brugeren skal kunne foretage periodevis afregning af godtgørelser ved udstationeringer, fx ved at gøre det muligt at oprette e rejse, der fra dag 1 opererer med nedsat godtgørelsesbeløb (i stedet for efter d. 28. dag) (ØK). Brugeren skal nemt kunne registrere rejsedage som privat del tjenesterejsen. Private rejsedage som del af en tjeneste forekommer, når medarbejderen tager af sted tidligere end tjenesterejsen starter, hjemrejser senere end tjenesterejsen formelt slutter, eller afholder private rejsedage midt i tjenesterejsen (PK). STRUHS skal ikke beregne godtgørelser for dage, der er registreret som private dele af tjenesterejsen (ØK). Brugeren skal notificeres såfremt registreringen af måltidsfradrag ikke stemmer overens med rejsens start-/slutklokkeslæt, fx hvis der på en rejsedag er registreret aftensmadsfradrag, selvom den slutter om eftermiddagen (ØK). Systemadministratorer skal kunne angive en standardopsætning for gratis måltider pr. dag, så rejsedage som standard kun indeholder fx et gratis Side 26 af 79

27 morgenmadsmåltid, og der således som standard registreres måltidsfradrag for frokost og aftensmad, medmindre brugeren ændrer dette (ØK). 2A A Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A A A Kørsler og kørselsgodtgørelser STRUHS skal kunne håndtere udregning og afregning af transportgodtgørelse (MK). Beregning af kørselsgodtgørelse skal ske under hensyntagen til transportgodtgørelsesform, destination, antal kilometer, akkumulerede antal kilometer, samt de til enhver tid gældende kørselsgodtgørelsessatser (MK). I rejsecirkulæret er defineret følgende transportgodtgørelsesformer: Privat bil-/motorcykelkørsel, lav sats Privat bil-/motorcykelkørsel, høj sats Knallert/cykel 2A A A A Ved et samlet akkumuleret antal kilometer over pt år. år skal kørselsgodtgørelsen beregnes efter den lave kørselsgodtgørelsessats (MK). Systemadministratorer skal kunne opsætte en standard transportgodtgørelsesform for hver brugerprofil, således at brugeren aktivt skal vælge en anden godtgørelsesform (ØK). Brugeren skal hurtigt og nemt kunne udfylde grundlaget for godtgørelsesberegningen, fx med udgangspunkt i standardværdier fra brugerens brugerprofil, sidst benyttede værdier, standardruter, osv. (PK). STRUHS skal understøtte befordringsafregning ved brug af kortfunktion (fx Google Maps, Bing Maps, Krak el. lign.), således at registrering, beregning og dokumentation af befordring lettes (PK). Side 27 af 79

28 2A A A A A STRUHS skal understøtte overholdelse af reglen om, at afstanden fra hjemmet til arbejdsstedet som hovedregel skal fratrækkes, såfremt tjenesterejsen starter fra hjemmet (PK). STRUHS skal kunne oprette kørsler på baggrund af filer overført fra en kørebog og tildele dem den rette bruger. Således behøver brugerne ikke at indtaste befordringsoplysninger, der automatisk er registreret i et andet system Se også krav bilag XX vedr. integration til kørebøger (PK). Brugeren skal nemt kunne importere kørsler til en afregning (ØK). STRUHS skal understøtte beregning af kørselsgodtgørelsen under hensyntagen til 60-dages reglen, der er defineret i SKAT s regler for skattefri rejsegodtgørelse (ØK). Hver kørsel skal registreres med mindst dato, transportgodtgørelsesform, rute, bilregistreringsnummer og antal kilometer (ØK). 2A STRUHS skal kunne understøtte registrering af kilometerantal med op til 2 decimaler (PK). 2A A Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 3. Processerne der dækkes af krav XX og XX. 4. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Generelt om godtgørelser og indberetning til SKAT I indeværende afsnit opstilles de krav, som ligger til grundlag for korrekt beregning af godtgørelser med henblik på korrekt indberetning til SKAT. Yderligere krav til integrationen til SKAT findes i bilag XX. 2A STRUHS skal registrere godtgørelser med henblik på indberetning af skattefri og skattepligtige godtgørelser til SKAT (PK). Side 28 af 79

29 2A A A A A Godtgørelser beregnet i et afregningsdokument skal som standard registreres som værende skattefri, således at godtgørelsesbeløbet kan indberettes som skattefri godtgørelser til SKAT (ØK). Godtgørelsesgrundlaget i et afregningsdokument (fx enkelte rejsedage eller kørsler) skal af brugeren kunne angives som skattepligtige, således at det registreres, at godtgørelsesbeløbet skal indberettes som skattepligtig indkomst hos SKAT (PK). Godtgørelser beregnet i forhåndsgodkendelsesdokumenter skal ikke indberettes til SKAT (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 5. Processerne der dækkes af krav XX og XX. 6. Eventuelle yderligere funktioner der understøtterxxx i STRUHS, jf. krav. XY. Funktionalitet vedrørende XX er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.7 Registrering af omkostninger Statens ansatte har mulighed for at benytte flere betalingsmåder, herunder kreditkort, taxakort og kontantudlæg, og i STRUHS skal brugerne kunne registrere omkostningerne med henblik på efterfølgende bogføring af de afholdte tjenesteudgifter og evt. udbetaling. Alle omkostningsposter skal kunne knyttes til en omkostningstype, der refererer til et kontonummer i den pågældendes institutions kontoplan. Yderligere krav til kontering og dimensionering af omkostningsposter findes i det efterfølgende afsnit XX. 2A A A Brugeren skal i STRUHS nemt kunne registrere og afregne afholdte tjenesteudgifter (MK). Brugeren skal kunne tildele en omkostningspost en omkostningstype, der refererer til et kontonummer i den pågældendes institutions kontoplan (PK). Brugeren skal i STRUHS nemt og med et minimum af museklik kunne afregne kontantudlæg afholdt i tjenesteøjemed (PK). Side 29 af 79

30 2A A A A A A A A A A A A Brugeren skal i STRUHS nemt og med et minimum af museklik kunne afregne kreditkort-/rejsekontotransaktioner betalt med institutionens kreditkort eller rejsekonto. Læs om integration til banker i bilag XX (PK). Brugeren skal i STRUHS nemt og med et minimum af museklik kunne afregne taxatransaktioner betalt med institutionens taxakort. Læs om integration til taxaselskab i bilag XX (PK). STRUHS skal give brugeren et overblik over de kredit-/rejsekonto- /taxakorttransaktioner, der ligger klar til afregning, og vise detaljer om hvad beløbene dækker over, dato for køb, mv. (ØK). STRUHS skal understøtte en nem og brugervenlig arbejdsgang for tilknytning af transaktioner til et afregningsdokument, og fx tillade brugeren at massetilføje transaktioner (ØK). Brugeren skal kunne opdele kreditkort-/rejsekonto-/taxatransaktioner i flere omkostningsposter, således at transaktioner der fx dækker over flere forskellige køb, kan få tilknyttet forskellige omkostningstyper og dermed konteres på forskellige finanskonti (ØK). Ved opsplitning af transaktioner skal alle transaktionsoplysninger nedarves til de nye omkostningsposter (ØK). Brugeren skal kunne registrere hele eller dele af en transaktion som værende egenbetaling, dvs. at beløbet skal betales tilbage/modregnes af brugeren. Dette er aktuelt når brugeren fx har benyttet institutionens kreditkort til betaling for ikke-tjenstlige udgifter (PK). STRUHS skal automatisk kunne tildele kreditkort-/rejsekonto- /taxatransaktioner den rette omkostningstype, således at brugeren skånes for at gøre det manuelt. Transaktioner fx tildeles den rette omkostningstype på baggrund af transaktionens produktid (se mere i bilag X om integrationen til banker). Hver omkostningspost skal registreres med mindst dato, beløb og forklaringstekst. (ØK). Systemadministratoren skal kunne vælge, hvilke evt. andre felter der vises og kræves udfyldt (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter håndteringen af omkostninger i STRUHS(PK). Side 30 af 79

31 Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter håndteringen af omkostninger i STRUHS, jf. krav. XY. Funktionalitet vedrørende håndteringen af omkostninger i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.8 Kontering og dimensionering Alle omkostningsposter i STRUHS skal have defineret en finanskonto for hhv. debet og kredit, og have dimensionsværdier eller et Alias, der udleder dimensionsværdier tilknyttet, med henblik på bogføring i Navision Stat. Dimensioner eller Alias skal udfyldes pr. dokument af brugeren evt. ved hjælp af forhåndsudfyldelse, og skal medføre, at de valgte dimensionsværdier eller Aliasværdier nedarves til alle omkostningsposter oprettet i dokumentet. I konteringen (debet/kredit) af de enkelte omkostningsposter skal STRUHS tage højde for, at brugeren ikke har kendskab til institutionens kontoplan. Til bestemmelse af hvilken konto omkostningen skal debiteres, skal omkostningstyper el.lign. benyttes. Omkostningstyper er oprettet af en systemadministrator er knyttet til en given konto i institutionens finanskontoplan. I konteringen af en omkostningspost skal brugeren således blot tildele posten en omkostningstype for at omkostningen debiteres denne konto og dermed konteres korrekt. Omkostningstyper skal også kunne have dimensionsværdier tilknyttet, som kan overstyre, hvad der evt. er blevet nedarvet af dokumentdimensioneringen. Til bestemmelse af hvad omkostningen skal krediteres, skal STRUHS se på omkostningens betalingsmiddel, om det fx er et personligt udlæg, som moderegnes/udbetales, eller en kreditkorttransaktion som afregnes på en mellemregningskonto. 2A A A STRUHS skal kunne understøtte Navision Stats finans- og dimensionskontoplan (MK). Konteringen skal udføres med det enkelte regnskabs dimensionskontoplan overført fra Navision Stat (MK) Tildeling af finanskonti Alle omkostningspost i STRUHS skal konteres, dvs. have tilknyttet en debetog kredit-finanskonto med henblik på bogføring i Navision. Side 31 af 79

32 2A A A A A A STRUHS skal understøtte kontering pr. omkostningspost (MK). Lokaladministratoren skal kunne oprette omkostningstyper, der definerer hvilken finanskonto en given omkostning debiteres (PK). Lokaladministratoren skal kunne definere hvordan en given omkostning krediteres ud fra dens betalingsmiddel (udlæg, taxakort, kreditkort, mv.)(øk). STRUHS skal understøtte alternativ debet-kontering, således at kontering af en omkostningspost kan opsættes til at afvige fra standardopsætningen, fx på baggrund af den valgte rejsetype (se afsnit XX om rejsetyper) (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter tildelingen af finanskonti i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. 2A A A A A A A Tildeling af dimensionsværdier STRUHS skal understøtte dimensionering pr. dokument, således at de valgte dimensionsværdier nedarves til alle omkostningsposter i dokumentet (MK). En bruger skal let, hurtigt og med et minimum af operationer kunne udfylde dimensionsværdierne på et dokument (PK) Brugeren skal kunne benytte en søgefunktion (på både Id og navn) til at finde ønskede dimensionsværdier i en given dimension (PK). STRUHS skal understøtte automatiseret beslutningsstøtte for valg af dimensionsværdier, fx ved hjælp af forslagskontering, sidst benyttede værdier, bruger-/enhedsspecifikke begrænsninger mv. (PK) STRUHS skal understøtte institutionernes regelsæt om gyldige/ugyldige kombinationer af dimensionsværdier, således at brugeren forhindres i at vælge ugyldige kombinationer. Se desuden krav til integration til Navision Stat, krav XXX (PK). Lokaladministratoren skal kunne definere, hvilke dimensioner det er obligatorisk at udfylde, og det skal tydeligt fremgå for brugeren, om en dimension er obligatorisk (ØK). Side 32 af 79

33 2A A A A A A A A STRUHS skal forhindre et dokument i at blive godkendt, såfremt kravene til minimumsudfyldelse af dimensioner ikke opfyldt (PK). Lokaladministratoren skal kunne definere navnet og rækkefølgen på dimensionerne vist i et dokument (ØK). Brugeren skal nemt kunne splitte et helt dokuments dimensionsstreng i både procent og beløb, således at alle omkostningsposter i dokumentet opdeles. (ØK). Brugeren skal nemt kunne splitte en enkelt omkostningsposts dimensionsstreng i både procent og beløb (ØK). Ved opsplitning af omkostningsposter skal alle omkostningsoplysninger nedarves til de oprettede ekstra posteringslinjer (ØK). Brugeren skal nemt kunne ændre de angivne dimensionsværdier for hver enkelt omkostningspost, således at en enkelt omkostningsposts dimensionsværdier kan afvige fra de dimensionsværdier, der evt. er nedarvet (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. 2A Særligt om Alias STRUHS skal understøtte Navision Stat s Alias. En Aliasværdi består af en kombination af dimensionsværdier. Alias benyttes som dimensioneringshjælp til brugerne, således at blot skal kende én værdi, der så udleder en hel dimensionsstreng. 2A A STRUHS skal understøtte brugen af Alias til dimensionering af dokumenter (PK). STRUHS skal understøtte udfoldelse af et Alias underdimensioner, således at brugeren ved valg af en given alias-værdi, kan se hvilke dimensionsværdier, Alias et består af (PK). Side 33 af 79

34 2A A A A Brugeren skal kunne ændre en dimensionsværdi, som er afledt af et Alias(PK). Såfremt et Alias er blevet udfoldet, er det alene dimensionsværdierne, der skal overføres til Navision Stat, og ikke Alias et (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. 2A Særligt om momshåndtering Afløftning af moms sker i Navision på baggrund af momskoderne angivet for hver finanskonto, eller på baggrund af den momskode, en transaktion evt. overføres med. Momskoden angivet på en transaktion overstyrer, hvad finanskoden evt. er sat op med. Ved overførsel af en institutions kontoplan modtager STRUHS jf. bilag XX om Navision-integration oplysninger om momskoden for hver enkelt konto. STRUHS skal understøtte, at brugeren kan se og ændre momskoderne pr. omkostningspost, således at omkostningen kan bogføres med en anden momskode end den, den som standard ville blive bogført med. 2A A A A STRUHS skal understøtte tilknytning af momskoder pr. omkostningspost, fx ved tilknytning af momskoden til en omkostningstype eller ud fra finanskontoen (PK). STRUHS skal understøtte opsætning af alternative momskoder, således at momskoden opsat på en omkostningstype kan afvige fra standardopsætningen fx på baggrund af rejsetype (se afsnit XX for definition af rejsetyper) (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS. Der lægges vægt på, at STRUHS håndterer både opsætningen og brugen af momskoder så brugervenligt som muligt. (PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: Side 34 af 79

35 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. 2A.3.9 Dokumentflow Et centralt formål med digitaliseringen af administration af rejser og udgifter er overholdelsen af kontrol- og godkendelsesprocedurer og at opnå et effektivt og dokumenterbart workflow, der sikrer en overskuelig arbejdsproces for alle parter involveret i oprettelsen og viderebehandling af dokumenter i STRUHS. 2A Opsætning af dokumentflow I opsætning af et dokumentflow skal der navnlig tages stilling til hvor mange personer der skal gennemgå et dokument før det er færdigbehandlet i STRUHS. Dokumenter til forhåndsgodkendelse sendes typisk igennem to led et oprettelsesled og et godkendelsesled, alt imens dokumenter til afregning af rejser/tjenesteudgifter typisk sendes igennem tre led et oprettelsesled, et kontrolled og et godkendelsesled. I dokumentflowet skal det desuden defineres, hvem der har ansvaret for fx at kontrollere og godkende et dokument oprettet af en given bruger, således at det for hver bruger er defineret, hvem der viderebehandler deres dokument, når de sender det i dokumentflow. 2A A A A A STRUHS skal fungere som et workflowssystem, der understøtter et dokumentflow baseret på interne kontrol-/ og godkendelsesprocedurer (MK). Systemadministratorer skal nemt kunne opsætte dokumentflow ud fra dokumenttype, således at dokumentflowet kan afvige alt efter om der er tale om et forhåndsgodkendelsesdokument eller et afregningsdokument (ØK). Systemadministratorer skal nemt kunne opsætte antallet af led i et dokumentflow, dvs. hvor mange led et dokument skal sendes igennem, før det er færdigbehandlet. Fx skal en systemadministrator kunne definere, om dokumentopretter kun skal sende et dokument til godkendelse før det er færdigbehandlet, eller om det først skal sendes til kontrol (ØK). Systemadministratorer skal nemt kunne opsætte et dokumentflow til en gruppe af brugere, fx ud fra afdeling/kontor, således at fx en chef kan opsættes til at godkende alle dokumenter, som ansatte i afdelingen/kontoret opretter (ØK). Systemadministratorer skal nemt kunne opsætte, at flere personer kan have ansvaret for et led i dokumentflowet, således at dokumentet blot skal behandles af én af de angivne. Dette er fx hensigtsmæssigt ved administrative fællesskaber, hvor en større gruppe af personer vil skulle gives rettigheder til fx at kontrollere dokumenter for alle brugere i en eller flere institutioner (PK). Side 35 af 79

36 2A A A A A A A Systemadministratoren skal kunne opstille krav pr. organisationsenhed om, at én bruger ikke kan sende et dokument igennem hele dokumentflowet, uanset om brugerens systemrolle tillader dette (ØK). Systemadministratoren skal kunne opsætte af alternativt dokumentflow for dokumenter, der overstiger en brugers prokuragrænser, således at et dokument fx ikke sendes til en godkender, der ikke har den nødvendige prokura (ØK). Systemadministratoren skal kunne opsætte alternativt dokumentflow for dokumenter med en given rejsetype (jf. krav XX) eller en given dimensionsværdi, således at et dokument med en specifik værdi bliver sendt til en anden kontrollant/godkender, end det er defineret i standardopsætningen (ØK). Systemadministratoren skal kunne opsætte alternativt dokumentflow for afregningsdokumenter, det er knyttet til et forhåndsgodkendelsesdokument, således at en godkender ikke skal godkende samme udgift/rejse to gange. Fx skal det være muligt at genanvende godkendelsen af en forhåndsgodkendt rejse, hvor afregningen af samme rejse ikke eller kun delvist afviger fra det forhåndsgodkendte, fx ud fra parametre som kontering, max pris, mv. (PK). Systemadministratoren skal kunne give brugerne tilladelse til at sende dokumenter til andre personer, end de prædefinerede (ØK). Processerne der dækkes af ovenstående krav 2A A er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter opsætning af dokumentflow i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter opsætning af dokumentflow i STRUHS, jf. krav. 2A Funktionalitet vedrørende opsætning af dokumentflow i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Dokumenter i dokumentflow STRUHS skal understøtte en effektiv behandling af dokumenter og sikre en smidig afsendelse af dokumenter gennem det opstillede dokumentflow for brugerne af systemet. STRUHS skal understøtte tilbageløb og afvigelser i dokumentflowet, således at der sikres en fleksibel proces for behandling af dokumenter. Side 36 af 79

37 2A A A A A A A STRUHS skal sikre, at en brugers dokumenter som standard sendes igennem det dokumentflow, som er opsat af systemadministratoren (MK). Brugeren skal nemt og med et minimum af museklik kunne afvige fra det forudbestemte dokumentflow, således at der fx kan vælges en anden kontrollant/godkender end den forudbestemte (ØK). Brugeren skal nemt kunne afvige fra det forudbestemte antal led i dokumentflowet, således at et dokument fx kan sendes til ekstra et kontrolled (PK). Ved afsendelse af et dokument gennem dokumentflowet, skal et dokument kunne videresendes uden at åbne dokumentet, fx skal en kontrollant kunne sende dokument videre direkte fra oversigten over dokumenter til behandling (ØK). STRUHS skal understøtte afvisning af et dokument og tilbagelevering til første eller forrige led, således at fx en godkender kan sende et dokument tilbage til kontrolledet (ØK). Ved afvisning af et dokument skal STRUHS understøtte muligheden for at informere om årsagen til afvisningen, fx ved at indtaste en kommentar til dokumentet (ØK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter opsætning af dokumentflow i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 3. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter opsætning af dokumentflow i STRUHS, jf. krav. 2A Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.10 Andre krav til STRUHS I dette afsnit er angivet en række krav til forskellige områder i STRUHS, der understøtter de underliggende processer, der er af relevans for at kunne skabe en samlet effektiv understøttelse af administrationen af rejser og udlæg i Staten. 2A Sammenkobling af dokumenter Når en rejse forhåndsgodkendes og afregnes gennem STRUHS, er det hensigtsmæssigt at kunne sammenkoble forhånds- og afregningsdokumentet Side 37 af 79

38 med henblik på sammenligning af de budgetterede og afholdte udgifter, forsimpling af dokumentflowet eller blot for nem reference. I andre tilfælde vil det være hensigtsmæssigst at sammenkoble to eller flere afregningsdokumenter i forbindelse med afregning af fx forsinkede kreditkorttransaktioner eller kreditnotaer, som hører til transaktioner, der afregnet i et tidligere afregningsdokument. 2A A A A A A STRUHS skal understøtte sammenkobling af dokumenter, således at brugeren kan registrere, at et dokument har forbindelse til et eller flere andre dokumenter i systemet (PK). Brugeren skal i alle led i dokumentflowet og i listeformer kunne se, at et dokument er sammenkoblet til et andet (ØK). Brugeren skal kunne åbne et dokuments sammenkoblede dokument direkte, fx via et link i dokumentet, således at brugeren nemt kan tilgå det sammenkoblede dokument (ØK). Ved sammenkobling af et forhåndsgodkendelses- og et afregningsdokument, skal STRUHS vise en sammenligning mellem de forventede udgifter, rejsedage, mv. angivet i forhåndsgodkendelsesdokument og de afholdte udgifter, rejsedage mv. registreret i rejseafregningen. Sammenligningen skal bruges af fx godkendere, så de kan danne sig et overblik over afvigelser (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Kopiering af dokumenter og skabelonopsætning Mange rejsende afholder gentagne rejser med samme destinationer. Der er behov for en funktion, der tillader den enkelte bruger at kopiere egne tidligere dokumenter, således at rejseoplysninger, kontering mv. bliver overført til et nyt. Dog uden at sammenkoble de to dokumenter. Formålet er at begrænse det antal oplysninger brugeren skal indtaste, når der håndteres dokumenter, der ligner brugerens tidligere oprettede dokumenter. Side 38 af 79

39 Mange institutioners ansatte rejser til de samme destinationer gentagne gange, fx ved rejser til og fra Bruxelles. Institutionen skal kunne oprette en dokumentskabelon for sådanne gentagne rejser, som udfyldes med prædefinerede rejseoplysninger og kontering, således at brugerne kan kopiere skabelonen. Formålet er dels at begrænse det antal oplysninger brugeren skal indtaste, dels at sikre, at et dokument er forhåndsudfyldt med korrekte oplysninger. Kopifunktionen skal kunne bruges ved både forhåndsgodkendelses- og afregningsdokumenter. 2A A A A STRUHS skal understøtte kopiering dokumenter, således at gamle dokumenters rejseoplysninger, kontering, mv. overføres til et nyt. (ØK). En lokal administrator skal kunne oprette en skabelon for dokumenter, der indeholder rejseoplysninger, kontering, mv., for ofte foretagne rejser i en institution, således at brugerne kan danne et nyt dokument på baggrund af skabelonen (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Samtidige adgange til et dokument Det kan ske, at to eller flere brugere forsøger at tilgå et dokument samtidigt. Det kan i nogle tilfælde være acceptabelt, fx i forbindelse med en supportsag. Men det skal ikke være muligt, at to brugere forsøger at redigere de samme dele af et dokument simultant. 2A Hvis mere end en bruger forsøger at åbne og/eller redigere et dokument på en gang, skal STRUHS sikre hensigtsmæssig afgrænsning af muligheden for at redigere dokumentet, så den ene brugeres arbejde i dokumentet ikke kan påvirke den anden brugers arbejde i dokumentet uhensigtsmæssigt (PK) Side 39 af 79

40 2A A A STRUHS skal automatisk gøre en bruger opmærksom på, hvis brugerens rettigheder til at redigere et specifikt forretningsdokument, er begrænset som følge af at en anden bruger anvender dokumentet (ØK) Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. 2A Dokumentationsbilag Alle afholdte tjenesteudgifter skal kunne dokumenteres ved visning af fakturaer/kvitteringer. STRUHS skal understøtte dokumentationskravet ved at gøre det nemt og brugervenligt at tilføje filer til dokumentation af udgifter. 2A A A A A A A STRUHS skal understøtte kravene til vedhæftning af dokumentationsbilag i overensstemmelse med kravene til revisionsspor (MK). STRUHS skal kunne understøtte vedhæftelsen af dokumentationsbilag i alle gængse formater (fx pdf, jpg, msg, doc, docx) (ØK). Brugeren skal kunne vedhæfte dokumentationsbilag, der ligger lokalt på den enhed, som systemet tilgås fra (ØK). Brugeren skal kunne vedhæfte dokumentationsbilag ved hjælp af en drag-anddrop funktion, således at antallet af museklik, det tager at hente at vedhæfte en fil, minimeres (PK). Brugeren skal kunne vedhæfte én eller flere dokumentationsbilag pr. omkostningspost (ØK). STRUHS skal kunne modtage filer (fx PDF-filer) sendt fra tredjepart og automatisk allokere dem den rette bruger, således at brugeren kan vedhæfte filen som dokumentationsbilag i et dokument (PK). STRUHS skal kunne modtage MMS er sendt fra brugerens mobiltelefon og automatisk tildele dem den rette bruger, således at brugeren kan vedhæfte MMS en som dokumentationsbilag i et dokument (PK). Side 40 af 79

41 2A A A A A Brugeren skal nemt kunne tilknytte modtagne dokumentationsbilag (fx MMS er) til et dokument, fx ved at vælge dokumentationsbilagene fra en liste (ØK). Brugeren skal kunne åbne og udskrive et dokumentationsbilag i printvenligt format (ØK). Brugeren skal kunne vælge at få udskrevet alle dokumentationsbilag tilhørende en given bestilling/afregning på én gang (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Posterings-, konterings- og dimensioneringsoversigt Med henblik på fejlsikring, opfølgning og afstemning af konteringsfejl, skal det i hvert dokument kunne ses, hvordan hver af omkostningsposterne i dokumentet er konteret og dimensioneret. 2A A A A A STRUHS skal vise, hvordan hver omkostningspost i et dokument er debiteret og krediteret, og hvilke Alias, dimensionsværdier, momskoder m.m. der er knyttet til (ØK). STRUHS skal vise posteringen præcis som de bliver overført til Navision Stat, således at der dannes optimalt sammenlignelighedsgrundlag (PK). Brugerne skal kunne se posteringerne i hvert dokument (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Side 41 af 79

42 Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Historik og logning af ændringer I forbindelse med revision og opfølgning på hvor længe et dokument er om at blive behandlet i et dokumentflow, skal STRUHS kunne logge og vise et dokuments historik. 2A A A A STRUHS skal logge alle relevante handlinger, der er foretaget på et dokument. Det skal tydeligt fremgå, hvilken handling der er tale om, hvem der har foretaget handlingen og hvornår handlingen er foretaget (PK). Brugeren kunne et dokuments historik i dokumentet (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Udskrift af dokumenter Brugerne i STRUHS skal kunne udskrive oprettede dokumenter. Udskriftene skal indeholde alle nødvendige og tilstrækkelige oplysninger. 2A A STRUHS skal understøtte udskrift af et dokument i alle led af dokumentflowet (MK). Udskriften skal indeholde alle nødvendige og tilstrækkelige oplysninger, herunder dokumentnummer, dokumenttype, personoplysninger (herunder navn, initialer, adresse og andre kontaktoplysninger), dato for oprettelse, evt. Side 42 af 79

43 starttid- og sluttid, evt. afrejse- og destinationssted, godtgørelsesform, forklaringstekst, eventuelle rejsedage, kørsler, udgifter (med angivelse af betalingsmåde, eventuel valutanavn, valutakurs og henvisning til bilag) godtgørelser, kontostreng og posteringslinjer, dokumentets historik, kommentarer skrevet i dokumentet, samt oversigt over samlede og vigtigste beløb i dokumentet (ØK). 2A A A A A Udskriften skal kunne udskrives med alle dokumentationsbilag, således at der ved udskrift af dokumentet fås én samlet udskrift af både dokumentoplysninger og vedhæftede bilag (PK). Brugeren skal kunne konfigurere hvad indholdet i en dokumentudskrift, så de fx kan fravælge udskriften af specifikke afsnit, fx posteringslinjer (ØK). STRUHS skal understøtte udskrift i printvenligt format (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Valutahåndtering Idet rejsende i Staten ofte er på udenlandske rejser, skal STRUHS kunne understøtte afregningen af beløb i andre valutaer end danske kroner. Nogle institutioner benytter kun gængse valutaer, mens andre institutioner har rejseaktiviteter i lande med valutaer, der er mindre almindelige. 2A A A STRUHS skal understøtte afregning i alle valutaer (PK). STRUHS skal automatisk opdatere valutakurser, således at systemet opererer med aktuelle valutakurser (PK). Brugeren skal kunne angive en omkostningsposts valutakurs manuelt, således at kursen kan afvige fra det, som STRUHS definerer (ØK). Side 43 af 79

44 2A A A A STRUHS skal kunne sammenligne manuelt angivede valutakurser med systemets valutakurser (ØK). Systemadministratorer skal kunne oprette valutaer og valutakurser manuelt (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A A A A A A A Sproglag STRUHS skal understøtte dansk og engelsk sproglag (MK) Sproglaget skal slå igennem i alle dele af STRUHS, så alle tekster i brugergrænsefladen, adviseringer, fejlmeddelelser præsenteres for brugeren på det valgte sprog (PK). Valg af sproglag skal kunne konfigureres på brugerniveau (ØK). Brugeren skal selv kunne vælge sproglag (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Side 44 af 79

45 Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Udbetaling og afregning af forskud Når en bruger ikke har et tjenestekreditkort (fx fordi de er engangs- eller udenlandske ansatte) og det ikke ønskes, at de skal foretage udlæg, er det er det hensigtsmæssigt at kunne udbetale brugeren et forskud gennem STRUHS. Brugeren skal ligeledes kunne afregne forskudsbeløbet beløbet gennem STRUHS. 2A A A A A STRUHS skal understøtte udbetaling og efterfølgende afregning af forskud (PK). Brugeren skal ved afregning af forskud løbende kunne se, hvordan hver udgiftspost formindsker forskudsrestancen (ØK). Lokale administratorer skal trække en rapport over udestående (ikkeafregnede) forskud i STRUHS (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A EU-rådsrejser STRUHS skal kunne understøtte anmodningen om refusion af EU-rådsrejser. STRUHS skal bistå brugeren med at registrere de krævede EUrådsrejseoplysninger, og bistå institutionen med forenkling af det administrative arbejde forbundet med indsamling og indberetning af refusionsberettigede udgifter. EU-kommissionen dækker udelukkende transportomkostninger (fx fly, tog, bus, taxa eller kørsel i egen bil). Disse udgifter skal summeres pr. rejseafregning, så de udgør ét samlet beløb. For disse udgifter kræves vedhæftet dokumentation. For hver afregning skal brugeren udfylde en afregningsskabelon, der lever op til EU-kommissionens dokumentationskrav. Side 45 af 79

46 2A A A STRUHS skal understøtte indberetningen af EU-rådsrejser, der giver ret til refusion (MK). Brugeren skal kunne registrere et rejseafregningsdokument som værende en EU-rådsrejse (ØK). STRUHS skal ved oprettelse af EU-rådsrejser gøre det obligatorisk at have udfyldt de til enhver tid gældende dokumentationsoplysninger bestemt af EUkommissionen. Pt. skal følgende data registreres (PK): Navn ESDP-møde Forklaring ESDP/non-ESDP (kan evt. angives som en boolean) Dato mødets/rejsens første dag * Fx Rejsendes navn * Navn på organisation * Afrejseby * Mødekode Mødetitel By, som mødet afholdes i * Rejseomkostninger (i DKK).* Fornavn, evt. mellemnavn, efternavn Ministerium eller styrelse Fx København Fx Council meeting eller 4c09 Fx GAC, RELEX Fx Bruxelles Fx 245,50 kr. 2A A A A A A A Felter markeret med (*) skal automatisk hentes fra oplysninger indtastet i afrejsedokumentet, således at det begrænses, hvad brugeren skal genindtaste (ØK). Brugeren skal kunne udfylde og redigere alle felter, uanset om de er forhåndsudfyldt (ØK). STRUHS skal summere afregningsdokumentets rejseomkostninger, og ikke medtage eventuelle ikke-transportrelaterede udgifter, som dokumentet evt. også indeholder. Dette kan fx ske ud fra en opsætning, der grupperer omkostningstyper i transport- og ikke transportrelaterede udgifter. (PK). STRUHS skal ved EU-rådsrejser gøre det obligatorisk for brugeren at vedhæfte dokumentation for de transport-relaterede omkostningsposter (ØK). Brugeren skal kunne generere en rapport over egne EU-rådsrejser og de indtastede dokumentationsoplysninger (ØK). Lokaladministratoren skal kunne generere en rapport over alle EU-rådsrejser og de indtastede dokumentationsoplysninger (ØK). Rapporten over EU-rådsrejser skal foruden oplysninger specificeret i krav XX, indeholde en kolonne med dokumentnummeret og en kolonne med links til Side 46 af 79

47 dokumentets transport-relaterede dokumentationsbilag, således at disse kan tilgås direkte fra rapporten (PK). 2A A A A Rapporten over EU-rådsrejser skal kunne trækkes både med og uden med specifikation af de enkelte omkostningsposter, som dokumentet indeholder. Som standard skal EU-rådsrejserapporten trækkes uden specifikation og således kun indeholde en række pr. dokument (PK). Rapporten over EU-rådsrejser skal kunne eksporteres til Excel med henblik på videreredigering og indberetning til EU-kommissionen (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Søgefunktion og dokumentoversigter STRUHS skal understøtte en effektiv søgemekanisme til at finde dokumenter i systemet. 2A A A A A Søgemulighederne i STRUHS skal være fleksible, brugervenlige og omfattende (MK) Søgeresultater skal fremvises på en struktureret og overskuelig form, så brugerne fx får et oversigtsbillede med et dokument pr linje (ØK). Brugeren skal kunne tilgå et dokument direkte fra søgeresultatet (ØK). Det skal fremgå tydeligt, hvor mange resultater der er fundet af en søgning, også 0, hvis der ingen resultater er fundet, så brugeren tydeligt kan se at søgningen er gennemført (ØK). Antallet af søgeresultater som systemet kan returnere, må ikke være afgrænset, men antallet af søgeresultater der vises pr. side må gerne være afgrænset (ØK) Side 47 af 79

48 2A A A A A A A A A A A A A A STRUHS skal have en effektiv metode til at håndtere store søgeresultater, således systemet kan håndtere fx en blank søgning, der returnerer et stort antal dokumenter (PK). Status og tilhørsforhold skal tydeligt fremgå af søgeresultatet så man fx kan se, at et specifikt dokument er sendt til godkendelse hos en specifik godkender i en specifik organisationsenhed (ØK). Søgeresultatet skal kunne vise alt data som brugeren har adgangsrettigheder til at se i systemet, således at en bruger fx får vist alle dokumenter tilhørende brugere, som han har adgangsrettigheder til at se (ØK). Det skal tydeligt fremgå af søgeresultatet, om en anden bruger anvender et dokument, som fremgår på søgeresultatet (ØK). Brugeren skal kunne søge ud fra en kombination af søgekriterier, fx ud fra status og organisationsenhed (ØK). Brugeren skal kunne søge på en kombination af parametre, så en bruger fx kan fremsøge alle dokumenter med en af to forskellige statusser i én samlet søgning (ØK). Brugeren skal kunne søge på dokumentnummer (PK) Det skal være muligt at søge efter dokumenter der har været håndteret af en bestemt bruger i kombination med en specifik handling, så en revisor fx kan fremsøge alle dokumenter, der er blevet godkendt af en specifik bruger (PK) Brugeren skal kunne søge ud fra et dokuments status (ØK). Brugeren skal kunne fremsøge et dokument ud fra en dimensionsværdi der er angivet på dokumentet, eller en kombination af dimensionsværdier der er angivet på dokumentet (ØK). Brugeren skal kunne søge ud fra tilhørsforhold, fx alle dokumenter tilhørende brugere fra en bestemt afdeling eller en bestemt organisation (ØK). En bruger skal kunne eksportere et søgeresultat til Excel eller lignende (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: Side 48 af 79

49 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Rapportering og statistik STRUHS skal kunne understøtte udtrækning af data og rapportering som kan anvendes til at analysere aktivitet, opsætninger, statistik, historik og opfølgningsrutiner. STRUHS skal med rapporteringsværktøjerne desuden hjælpe medarbejderne og ledelse med at skabe overblik over egne og organisationens rejseaktiviteter og omkostninger. 2A A A A A STRUHS skal stille fleksible og brugervenlige rapporteringsmuligheder til rådighed for brugerne, i systemets egen brugergrænseflade (PK) Brugerne skal kunne eksporteres rapporter fra STRUHS til Excel eller lignende, så data nemt kan viderebehandles (PK) STRUHS skal sikre, at rapporter vises i printvenligt format (ØK). STRUHS skal understøtte rapporteringsdannelse af både stamdata og transaktionsdata, fx brugerdata, konteringsopsætninger, rejsedestinationer, rejseomkostninger, dokumentflow, osv. (PK). Systemadministratorer skal kunne oprette og tilgængeliggøre standardrapporter på tværs af organisationsenheder, fx til brug ved sikkerhedsinstrukser og afstemning (PK). En ikke udtømmende liste over rapporter, der er relevante, er: Brugerrettighedsoversigt. Oversigt over brugers ID, navn, tilhørsforhold, rettigheder, prokuragrænser m.m. Dokumentflowsoversigt. Oversigt over hvor hurtigt dokumenter er kommet igennem et dokumentflow og hvem der har behandlet hvert led i flowet i en given periode. Oversigt over uafregnede kreditkort-, rejsekonto-, og taxakørselstransaktioner. Oversigt over samlede rejseudgifter afholdt/udbetalt pr. bruger, afdeling eller organisationsenhed. Oversigt over alle stedfortræderforhold. Oversigt over indberetninger til SKAT. Oversigt over batches med afregninger overført til Navision Stat. 2A Systemadministratorer skal kunne definere, hvilke systemroller har læserettigheder til de enkelte rapporter (PK). Side 49 af 79

50 2A A Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Informations- og fejlmeddelelser STRUHS skal vejlede brugeren i brugen af systemet, dels ved at understøtte opsætning af informations- og vejledningsmeddelelser, dels ved at returnere sigende og forståelige fejlmeddelser, som brugeren kan forstå og tage stilling til. 2A A A A A A Systemadministratorer skal nemt kunne opsætte institutionsspecifikke informations-/vejledningstekster for specifikke delopgaver i udfyldelsen af et dokument, således at der fx vises en informationsmeddelelse om kørselsregler, når brugeren registrerer en kørsel (PK). Systemadministratorer skal nemt kunne opsætte institutionsspecifikke informations-/vejledningstekster ved behandling af dokumenter i dokumentflow, således at der fx kan opsættes en meddelelse til godkendere om, at de skal huske at tjekke konteringen på dokumenter (ØK). Hvis en bruger forsøger at gennemføre en ugyldig handling, eller hvis et teknisk problem gør, at en handling ikke kan gennemføres korrekt, skal STRUHS automatisk returnere en fejlmeddelese til brugeren (ØK). Teksterne i fejlmeddelelserne skal være sigende sammenhængende og forståelige standardtekster, og skal vejlede brugerne til at komme videre i deres brug af systemet (PK). Globale administratorer skal kunne konfigurere fejlmeddelelserne (ØK) Indholdet af fejlmeddelelserne skal kunne hente oplysninger fra STRUHS, der får fejlmeddelelsen til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne og beløb (ØK) Side 50 af 79

51 2A A Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Adviseringer STRUHS skal kunne konfigureres til automatisk at gøre brugerne opmærksomme på ændringer og forhold i STRUHS, der er relevante for brugerne. 2A A A A A A STRUHS skal kunne advisere brugerne om udeståender i systemet (MK). Adviseringen skal sendes som s til brugerne (PK) Enhver relevant handling som STRUHS enten foretager automatisk eller som gennemføres af en bruger, skal kunne generere en advisering til de relevante brugere. En ikke udtømmende liste over handlinger, der er relevante, og som derfor skal kunne udløse et advis til en bruger, er (ØK): Brugeren har importerede transaktioner/kørsler/ dokumentationsbilag liggende klar til afregning. Brugeren har uafregnet forskud liggende til afregning. Brugeren har dokumenter liggende, der er klar til behandling. Brugeren har dokumenter liggende, der er blevet afvist og skal genbehandles. Brugerens bestillingsdokumenter er blevet godkendt. Teksterne i adviseringerne skal være sigende, sammenhængende, forståelige og forklarende (ØK). Indholdet af adviseringerne skal være konfigurerbart globalt, således at globale administratorer kan ændre i indholdet i standardteksterne (PK). Indholdet af adviseringen skal kunne hente oplysninger fra STRUHS, der får adviseringen til at fremstå personlig og informerende, fx ved angivelse af brugernavne, dokumentnumre, dokumentforklaringer og beløb (ØK). Side 51 af 79

52 2A A A A A A A A A Teksterne i adviseringerne skal indeholde dybe links, så en bruger kan gå direkte til et evt. dokument(er), adviseringen henviser til (PK). Lokale administratorer skal på organisationsniveau kunne opsætte frekvens for afsendelse af hver adviseringsstype, så det fx kan bestemmes, at én type advisering skal afsendes ugentligt (fx adviseringer om uafregnede transaktioner), mens en anden advisering skal afsendes øjeblikelligt (fx adviseringer vedr. afviste dokumenter) (PK). Brugerne skal kunne konfigurere præferencer(regler) for modtagelse af adviseringer, således at brugerne kan til-/fravælge at modtage specifikke adviseringstyper (ØK). STRUHS skal understøtte, at visse funktioner gennemføres direkte gennem adviseringen uden at brugeren skal logge ind. Fx skal en bruger med godkenderrettigheder kunne godkende en afregning ved trykke på et link i adviseringen (ØK). Lokaladministratoren skal manuelt kunne generere en given advisering til en bruger. Fx er der i forbindelse med årsafslutning ofte et behov for at afsende ekstra rykkere for bl.a. afregning af rejser og transaktioner (ØK) STRUHS skal understøtte muligheden for at generere mailadviseringer ved afsendelse/modtagelse af data gennem integrationerne, så der fx kan sendes en mail til en regnskabsmedarbejder ved afsendelse af en batch til Navision (ØK). Systemadministratoren i oversigtsform kunne se retursvar for afsendelser af mail-notifikationer, så det kan opdages, at mails ikke bliver modtaget grundet fx slåfejl i mailadressen angivet for en given brugerprofil (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.3.11 Understøttelse af mobile platforme Side 52 af 79

53 2A A A A A A A A A A A A Brugeren skal kunne tilgå STRUHS via mobile enheder som smartphones og tablets, på brugergrænseflader beregnet til mobile enheder (MK). Brugeren skal kunne oprette dokumenter og udfylde grundoplysninger som forklaring, dato for rejse, afrejse- og destinationssted, osv. (PK). Brugeren skal kunne tilføje dimensioner til dokument (ØK). Brugeren skal kunne tilføje en omkostning til et dokument, fx et udlæg til repræsentation (PK). Brugeren skal kunne tilføje kreditkort-/rejsekonto-/taxatransaktioner til et dokument (ØK). Brugere skal let kunne vedhæfte billeder som dokumentationsbilag, så fx billeder af en kvittering som dokumentation for et udlæg kan tilføjes (PK). Brugeren skal kunne benytte telefonens GPS-funktion til registrering af befordring (PK). Brugerne skal kunne sende dokument videre eller tilbage i dokumentflowet, således at en godkender fx både kan afvise og godkende et dokument (ØK). Brugeren skal kunne tilgå den mobile version af STRUHS offline og gemme ændringer lokalt (ØK). Den mobile version af STRUHS skal kunne tilgås med samme login som på STRUHS s webmodul (ØK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. Side 53 af 79

54 2A.3.12 Systemkonfiguration STRUHS skal kunne konfigureres på tre niveauer: Globalt af globale systemadministratorer, lokalt (organisationsniveau) af lokale systemadministratorer og på brugerniveau. Dele af konfigurationen på brugerniveau skal den enkelte bruger selv kunne gennemføre, mens det er den lokale systemadministrator, der skal udføre andre dele af brugerkonfigurationen. Det forudsættes, at STRUHS i stor udstrækning kan konfigureres, men at det ligeledes kan anvendes med en standardopsætning konfigureret af Tilbudsgiver, således at STRUHS er meget simpelt at tage i brug for Kunden. Det bemærkes, at der i de foregående afsnit også er fremgået krav til systemkonfiguration løbende med kravspecificeringen af de funktionelle krav. De nedenstående krav til systemkonfiguration ligger udover og/eller i forlængelse af de allerede nævnte krav til systemkonfiguration. 2A A A A A A A A A Opsætning af systemet skal kunne konfigureres af Kunden (MK) Globale administratorer skal nemt kunne konfigurere systemets brugergrænseflade (ØK). De enkelte enheder/organisationer og brugere i systemet skal kunne konfigureres forskelligt (PK) Systemadministratorer skal have adgang til værktøjer til at eksportere og importere opsætningsdata, herunder brugerstamdata og rettigheder, kreditkort, omkostningstyper, mv. (PK) STRUHS skal sikre en validering af indlæst data (ØK). Systemadministratoren skal nemt kunne oprette, redigere og inaktivere omkostningstyper (PK). Systemadministratoren skal kunne oprette, redigere og skjule dimensioner i institutionens dimensionskontoplan (ØK). Systemadministratoren skal kunne definere faste dimensionsværdier pr. finanskonto, således finanskontoen altid overføres med den valgte dimensionsværdi, uanset hvad brugeren har valgt i dokumentet (ØK). Systemadministratoren skal pr. finanskonto kunne definere, at posteringslinjer overføres samlet, såfremt de har samme dimensionsværdier tilknyttet, således at det undgås, at en flere små beløb med samme kontering overføres til Navision (ØK). Side 54 af 79

55 2A A A Systemadministratoren skal kunne definere, at posteringslinjer der vedrører udbetaling til brugeren, overføres samlet, således at det det udbetalte beløb overføres samlet og ikke i delbeløb (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A Brugeroprettelser og -administration Kravene i dette afsnit om brugerkonfiguration ligger i forlængelse af de opstillede krav i afsnit XX om brugere, roller og rettigheder. Dette afsnit indeholder krav forbundet med nem oprettelse og vedligeholdelse af brugeropsætninger. 2A A A A A STRUHS skal gøre det nemt for en systemadministrator at oprette en ny bruger, fx ved klar markering af obligatoriske felter, forhåndsudfyldelse, mv. (ØK). Systemadministratorer skal ved oprettelse af nye brugere kunne kopiere en eksisterende brugers opsætning, således at de begrænses, hvad systemadministratoren skal indtaste manuelt (PK). Den globale administrator skal kunne konfigurere kopifunktionen, således det kan ændres hvilke feltværdier der bliver kopieret til en ny bruger (ØK). Systemadministratoren skal kunne oprette brugere på baggrund af brugerdata modtaget fra et andet system, således at systemadministratoren kun skal berige brugeren med STRUHS-specifikke værdier for at oprette brugeren. Målet er at formindske antallet at indtastninger, når en bruger skal oprettes i flere systemer samtidigt (PK). Systemadministratoren skal ved oprettelse af ny bruger kunne indtaste akkumulerede kørte kilometer indenfor indeværende år, således at STRUHS kan medtage kørte kilometer registreret af 3. part (PK). Side 55 af 79

56 2A A A A A A A A A A A A Systemadministratoren skal kunne masse-oprette brugerprofiler ved indlæsning fra et Excel-ark (PK). STRUHS skal ved oprettelse af en nye bruger kunne generere en mail, der automatisk har fået tilføjet udvalgte brugeropsætningsdata, herunder brugernavn, password, rettigheder, mv., således at systemadministratoren ikke skal sende en mail manuelt (ØK). Systemadministratoren skal kunne konfigurere mailen med brugeropsætningsdata (ØK). Systemadministratorer skal kunne inaktivere brugerprofiler, således at fx tidligere ansatte ikke kan tilgå systemet og der ikke kan oprettes dokumenter på deres vegne (ØK). Systemadministratorer skal kunne angive en fremtidig dato for inaktivering af en bruger, således at en brugerprofil inaktiveres på en på forhånd kendt fratrædelsesdag (ØK). STRUHS skal understøtte brugerprofiler uden systemadgang, således at medarbejderen ikke kan tilgå systemet, men at stedfortrædere kan oprette dokumenter på deres vegne (ØK). STRUHS skal understøtte en effektiv metode for sletning af personprofiler, så fx fejloprettede eller tidligere ansatte kan slettes fra systemet (PK). Systemadministrator skal kunne definere standarddimensionsværdier på en brugerprofil, således at alle dokumenter oprettet af brugeren som standard er udfyldt med den valgte dimensionsværdi (PK). Systemadministratoren skal kunne indtaste kontooplysninger for hver personprofil, med henblik på overførsel af betalingsoplysninger til Navision Stat (ØK). Systemadministratoren skal kunne definere personalekreditornummeret for hver brugerprofil, som er nøglen til integrationen til Navision Stat (se mere om integrationen til Navision Stat i bilag XX). Systemadministratoren skal kunne opdele brugerprofiler ud fra om de har valide CPR-numre, eller om de intet CPR-nummer har eller er oprettet med et fiktivt CPR-nummer. Dette skal ske af hensyn til indberetning af godtgørelser til SKAT, jvf. bilag XX (PK). Processerne der dækkes af ovenstående krav XX og XX er løsningsbeskrevet i underbilag 2B afsnit XX af Tjenesteyder (PK). Side 56 af 79

57 2A yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter XX af XXX i STRUHS(PK). Tilbudsgiver skal i underbilag 2B afsnit redegøre for følgende: 1. Processerne der dækkes af krav XX og XX. 2. Eventuelle yderligere funktioner der understøtter tildelingen af finanskonti i STRUHS, jf. krav. XY. Funktionalitet vedrørende XXX i STRUHS er yderligere kravsat i usecase XX og use XX i underbilag XX. 2A.4 Ikke-funktionelle krav Følgende kapitel indeholder de tekniske og ikke-funktionelle krav til STRUHS. Derved forstås f.eks. arkitekturprincipper, krav til integrationerne, brugervenlighed, tilgængelighed samt lovgivningsmæssige og politiske krav. Hvor funktionelle krav beskriver funktionalitet, som STRUHS skal stille til rådighed, beskriver ikke-funktionelle krav egenskaberne, hvormed STRUHS leverer funktionaliteten. 2A.4.1 Struktur, fleksibilitet og Platform Det er kundens ønske, at STRUHS skal være et standardsystem, der stilles til rådighed for kunden med et minimum af tilretninger. Men samtidig vil STRUHS kunne betragtes som et komponent i et fællesstatslig ERP system, der består af en række best-of-breed systemer og infrastrukturkomponenter, og som en del af statens samlede it-systemportefølje. Kundens krav til struktur, fleksibilitet og platform tager dels hensyn til at STRUHS skal være en del af en fælles statslig it-systemportefølje, og de principper der generelt skal anvendes for statens it-løsninger, dels tages der hensyn til kundens konkrete behov og endeligt tages der hensyn til at STRUHS skal være et eksisterende standardsystem. 2A A A A Data skal vedligeholdes ét sted og genbruges på tværs. Dette betyder fx, at konti og dimensionsværdier som udgangspunkt fødes og vedligeholdes i Navision Stat installationerne (PK) Integration mellem løsninger, internt såvel som eksternt, skal så vidt muligt foretages via samme integrationsarkitektur (PK) STRUHS skal være baseret på moderne og fuldt understøttede platforme (PK) Tjenesteyder skal sikre, at systemplatformen er opdateret, supporteret og overholder alle lovmæssige krav (PK) Side 57 af 79

58 2A A A A A A.4.2 2A A A A A A Databaseplatformen skal være baseret på en relationel database. Tjenesteyder skal sikre opdatering og support af databaserne. Der skal på forlangende fremlægges dokumentation for support og vedligehold af platformen i hele kontraktens løbetid (PK) Databaseplatformen skal være skalerbar, så Kunden uden begrænsninger kan tilslutte de af kontrakten omfattede myndigheder til løsningen uden at det påvirker systemets performance (PK) Systemet skal kunne tilgås fra smartphones. GUIen som kan anvendes ved tilgang fra en smartphone skal være beregnet til at blive anvendt fra en smartphone og skal gøre det nemt for en bruger at gennemføre operationer i systemet (PK) Systemet skal kunne tilgås fra tablets. GUIen som kan anvendes ved tilgang fra en tablet skal være beregnet til at blive anvendt fra en tablet og skal gøre det nemt for en bruger at gennemføre operationer i systemet (PK) Tjenesteyder skal tydeligt redegøre for om og i hvilket omfang, adgangen til systemet eller adgang til funktionalitet i systemet, er betinget af, at der er specifikt programmel, fx Silverlight eller Java plug-in, installeret på den enhed som brugeren prøver at tilgå systemet fra (ØK) Log ind og adgangsforhold Adgangsforhold til STRUHS skal reguleres ved brug af brugernavn og password (MK) En bruger skal kunne bestille et nyt password som STRUHS automatisk sender til brugerens adresse, hvis brugeren har glemt sit password (PK) STRUHS skal understøtte anvendelsen af Single Sign-On, (SSO) således at en intern bruger, der logger på i egen brugerinstitution, automatisk også bliver logget på STRUHS. Fx ved adgang og autentifikation af brugeren via Windows Active Directory. Dvs. at brugeren kendes ud fra Windows brugernavn (PK) Anvendelse af Single Sign-On skal kunne implementeres for enkeltstående juridiske enheder i STRUHS (PK). STRUHS skal overholde de fællesoffentlige retningslinjer specificeret i OIOSAML 2.0 standarden som er relevante for "Service Provider"-rollen med henblik på deltagelse i den fællesoffentlige SSO løsning 5 (PK) STRUHS skal kunne tilgås via Internettet ved anvendelse af gængse browsere, fx MS Explorer, Google Chrome, Mozilla Firefox og Safari. Tilbudsgiver skal i 5 Side 58 af 79

59 løsningsbeskrivelsen angive hvilke browsere, herunder hvilke versioner, der understøttes af STRUHS, samt tilbudsgivers politik for hvilke versioner der understøttes fremadrettet (PK). 2A A A Det skal tydeligt fremgå af logon-siden til systemet, hvis der er driftsforstyrrelser eller lignende. Tilsvarende skal det være tydeligt for brugere der tilgår systemet fra et dybt link eller lignende om der er driftsforstyrrelser eller lignende (ØK). Logon-siden skal huske brugeren, men ikke brugerens password, så en bruger der anvender den samme enhed til at tilgå systemet, kan undlade at taste sit brugernavn for at logge på systemet (ØK) Sessionen skal automatisk lukke, når brugeren lukker browservinduet (ØK) 2A Sessionen skal lave en time out efter et antal minutters inaktivitet, fx efter 30 minutters inaktivitet (PK) 2A A A.4.3 Tilbudsgiver skal i løsningsbeskrivelsen redegøre, hvad der gemmes, når sessionen laver time out, herunder mulighed for at gemme: Igangværende behandling af dokument Rapportvisning Søgeresultat (PK) STRUHS skal være lettilgængeligt for brugerne, hvorfor log-on til systemet ikke som udgangspunkt må kræve flerfaktorautentifikation. Moderniseringsstyrelsen ønsker dog at løsningen er fremtidssikret, hvorfor det ønskes muligt at flerfaktorautentifikation på et senere tidspunkt kan tages i anvendelse for alle brugere, eller for brugere med særligt stærke rettigheder, fx systemadministratorer. Tjenesteyder skal redegøre for mulighederne for at etablere flerfaktorautentifikation til løsningen (ØK) Integrationer STRUHS skal integrere til en række systemer: Navision Stat, for overførsel af bogføringsdata, samt modtagelse af stamdata. SKAT, for indberetning af godtgørelser. Banker, for modtagelse af kreditkort- og rejsekontotransaktioner. Taxaselskaber, for modtagelse af taxatransaktioner. Kørselsregistreringsvirksomheder, for modtagelse af GPS-registrerede kørsler. Statens rejsebureau, for overførsel af rejsebestillinger og stamdata, og modtagelse af rejsedata. Side 59 af 79

60 Statens Datavarehus (ØSLDV), for overførsel af data til et miljø, der indeholder data fra alle institutionens systemer, og som således danner grundlag for tværgående rapporteringsdannelse. Rejsekortet, for modtagelse af billetter. Integrationen til Rejsekortet skal dog ikke opsættes fra start. Integrationsudvikling håndteres som ændringsanmodning jf. ændringsanmodningsbilag XX, når Rejsekortet har fået udviklet en eksportfunktion til brug ved afregning af grupperejsekort. For alle integrationer gælder det, at STRUHS skal understøtte sikre og overvågede snitflader, der registrerer og afsender kvitteringer, der meddeler, om og hvordan data er modtaget. STRUHS skal desuden stille værktøjer til rådighed for systemadministratorer til at overvåge og fejlrette modtagne data. 2A Navision Stat Hver institution har eget regnskab i et ERP system, som STRUHS skal kobles op til. Fra Navision Stat modtager STRUHS stamdata som kontoplaner, dimensioner, dimensionsværdier, ugyldige dimensionskombinationer og kreditoroplysninger, og fra STRUHS sendes batches med afregningsdokumenter, sammen med kreditoroplysninger og dertilhørende betalingsoplysninger, med henblik på bogføring og udbetaling i Navision. Det er muligt, at institutioner med et andet ERP-system end Navision Stat vil anvende STRUHS. Dette må i hvert enkelt tilfælde vurderes om muligt og økonomisk fordelagtigt. Tilslutningen af disse institutioner vil blive aftalt separat evt. med ændringshåndtering, jf. bilag XX. 2A A A A A STRUHS skal understøtte, at integrationen til Navision Stat kan ske til flere separate Navision-installationer og regnskaber (MK) Al kommunikation med Navision Stat skal ske i det prædefinerede GIS-format (MK). STRUHS skal afsende data til og afhente data fra en sftp-server, som Kunden dokumenterer og leverer (ØK). Tjenesteyder er ansvarlig for at sikre, at integration til sftp-serveren (med henblik på dataoverførsel til Navision Stat) kan opsættes for hver institution. Kunden ser helst, at Tjenesteyder leverer værktøjer til Kunden, der sætter Kunden i stand til at opsætte integrationer mellem sftp-serveren og STRUHS for hver institution. I det omfang Tjenesteyder ikke leverer værktøjer til dette, er Tjenesteyder forpligtet til at assistere ved opsætningen af integrationen som en del af den almene drift (PK). Tjenesteyder skal overvåge integration til Navision Stat og informere Kunden, samt sørge for afhjælpning, hvis en overførsel gentagne gange ikke gennemføres korrekt (PK) Side 60 af 79

61 2A Tjenesteyder skal redegøre for, hvilke processer Kunden skal anvende for at håndtere fejl og afvisninger i forbindelse med overførsel mellem Navision Stat og STRUHS (PK) Afsendelse af batches fra STRUHS til Navision Stat STRUHS skal sende godkendte afregningsdokumenter til Navision Stat med henblik på bogføring og evt. udbetaling. En gruppe afregningsdokumenter sendt til Navision Stat kaldes en batch. Overførslen af batches skal foregå som et scheduleret job, hvor STRUHS mindst en gang i døgnet eller ved manuel initiering overfører en batch til en sftp-server, hvorfra den afhentes og bogføres i Navision Stat. STRUHS skal via et scheduleret job ligeledes afhente kvitteringen, som Navision Stat kvitterer med ved modtagelse af en batch. 2A A A A A A A STRUHS skal via et scheduleret job sende godkendte afregningsdokumenter til en sftp-server med henblik på bogføring i hver tilknyttede Navision Stat installation (MK). STRUHS skal via et scheduleret job afhente kvitteringer fra sftp-serveren med henblik på at kunne registrere, om og hvordan en batch er modtaget i hver tilknyttede Navision Stat installation (MK). Afsendelse af batches skal scheduleres til at blive afsendt mindst dagligt (MK). Afhentning af kvitteringer skal scheduleres til at blive afhentet mindst dagligt (ØK). Batches skal overføres i XML-format i overensstemmelse formatbeskrivelsen i afsnit XX. (PK). Systemadministratoren skal manuelt kunne initiere overførsel af batches, således at batchen overføres til sftp-serveren øjeblikkeligt (PK). Systemadministratoren skal manuelt kunne genfremsende en batch med et nyt batchid, fx hvis batchen ved en fejl er blevet slettet eller fejlbehandlet i Navision Stat (PK). Side 61 af 79

62 2A A Ved afsendelse af en batch til Navision Stat skal batchen og de indeholdende dokumenter få status Afsendt til Navision Stat el.lign., indtil kvitteringen er modtaget, hvorefter status skal ændres til afspejle tilbagemeldingen (ØK). STRUHS skal på baggrund af kvitteringen kunne gennemføre følgende handlinger (PK): Importfejl : STRUHS skal genfremsende batchen med samme batchid. Batchen og dokumenterne i batchen skal få tildelt status Fejl: Genfremsendt til Navision Stat el.lign., indtil ny kvittering er modtages. Behandlingsfejl : Batchen er modtaget, men skal behandles manuelt af en regnskabsmedarbejder. I STRUHS kan batchen og dokumenterne i batchen få tildelt status Modtaget i Navision el.lign. Behandlet: Batchen er modtaget i Navision Stat uden fejl. I STRUHS kan batchen og dokumenterne i batchen få tildelt status Modtaget i Navision el.lign. Ingen kvittering: Batchen er ikke modtaget i Navision Stat. Batchen og dokumenterne i batchen skal få tildelt status Fejl: Genfremsendt til Navision Stat el.lign., indtil kvittering er modtaget. 2A A A A Systemadministratorer skal i overbliksform kunne se, hvornår der er blevet sendt batches, hvad der er blevet sendt (batchnummer, batchstørrelse, batchens indhold af afregningsdokumenter), og status (PK). Systemadministratorer skal i overbliksform kunne se, hvornår der er modtaget kvitteringer, hvad der blev modtaget (kvitteringsnummer og tilhørende batchnummer), og kvitteringssvar (ØK). STRUHS skal jf. formatbeskrivelsen aflevere kreditoroplysninger med betalingsoplysninger for hvert afregningsdokument i batchen, således at det i Navision Stat er muligt at afvikle den automatiserede betalingskontrol ved udsøgning af betalinger afledt af kreditorkonteringer fra STRUHS (MK). STRUHS skal jf. formatbeskrivelsen aflevere transaktionsoplysninger med unikt RejseID for hver transaktion, der indeholder et sådanne, således at der i Navision Stat er muligt at afvikle den automatiserede afstemning af mellemregningskonti (MK). Stamdataoverførsel fra Navision Stat til STRUHS STRUHS skal kunne modtage og indlæse stamdata fra Navision. Stamdataoverførsel initieres af STRUHS ved afsendelse af en stamdataforespørgsel til sftp-serveren via et scheduleret job, eller når overførslen initieres manuelt af en bruger i STRUHS. STRUHS skal afhente stamdata fra sftp-serveren igen, efter Navision Stat har afleveret stamdatafilen på baggrund af den afhentede stamdataforespørgsel. Data kan Side 62 af 79

63 overføres som en delta-overførsel, hvor der alene overføres ændringer, der er foretaget i Navision Stat siden sidste dataoverførsel, eller som et fuldt load, hvor alle data overføres. Det er kundens ønske, at overførsel af stamdata som udgangspunkt sker som delta-overførsler, og at der alene overføres et fuldt datasæt, for at afhjælpe fejl eller ved tilslutning af nye bogføringskredse. Filtreringen til afhentning af delta skal ske ud fra datofiltrering i stamdataforespørgselen. 2A A A A A A A A STRUHS skal via et scheduleret job sende stamdataforespørgselsfiler til en sftp-server med henblik på modtagelse af stamdata fra hver tilknyttede Navision Stat installation (MK) STRUHS skal via et scheduleret job afhente Navision Stat stamdatafiler fra en sftp-server (MK). STRUHS skal kunne afsende en stamdataforespørgsel og indlæse en deltaoverførsel af stamdata fra hver tilknyttede Navision Stat-installation op til en gang i timen og mindst dagligt (PK) STRUHS skal kunne afsende en stamdataforespørgsel og indlæse en fuld overførsel af stamdata fra hver tilknyttede Navision Stat-installation op til en gang i døgnet (PK) Stamdataforespørgslen skal overføres i XML i formatbeskrivelsen specificeret i bilag XX. (ØK). Stamdatafilen fra Navision Stat modtages i XML i formatbeskrivelsen specificeret bilag XX. (ØK). Med henblik på at kunne indlæse en delta-overførsel, skal STRUHS kunne overføre stamdataforespørgslen med dato-filtrering, således at STRUHS kun afhenter data, der er blevet ændret siden sidste stamdataafhentning (PK). Systemadministratoren skal manuelt kunne initiere og indlæse en deltaoverførsel og kunne angive datoen, som stamdataforespørgslen filtrerer på (PK). Side 63 af 79