2A Kravspecifikation

Transkript

1 2A Kravspecifikation

2 Dokumentejer: Jakob M. Hein Version Dato Ændring Af Distribution 01 1/ Første udgave JMH Side 2 af 95

3 2A.1 INTRODUKTION TIL DET ØNSKEDE SYSTEM A.2 ARBEJDSGANGE I IFS A.3 INTRODUKTION TIL INTEGRATIONER A.4 OVERORDNEDE KRAV A.5 FUNKTIONELLE KRAV A.5.1 Koncernstruktur og administrative fællesskaber A.5.2 Brugere, roller og rettigheder A.5.3 Oprettelse af vareleverandører i IFS A.5.4 Aftaler A.5.5 Kataloger og punch-out A.5.6 Favoritlister A.5.7 Indkøbskurv A.5.8 Rekvisition og ordreafgivelse A.5.9 Varemodtagelse A.5.10 Fakturaer A.5.11 Generelt om anvendelse af IFS, dokumentbehandling og kontering A.5.12 Kreditnotaer A.5.13 Rykkere og kontoudtog A.5.14 Forsyningsspecifikationer (UTS) A.5.15 Søgning i IFS A.5.16 Systemkonfiguration A.5.17 Rapportering A.5.18 Øvrigt A.6 IKKE-FUNKTIONELLE KRAV A.6.1 Struktur, fleksibilitet og Platform A.6.2 NemHandel A.6.3 Integrationer A.6.4 Myndighedskrav A.6.5 Performance, servicemål og vedligeholdelse A.6.6 Historik og logning A.6.7 Brugervenlighed A.6.8 Brugermanualer A.6.9 Andre ydelser A.7 AFKLARINGSFASE, SYSTEMBESKRIVELSE OG TIDSPLAN A.7.1 Indledning A.7.2 Systembeskrivelsens indhold... Fejl! Bogmærke er ikke defineret. 2A.7.3 Godkendelse af systembeskrivelsen... Fejl! Bogmærke er ikke defineret. 2A.7.4 Ændringer i systembeskrivelsen... Fejl! Bogmærke er ikke defineret. 2A.7.5 Tidsplan A.8 COMPLIANCE SKEMA Side 3 af 95

4 2A.1 Introduktion til det ønskede system Moderniseringsstyrelsen ønsker at stille et fælles system til understøttelse af indkøbs- og fakturahåndteringsprocessen (også benævnt Indkøbs- og fakturahåndteringssystem, IFS) til rådighed for de statslige myndigheder og de statslige selvejende institutioner. Dette bilag indeholder Kundens specifikation af krav til Indkøbs- og fakturahåndteringssystemets funktion og virkemåde. Kravspecifikationen er udarbejdet i samarbejde med tværstatslige referencegrupper, med repræsentanter fra Ministerområ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. IFS skal integreres med Navision Stat samt Statens data-varehus, ØS LDV. Systemet skal indgå som en del af Moderniseringsstyrelsens system-portefølje på økonomiområdet. Samlet set skal IFS: Understøtte effektiv, enkel og brugervenlig håndtering af elektroniske fakturaer og fuldt digitale indkøb Understøtte effektiv organisering i administrative fællesskaber såvel inden for ministeransvarsområder som på tværs af ministeransvarsområder Understøtte den statslige effektivisering af indkøbsområdet, herunder anvendelsen af både fællesstatslige og lokale indkøbsaftaler På en række områder efterspørges funktionalitet og tekniske løsninger, der kan være tilrettelagt på mange måder. Her vil det i vid udstrækning være op til Tilbudsgiveren at specificere hvordan det forretningsmæssige behov kan opfyldes af IFS. Det anbefales at læse Statens Best Practice for Digitale Indkøb inden besvarelse af kravspecifikationen, da Best Practice for Digitale Indkøb tager udgangspunkt i de forretningsmæssige mål med at digitalisere indkøbsprocesserne og giver en grundlæggende forståelse for Kundens ønsker og behov. Best Practice for Digitale Indkøb er vedlagt i underbilag 2H, eller Side 4 af 95

5 kan findes her: Practice-for-Digitale-Indkoeb. 2A.2 Arbejdsgange i IFS Den samlede potentielle brugergruppe omfatter de statslige myndigheder samt de statslige selvejende institutioner 1, jf Bilag 2 afsnit 2.2. IFS skal i princippet kunne benyttes af alle medarbejdere i de omfattede myndigheder og selvejende institutioner. Derudover skal IFS kunne benyttes af Statens vareleverandører, der skal udveksle kataloger/ordrer/fakturaer mv. med deres statslige kunder. IFS skal sammen med Navision Stat og STRUHS kunne understøtte en nem organisering af forretningsgangene på området i henhold til nedenstående Best Practice processer, jf. Best Practice processer for digital Indkøbs- og Fakturahåndtering 2. I det følgende vil delprocesserne i Best Practice procesdiagrammet blive gennemgået, med baggrund i de beskrivelser som findes i Moderniseringsstyrelsen Best Practice processer for digital Indkøbs- og Fakturahåndtering. Figur 2A.1: Best Practice Procesdiagram 3. Ordreafsend else 1. Aftaleindgåelse 7. Betaling 8. Kreditnota 2. Rekvisition 4. Leverancemodtagelse 5. Fakturamodtagelse 6. Bogføring (lager) 2A Aftaleindgåelse 1 I udbudet begunstiges de statslige myndigheder og institutioner samt statslige selvejende institutioner, hvis bevilling er optaget på finansloven og yderligere navngivne statslige selvejende institutioner. Listerne kan hentes i.pdf format på dette udbuds hjemmeside her: RejsUd-og-IndFak/Institutioner 2 Moderniseringsstyrelsen Best Practiceprocesser for digital Indkøbs- og Fakturahåndtering findes her: Side 5 af 95

6 Ved aftaleindgåelse mellem en statslig myndighed og en vareleverandør, skal der tages højde for at indkøbsprocessen kan foregå elektronisk. Det kan betyde at vareleverandøren skal levere et elektronisk katalog og/eller oprettes i Navision Stat. 2A Rekvisition Rekvisitionen er den interne del af indkøbsprocessen, hvor de ønskede varer udvælges, konteres og godkendes af en person med tilstrækkelige rettigheder. Rekvisitionsprocessen kan involvere én eller flere brugere afhængigt af placering af rettigheder. 2A Ordreafsendelse Den godkendte rekvisition omdannes til en ordre, der afsendes til vareleverandøren. Det skal sikres, at oplysningskravene i forbindelse med ordreafgivelse er opfyldt, jf. 3 i bekendtgørelsen om elektronisk afregning med offentlig myndighed. Kommentar [F1]: Indsæt fodnote med reference 2A Leverancemodtagelse Leverancemodtagelsen er processen for registrering af varens modtagelse, der er afgørende for at den elektroniske faktura må betales. Rettidig registrering af varemodtagelse i IFS er en forudsætning for at godkendelse af fakturaer kan ske automatisk. 2A Fakturamodtagelse Alle fakturaer skal modtages i Systemet. Fakturaer med en ordrereference skal automatisk tilknyttes ordren og forsøges matchet med ordren på baggrund af oplysningerne på fakturaen og oplysningerne på ordren herunder oplysninger om varemodtagelse. Det er målet at oplysningerne matcher så fakturaen kan godkendes automatisk. Fakturaer der ikke kan matches med en ordre skal varemodtages og godkendes af en eller flere brugere i Systemet, afhængigt af placering af rettigheder. Når en faktura er godkendt i IFS skal den automatisk overføres til Navision Stat. 2A Bogføring Bogføringsprocessen omfatter bogholderens arbejde fra fakturaen modtages i Navision Stat til den er bogført. Processen håndteres for de fleste statslige myndigheder af ØSC (Økonomi Service Centeret) under Statens Administration. Side 6 af 95

7 For de selvejende institutioner håndteres processen normalt af institutionen selv. 2A Betaling Ligesom bogføringsprocessen varetages betalingsprocessen i Navision Stat. 2A Kreditnota Processen for håndtering af kreditnotaer er som udgangspunkt den samme som for håndtering af fakturaer. Kreditnotaer kan dog modtages på forskellige tidspunkter i et workflow. En kreditnota kan modtages enten før eller efter den tilhørende faktura er godkendt og betalt. Som ved fakturabehandling overføres kreditnotaen først til Navision Stat, når Kreditnotaen er konteret og godkendt i IFS. 2A.3 Introduktion til integrationer Dataflowet til og fra Systemet er gengivet i figuren nedenfor. Dataflowet viser integrationen mellem IFS og de systemer/instanser, der sendes data til, eller modtages data fra. Figur 2A.2: Systemunderstøttet dataflow Leverandør B (Ikke registreret i NHR) Datadump Statens Datavarehus (DV) Leverandør tilgår Fakturablanketten Indkøbsordre til ikke NHR-registreret leverandør Indkøbs- og fakurahåndteringssystem (IFS) Fakturablanketten (Virk.dk) Ordrebekræftelse Indkøbsordre til registreret leverandør Varekatalog Købsfaktura mv. Kvittering for modtagelse af købsfaktura mv. Godkendt faktura mv. Kvittering for modtagelse af godkendt faktura mv. Transaktionsdata (status på betalinger) Stamdata (finanskonti, dimensioner, kreditorer og anlæg) Afstemningsdata Købsfaktura mv. fra Leverandør B Ordrebekræftelse Indkøbsordre Varekatalog NemHandel (OIOUBL dokumenter) Leverandør A (Registreret i NHR) Kvittering for modtagelse af godkendt faktura mv. Navision Stat Afsendelse af købsfaktura mv. Godkendt faktura mv. Kvittering for modtagelse af købsfaktura mv. Side 7 af 95

8 2A A A A A NemHandel: Er en samlet betegnelse for OIOUBL formaterne, webserviceprofilen OIORASP og NemHandelsregisteret med tilhørende services. NemHandel er den offentlige danske standard for ehandel. Leverandør A: En Vareleverandør der er registreret i NemHandelsregisteret. Afsender typisk kataloger, fakturaer og kreditnotaer fra eget økonomisystem og kan evt. modtage kvitteringer (ApplicationResponses), afhængig af de registrerede profiler. Kan derudover respondere på ordrer med bekræftelse eller ændring mv. Leverandør B: En Vareleverandør der ikke er registreret i NemHandelsregisteret. Afsender typisk fakturaer og kreditnotaer fra Fakturablanketten på Virk.dk, eller lignende, og modtager evt. kvitteringer på fra det pågældende system. I forhold til afsendelse af kataloger, vil vareleverandøren typisk være afhængig af at kunne oploade kataloger direkte til IFS, fx fra en flad fil. Vareleverandøren vil typisk kun kunne modtage ordrer fra IFS pr. . Navision Stat: Hver institution har en eller flere bogføringskredse i en Navision Stat database, som IFS modtager stamdata og transaktionsdata fra. Derudover modtages alle godkendte fakturaer, kreditnotaer, rykkere og kontoudtog i Navision Stat, hvor de bogføres og betales. Statens Datavarehus: Alt data fra IFS, med undtagelse af rene systemdata, skal overføres til Statens Datavarehus, hvorfra data kan anvendes til rapportering, analyser, opfølgning på dispositionsregnskaber mv. Integrationerne er beskrevet i detaljer under afsnit 2A.6 Ikke-Funktionelle krav Side 8 af 95

9 2A.4 Overordnede krav I det følgende er de overordnede krav til IFS specificeret. Alle de overordnede krav er mindstekrav og kan have karakter af funktionelle krav eller ikke funktionelle krav. 2A A A A A Systemet skal understøtte effektiv fakturahåndtering for brugerinstitutionerne (MK) Systemet skal understøtte effektive digitale indkøb både med og uden elektroniske varekataloger (MK) Systemet skal fungere som et workflowssystem, der understøtter interne kontrol-/ og godkendelsesprocedurer (MK) Systemet skal stilles til rådighed som en hosted løsning og skal kunne tilgås via en browser (MK) Systemet skal understøtte grænseflader der tilgås via tablets- og smartphones (MK) 2A Systemet skal understøtte NemHandel og OIO-standarderne på e- handelsområdet (MK) 2A A A A A A A Systemet skal integreres til Navision Stat (MK) Systemet skal integreres med statens datavarehus, ØS LDV (MK) Systemet 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) Systemet skal sætte brugerne i stand til at udføre deres opgaver nemt, hurtigt og effektivt, herunder ved at tilbyde beslutningsstøtte og hjælp til fejlidentifikation og fejlhåndtering i dagligdagen (MK) Systemet 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) Systemet skal overholde gældende revisions- og regnskabsmæssige krav (MK) Løsningen skal være sikker og understøtte principperne i ISO27001 standarden eller lignende (MK) Side 9 af 95

10 2A.5 Funktionelle krav I det følgende er de funktionelle krav til IFS specificeret. Kravene er grundlæggende struktureret efter beskrivelserne i vejledningen til Best Practice for Digitale Indkøb, der fokuserer på at effektivisere det samlede flow fra bestilling til betaling. I de funktionelle krav er der dog også behandlet en række yderligere processer, der på forskellig vis er af relevans for at kunne skabe en samlet effektiv systemunderstøttelse af brugerinstitutionerne. 2A.5.1 Koncernstruktur og administrative fællesskaber IFS 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, statslige institutioner og evt. selvejende statslige institutioner under sig. Hvert eneste ministerium og institution er en selvstændig juridisk enhed som har et eller flere regnskaber (Navision Stat bogføringskredse) tilknyttet. En styrelse kan fx have mere end et regnskab fordi den administrerer en tilskudsordning. Hvert regnskab kan altså betragtes som en separat organisatorisk enhed, der indgår i et statsligt hierarki. Det er nødvendigt, 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 og indkøbsfællesskaber kan understøttes, uden at brugeren skal oprettes mere end en gang. Ligeledes skal kataloger kunne anvendes på tværs af organisationer i hierarkiet, så statens fælles indkøbsaftaler kan anvendes bredt, og så indkøbsfællesskaber inden for og på tværs af ministeransvarsområder understøttes, med et minimum af administration for både statens institutioner og statens vareleverandører. Endeligt gælder det, at den hierarkiske opsætning af organisationerne skal være fleksibel og kunne ændres, fx i forbindelse med en ressortændring af Staten. Organisationshierarkiet i IFS skal styres af Moderniseringsstyrelsens globale systemadministratorer, mens tildeling af brugerrettigheder og publicering af kataloger i dele af den hierarkiske organisationsstruktur også skal kunne gennemføres af henholdsvis en lokal systemadministrator og en indholdsansvarlig i de dele af organisationshierarkiet som den lokale systemadministrator/indholdsansvarlige har adgang til. 2A En global systemadministrator skal nemt kunne oprette, ændre og spærre organisationsenheder i IFS, således at han fx kan administrere oprettelsen af en ny institution eller sammenlægning af to institutioner (PK) Side 10 af 95

11 2A A A A A A A A A A A En global systemadministrator skal nemt kunne opsætte og ændre den hierarkiske struktur for organisationsenhederne i IFS, således at han fx kan administrere flytningen af en institution til et nyt ministeransvarsområde (PK) En lokal systemadministrator skal nemt kunne oprette, ændre og spærre organisationsenheder i IFS, inden for det domæne han har adgang til, således at han fx kan administrere oprettelsen af en ny afdeling i en institution eller sammenlægning af to afdelinger (ØK) En lokal systemadministrator skal nemt kunne opsætte og ændre den hierarkiske struktur for organisationsenhederne i IFS, inden for det domæne han har adgang til, således at han fx kan administrere flytningen af en afdeling fra en styrelse til en anden (PK) En bruger skal, på den samme brugerprofil, nemt kunne tildeles systemroller til en, flere eller alle organisationer der er oprettet i IFS (PK) En bruger skal nemt kunne tildeles forskellige systemroller i forskellige organisationer, på den samme brugerprofil, så en bruger fx kan have seadgang til et helt ministeransvarsområde, og rekvirent-rettigheder til en enkelt organisation under ministeransvarsområdet (PK) En bruger med systemroller i flere forskellige organisationsenheder, skal nemt kunne behandle data på tværs af organisationsenhederne, så en bruger fx kan trække rapporter for et helt ministerområde på en gang (ØK) Når en bruger med systemroller i flere organisationer logger sig ind, skal alle brugerens igangværende arbejder i alle organisationer vises overskueligt på brugerens forside, så brugeren fx ikke skal vælge hver enkelt organisation for at se brugerens igangværende arbejde i den enkelte organisation (ØK) Det skal være tydeligt for en bruger i hvilken organisation data er placeret, så det fx er tydeligt for brugeren, for hvilken organisation brugeren er i gang med at behandle et forretningsdokument (ØK) En bruger med tilstrækkelige rettigheder skal nemt kunne flytte et ikkegodkendt forretningsdokument fra en organisation til en anden, fx hvis en faktura er sendt til en styrelses driftsregnskab, men vedrører tilskudsregnskabet (ØK) Enkelte kataloginstanser skal kunne anvendes i flere forskellige organisationer, så en indholdsansvarlig på et overordnet hierarkisk niveau nemt kan modtage og godkende et katalog og herefter synliggøre kataloget for flere forskellige indholdsansvarlige brugere, på lavere hierarkiske niveauer, som hver især kan publicere hele eller dele af kataloget lokalt (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrevet i underbilag 2B. Side 11 af 95

12 2A Tjenesteyder bedes løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Koncernstruktur og administrative fællesskaber i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Koncernstruktur og administrative fællesskaber i IFS] Funktionalitet vedrørende Koncernstruktur og administrative fællesskaber er yderligere kravsat i Use case 1 i underbilag 2C. 2A.5.2 Brugere, roller og rettigheder En brugers rettigheder i IFS kan inddeles i to typer af rettigheder, funktionsrettigheder fx retten til at kunne godkende en ordre og adgangsrettigheder fx retten til at tilgå en specifik organisation. Funktionsrettigheder skal styres på rolleniveau, mens adgangsrettigheder skal styres på brugerniveau, og de to typer af rettigheder skal kunne kombineres så en bruger fx kan tildeles en specifik rolle i en specifik organisation og en anden rolle i en anden organisation. I IFS skal en brugers funktionsrettigheder til at godkende vise typer af forretningsdokumenter endvidere kunne afgrænses ved en prokuragrænse. En bruger skal kunne tildeles forskellige prokuragrænser i forskellige organisationer. Rollerne i IFS skal styres globalt, mens tildeling af systemroller og adgangsrettigheder til den enkelte bruger skal kunne ske lokalt. I denne kravspecifikation opereres der med følgende funktionsroller: Global Systemadministrator De globale systemadministratorer for IFS er placeret i Moderniseringsstyrelsen og har adgangsrettigheder til hele IFS. Den globale systemadministrator har til opgave at oprette, vedligeholde og administrere organisationer og organisationshierarkiet i IFS, at oprette lokale systemadministratorer og evt. at oprette, vedligeholde og administrere roller, og globale konfigurationer i IFS. Lokal Systemadministrator Den lokale systemadministrator har adgang til en eller flere organisationer i IFS. Den lokale systemadministrator har, for de pågældende organisationer, til opgave at oprette og tildele rettigheder og prokura til brugere, samt at administrere lokale konfigurationer på organisationsniveau. Indholdsansvarlig Den indholdsansvarlige har til opgave dels at oprette og administrere aftaler i IFS, og dels at godkende kataloger og udstille hele eller dele af kataloger for Side 12 af 95

13 indkøberne i organisationerne. Det er væsentligt at en indholdsansvarlig på et overordnet niveau i organisationshierarkiet, kan godkende et katalog og distribuere det til indholdsansvarlige på lavere niveauer i organisationshierarkiet, som så kan udstille hele eller dele af kataloget lokalt, fx hvis den enkelte institution har en lokal indkøbspolitik om at anvende et begrænset udvalg af varer på en fællesstatslig indkøbsaftale. Rekvirent Rekvirenten er den, der har behov for en given vare eller ydelse. Rekvirenten opretter en rekvisition i systemet, konterer denne og videresender den til indkøberen. Rekvirenten kan også omtales som intern bestiller eller leverancemodtager. Hvis et indkøb foretages uden en elektronisk ordre vil det typisk være rekvirenten, der skal modtage fakturaen og foretage dele af fakturabehandlingen. Rekvirenten er ansvarlig for at registrere varemodtagelse i systemet. Registreringen er afgørende for at betaling kan ske, da der pr. definition ikke må betales for varer eller ydelser, der ikke er modtaget. Indkøber Modtager rekvisitionen fra rekvirenten, og sørger for at den ønskede vare eller ydelse anskaffes på den mest hensigtsmæssige måde, fx ved at undersøge om varen er på lager eller om der kan benyttes en eksisterende indkøbsaftale. Disponent En disponent er tildelt begrænset eller ubegrænset prokura til dele af eller til hele registreringsrammen ( kontoplanen ) på et regnskab i en organisatorisk enhed. En disponent vil ofte være budgetansvarlig, men der kan også være tale om at disponenten har fået tildelt prokura af en budgetansvarlig. I IFS har disponenten til opgave at godkende indkøb og sikrer, at konteringen er korrekt. Fakturafordeler Hvis en modtaget faktura (eller andet forretningsdokument) ikke automatisk kan behandles eller sendes til den rette rekvirent, har fakturafordeleren til opgave at finde den rette modtager og sende fakturaen til vedkommende. Typisk vil det også være fakturafordeleren der holder øje med at alle forretningsdokumenter behandles rettidigt. Se -bruger I forbindelse med support eller revision er det nødvendigt at en bruger kan tildeles se -rettigheder til hele IFS, eller til dele af IFS, således at brugeren kan fremsøge data, generere rapporter og analysere data, men uden at brugeren har rettigheder til at ændre data. I systemet skal der være systemroller som understøtter ovenstående funktionsroller. Det er ikke et krav at systemrollerne er identiske med de ovenstående funktionsrollerne, men det gælder at systemrollerne skal kunne Side 13 af 95

14 dække funktionsrollernes arbejdsopgaver, på en måde der er i overensstemmelse med Best Practice og revisions- og sikkerhedshensyn. 2A A A A A A A A A A A A A Der skal nemt kunne oprettes globale systemadministratorer med adgang til det samlede IFS (PK) Globale systemadministratorer skal nemt kunne oprette lokale systemadministratorer (PK) Af sikkerhedshensyn skal der være to globale eller lokale systemadministrator inde over oprettelse og rettighedstildeling til en bruger (ØK) Globale og lokale systemadministratorer skal kunne oprette, ændre og inaktivere brugere i systemet (MK) En bruger skal kunne tildeles en ren se -rolle, som kan anvendes med henblik på support eller revision (MK) Det må ikke være muligt at slette oprettede brugere af hensyn til historikken, hvis brugeren har foretaget handlinger, der indgår i et transaktions- eller kontrolspor (PK) Funktionsrettigheder i IFS skal tildeles gennem en rollebaseret brugerrettighedsstruktur (PK) Funktionsrettigheder i systemet skal følge CRUD (Create, Read, Update, Delete) strukturen (ØK) Systemet 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 kunne en systemrolle give adgang til at kontere et dokument, mens en anden rolle kunne give adgang til at ændre momskoder på det samme dokument (ØK) Systemet skal understøtte følgende funktionsroller som er beskrevet ovenfor: Global Systemadministrator, Lokal Systemadministrator, Indholdsansvarlig, Rekvirent, Indkøber, Disponent, Fakturafordeler og Se -bruger (PK) En bruger skal nemt kunne tildeles et sæt af systemroller i IFS som dækker en, flere eller alle forskellige funktionsroller i IFS (PK) Globale og lokale systemadministratorer skal nemt kunne redigere en eksisterende brugers systemroller indenfor det domæne (de organisationsenheder) systemadministratoren har rettigheder til (PK) Globale og lokale 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 Side 14 af 95

15 brugerprofiler som hver især består af specifikt sæt kombinationer af systemroller, prokuragrænser, og adgangsrettigheder til organisatoriske enheder (ØK) 2A A Brugeradministrationen skal være placeret i et modul, der er baseret på en moderne, fuldt understøttet applikation, fx kan det være at brugeradministrationen gennemføres i samme brugergrænseflade som IFS generelt tilgås med(pk) Processerne der dækkes af ovenstående krav (2A A og 2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter administration af Brugere, roller og rettigheder i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A A Eventuelle yderligere funktioner der understøtter administration af Brugere, roller og rettigheder i IFS] Funktionalitet vedrørende Brugere, roller og rettigheder er yderligere kravsat i Use case 2 i underbilag 2C. 2A Prokura Prokura er retten til at foretage indkøb, og godkende fakturaer på indkøb som er foretaget, under visse beløbsgrænser (beløbsgrænsen, betegnes også som prokuragrænsen ). Brugere med funktionsrollen Disponent tildeles prokura, der kan være afgrænset på flere forskellige parametre. 2A A A A A Lokale systemadministratorer skal kunne opsætte generelle og specifikke prokuragrænser for de enkelte disponenter (MK) Specifikke prokuragrænser skal nemt kunne opsættes på fx konteringsværdier, leverandører, kataloger og produktkategorier (UNSPSC), så en it-ansvarlig fx kun har ret til at godkende køb af IT-udstyr (PK) Det skal være nemt at opsætte prokuragrænser pr. transaktion, så en disponent fx ikke kan godkende et dokument, eller dele af et dokument, der overstiger disponentens prokuragrænse (PK) Det skal være nemt at opsætte prokuragrænser som en sum over en periode, så en disponent fx kun kan godkende transaktioner op til et vist beløb pr. dag, uge, måned eller år (ØK) Det skal være nemt at kombinere prokurabegrænsninger pr. transaktion og pr. periode, så en disponent kan tildeles begge typer af begrænsninger og så Side 15 af 95

16 systemet kontrollerer begge typer af prokuragrænser når disponenten forsøger at godkende en transaktion (ØK) 2A A Når IFS kontrollerer om en bruger har prokura til at godkende en transaktion, skal IFS automatisk tage højde for hvilken valuta henholdsvis transaktionen og prokura er angivet i (PK) Processerne der dækkes af ovenstående krav (2A A )er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Prokura i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Prokura i IFS] Funktionalitet vedrørende Prokura er yderligere kravsat i Use case 3 i underbilag 2C. 2A Brug af 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 IFS. IFS skal have en stedfortræderfunktionalitet så en brugers rettigheder og opgaver nemt kan flyttes til en anden bruger i en kortere eller længere periode. 2A A A A A Systemet skal have en stedfortræderfunktion (PK) En bruger, der udpeges som stedfortræder, skal nemt kunne overtage de roller og rettigheder eller et udsnit af disse, som den person vedkommende er stedfortræder for, er tildelt (PK) Mens stedfortræderfunktionen er slået til så en bruger er tildelt en stedfortræder skal stedfortræderen modtage alle relevante forretningsdokumenter og adviser, der sendes til brugeren, og dokumenter, der allerede er allokeret til brugeren skal fremgå på en oversigt 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 (ØK) En bruger skal nemt selv kunne opsætte og fjerne en stedfortræder for brugerens egne rettigheder, så brugeren fx kan angive en stedfortræder inden brugeren tager på ferie (ØK) Side 16 af 95

17 2A A A A A Den lokale systemadministrator skal nemt kunne tildele og fjerne stedfortræder rettigheder for brugere i den eller de organisationer han er administrator for (ØK) Det skal være nemt at angive en start og en slutdato for hvornår stedfortræderrettighederne skal være tildelt (ØK) Det skal være muligt at angive flere stedfortrædere i forskellige datointervaller (ØK) En lokal systemadministrator skal kunne opsætte regler for hvilke stedfortrædere en bruger kan vælge, så det fx kan styres at det ikke er muligt at angive en stedfortræder for en disponent, der ikke har tilsvarende prokura (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Brugen af stedfortrædere i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Brugen af stedfortrædere i IFS 2A.5.3 Oprettelse af vareleverandører i IFS Oprettelse og vedligeholdelse af vareleverandørens stamdata sker i Navision Stat. Vareleverandørens stamdata overføres løbende fra Navision Stat til IFS, for hvert enkelt Navision Stat regnskab. 2A A A A Vareleverandørerne skal automatisk oprettes og opdateres med data overført fra Navision Stat (MK) Vareleverandører skal kunne identificeres ved hjælp af mindst ét sæt og højest to sæt af identifikatorer et primært og et sekundært den primære identifikator skal altid være kreditors juridiske enhed, fx DK:CVR eller DK:CPR, den sekundære identifikator kunne fx være et P-nr (PK) Vareleverandørernes primære identifikator er obligatorisk, mens den sekundære identifikator er frivillig, og fx vil blive anvendt hvis flere leverandører har samme CVR-nr, men forskellige sekundære identifikatorer fx P-nr (ØK) Kombination af de to identifikatorer skal være unik for hver leverandør indenfor det enkelte Navision Stat regnskab. Det vil sige, at hvis IFS allerede har modtaget en leverandør fra et specifikt Navision Stat regnskab med et Side 17 af 95

18 specifikt CVR-nr, kan der ikke oprettes endnu en leverandør med samme CVR-nr, medmindre der fx også er angivet et unikt P-nr (ØK) 2A A A Hvis en vareleverandør oprettes, ændres eller deaktiveres i NS, skal dette automatisk opdateres i IFS (PK) Det skal fremgå af IFS, hvornår en vareleverandør er oprettet i IFS og hvornår vareleverandøren senest er ændret i IFS (ØK) Det skal tydeligt fremgå i systemet, hvordan en vareleverandør, vil modtage forretningsdokumenter og Application Responses (fx på en specifik NemHandelsregistrering eller på en specifik mail-adresse). Oplysningerne om modtagelse skal også fremgå de relevante steder i IFS, herunder på aftaler, kataloger, ordrer og andre forretningsdokumenter der sendes fra IFS til vareleverandøren. Oplysningerne overføres ikke fra Navision Stat til IFS, hvorfor det forudsættes at IFS foretager opslag på NemHandelsregisteret. (ØK) Krav til integrationen, herunder stamdataoverførslen, mellem Navision Stat og IFS er beskrevet nærmere i afsnit 2A A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter oprettelse af vareleverandører i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Oprettelse af vareleverandører i IFS Funktionalitet vedrørende Oprettelse af vareleverandører er yderligere kravsat i Use case 4 i underbilag 2C. 2A.5.4 Aftaler Hovedparten af statens indkøb sker på baggrund af forpligtende aftaler. Der kan både være tale om centrale rammeaftaler og om lokale aftaler. IFS skal understøtte administrationen af aftaler og kobling af indkøb til aftaler. 2A A Systemet skal have et aftalemodul, der understøtter indkøbsprocessen (PK) En indholdsansvarlig skal nemt kunne oprette nye aftaler og redigere og spærre eksisterende aftaler (ØK) Side 18 af 95

19 2A A A A A A A A IFS skal nemt kunne understøtte anvendelsen af rammeaftaler, der anvendes af flere institutioner, dvs. aftaler skal kunne gøres tilgængelige for en, flere eller alle organisatoriske enheder (ØK) IFS skal gøre det nemt at administrere og få overblik over aftaler (PK) Det skal tydeligt fremgå hvilke varekataloger og/eller Punch out - opsætninger, der er tilknyttet til en aftale (ØK) IFS skal understøtte indkøberne i nemt at handle på aftaler når indkøbet foretages (ØK) Det skal være nemt at angive aftalevilkår, som vil fremgå tydeligt for indkøber når der indkøbes på aftalen (ØK) Hvis der er angivet aftalevilkår og der er tilknyttet et katalog til aftalen, skal aftalevilkårene, tydeligt fremgå ved visning af de tilhørende katalogvarer (ØK) IFS skal gøre det nemt at følge op på, om gennemførte indkøb er sket gennem en oprettet aftale (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Aftaler i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Aftaler i IFS] 2A.5.5 Kataloger og punch-out Når der er indgået en aftale om indkøb af standardiserede varer, vil indkøbet typisk kunne ske via elektroniske varekataloger. Ved brug af elektroniske varekataloger er det væsentligt, at de enkelte brugerinstitutioner dels har mulighed for at benytte fælles varekataloger (fx fra vareleverandører på de fællesstatslige indkøbsaftaler eller SKI-aftaler), samt at de kan benytte deres egne vareleverandørers kataloger overfor deres egne brugere. Brugerinstitutionerne skal således kunne benytte både globale og lokale elektroniske kataloger i IFS. Dvs. kataloger skal både kunne modtages, godkendes og publiceres så de kan anvendes af alle brugerinstitutioner og så de kan anvendes af en eller flere brugerinstitutionerne indenfor et enkelt ministerområde eller på tværs af ministerområder. Uanset om katalogerne er globale eller lokale, skal de kunne begrænses lokalt, så brugerinstitutionens Side 19 af 95

20 indkøbere kun får vist en mindre del af det samlede sortiment på aftalen, fx hvis der er vedtaget en lokal indkøbspolitik. Det er vigtigt, at katalogerne i IFS løbende opdateres, således at de altid afspejler de gældende kontraktlige aftaleforhold, herunder at der kun kan ses kataloger fra godkendte vareleverandører og at de viste priser og produkter er korrekte. 2A A A A A A A IFS skal understøtte brugen af elektroniske varekataloger (MK) IFS skal nemt kunne understøtte anvendelsen af rammeaftaler, der anvendes af flere institutioner, dvs. kataloger skal kunne gøres tilgængelige for en, flere eller alle enheder (PK) Vareleverandører skal nemt kunne se, hvordan deres kataloger og katalogopdateringer præsenterer sig i systemet, inden katalogerne godkendes (PK) Der skal være et godkendelsesflow for kataloger, katalogopdateringer og/eller prislister i systemet (godkendelse inden publicering) (PK) Systemet skal understøtte anvendelsen af punch out til en leverandørs egen webbutik, så en bruger kan konfigurere en vare elle en ydelse i en vareleverandørs webbutik og trække varen/ydelsen retur til IFS til videre behandling (ØK) Globale og lokale systemadministratorer skal nemt kunne slå punch-out funktionalitet til og fra på brugerinstitutionsniveau (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrevet i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A ] 2A Indlæsning af kataloger Det er væsentligt at alle vareleverandører har mulighed for at understøtte brugerinstitutionernes indkøb via elektroniske varekataloger, og det vil derfor være et element i IFS at tilbyde forskellige måder hvorpå elektroniske varekataloger kan indlæses i IFS. 2A A Brugerinstitutionernes vareleverandører skal kunne sende kataloger direkte til IFS i OIOUBL format (MK) Brugerinstitutionernes vareleverandører skal nemt kunne indlæse kataloger i IFS via et katalogværktøj stillet til rådighed af Tjenesteyder (PK) Side 20 af 95

21 2A A A A A Katalogværktøjet skal nemt kunne konvertere kataloger fra fx kommasepareret fil, regnearks-/databasefil eller andre formater til OIOUBL (ØK) Katalogværktøjet skal være nemt og effektivt at anvende, også for små vareleverandører uden særlige it-kompetencer (PK) En vareleverandør skal nemt kunne angive, hvilken brugerinstitution kataloget skal tilknyttes og IFS skal automatisk route kataloget til den korrekte indholdsansvarlige (PK) IFS skal nemt kunne håndtere at en vareleverandør leverer til flere brugerinstitutioner, men at varesortimentet som skal udstilles for brugerinstitutionerne ikke nødvendigvis er ens (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Indlæsning af kataloger i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Indlæsning af kataloger i IFS] 2A Opdatering af Kataloger Der vil løbende skulle ske ændringer til de katalogvarer som udstilles i IFS. Det er nødvendigt at IFS har funktionalitet der sikrer, at kataloger og varer kan opdateres uden at der tabes historik, så indkøbere og indholdsansvarlige let kan se og overskue ændringer til de varer de anvender 2A A A A Brugerinstitutionernes vareleverandører skal kunne sende katalogopdateringer direkte til IFS i OIOUBL format (MK) Brugerinstitutionernes vareleverandører skal nemt kunne indlæse katalogopdateringer til IFS via et katalogværktøj stillet til rådighed af Tjenesteyder (PK) Katalogerne skal nemt kunne opdateres løbende enten ved at overskrive eksisterende kataloger med opdaterede kataloger eller ved at opdatere enkelte elementer i eksisterende kataloger. (ØK) Det skal være nemt at opdatere dele af et katalog, fx prisændringer eller udskiftning af enkelte varer (PK) Side 21 af 95

22 2A A A A A Det skal være muligt nemt at få et overblik over de ændringer der er foretaget i et katalog, så en bruger med tilstrækkelige rettigheder fx let kan få et overblik over prisudviklingen for varerne i et katalog (PK) Indlæses et nyt katalog, skal vareleverandøren kunne angive hvilket katalog, der skal overskrives (ØK) IFS skal være fleksibelt i forhold til opdatering af kataloger, så det fx kan håndteres, hvis der refereres til en forkert tidligere version af kataloget i en katalogopdatering (ØK) Varer på en favoritliste eller lignende må alene påvirkes af en katalogopdatering eller indlæsning af nyt erstatningskatalog, hvis der foretages ændringer til den konkrete vare (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Opdatering af kataloger i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Opdatering af kataloger i IFS] Funktionalitet vedrørende Opdatering af kataloger er yderligere kravsat i USECASE 5 i underbilag 2C. 2A A A A A A Godkendelse og publicering af kataloger IFS skal sende et advis til en relevant indholdsansvarlig når der er indlæst et nyt katalog eller en katalogopdatering i IFS (ØK) Den indholdsansvarlige skal nemt kunne godkende kataloger og katalogopdateringer (PK) Den indholdsansvarlige skal nemt kunne opsætte intervaller for automatisk godkendelse af katalogopdateringer (fx prisændringer). Intervallerne skal kunne baseres på procenter, tidsinterval og beløb, og der skal kunne opsættes forskellige intervaller for forskellige aftaler, kataloger og varekategorier. (ØK) Den indholdsansvarlige skal nemt kunne publicere ét katalog i en eller flere organisatoriske enheder, som den indholdsansvarlige har adgang til(pk) Det skal fremgå tydeligt i systemet om et katalog er publiceret, hvornår det er publiceret, hvem der har publiceret kataloget og hvornår kataloget senest er opdateret (ØK) Side 22 af 95

23 2A A A A A A A A A A A A Den indholdsansvarlige skal nemt kunne udvælge dele fra et katalog, og gøre udsnittet tilgængeligt lokalt (ØK) Et katalog eller en katalogopdatering, samt de tilhørende katalogvarer skal først kunne ses og anvendes af brugerne når de er godkendt og publiceret af en indholdsansvarlig (PK) Leverandøren skal kunne angive ikrafttrædelsesdato og udløbsdato for kataloget. Fx fra 01/01/2016 kl til 31/01/2016 kl (ØK) Hvis leverandøren har angivet ikrafttrædelsesdato og/eller udløbsdato for kataloget, skal det ikke være muligt at vælge varer fra kataloget uden for den periode, hvor kataloget gælder (ØK) Der skal i systemet kunne opsættes alarmer som gør en indholdsansvarlig opmærksom på at et katalog er ved at udløbe (ØK) Den indholdsansvarlige skal nemt kunne afvise kataloger og katalogopdateringer (ØK) Den indholdsansvarlige skal nemt kunne afvise dele af et katalog og dele af en katalogopdatering, dvs. den indholdsansvarlige skal kunne vælge en eller flere varelinjer, og afvise disse (ØK) Såfremt et katalog eller en katalogopdatering helt eller delvist afvises af en indholdsansvarlig, skal der i IFS genereres en sigende fejlmeddelelse som sendes til vareleverandøren (ØK) Den indholdsansvarlige skal i fejlmeddelelsen nemt kunne angive årsagen til afvisningen, herunder vedhæfte eventuelle bilag mv. (ØK) En indholdsansvarlig skal nemt kunne spærre et katalog helt eller spærre et katalog delvist ved spærre udvalgte varelinjer, så det ikke er muligt for indkøbere at vælge de spærrede varelinjer og kataloger (ØK) Den indholdsansvarlige skal nemt kunne tilføje en tekst til enten alle varer i et katalog eller udvalgte varer, som tydeligt fremgår for de pågældende varer i systemet. Funktionaliteten kunne fx anvendes til at gøre indkøberne opmærksom på ekstra leveringsomkostninger som tillægges små ordrer (ØK) Processerne der dækkes af ovenstående krav (2A A og 2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Godkendelse og publicering af kataloger i IFS i underbilag 2B (PK) Side 23 af 95

24 1. Processerne der dækkes af krav 2A A og 2A A Eventuelle yderligere funktioner der understøtter Godkendelse og publicering af kataloger i IFS] Funktionalitet vedrørende Godkendelse og publicering af kataloger er yderligere kravsat i Use case 6 i underbilag 2C. 2A A A A A A A A A A A Visning af Kataloger og katalogvarer IFS skal gøre det nemt for brugerne at anvende elektroniske varekataloger (PK) IFS skal vise varekataloger på en måde, der giver et overskueligt og hurtigt overblik over den enkelte vare, herunder billede, beskrivelse, pris, varianter, forpakning (fx pakke á 4 stk.) mv. (PK) Det skal være nemt at få vist detaljerede oplysninger om den enkelte vare i systemet (PK) IFS skal kunne præsentere katalogerne og varerne på en måde, så de afspejler brugernes behov, fx ved at brugerne nemt kan til- og fravælge hvilke vareinformationer de vil se (ØK) Aftalenavn og Aftale ID for et katalog, skal tydeligt fremgå for brugerne både i søgeresultat ved søgning på katalog eller søgning på varer og ved varevisning (ØK) IFS skal nemt give den enkelte bruger en oversigt over alle de kataloger (aftaler) som brugeren har adgang til, og her igennem give adgang til at kunne købe varer indeholdt i det pågældende katalog (PK) Det skal være nemt at sammenligne varer, så man fx kan se samme type vare fra flere vareleverandører i forhold til hinanden. (ØK) IFS skal vise katalogerne på en måde, der understøtter mulighederne i OIOUBL-standarderne, herunder mulighederne for visning af sammenknyttede varelinjer. For en række produktområder, bl.a. møbler og pc er, er slutproduktet et resultat af en konfigurationsproces, som brugeren selv forestår. For at sådanne produkter kan disponeres tilfredsstillende elektronisk, kræver det at varekatalogets indeholdte relationer eksponeres og overholdes i løsningen (ØK) IFS skal vise den samlede pris for varen inklusive eventuelle gebyrer mv. (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og Side 24 af 95

25 brugervenligt understøtter Visningen af Kataloger og katalogvarer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Visningen af Kataloger og katalogvarer i IFS] 2A.5.6 Favoritlister Formålet med favoritlister er at mindske den tid rekvirenter og indkøbere bruger på at fremsøge varer, som bestilles og indkøbes ofte eller jævnligt. 2A A A A A Systemet skal understøtte brugen af favoritliser (MK) Rekvirenter og indkøbere skal kunne oprette, redigere og slette egne favoritlister (PK) Favoritlister skal automatisk opdateres, således at de afspejler en vares aktuelle status, fx hvis varen er slettet eller spærret i en indkøbsaftale (PK) Ændres en vare, som optræder på en eller flere favoritlister, skal varen markeres i favoritlisterne med samtidig angivelse af den specifikke ændring som er foretaget (fx prisstigning eller spærring), så brugerne bliver opmærksomme på ændringen (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Favoritlister i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Favoritlister i IFS] Funktionalitet vedrørende Favoritlister er yderligere kravsat i Use case 7 i underbilag 2C. 2A.5.7 Indkøbskurv Ønskede varer skal kunne opsamles og lagres i en indkøbskurv, således at en bruger kan afbryde en indkøbsproces, uden at skulle starte forfra senere. Indkøbskurve anvendes også til at gemme ønskede varer over en periode til en samlet ordre med henblik på at opnå aftalte mængde- og prisrabatter, undgå leveringsgebyrer o. lign. Side 25 af 95

26 2A A A A A A A A A IFS skal understøtte brugen af indkøbskurve (PK) Rekvirenter og indkøbere skal nemt kunne lægge varer i en indkøbskurv i systemet (ØK) Rekvirenter og indkøbere skal nemt kunne tilføje varer, justere antal ønskede varer og slette varer i en indkøbskurv (ØK) Varer som ikke længere findes i et katalog eller som er spærrede, må ikke kunne tilføjes en indkøbskurv (ØK) Rekvirenter og indkøbere skal nemt kunne gemme, redigere og slette forskellige indkøbskurve, som de kan navngive efter behov (ØK) I de gemte indkøbskurve skal rekvirenter og indkøbere nemt kunne tilføje varer, justere antal ønskede varer og slette varer (ØK) Priserne og status på varerne i en indkøbskurv (også evt. gemte indkøbskurve) skal opdateres automatisk, hvis de bagvedliggende kataloger ændres (ØK) Indholdet af en indkøbskurv må aldrig nulstilles, med mindre brugeren aktivt har valgt dette. Således må indkøber fx ikke miste en indkøbskurv hvis sessionen løber ud (ØK) Processerne der dækkes af ovenstående krav (2A A og 2A A er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Indkøbskurve i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Indkøbskurve i IFS] Funktionalitet vedrørende Indkøbskurve er yderligere kravsat i Use case 8 i underbilag 2C. 2A.5.8 Rekvisition og ordreafgivelse Afsendelse af indkøbsordre består af flere elementer og kan involvere flere brugere i IFS. En rekvirent har et behov og opretter en elektronisk rekvisition, hvori den ønskede vare eller ydelse hentes fra en indkøbskurv eller beskrives og kvantificeres i fritekst, og hvor indkøbet evt. konteres helt eller delvist. Herefter varetager en indkøber den praktiske anskaffelse, vurderer om varen/ydelsen skal tages fra et lager eller om den skal købes direkte hos vareleverandøren, og angiver evt. yderligere kontering. Endeligt Side 26 af 95

27 godkender en disponent den konkrete bestilling og kontering evt. efter at have angivet yderligere kontering. Funktionsrollerne som rekvirent, indkøber og disponent kan være fordelt på en, to eller tre brugere i det enkelte indkøb. Når rekvisitionen er blevet godkendt ændrer rekvisitionen status til en indkøbsordre, for så vidt angår terminologien i denne kravspecifikation, og afsendes til vareleverandøren. 2A Særligt vedrørende forskellige indkøbstyper I Best Practice er der identificeret syv indkøbstyper, der er beskrevet i nedenstående figur: Figur 2A.3: Indkøbstyper Indkøbstype Eksempler Standardkøb Kontorartikler, kaffe, IT-forbrugsstoffer (papir, toner mv.), konsulenter (bodyshopping), vikarer mv. Dialogbaserede indkøb Konsulentbistand, værkstedsbesøg, håndværkerydelser Koncernfælles indkøb Pc er, printere, mobiltelefoner, møbler mv. Stående ordrer Husleje, avis- og tidsskriftsabonnementer, telefonregninger Internetkøb Kursusbestilling, bestilling af tog- og flybilletter, hvor der modtages en efterfølgende faktura Kreditorkortkøb Bogkøb, hotelregninger, taxikørsel, repræsentation, betaling i forretninger med lånt institutionskort, fx visse internetkøb Udlæg Klippekort, togbilletter, taxikørsel, visse internetkøb mv. Udlæg håndteres ikke i IFS, men i STRUHS, mens de øvrige 6 typer indkøb skal kunne understøttes i IFS, hvilket der tages højde for i de funktionelle krav. De forskellige indkøbstyper stiller forskellige krav til flowet igennem IFS. Standardkøb og dialogbaserede indkøb understøttes direkte af IFS, fx via elektroniske varekataloger eller ved at der afsendes en ordre med fritekst med reference til forudgående dialog. Side 27 af 95

28 Koncernfælles indkøb stiller nogle særlige krav til rettigheder og informationer på ordre og faktura; fx at der angives forskellig kontering og forskellige leveringssteder for varerne/ydelsen. Stående ordrer er specielle idet de er regelbundne, fx periodiske og med et (ofte) kendt beløb. Udfordringen er at sikre den størst mulige automatisering ved behandling af disse opkrævninger. Såfremt Internetkøb og Kreditkortkøb resulterer i en efterfølgende faktura, der skal betales af brugerinstitutionen, betragtes disse som indkøb uden ordre i IFS (ligesom indkøb foretaget pr. mail eller telefon), og fakturaen skal behandles som en faktura uden tilknyttet ordre. Er det derimod brugeren, der selv betaler med kreditkort eller ved indkøb på Internettet, er der tale om et Udlæg, der ikke skal behandles i IFS men i STRUHS 2A A A A A A A A A IFS skal nemt understøtte Standardkøb, Dialogbaserede indkøb, Koncernfælles indkøb, Stående ordrer, Internetkøb og Kreditkortkøb (MK) Oprettelse af rekvisitioner og afsendelse af indkøbsordrer Rekvirenter skal kunne oprette rekvisitioner i IFS (MK) Rekvirenter skal nemt kunne oprette rekvisitioner ud fra katalogvarer, punchout-varer og rekvirentens egen beskrivelse dvs. Fritekst-varer (PK) På rekvisitionstidspunktet skal en bruger nemt kunne angive, at ordren ikke må automatches, fx hvis der er tale om en rekvisition, der ikke på rekvisitionstidspunktet kan momsangives korrekt. I så fald skal IFS ikke automatisk godkende en faktura, der matcher den pågældende varemodtagede ordre (ØK) I rekvisitionen skal en bruger nemt kunne angive, hvis man ikke vil acceptere delleverancer (ØK) Rekvirenten skal nemt kunne opsætte en standard indkøber, som automatisk vil være angivet på alle rekvisitioner som rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Rekvirenten skal nemt kunne opsætte en standard disponent, som automatisk vil være angivet på alle rekvisitioner rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Rekvirenten skal nemt kunne opsætte en standard leveringsadresse, som automatisk vil være angivet på alle rekvisitioner som rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Side 28 af 95

29 2A A A A A A A A A A A A A A En bruger skal nemt kunne angive ønskede leveringsdatoer på en rekvisition (PK) En bruger skal nemt kunne tilføje eksterne noter til en rekvisition, som sendes til leverandøren som en del af indkøbsordren (PK) En bruger skal nemt kunne tilføje interne noter til en rekvisition, som ikke fremgår af indkøbsordren, der sendes til leverandøren (ØK) Rekvirenten skal kunne kontere rekvisitionen helt eller delvist (MK) Rekvirenten skal kunne sende en helt eller delvist konteret rekvisition videre til en Indkøber (MK) Indkøberen skal nemt kunne færdiggøre rekvisitionen ved at ændre alle allerede angivne værdier (fx referenceperson, disponent, kontering, leveringsadresser, leveringsdatoer, eksterne kommentarer mv.), tilføje, fjerne eller redigere varelinjer og udfylde eller redigere de resterende/ manglende oplysninger i rekvisitionen (PK) Hvis de ønskede varer ikke findes i et katalog i IFS skal indkøberen nemt kunne specificere og bestille varen gennem IFS, som fritekstvarer eller via Punch-Out til en leverandørs egen webbutik (PK) En Indkøber skal nemt kunne samle flere rekvisitioner til samme leverandør til én samlet rekvisition (PK) IFS skal automatisk angive en standard referenceperson på rekvisitionen (PK) Det skal kunne konfigureres på organisationsniveau og på leverandørniveau, hvem der angives som standard referenceperson, dvs. om det fx skal være rekvirent, indkøber eller disponent der som standard angives som referenceperson på den enkelte ordre (ØK) Det skal være nemt at overstyre standard referencepersonen på rekvisitionen, med en anden referenceperson (PK) Indkøberen skal kunne sende en helt eller delvist konteret rekvisition, hvor alle andre obligatoriske oplysninger er udfyldt, til godkendelse hos en Disponent (MK) En rekvisition skal nemt kunne sendes til godkendelse hos flere disponenter inden ordren afgives, fx hvor der er tale om et indkøb til flere enheder inden for samme regnskab (PK) Disponenten skal nemt kunne redigere og færdiggøre konteringen af de dele af rekvisitionen der er sendt til godkendelse hos disponenten (PK) Side 29 af 95

30 2A A A A A En Disponent skal let kunne godkende eller afvise de dele af en rekvisition der er sendt til godkendelse hos den pågældende disponent (MK) Når alle disponenterne har godkendt deres del af rekvisitionen, skal rekvisitionen automatisk danne en indkøbsordre eller omdannes til en indkøbsordre, eller, hvis der er valgt varer fra mere end en vareleverandør, skal der automatisk dannes en indkøbsordre pr. vareleverandør (PK) Når alle disponenterne har godkendt deres del af rekvisitionen, og der er dannet en eller flere indkøbsordrer, skal IFS automatisk sende indkøbsordrerne til vareleverandørerne i OIOUBL format eller som s, afhængigt af, hvordan vareleverandøren er registreret i NemHandelsregistret (PK) En bruger med tilstrækkelige rettigheder skal kunne oprette en ordre i IFS som en efterregistrering, hvor ordren ikke sendes til vareleverandøren. Efterregistreringer af ordrer bruges blandt andet til at få et retvisende dispositionsregnskab (ØK) Processerne der dækkes af ovenstående krav (2A A , 2A A , 2A A og 2A A er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Oprettelse af rekvisitioner og afsendelse af indkøbsordrer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav (2A A , 2A A , 2A A og 2A A Eventuelle yderligere funktioner der understøtter Oprettelse af rekvisitioner og afsendelse af indkøbsordrer i IFS] Funktionalitet vedrørende Oprettelse af rekvisitioner og afsendelse af indkøbsordrer er yderligere kravsat i Use case 9 i underbilag 2C. 2A A A Gentagede køb og stående ordrer IFS skal give muligheder for at en bruger nemt kan foretage gentagne køb, fx så en rekvisition kan oprettes ud fra en tidligere rekvisition eller en tidligere ordre (PK) Det skal være nemt for en rekvirent at oprette en helt eller delvist udfyldt rekvisition på baggrund af en skabelon eller lignende, fx hvis der skal indkøbes en standard pakke af varer til en ny medarbejder (bord, stol, lampe, blomster etc.) (ØK) Side 30 af 95

31 2A A A IFS skal fleksibelt, intuitivt og brugervenligt understøtte indkøb på stående ordrer, fx periodiske forsyningssektorydelser eller abonnementsordninger (PK) IFS skal fleksibelt, intuitivt og brugervenligt understøtte, at konteringen som skal gælde for en ydelse på en stående ordre kan ændre sig over tid (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Gentagede køb og stående ordrer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Gentagede køb og stående ordrer i IFS] Funktionalitet vedrørende Gentagede køb og stående ordrer er yderligere kravsat i Use case 10 i underbilag 2C. 2A Behandling af ordrer hos vareleverandøren Efter at rekvisitionen er godkendt og der er sendt en ordre til vareleverandøren, kan det ske at vareleverandøren svarer med oplysninger, der skal medføre en ændring på ordren i IFS. Det kan også ske at kunden bliver opmærksom på forhold der gør at ordren skal annulleres. 2A A A A A Det skal være muligt for en bruger at annullere en ordre i IFS. Annulleringen skal medføre at ordren skifter status i IFS (ØK) Når en ordre annulleres skal IFS automatisk sende besked til vareleverandøren i et format vareleverandøren understøtter, fx via OrderCancellation dokumentet i NemHandel standarden, eller via (ØK) Vareleverandøren skal kunne sende en simpel ordrebekræftelse (OrderResponseSimple) til IFS, som automatisk skal opdatere ordren i IFS med de relevante oplysninger, om accept eller afvisning (PK) Hvis leverandøren ikke sender ordrebekræftelsen elektronisk skal en bruger med de rette rettigheder kunne opdatere oplysningerne manuelt på ordren i stedet (ØK) Vareleverandøren skal kunne sende en ordrebekræftelse (OrderResponse) til IFS, som automatisk skal opdatere ordren i IFS med de relevante oplysninger, Side 31 af 95

32 og evt. initiere et fornyet workflow, fx, hvis leverandøren foreslår en erstatningsvare (PK) 2A A En bruger med tilstrækkelige rettigheder skal nemt kunne lukke en åben ordre, fx hvis faktura og ordre ikke blev matchet korrekt, eller hvis leverandøren afviser ordren pr. mail eller telefon (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Behandling af ordrer hos vareleverandøren i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af behandling af ordrer hos vareleverandøren i IFS] Funktionalitet vedrørende Behandling af ordrer hos vareleverandøren er yderligere kravsat i Use case 11 i underbilag 2C. 2A.5.9 2A A A A A A Varemodtagelse En rekvirent skal i IFS kunne varemodtage ud fra oplysningerne på ordren, eller ud fra oplysningerne på fakturaen, hvis der ikke er tilknyttet en ordre til fakturaen (MK) Det skal være muligt at varemodtage alle varer på et dokument med en enkelt handling i systemet (MK) En rekvirent skal nemt kunne registrere delvis varemodtagelse i systemet, også på linjeniveau (PK) En rekvirent skal nemt kunne lukke restordrer på en ordre, hvis der ikke forventes yderligere leverancer (ØK) En rekvirent skal nemt kunne registrere negativ varemodtagelse i systemet, så han fx kan starte med at varemodtage alle varer på et dokument, og derefter kan justere for enkelte ikke leverede varer. Det kan også være relevant at foretage en negativ varemodtagelse, hvis det konstateres at en vare er defekt efter at varen er varemodtaget i systemet, men inden den tilhørende faktura er behandlet (ØK) Når en rekvirent foretager en varemodtagelse i IFS, skal modtagelsesdatoen registreres i IFS. Som default skal modtagelsesdatoen automatisk være dags Side 32 af 95

33 dato, men rekvirenten skal have mulighed for nemt at angive en anden modtagelsesdato (PK) 2A A En rekvirent skal nemt kunne ændre en angivet modtagelsesdato, for den enkelte varemodtagelse, på et dokument i systemet. Modtagelsesdatoen er bestemmende for i hvilken regnskabsperiode et dokument bogføres i Navision Stat (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Varemodtagelse i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Varemodtagelse i IFS] Funktionalitet vedrørende Varemodtagelse er yderligere kravsat i Use case 12 i underbilag 2C. 2A.5.10 Fakturaer Fakturabehandling i IFS skal som udgangspunkt bestå af varemodtagelse, kontering og godkendelse af en faktura. Hvis en faktura er koblet med en ordre, vil varemodtagelsen og konteringen være registeret på ordren og fakturaen kan herefter automatisk blive godkendt. I tilfælde af at fakturaen ikke kan godkendes automatisk fx pga. en afvigelse i prisen mellem ordre og faktura, skal fakturaen automatisk sendes til indkøber. Indkøber afgør hvorvidt afvigelsen er i orden, og sender herefter fakturaen til godkendelse, eller tager kontakt til leverandøren. Alternativt modtages en faktura i IFS, hvortil der ikke findes en ordre, så varemodtagelse, kontering og godkendelse skal registreres på fakturaen. IFS skal i begge tilfælde kunne opsættes til, at den samme bruger både kan varemodtage, kontere og godkende, hvis brugeren har tilstrækkeligt med rettigheder og prokura. En række af kravene til behandling af fakturaer i IFS finder også anvendelse for kreditnotaer og rykkere med gebyrer, jf. afsnit XX og afsnit XX. 2A Indlæsning af elektroniske fakturaer Side 33 af 95

34 Nedenfor er der angivet en række krav til indlæsning af fakturaer i IFS, samt krav til dokumentation af originalfakturaer. 2A A A A A A A A A A A A Modtagelsen af en faktura i IFS, skal være uafhængig af om leverandøren er oprettet i Navision Stat og overført til IFS (MK) Brugerinstitutionernes vareleverandører skal kunne sende fakturaer direkte til IFS i OIOUBL format gennem NemHandel (MK) En vareleverandør skal nemt og sikkert kunne angive, hvilken brugerinstitution fakturaen skal tilknyttes og IFS skal automatisk route fakturaen til den korrekte bruger i institutionen (PK) Hvis leverandøren er oprettet og overført fra Navision Stat skal IFS automatisk sikre kobling mellem faktura og leverandør ved indlæsning af fakturaen (PK) Hvis der ikke findes et stamkort på leverandøren i IFS, overført fra Navision Stat, skal det tydeligt fremgå for de brugere der behandler fakturaen i IFS (ØK) IFS skal understøtte anvendelse af alle komplette og ukomplette betalingsmetoder, såvel danske som udenlandske, der kan anvendes i OIOUBL formatet. En udtømmende liste af mulige betalingsmetoder fremgår af Løsningsbeskrivelsen i Bilag 2B (PK) Når en faktura modtages og indlæses i IFS skal der automatisk gemmes en skrivebeskyttet kopi af originalfakturaen til revisionsmæssig brug i systemet (MK) Når fakturaen senere godkendes, skal originalfakturaen automatisk medsendes den godkendte faktura til Navision Stat (MK) Originalfakturaen skal ikke vises som et selvstændigt dokument ved søgning i IFS (ØK) En bruger skal i IFS nemt kunne tilgå originalfakturaen direkte fra fakturaen (PK) Originalfakturaen skal vises for brugerne i et brugervenligt og overskueligt stylesheet, som giver brugerne en oplevelse af genkendelighed i forhold til en papirfaktura (PK) Det anvendte stylesheet skal som minimum indeholde de oplysninger som medtages i Digitaliseringsstyrelsens til enhver tid anbefalede stylesheet 3. Der Kommentar [F2]: Liste over mulige PIR: tilretning forsøgt 3 Digitaliseringsstyrelsens Stylesheets findes her: Side 34 af 95

35 skal desuden være yderlige tiltag i forhold til overskuelighed og læsbarhed (ØK) 2A Processerne der dækkes af ovenstående krav (2A A og 2A A )er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Indlæsning af elektroniske fakturaer i IFS i underbilag 2B (PK) 2A A A A A A Processerne der dækkes af krav 2A A og 2A A Eventuelle yderligere funktioner der understøtter Indlæsning af elektroniske fakturaer i IFS] Funktionalitet vedrørende Indlæsning af elektroniske fakturaer er yderligere kravsat i Use case i underbilag X. Tilknytning af elektroniske fakturaer til ordrer og automatisk routning af elektroniske fakturaer I det følgende beskrives regelsættet for, hvorhen en elektronisk modtaget faktura skal routes, samt krav til tilknytning af en modtaget elektronisk faktura til en ordre IFS skal ved modtagelse af fakturaer automatisk forsøge at tilknyttet fakturaen til en åben ordre på baggrund af leverandør identifikatorer og angivet ordrenummer på fakturaen (MK) Når en faktura modtages i en organisation i IFS, skal fakturaen automatisk routes til den relevante bruger, hvis fakturaen ikke automatches med en ordre (PK) Hvis fakturaen kan tilknyttes en ordre, men ikke automatches, skal fakturaen automatisk routes til indkøberen på ordren, med mindre indkøberen er spærret, ikke (længere) har rettigheder til at behandle fakturaer eller lignende (ØK) Hvis fakturaen ikke kan tilknyttes en ordre skal fakturaen automatisk routes til en bruger der matcher personreferencen på fakturaen, medmindre brugeren er spærret, ikke har rettigheder til at behandle fakturaer eller lignende (ØK) Hvis fakturaen ikke kan routes til en specifik bruger ud fra en ordrereference eller en personreference, skal fakturaen routes til en fakturafordeler, eller fakturafordeler skal på anden vis blive opmærksom på at der er modtaget en faktura som skal behandles (PK) Kommentar [F3]: INGEN SPECIFIK USECASE vi kan evt. genbruge et nr. da vi har flere cases hvor der indlæses fakturaer Side 35 af 95

36 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Tilknytning af elektroniske fakturaer til ordrer og automatisk routning af elektroniske fakturaer i IFS i underbilag 2B (PK) 2A A A A A A A A Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Tilknytning af elektroniske fakturaer til ordrer og automatisk routning af elektroniske fakturaer i IFS] Funktionalitet vedrørende Tilknytning af elektroniske fakturaer til ordrer og automatisk routning af elektroniske fakturaer er yderligere kravsat i Use case XX i underbilag 2C Oprettelse af manuelle fakturaer Brugerinstitutionerne kan have behov for at oprette manuelle fakturaer i IFS, typisk fordi udenlandske leverandører, der ikke er omfattet af dansk lov, sender fakturaer med papirpost Det skal være muligt at oprette manuelle fakturaer i systemet, på baggrund af modtagne papirfakturaer (MK) Det skal være nemt at afgrænse, hvilke brugere der kan oprette manuelle fakturaer i systemet, så det fx kun er brugere med rollen fakturafordeler, der kan oprette manuelle fakturaer, eller så retten til at oprette manuelle fakturaer er en separat systemrolle, der kan tildeles en bruger (ØK) En bruger skal nemt kunne oprette manuelle fakturaer ud fra skabeloner eller lignende i systemet (PK) Som en del af processen for oprettelse af manuelle fakturaer skal det være obligatorisk at brugeren vedhæfter en indscannet kopi af originalfakturaen, som ikke efterfølgende kan slettes (ØK) Processen for oprettelse af manuelle fakturaer skal være klart adskilt fra workflowet for varemodtagelse og godkendelse af fakturaer, så felter låses for redigering når oprettelsen færdiggøres, svarende til hvad der er gældende for en elektronisk modtaget faktura (PK) Under oprettelsen af en manuel faktura, skal brugeren nemt kunne gemme sit arbejde som en kladde, således at han kan afbryde oprettelsen og senere vende tilbage og færdiggøre den (ØK) Brugeren der har oprettet en manuel faktura skal nemt kunne slette fakturaen/kladden igen, hvis fakturaen ikke er blevet godkendt, så det unikke Kommentar [F4]: Ingen use case som passer rigtig godt Side 36 af 95

37 2A A A A A A A A dokumentid kan genanvendes på en ny mauelt oprettet faktura i IFS, fx hvis brugeren bliver opmærksom at der er sket en fejl ved oprettelsen af fakturaen (ØK) IFS skal understøtte nem oprettelse og behandling af fakturaer fra udenlandske leverandører i systemet. Alle valide valutakoder og komplette og ukomplette betalingsformer som kan anvende både indenfor EU og udenfor EU, skal understøttes i IFS (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive en udtømmende liste over de valutaer og betalingsformer som IFS understøtter jf. krav 2A , samt løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Oprettelse af manuelle fakturaer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Liste over samtlige valutaer og betalingsformer som understøttes af IFS jf. krav 2A Eventuelle yderligere funktioner der understøtter Oprettelse af manuelle fakturaer i IFS] Funktionalitet vedrørende Oprettelse af manuelle fakturaer er yderligere kravsat i Use case 13 i underbilag 2C. Fakturabehandling, generelt I det følgende beskrives krav, der er generelle for behandling af fakturaer med eller uden tilknyttede ordrer. IFS skal understøtte varemodtagelse, kontering og godkendelse af elektroniske fakturaer og manuelt oprettede fakturaer (MK) En bruger med tilstrækkelige rettigheder skal manuelt kunne tilknytte en faktura til en ordre (MK) En bruger med tilstrækkelige rettigheder skal nemt kunne frakoble fakturaer og ordrer. Frakobling må ikke medføre at godkendte dokumenter genåbnes (PK) Sammenkoblingen af faktura og ordre skal nemt kunne varetages af flere brugere så længe fakturaen er undervejs i flowet (PK) En bruger må ikke kunne redigere i betalingsoplysningerne på en elektronisk modtaget faktura eller på en færdigoprettet manuel faktura (MK) Kommentar [F5]: PIR: betalingsformer er allerede dækket af krav 2A JMH: Ja, men der er betalingsformer vi skal håndtere som ikke kan håndteres naturligt i UBL, det aspekt skal vi have med. Kommentar [F6]: Til PIR,. vi skal eksplicit bede om at få opgivet hvilke valutaer og betalingsformer der understøttes i løsningsbeskrivelsen JMH: Se ovenstående Side 37 af 95

38 2A A A A A A En bruger må ikke kunne redigere i fakturaens totale pålydende (inkl. skatter og afgifter) på en elektronisk modtaget faktura eller på en færdigoprettet manuel faktura (MK) En faktura må kun kunne godkendes, hvis varen eller ydelsen er registreret som varemodtaget (MK) Godkendelsen af en faktura i IFS, skal være uafhængig af om leverandøren er oprettet i Navision Stat (PK) Hvis en faktura godkendes og sendes til Navision Stat uden at leverandøren er oprettet og overført til IFS, skal fakturaen automatisk kobles til leverandøren i IFS, når leverandøren efterfølgende overføres fra Navision Stat til IFS (ØK) Godkendte fakturaer skal automatisk overføres til Navision, hvor de bogføres og udsøges til betaling (MK) Processerne der dækkes af ovenstående krav (2A A og 2A A ) er løsningsbeskrevet i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A A ] Funktionalitet vedrørende Fakturabehandling, generelt, er yderligere kravsat i Use case 15 i underbilag 2C. 2A Fakturabehandling af fakturaer uden tilknyttede ordre I dag modtages langt de fleste fakturaer uden at der forinden er afgivet en elektronisk ordre ( almindelige fakturaer ). Selvom det forventes, at der fremover vil ske en stigning i afgivelsen af elektroniske ordrer, vil almindelige fakturaer stadig udgøre en væsentlig andel af transaktionerne. Det er derfor vigtigt, at IFS understøtter en effektiv og enkel håndtering af fakturaer som ikke er tilknyttet en ordre. 2A A A En fakturafordeler eller en rekvirent skal nemt kunne kontere en faktura helt eller delvist samt angive en eller flere disponenter på fakturaen (PK) Fakturaen skal nemt kunne varemodtages af en rekvirent jf. kravene i afsnit 2A.5.9 (PK) Når fakturaen er fuldt varemodtaget skal den automatisk sendes til godkendelse hos den eller de angivne disponenter (PK) Side 38 af 95

39 2A A A A En disponent skal nemt kunne redigere og færdiggøre konteringen af de dele af fakturaen der er sendt til godkendelse hos disponenten (PK) En Disponent skal let kunne godkende eller afvise de dele af en faktura der er sendt til godkendelse hos den pågældende disponent (MK) Når alle disponenterne har godkendt deres del af fakturaen, skal fakturaen automatisk ændre status og afsendes til Navision Stat (PK) Processerne der dækkes af ovenstående krav (2A A og 2A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Fakturabehandling af fakturaer uden tilknyttede ordre i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A Eventuelle yderligere funktioner der understøtter anvendelse af Fakturabehandling af fakturaer uden tilknyttede ordre i IFS] Funktionalitet vedrørende Fakturabehandling af fakturaer uden tilknyttede ordre er yderligere kravsat i Use case 18 i underbilag 2C. 2A Fakturabehandling af fakturaer med tilknyttede ordre I det følgende beskrives krav der er generelle for behandling af fakturaer med tilknyttede ordrer. 2A A A A Hvis en faktura tilknyttes en ordre, skal IFS afgøre om der er match mellem oplysningerne på ordren og fakturaen (MK) Matchet skal kunne ske, hvis leverandør identifikatorer, angivet ordrenummer samt beløb på ordre og faktura, alle er identiske, på ordre og faktura, eller inden for en opsat afvigelsestolerance jf. afsnit 2A (PK) Matches faktura og ordre skal IFS kontrollere, om varen er varemodtaget. Såfremt dette er tilfældet, skal den matchede faktura automatisk godkendes og videresendes til økonomisystemet til bogføring og betaling, medmindre automatch er fravalgt på ordren eller i organisationsenheden (MK) IFS skal kunne automatche ved delfakturering, der ikke dækker den fulde ordre (ØK) Side 39 af 95

40 2A A Er der ikke registreret tilstrækkelig varemodtagelse for ordren, afventes dette, før den matchede faktura automatisk videresendes til bogføring og betaling (PK) Hvis en faktura automatisk eller manuelt tilknyttes en ordre, men der ikke er match mellem dokumenterne, skal IFS tydeligt orientere den relevante bruger om dette, samt angive årsagen til det manglende match, og orientere brugeren om, hvilke handlinger, der skal foretages (ØK) 2A Processerne der dækkes af ovenstående krav (2A og 2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Fakturabehandling af fakturaer med tilknyttede ordre i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A og 2A A Eventuelle yderligere funktioner der understøtter Fakturabehandling af fakturaer med tilknyttede ordre i IFS] 2A A Funktionalitet vedrørende Fakturabehandling af fakturaer med tilknyttede ordre er yderligere kravsat i Use case XX i underbilag 2C. Særligt om match af fakturaer med stående ordrer En stor del af de fakturaer, der modtages af de offentlige myndigheder vedrører stående ordrer (abonnementer, forsyningsaftaler mv.), hvor kreditoren og aftalegrundlaget er kendt på forhånd, men hvor størrelsen af den enkelte faktura ikke på forhånd kendes eksakt. I mange tilfælde vil myndigheden ikke have mulighed for at påvirke beløbsstørrelsen, og det er derfor et stort ønske fra myndighedernes side, at disse fakturaer i videst mulige udstrækning kan håndteres automatisk. Eksempler på automatiseret håndtering af stående ordrer kan være at man i stedet for at matche på et ordrenummer matcher på andre kriterier som fx abonnementsnummer, kundenummer el. lign. Samtidig vil det være ønskeligt, at der kan sættes kriterier op for hvornår automatch accepteres. Det kan fx være inden for faste beløbsintervaller (hvis der er tale om en fast opkrævning, á conto-opkrævninger mv.) og/eller at fakturaen skal modtages i et særligt datointerval, så fakturaer fx kun behandles automatisk i en 2-ugers periode pr. kvartal. IFS skal understøtte automatisk matchning af fakturaer og stående ordrer, dvs. ordrer hvor der ikke er afgivet individuelle indkøbsordrer for de modtagne fakturaer, og hvor der evt. ikke varemodtages på de stående ordrer, og match Kommentar [F7]: INGEN SPECIFIKKE USE CASES FOR MATCH JMH: Ok. Så længe det er et element i nogle use cases, vi kan referere til disse. Side 40 af 95

41 derfor skal ske ud fra andre kriterier, fx kundenummer, abonnementsnummer eller lignende (PK) 2A A IFS skal nemt understøtte muligheder for at afgrænse matchningen, fx så match kun sker inden for fastsatte økonomiske intervaller eller datointervaller (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Match af fakturaer med stående ordre i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Match af fakturaer med stående ordre i IFS] Funktionalitet vedrørende Match af fakturaer med stående ordre er yderligere kravsat i Use case 10 i underbilag 2C. 2A Særligt om match af fakturaer med rabat, afgifter mv. I en række tilfælde vil fakturaer indeholde diverse rabatter, gebyrer, afgifter mv. Dette kan give anledning til vanskeligheder med at matche ordrer og fakturaer automatisk, da ordren sjældent vil indeholde de samme gebyrer mv. som fakturaen, og det samlede fakturabeløb derfor ikke svarer til ordrebeløbet. I OIOUBL-standarden er det muligt at angive afgifter mv. i særlige felter i den tekniske standard, således at fakturaen indeholder en pris for selve de leverede varer/ydelser og en yderligere specifikation af AllowanceCharge elementer (rabatter og gebyrer) og Tax elelementer (skat, afgifter, moms). Det bør være muligt at matche faktura og ordre ud fra hovedydelsen og evt. sætte kriterier op for automatisk godkendelse AllowanceCharge og Tax elementer. 2A A A IFS skal understøtte automatisk behandling af fakturaer med AllowanceCharge og Tax elementer (ØK) IFS skal understøtte en nem opsætning af intervaller for automatisk godkendelse af AllowanceCharge og Tax elementer (ØK) IFS skal understøtte mulighederne for automatisk kontering af AllowanceCharge elementer på header-niveau, se også krav XX. (ØK) Side 41 af 95

42 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Match af fakturaer med rabat, afgifter mv. i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Match af fakturaer med rabat, afgifter mv. i IFS] Funktionalitet vedrørende Match af fakturaer med rabat, afgifter mv. er yderligere kravsat i Use case 14 og Use case 16 i underbilag 2C. 2A.5.11 Generelt om anvendelse af IFS, dokumentbehandling og kontering I dette afsnit er der beskrevet en række generelle krav til hvad der skal gælde for brugeres anvendelse af IFS herunder generelle krav til behandling af alle typer af forretningsdokumenter og generelle krav til kontering i IFS. 2A A A A Kun de funktioner, værdier og forretningsdokumenter, som er relevante for en bruger, givet brugerens rettigheder, skal være synlige for brugeren i systemet (PK) Data i IFS skal præsenteres struktureret, tydeligt og ensartet for brugerne, så brugerne let kan orientere sig og navigere i systemet (PK) En bruger skal kun have mulighed for at vælge relevante brugere og værdier ved behandling og distribution af forretningsdokumenter i systemet, det må fx ikke være muligt at vælge en spærret dimensionsværdi ved kontering eller at sende en transaktion til godkendelse hos en bruger der enten er spærret, eller ikke har disponent rollen, eller ikke har tilstrækkelig prokura til at godkende transaktionen (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrevet i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A ] 2A Værktøjer til fakturafordelerrollen En fakturafordeler har til opgave, at sikre at alle dokumenter i en eller flere organisationsenheder behandles rettidigt, og at sikre at eventuelle problemer i et dokumentflow undersøges og udbedres. 2A Der skal stilles værktøjer til rådighed, således at fakturafordeleren kan følge op på åbne forretningsdokumenters status og tilhørsforhold inden for Side 42 af 95

43 fakturafordelerens domæne, fx oversigter over alle ubehandlede fakturaer, kreditnotaer mm., i brugerinstitutionen eller inden for flere brugerinstitutioner på én gang (PK) 2A A Fakturafordelerens opfølgning og håndtering af dokumenter i IFS, skal være understøttet af nem og omfattende funktionalitet, så en fakturafordeler kan gennemføre sine opgaver i systemet hurtigt og effektivt (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Værktøjer til fakturafordelerrollen i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Værktøjer til fakturafordelerrollen i IFS] Funktionalitet vedrørende Værktøjer til fakturafordelerrollen er yderligere kravsat i Use case 1 i underbilag 2C. 2A Egne dokumenter I IFS skal dokumenter kunne sendes til en bruger til behandling. Dokumenter en bruger har oprettet, dokumenter som er allokeret til en bruger, og dokumenter som en bruger har ændret betegnes her samlet som brugerens egne dokumenter. 2A A A A Hvis en bruger opretter et forretningsdokument, skal dette gemmes som en kladde indtil der foretages en forpligtende handling. Det skal være muligt at slette oprettede kladder (ØK) En bruger skal nemt kunne få et overblik over dokumenter der ligger til behandling hos brugeren, i systemet (PK) Brugerne af systemet skal nemt kunne se deres egne dokumenters status, herunder også færdigbehandlede dokumenter, så brugeren hurtigt og effektivt kan identificere handlingsbehov for dokumenterne, fx i tilfælde af at et dokument ikke godkendes rettidigt (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter behandling af Egne dokumenter i IFS i underbilag 2B (PK) Side 43 af 95

44 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter behandling af Egne dokumenter i IFS 2A Samtidige operationer på forretningsdokumenter Det kan ske at mere end en bruger forsøger at tilgå og behandle et dokument samtidigt. Det kan i nogle tilfælde være acceptabelt, fx hvis forskellige disponenter ønsker at godkende forskellige linjer på et dokument samtidigt. Men det skal ikke være muligt, at to brugere forsøger at redigere de samme dele af et dokument simultant, ligesom en bruger ikke må kunne redigere oplysninger på et dokument som påvirker en anden brugers igangværende arbejde på dokumentet, uden at den anden bruger bliver gjort opmærksom på de konkrete ændringer. 2A A A A A A Hvis mere end en bruger forsøger at åbne og/eller redigere et dokument på en gang, skal IFS sikre hensigtsmæssig afgrænsning af brugernes rettigheder til at redigere dokumentet, så den ene brugeres arbejde i dokumentet ikke kan påvirke den anden brugers arbejde i dokumentet uhensigtsmæssigt (PK) IFS 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 (2A )er løsningsbeskrevet i underbilag 2B Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Samtidige operationer på forretningsdokumenter i IFS i underbilag 2B (PK) [Tilbudsgiver skal i underbilag XX redegøre for følgende: 1. Processerne der dækkes af krav 2A Eventuelle yderligere funktioner der understøtter samtidige operationer på forretningsdokumenter i IFS] Særligt om brugere med flere funktionsroller Når en bruger arbejder på et dokument skal IFS automatisk tage hensyn til og tilpasse workflowet, hvis brugeren har flere forskellige funktionsroller En bruger skal nemt kunne gennemføre et helt dokumentflow i systemet, hvis brugeren har tilstrækkelig prokura og rettigheder (PK) IFS skal i dokumentflowet tage højde for om en bruger har flere roller. Brugeren skal nemt kunne gennemføre alle de dele af flowet som brugeren har rettigheder til, uden at brugeren skal fremsende dokumentet til sig selv, eller på anden måde foretage overflødige operationer i systemet. Det skal fx være muligt at varemodtage og godkende en faktura i én handling, hvis brugeren har tilstrækkelige rettigheder og prokura (PK) Kommentar [F8]: Er der behov for forklaringer her? Side 44 af 95

45 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Brugere med flere funktionsroller i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Brugere med flere funktionsroller i IFS] Funktionalitet vedrørende Brugere med flere funktionsroller er yderligere kravsat i Use case 11 i underbilag 2C. 2A Lukning, afvisning og genåbning af forretningsdokumenter Det kan ske at, der opstår fejl i et indkøbsflow der gør at et dokument ikke skal færdigbehandles, fx, hvis et indkøbsforløb afbrydes uden at varen leveres, eller hvis en vareleverandør kommer til at sende et forretningsdokument til en forkert modtager. IFS skal indeholde funktionalitet der gør det muligt at håndtere fejlscenarier, så systemet ikke forurenes med åbne forretningsdokumenter der aldrig kan færdigbehandles 2A A A A A A Alle ikke-godkendte dokumenter skal nemt kunne lukkes/afvises, og genåbnes i systemet (handlingerne skal fremgå af dokumenternes transaktionsspor) (PK) Det skal kunne afgrænses hvilke bruger der har rettigheder til at lukke/afvise og genåbne dokumenter, så funktionen fx kun er tilgængelig for fakturafordelere (ØK) Ved afvisning af et dokument, modtaget fra en vareleverandør, skal systemet sende en besked om at dokumentet er blevet afvist til vareleverandøren, hvis brugeren der afviser dokumentet ønsker det. Det skal være muligt at angive en årsag til hvorfor dokumentet afvises, som medsendes afvisningsbeskeden (ØK) Det skal være nemt at udsøge en gruppe af dokumenter og lukke dem samtidigt, uden at man behøver at tilgå det enkelte dokument, så det fx er muligt at lukke alle åbne ordrer hvor leveringsdatoen er overskredet med mere end 3 måneder fra en samlet oversigt (ØK) Ved masselukning af dokumenter, skal det være nemt at vælge alle udsøgte dokumenter på en gang og derefter fravælge enkelte dokumenter inden de resterende dokumenter lukkes én enkelt operation (ØK) Godkendte dokumenter må ikke kunne genåbnes eller redigeres yderligere af en bruger i IFS, der er dog angivet undtagelser til denne regel i krav 2A og i krav 2A om annullering af ordrer (PK) Kommentar [F9]: Jeg har flyttet kravet, referencen skal opdateres Side 45 af 95

46 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Lukning, afvisning og genåbning af forretningsdokumenter i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Lukning, afvisning og genåbning af forretningsdokumenter i IFS] Funktionalitet vedrørende Lukning, afvisning og genåbning af forretningsdokumenter er yderligere kravsat i Use case 20 i underbilag 2C. 2A Distribution af forretningsdokumenter I det følgende er det beskrevet, hvordan ikke-godkendte forretningsdokumenter kan sendes mellem brugere i IFS. Godkendte forretningsdokumenter er pr. definition ikke allokeret til en bruger og kan derfor ikke sendes til en bruger. 2A A A A A A Hvis en specifik vareleverandør sender et dokument til et regnskab i IFS, hvor der allerede findes et dokument fra den samme vareleverandør med samme dokumentid (og versionsnummer fsva kataloger), skal IFS automatisk afvise dokumentet og sende en sigende fejlbesked til vareleverandøren enten i OIOUBL formatet eller som en , hvis vareleverandøren ikke er i stand til at modtage en afvisning i OIOUBL formatet (PK) Alle brugere skal nemt kunne videresende et ikke godkendt forretningsdokument til en anden bruger med tilstrækkelige rettigheder indenfor deres egen brugerinstitution (dvs. inden for det opstillede domæne, brugeren er en del af) (PK) En bruger skal nemt kunne sende dokumenter, der endnu ikke er godkendte, mellem regnskaber som brugeren har rettigheder til (ØK) En bruger skal nemt kunne returnere et dokument til den bruger der har fremsendt dokumentet til brugeren. Brugeren skal kunne angive en kommentar som en del af denne proces (MK) En bruger skal altid kunne sende et ikke godkendt forretningsdokument til en fakturafordeler (ØK) En fakturafordeler skal altid kunne videresende et ikke godkendt dokument fra en bruger til anden bruger, uanset om dokumentet er sendt retur til fakturafordeleren eller ej (PK) Side 46 af 95

47 2A A A A A Videresendelse af dokumenter til en anden bruger skal kunne gennemføres uden at brugeren behøver at åbne de pågældende dokumenter, så dokumenter fx kan fremsendes direkte fra en oversigt (ØK) En bruger skal nemt kunne videresende flere dokumenter til en anden bruger på en gang, fx fra et oversigtsbillede (ØK) Et dokument, der kan varemodtages, skal nemt kunne sendes til delvaremodtagelse hos flere forskellige rekvirenter (PK) Et dokument, der kan godkendes, skal nemt kunne sendes til del-godkendelse hos flere forskellige disponenter (PK) Processerne der dækkes af ovenstående krav (2A A og 2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Distribution af forretningsdokumenter i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Distribution af forretningsdokumenter i IFS] Funktionalitet vedrørende Distribution af forretningsdokumenter er yderligere kravsat i Use case 17 i underbilag 2C. 2A Adviser og fejlmeddelelser Når en bruger modtager et forretningsdokument i IFS er det nødvendigt, at brugeren bliver gjort opmærksom på, at der er allokeret et dokument til brugeren som kræver handling. For brugere der kun sjældent logger ind i IFS er det hensigtsmæssigt, at IFS automatisk sender en advisering til brugeren, når der bliver allokeret et nyt forretningsdokument til brugeren, eller når en anden bruger foretager en væsentlig handling på et dokument som brugeren har et tilhørsforhold til. IFS skal desuden generere fejlmeddelelser, hvis en bruger forsøger at gennemføre en handling, som ikke er understøttet af dokumentflowet og/eller brugerens rettigheder. Under afsnit XX vedrørende systemkonfiguration er der angivet en række yderligere krav til adviser og fejlmeddelelser. 2A Systemet skal automatisk generere -adviser når det er relevant (fx når et dokument allokeres til en bruger eller hvis en bruger skal mindes om behandlingen af et dokument) (PK) Side 47 af 95

48 2A A A A Det skal være nemt for en Disponent at godkende et dokument direkte fra et advis, der indeholder alle relevante oplysninger om dokumentet, således at disponenten ikke behøver at logge på IFS for at godkende dokumenter (ØK) Hvis en et dokument forsøges godkendt via en advis skal IFS berigtige, at det er disponenten, der godkender dokumentet, fx gennem en single-signon integration eller ved et password prompt (ØK) Hvis en bruger forsøger at gennemføre en handling som ikke er understøttet af dokumentflowet, eller som brugeren ikke har rettigheder til at udføre, skal Systemet automatisk generere (fejl)meddelelser, som kan bistå brugeren i problemløsningen. Meddelelserne skal være letforståelige og skal vejlede brugeren (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Adviser og fejlmeddelelser i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Adviser og fejlmeddelelser i IFS] 2A Noter og vedhæftede filer I forbindelse med behandlingen af forretningsdokumenter i IFS kan det være nødvendigt at en bruger tilføjer forklarende tekst eller dokumentation til et dokument, så andre aktører der skal behandle dokumentet bliver vejledt i deres håndtering af dokumentet. Der sondres i denne kravspecifikation mellem interne noter, der kun må kunne ses af brugere af IFS, og eksterne noter der skal fremgå af et dokument når det sendes fra IFS til et andet system eller en vareleverandør 2A A A En bruger skal nemt kunne tilføje interne noter på alle forretningsdokumenter, dvs. noter til andre brugere af IFS, så en indkøber fx kan skrive en forklarende tekst på et dokument til en disponent (PK) På alle forretningsdokumenter, der kan sendes fra IFS til vareleverandører skal en bruger nemt kunne tilføje eksterne noter dvs. noter til vareleverandører, fx jf. aftale af d.d., ønsket leveret efter 12, efter aftale med NN og lignende (PK) Interne noter skal ikke kunne ses af brugere udenfor brugerinstitutionen. Eksterne noter skal kunne ses af såvel de interne brugere (rekvirent, indkøber, disponent m.fl.) som eksterne parter (dvs. vareleverandøren) (PK) Side 48 af 95

49 2A A A A A A A A A A Noter skal kunne angives i et fritekstfelt af passende størrelse, der fsva. eksterne noter tager højde for begrænsningerne i OIOUBL standarden (ØK) Interne noter må ikke kunne slettes når dokumentet er routet videre, fra brugeren der har angivet noten (ØK) Eksterne noter må ikke kunne slettes når dokumentet er routet videre fra IFS til et andet system eller en vareleverandør (ØK) For alle noter skal det automatisk logges og være tydeligt, hvem der har angivet noten og hvornår noten er tilføjet (ØK) Interne noter på et dokument, skal automatisk fremgå i de adviseringsmails, der sendes til brugere som får tildelt dokumentet (ØK) Systemet skal kunne opsættes således, at brugere ved visse handlinger, fx ved ordreannullering eller når et dokument returneres til en fakturafordeler, promptes til at skrive en obligatorisk note på dokumentet, inden handlingen kan udføres (ØK) Det skal være muligt at vedhæfte en eller flere filer til alle forretningsdokumenter (PK) Funktionaliteten for vedhæftning af filer til et forretningsdokument, skal tage højde for begrænsningerne som følger af den gældende OIOUBL standard, og tydeligt orientere brugerne om disse (ØK) Vedhæftede filer skal automatisk medsendes et forretningsdokument der sendes fra IFS til en anden aktør. Fx så en indscannet originalfaktura medsendes en manuelt oprettet faktura, når den manuelle faktura bliver godkendt og fremsendt til Navision (PK) Processerne der dækkes af ovenstående krav (2A A , 2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Noter og vedhæftede filer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A , 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Noter og vedhæftede filer i IFS] Funktionalitet vedrørende Noter og vedhæftede filer er yderligere kravsat i Use case 4, Use case 13 og Use case 22 i underbilag 2C. Side 49 af 95

50 2A Berigelse af forretningsdokumenter, godkendelse af forretningsdokumenter og transaktionsspor I forbindelse med dokumentbehandling i IFS, vil en eller flere brugere ofte skulle berige et forretningsdokument med information, fx angivelse af aktører på dokumentet, leveringsadresser, datoer og sigende posteringstekster. Kontering af et forretningsdokument er også berigelse, men kravene til kontering er angivet separat under afsnit XXX Kontering generelt, i denne kravspecifikation. 2A A A A A A A A Når en bruger vil berige et dokument, skal IFS på baggrund af brugerens opsætning og egenskaber automatisk angive forslagsværdier til fx indkøber, disponent, leveringsadresse, kontering, leveringsdato og bekræftelsesdato (PK) Alle brugere med rette adgang skal have mulighed for nemt at redigere de relevante felter i et dokument, herunder felter hvor der er angivet forslagsværdier, indtil dokumentet er godkendt, uanset hvornår i processen dokumentet modtages eller tilgås (PK) IFS skal automatisk angive et sigende forslag til posteringstekster på linjerne på et forretningsdokument, det kan fx som udgangspunkt være varebeskrivelsen (ØK) En bruger med tilstrækkelige rettigheder skal nemt kunne ændre posteringsteksten på en linje på et forretningsdokument, med henblik på at sikre retvisende bogføringsoplysninger i Navision, det kan fx være relevant, hvis en vareleverandørs varebeskrivelse ikke er tilstrækkeligt udspecificeret (PK) Oplysninger på dokumentlinjer, som kan redigeres, skal nemt kunne redigeres for flere dokumentlinjer af gangen, så alle dokumentlinjer på en faktura fx kan beriges med den samme posteringstekst på en gang, eller så en disponent kan anføres på flere forskellige linjer på en gang (PK) Når en bruger godkender et dokument eller dele af et dokument, skal systemet kontrollere om brugeren har tilstrækkelig prokura, inden godkendelsen gennemføres eller afvises af systemet (MK) IFS skal gemme et transaktionsspor på hvert dokument, hvor alle relevante handlinger der er foretaget på dokumentet tydeligt fremgår. Det skal tydeligt fremgå, hvilken handling der er tale om, hvem der har foretaget handlingen, hvornår handlingen er foretaget og om handlingen er udført på en anden brugers vegne med stedfortræderfunktionen (PK) Alle varemodtagelseshandlinger og godkendelseshandlinger på et dokument skal fremgå af transaktionssporret (MK) Kommentar [F10]: Vi skal bede om at få beskrevet hvilke handlinger der logges, hvordan de logges og hvordan de kan tilgås Kommentar [F11]: Endvide re kan det overvejes i hvilket omfang det bør logges andetsteds (ikke på dokumentniveau), hvem der logger ind i systemet, hvornår, og hvad de foretager sig. (ikke funktionelt krav) Side 50 af 95

51 2A A A A A Tjenesteyder bedes løsningsbeskrive samtlige handlinger der logges i systemet, herunder hvordan de logges og hvordan informationen bliver tilgængelig for de forskellige aktører i systemet (PK) En bruger der står på et dokument skal kunne se eller tilgå transaktionssporet for forretningsdokumentet (PK) Processerne der dækkes af ovenstående krav (2A A og 2A )er løsningsbeskrevet i underbilag 2B Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Berigelse af forretningsdokumenter, godkendelse af forretningsdokumenter og transaktionsspor i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A Eventuelle yderligere funktioner der understøtter anvendelse af Berigelse af forretningsdokumenter, godkendelse af forretningsdokumenter og transaktionsspor i IFS] Funktionalitet vedrørende Berigelse af forretningsdokumenter, godkendelse af forretningsdokumenter og transaktionsspor er yderligere kravsat i Usecase 19 i underbilag 2C. Samspil med Navision Stat Fakturaer, kreditnotaer, rykkere og kontoudtog overføres efter godkendelse i IFS til Navision Stat, hvor dokumenterne skal accepteres, bogføres og betales. Det enkelte dokument behandles altså yderligere i Navision Stat, hvorfor det kan være relevant at et dokument i IFS, efter at dokumentet er sendt til Navision Stat, kan blive opdateret med en række oplysninger fra Navision Stat, fx om dokumentets status i Navision Stat. Ved overførsel til Navision Stat skal det være muligt, i IFS, kun at oprette én posteringslinje for det samlede dokument, eller en linje pr. konteringskombination, hvis der er flere forskellige linjekonteringer på dokumentet (Skal nok slettes) (ØK) 2A A Når et dokument forsøges overført fra IFS til Navision Stat skal dokumentet i IFS automatisk opdateres med oplysninger fra de tekniske Application Responses som tydeligt viser om dokumentet er afleveret korrekt eller om overførslen er fejlet (ØK) 2A A Det skal være nemt for globale og lokale systemadministratorer at trække oversigter over dokumenter der er hhv. forsøgt sendt til Navision Stat, afleveret korrekt til Navision Stat og fejlet i overførslen til Navision Stat (PK) Kommentar [F12]: Se kommentar ovenfor Kommentar [F13]: Årsag aktindsigt, nemt at finde fakturaer igen hvad skal være en alternativ løsning? (JMH: ofte er det vist leverandørnavn og CVR nummer der angives) Men hvad siger Statens Indkøb egentlig til dette, da det jo betyder at de ikke længere kan se det reelle indhold i fakturaen og dermed kan de ikke se om aftalerne er overholdt? JMH: Jeg syntes at det er et dårligt krav (det smadrer data), der bør i stedet ses på krav vedrørende redigering af oplysninger på flere linjer på en gang, og evt. på rapporteringsmulighederne i NS KKP Enig forstår ikke hvor aktindsigt kommer ind fordi der er mange linjer i en faktura. JMH: Behovet for at trække konsolideret data på Leverandørnavn, CVR nummer og konteringsværdier, kan både dækkes af rapporteringsmulighederne i Statens Datavarehus, og af en Navision Stat Rapport ( Vendor GLAcc Dim. Posting), der er udviklet til netop dette formål, Kravet er derfor slettet. Kommentar [F14]: KKP Der kan kun forventes teknisk applicationresponse, når deres eget afsendelsessystem mener at forsendelsen bør være gået godt. Side 51 af 95

52 2A A Hvis der for et godkendt dokument afsendt til Navision Stat modtages en ApplicationResponse, hvoraf det fremgår at dokumentet er blevet accepteret i Navision Stat (positiv forretningskvittering), skal dokumentet automatisk opdateres med oplysninger som tydeligt viser at dokumentet er accepteret i Navision Stat (ØK) 2A A Hvis der for et godkendt dokument afsendt til Navision Stat modtages en ApplicationResponse, hvoraf det fremgår at dokumentet er blevet afvist i Navision Stat (negativ forretningskvittering), skal dokumentet automatisk genåbnes i IFS, beriges med eventuelle oplysninger fra ApplicationResponsen om årsagen til afvisningen, og distribueres til den eller de relevante bruger(e), med henblik på fornyet behandling og godkendelse. (PK) 2A A Det skal være nemt for globale og lokale systemadministratorer at trække oversigter over dokumenter der er hhv. accepteret i Navision Stat, afvist i Navision Stat eller afleveret korrekt til Navision Stat, men endnu ikke accepteret eller afvist i Navision Stat (PK) 2A A IFS skal kunne modtage transaktionsdata fra Navision Stat, og automatisk opdatere forretningsdokumenterne med oplysninger om betalingsstatus (ikke betalt, helt betalt eller delvist betalt), jf. kravene i afsnit 2A (PK) 2A A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Samspillet med Navision Stat i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Samspillet med Navision Stat i IFS] 2A A A Kontering generelt Kontering i IFS skal ske med udgangspunkt i konteringsværdier fra en finansog dimensionskontoplan overført fra Navision Stat regnskaber. I det følgende refereres der til en række Navision stat konteringsværdier, og regelsæt, som er beskrevet yderligere i afsnit 2A vedrørende integrationer. Konteringen skal udføres med det enkelte regnskabs stamdata overført fra Navision Stat (MK) Det skal være muligt at angive header-kontering på et forretningsdokument, dvs. en konteringsstreng der gælder for alle linjerne på forretningsdokumentet (MK) Kommentar [F15]: KKP hvad blev der af Konteringselementer. Beskrivelsen er ikke bred nok, men skal her vel netop være helt generel. Side 52 af 95

53 2A A A A A A A A A A A Det skal være muligt at ændre en angivet konteringsværdi indtil forretningsdokumentet er godkendt (MK) Det må ikke være muligt at godkende et dokument med en eller flere ugyldige konteringsstrenge, herunder, hvis en eller flere linjer eller AllowanceCharge elementer ikke er konteret. (PK) Ved kontering skal en bruger kunne angive/søge efter en ønsket konteringsværdi ud fra enten værdien eller navnet, alt efter brugerens præferencer, dvs. der skal kunne søges ud fra fx DimVærdi og DimVærdiNavn (PK) Hvis konteringen for et eller flere felter på en eller flere linjer, skal have en afvigende kontering fra header-konteringen, skal det være muligt for en bruger, at angive afvigelsen alene ved at rette i de felter på de relevante linjer som skal have en afvigende kontering (PK) Posteringslinjer skal kunne opsplittes i to eller flere konteringslinjer, der skal kunne konteres separat, så udgiften belaster forskellige dele af regnskabet. Når en ordre sendes til en vareleverandør skal linjer der er opsplittet til konteringslinjer ikke sendes opsplittet til vareleverandøren (PK) Posteringslinjer skal bl.a. kunne opsplittes i konteringslinjer procentvist, på antal eller på beløb (ØK) Når et dokument splitkonteres, skal systemet automatisk for hver linje angive et linje-id, så posteringerne kan styres i Navision Stat, jf. afsnit XXXX. (PK) Systemet skal understøtte automatiseret beslutningsstøtte for brugerne, fx ved hjælp af forslagskontering, konteringsskemaer, sidst benyttede værdier og bruger og enheds-specifikke begrænsninger mv. (PK) En lokal systemadministrator skal for et regnskab kunne opsætte, hvilke felter det er obligatorisk at kontere på, inden dokumentet kan godkendes, og det skal tydeligt fremgå for brugerne om en dimension er obligatorisk når brugeren konterer (PK) Ved kontering skal der kunne angives følgende værdier: en konto (enten en finanskonto, en varekonto eller en anlægskonto), momsproduktbogføringsgruppe, Alias (som afleder andre konteringsværdier), Sag, Sagsopgave (hvilke sagsopgaver der skal kunne vælges afhænger af hvilken sag der er valgt), et Budget og en Dimensionsværdi for hver Dimension der er overført fra Navision Stat (PK) IFS skal ved kontering understøtte kontering med dimensionsværdier i et antal dimensioner, der er defineret i de enkelte Navision Stat regnskab (PK) Kommentar [F16]: KKP En tom konteringsstreng kan naturligvis også forstås som ugyldig, men det er pt. ikke tænkt i fht Ugyldigekombinationer. Det må ikke være muligt at godkende dokument der mangler kontering alle beløb skal konteres (undtagen tax). Det må ikke være muligt at godkende et dokument som har en ugyldig konteringsstreng. Jeg mener det er to ting. Kommentar [F17]: KKP Opsplitningen af en ordrelinje i konteringslinjer er en intern information og er leverandøren uvedkommende. En ordrelinje sendes samlet til Vareleverandøren. Kommentar [F18]: Til NS, skal vi uddybe vedrørende linjeid? KKP Pt. bruger vi ikke faktura linje ID men mapper det til bemærkning af teknisk årsag. Vi benytter til gengæld pt. InvoiceLine/OrderLineRefere nce/lineid for at løsningen med Fakturalinje til Ordrelinje match kan ske i NS. Ved fordeling i NS udskiftes Navisions interne Linjenummer når en linje udfoldes med Navisions fordeling. Det viser hvilke linjer der hører sammen. Så, ideelt set vil vi gerne have noget lignende til brug for... Kommentar [F19]: KKP Er det tydeligt nok at det er vilkårligt mange dimensioner på hver linje? Side 53 af 95

54 2A A A A A A A A A A A IFS skal understøtte anvendelsen af forskellige kontotyper overført fra Navision Stat, herunder finanskonti, varekonti og anlægskonti, så en bruger i en konteringsstreng kun kan angive én kontoværdi. Fx skal det ikke være muligt både at angive en finanskonto og en anlægskonto i den samme kontostreng (PK) IFS skal understøtte kontering af momsproduktbogføringsgrupper, overført fra Navision Stat. Momsproduktbogføringsgruppe skal automatisk kunne afledes fra konto- og aliasværdier. Men den enkelte bruger skal også have mulighed for at angive eller ændre momsproduktbogføringsgruppe i konteringsstrengen, hvis brugeren har tilstrækkelige rettigheder og den lokale opsætning tillader direkte angivelse/ændringer af momsproduktbogføringsgrupper(pk) IFS skal understøtte kontering med Alias, overført fra Navision Stat, og IFS skal understøtte automatisk udfoldelse af konteringsværdierne indeholdt i det valgte Alias, så brugerne kan se og evt. ændre værdierne som er afledt fra det specifikke alias (PK) IFS skal understøtte kontering af sag og sagsopgaver, overført fra Navision Stat. Ved konterings med sager og sagsopgaver skal systemet tage højde for sammenhængen mellem de enkelte sager og sagsopgaver (PK) IFS skal understøtte kontering af Budget, overført fra Navision Stat (PK) Ved kontering skal systemet automatisk aflede værdier som defineret i regelsæt (fx Alias og anden konteringshjælp, overført fra Navision Stat, jf. bilag 2F Integration fra Navision Stat til IFS (PK) Ved kontering skal systemet sikre validering mod og overholdelse af et regelsæt for ugyldige konteringskombinationer overført fra Navision Stat, jf. bilag 2F Integration fra Navision Stat til IFS (PK) En gyldig IFS konteringsstreng skal indeholde en konto en momsproduktbogføringsgruppe, samt øvrige værdier der er angivet som obligatoriske i opsætningen for den pågældende organisation/regnskab (PK) En linje med et negativt beløb må ikke kunne konteres med en anlægskonto, da man i Navision ikke kan foretage en negativ anskaffelse via en købsfaktura (PK) En bruger skal ved kontering kun kunne vælge de konteringsværdier vedkommende har fået adgang til (PK) IFS skal understøtte elementerne AllowanceCharge (rabatter og gebyrer) og Tax (moms og andre afgifter der afregnes til det offentlige) i henhold til UBLstandarden (PK) Kommentar [F20]: KKP Disse er gensidigt udelukkende. Kommentar [F21]: Til NS, Hvordan var det det er? Er det alle kontotyper der kan aflede mompbgruppe? KKP Finans og Vare kan direkte trækker en Momsproduktbogføringsgrup pe. De vil kunne udtrækkes til et nyt stamdatasæt. Anlæg ikke. Kommentar [F22]: KKP Skal der tages højde for at Alias kan aflede en finans/vare/anlæg, som vil overskrive en allerede konteret værdi. JMH: Det skal vi tage højde for, så vi skal have klarlagt, hvordan (det implicite) hierarki fungerer i Navision Kommentar [F23]: KKP Hvis der vælges et alias, der indeholder en finanskode, og der både er opsat momsproduktbogf.grp på finanskontoen og direkte i aliaskoden, bør det være den direkte opsætning i aliaskoden, der skal være den styrende, ellers giver det jo ikke mening at angive en momsprodukt. bogfr. brp kode direkte på aliaskoden. Side 54 af 95

55 2A A A A IFS skal kunne håndtere AllowanceCharge elementer som en del af konteringen, hvilket vil sige at rabatter og gebyrer skal kunne konteres, hvis de er angivet på dokumenthovedet (ØK) AllowanceCharge elementer som er angivet på dokumentlinjer, skal alene vises for brugerne, da beløbet er indeholdt i linjens total (ØK) En bruger skal let, hurtigt og med et minimum af operationer med mus og/eller keyboard kunne danne sig et overblik over kontering på et forretningsdokument (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Kontering generelt i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Kontering generelt i IFS} Funktionalitet vedrørende Kontering generelt er yderligere kravsat i Use case 14, Use case 16 og Use case 19 i underbilag 2C. 2A Omkontering: Hvis et dokument er blevet konteret forkert, kan det være nødvendigt at foretage en omkontering. Fejlkonterede ordrer vil skulle omkonteres i IFS for at sikre retvisende dispositionsregnskaber. Brugerinstitutionerne kan vælge kun at omkontere godkendte fakturaer, kreditnotaer og rykker i Navision Stat, men det vil være et ønske hos mange brugerinstitutioner, at det er muligt at foretage en omkontering direkte i IFS som også opdaterer data i Navision Stat. 2A A A A En bruger med tilstrækkelige rettigheder skal nemt kunne omkontere godkendte dokumenter i systemet (ØK) Der skal være et workflow for en omkonteringen, så en omkontering skal godkendes af en disponent med tilstrækkelig prokura (ØK) Det må kun være muligt at omkontere fakturaer, kreditnotaer eller rykkere der er accepteret i Navision Stat, dvs. hvor der er returneret en positiv forretningskvittering (ApplicationResponse) fra Navision Stat (ØK) En godkendt omkontering af en faktura, en kreditnota eller en rykker skal automatisk sendes til Navision Stat jf. kravene i afsnit XX (ØK) Kommentar [F24]: Jf. samtale med KKP skal det nok være bogført JMH: Og det svarer vist til at der er returneret delvist betalt eller betalt med Transaktionsdatafilen. Side 55 af 95

56 2A Processerne der dækkes af ovenstående krav (2A A )er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Omkontering i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Omkontering i IFS] 2A.5.12 Kreditnotaer Behandling af kreditnotaer bør som udgangspunkt fungere på samme måde som behandlingen af fakturaer, med to undtagelser: En kreditnota bør kobles til den faktura som kreditnotaen vedrører, hvis muligt, og en kreditnota bør ikke automatches/godkendes, da en kreditnota er et tegn på at der allerede er gået noget galt i transaktionsprocessen, hvorfor det ønskes at en kreditnota altid valideres af en bruger inden den godkendes. 2A A A A A En række krav vedrørende fakturabehandling finder tilsvarende anvendelse for behandling af kreditnotaer, det drejer sig om følgende krav (PK): 2A A A A A A A A A A A A Kun hvis det tilbudte system opfylder alle de underliggende krav skal tilbudsgiver angive compliance til krav 2A Er kun nogle af de underliggende krav opfyldt, skal tilbudsgiver angive delvis compliance til krav 2A og tydeligt redegøre for, hvilke af de underliggende krav, der er opfyldt, og, hvilke der ikke er, i bilag XX (PK) Ved modtagelse af en kreditnota skal systemet finde den tilhørende faktura og evt. ordre og automatisk tilknytte kreditnotaen til disse (ØK) Kan kreditnota ikke automatisk tilknyttes til en faktura, skal kreditnotaen manuelt kunne tilknyttes fakturaen og evt. en indkøbsordre (ØK) Modtages en kreditnota med en uønsket kobling til en ordre og/eller faktura, skal det være muligt at koble kreditnotaen fra både ordren og fakturaen (ØK) Kommentar [F25]: Bemærk at krav og ikke finder anvendelse da der ikke er payment means på en KN Kommentar [F26]: Numme rering skal verificeres, når kravspec er ved at være færdig Side 56 af 95

57 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter håndtering af Kreditnotaer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af udvalgte krav fra krav 2A Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter håndtering af Kreditnotaer i IFS] Funktionalitet vedrørende håndtering af Kreditnotaer er yderligere kravsat i Use case 20 og Use case 21 i underbilag 2C. 2A.5.13 Rykkere og kontoudtog Rykkere kan modtages med eller uden et rykkergebyr, der skal betales. For rykkere med et gebyr gælder det, som for en kreditnota, at behandling af rykkeren som udgangspunkt bør fungere på samme måde som behandlingen af fakturaer, med to undtagelser: En rykker bør kobles til den faktura som rykkeren vedrører, hvis muligt, og en rykker må ikke autogodkendes, da en rykker er et tegn på at der allerede er gået noget galt i transaktionsprocessen, hvorfor det ønskes at en rykker altid valideres af en bruger inden den godkendes. Dokumentflowet for rykkere uden et rykkergebyr og for kontoudtog bør være væsentligt simplere end flowet for fakturaer og rykkere med gebyr, da de ikke har direkte påvirkning på institutionernes regnskaber. Ud over kravene til dokumentbehandling generelt, gælder følgende krav for rykkere og kontoudtog: 2A A Brugerinstitutionernes vareleverandører skal kunne sende rykkere med eller uden gebyrer og kontoudtog direkte til IFS i OIOUBL format (MK) En række krav vedrørende fakturabehandling finder også anvendelse for behandling af rykkere med gebyrer, det drejer sig om følgende krav (PK): 2A A A A A A Side 57 af 95

58 2A A A A A A A A A A A A A Kun hvis det tilbudte system opfylder alle de underliggende krav skal tilbudsgiver angive compliance til krav 2A Er kun nogle af de underliggende krav opfyldt, skal tilbudsgiver angive delvis compliance til krav 2A og tydeligt redegøre for, hvilke af de underliggende krav, der er opfyldt, og, hvilke der ikke er, i bilag XX (PK) Ved modtagelse af en rykker med eller uden gebyr skal systemet finde den tilhørende faktura og evt. ordre og automatisk tilknytte rykkeren til disse (ØK) Kan en rykker med eller uden gebyr ikke automatisk tilknyttes til en faktura, skal rykkeren manuelt kunne tilknyttes fakturaen og evt. en indkøbsordre (ØK) Modtages en rykker med eller uden gebyr med en uønsket kobling til en ordre og/eller faktura, skal det være muligt at koble rykkeren fra både ordren og fakturaen (ØK) Indkomne rykkere uden gebyrer og kontoudtog skal automatisk fremsendes til den referenceperson, der er angivet på dokumentet. Hvis der ikke er en genkendelig personreference på dokumentet, skal dokumentet routes til en fakturafordeler, eller fakturafordeler skal på anden vis blive gjort opmærksom på at der er modtaget et dokument som skal behandles (ØK) Rykkere uden gebyr og kontoudtog skal kunne accepteres, eller på anden måde markeres som behandlet så dokumentet skifter status (ØK) Når en rykker uden betalingsanmodning eller et kontoudtog er accepteret skal dokumentet automatisk fremsendes til Navision Stat (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter håndtering af Rykkere og kontoudtog i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter håndtering af Rykkere og kontoudtog i IFS] Forsyningsspecifikationer (UTS) Kommentar [F27]: Numme rering skal verificeres, nå kravspec er ved at være færdig Side 58 af 95

59 2A A A A A A A A A Brugerinstitutionernes vareleverandører skal kunne sende Forsyningsspecifikationer (UTS-dokumenter) direkte til IFS i OIOUBL format (MK) IFS skal automatisk kunne modtage og vise OIOUBL ForsyningsSpecifikationen (UTS), som et selvstændigt bilag til det dokument de vedrører (PK) Sammenkoblingen mellem en forsyningsspecifikation og det dokument specifikationen vedrører skal automatisk ske, uanset hvilken rækkefølge de modtages i. Det er fx ikke unormalt at dokumenterne modtages med 12 timers mellemrum (PK) Det skal være nemt for en bruger manuelt at tilknytte eller frakoble en forsyningsspecifikation til et dokument, fx hvis referencen på specifikationen er forkert (ØK) I IFS skal det tydeligt fremgå, at et dokument har tilknyttet UTS dokumenter, og antallet af tilknyttede specifikationer skal tydeligt fremgå for brugeren (ØK) Et UTS-dokument skal kunne tilgås direkte fra det dokument som UTSdokumentet er tilknyttet (ØK) IFS skal automatisk videresende forsyningsspecifikationer til Navision Stat (PK) Visningen af et UTS-dokument skal som minimum være i det af Digitaliseringsstyrelsen til enhver tid anbefalede stylesheet. Der skal desuden være yderlige tiltag i forhold til overskuelighed og læsbarhed (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter håndtering af Forsyningsspecifikationer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter håndtering af Forsyningsspecifikationer i IFS] Funktionalitet vedrørende håndtering af Forsyningsspecifikationer er yderligere kravsat i Use case 22 i underbilag 2C. 2A.5.15 Søgning i IFS Søgning i IFS kan deles op i to typer af søgninger: Søgning på feltniveau, hvor en bruger søger efter en specifik værdi, fx en dimensionskontoværdi eller en Side 59 af 95

60 specifik bruger, med henblik på at vælge værdien så den bliver angivet i et specifikt felt på et dokument eller stamkort; og søgning på dokumentniveau/ stamkortniveau, hvor en bruger søger efter et eller flere stamkort eller dokumenter. Ved søgning på feltniveau vil en bruger normalt alene være interesseret i at finde frem til en specifik værdi, som der søges direkte efter. En bruger, der søger efter dokumenter eller stamkort kan derimod være interesseret i at få returneret mange resultater, der opfylder et sæt af søgekriterier, og kan være interesseret i at undersøge egenskaberne for det fremsøgte nærmere, fx kan en systemadministrator fremsøge brugerstamkort, med henblik på at undersøge brugernes rettigheder nærmere. 2A A A A A A A A A A A A Generelle krav til søgning Søgemulighederne i IFS skal være fleksible, brugervenlige og omfattende (MK) IFS skal have forskellige typer af søgemuligheder, fx fritekstsøgning, quicksøgning og kompleks søgning (PK) Søgeresultater skal fremvises på en struktureret og overskuelig form, så brugerne fx får et oversigtsbillede med et dokument eller en record (fx vare) pr linje (PK) Et søgeresultat må kun vise data som brugeren har adgangsrettigheder til at se i systemet, så en bruger fx kun får returneret varer fra kataloger som brugeren har rettigheder til (PK) En bruger skal selv have mulighed for at konfigurere, hvilke datafelter der skal vises som kolonner i søgeresultater (ØK) Det skal være nemt at gemme søgninger (PK) Det skal være nemt at filtrere/sortere på søgeresultater, så man fx kan sortere et søgeresultat efter leverandørnavn og/eller betalingsdato og/eller beløb (PK) Det skal være nemt at gemme den ønskede sortering af søgeresultater (Ø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å i praksis ikke være afgrænset, antallet af søgeresultater der vises pr side må gerne være afgrænset (PK) Det skal være nemt at søge efter dokumenter, varer, stamkort og værdier ud fra fritekst (PK) Kommentar [F28]: Det er vel ok, hvis begrænsningen er en 6 cifret størrelse eller mere? Side 60 af 95

61 2A A A A A A A A A A Det skal være nemt at søge på dele af et ord (PK) Det skal være nemt at anvende wildcards i søgningen, som fx xxx ved søgning efter et specifikt ord og brug af * eller % før eller efter et søgeord, hvor søgningen skal udvides (ØK) Ved søgning efter en specifik værdi på feltniveau skal det være nemt at foretage en søgning på synonymer for værdien, fx så en dimensionskontoværdi kan fremsøges både ud fra talkoden og ud fra beskrivelsen, og så en bruger kan fremsøges ud fra brugernavn, brugerens fulde navn eller brugerens initialer (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Søgning generelt i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Søgning i IFS] Funktionalitet vedrørende Søgning generelt er yderligere kravsat i Use case 23 i underbilag 2C. Varesøgning Brugeren skal nemt kunne fremsøge varer fra alle kataloger som brugeren har adgang til i et enkelt søgebillede (PK) En bruger skal nemt kunne fremsøge en vare i et elektronisk varekatalog, ud fra alle de oplysninger der fremgår om varen i kataloget, herunder metadata om varens tilknytning til kataloget, eller varens/katalogets tilknytning til en aftale og varens heraf afledte egenskaber (ØK) Brugerne skal nemt kunne begrænse varesøgning, baseret på varekategori, tilknytning til aftale eller favoritliste, katalog mm. (ØK) IFS skal understøtte søgning ved at benytte de synonymer (Keywords i OIO UBL terminologi) vareleverandørerne indsætter i katalogerne (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Varesøgning i IFS i underbilag 2B (PK) Kommentar [F29]: SWK: Trunkeret søgning (ved hjælp af * før og efter ordet). Det er ikke attraktivt, at man f.eks. skriver kaffe for at finde alle ordre på kaffefiltre og kaffekander osv., men så finder den alle ordrer, hvor bogstaverne k a f f e optræder individuelt. Også vigtigt, at den ikke skal skelne mellem store og små bogstaver. Kommentar [F30]: PIR: har tilføjet krav JMH: Vi skal passe på med at definere wildcards, det kan også håndteres på andre måder. Side 61 af 95

62 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Varesøgning i IFS] Funktionalitet vedrørende Varesøgning er yderligere kravsat i Use case 23 i underbilag 2C. 2A A A A A A A A A A Søgning på dokument og stamkortniveau Brugerne skal nemt kunne åbne et dokument eller et stamkort direkte fra et søgeresultat (PK) Dokumenter der er markeret som fortrolige må ikke fremgå af et søgeresultat medmindre brugeren der foretager søgningen har rettigheder til at se fortrolige dokumenter (ØK) Dokumentstatus og tilhørsforhold skal tydeligt fremgå af søgeresultatet så en bruger fx kan se, at en specifik faktura er sendt til godkendelse hos en specifik disponent i en specifik organisations-enhed (PK) Det skal være nemt at fremsøge dokumenter og stamkort (fx brugere, varer og kreditorer) i systemet som er blevet spærret, afvist eller lignende, og det skal være nemt at fravælge spærrede/afviste dokumenter og stamkort i søgekriterierne (PK) Det skal tydeligt fremgå af søgeresultatet om en anden bruger anvender et dokument, som fremgår på søgeresultatet (ØK) Ved dokumentsøgning skal det i søgeresultatet være nemt for en bruger at se om der er angivet en note til det enkelte dokumentet, og det skal være nemt at få et overblik over de angivne noter. Det kan fx være at der er angivet et ikon ud fra de dokumenter der har en note, og at indholdet af noten vises ved mouseover på ikonet (ØK) Det skal være nemt at fremsøge et dokument eller et stamkort ud fra en kombination af søgekriterier (PK) Det skal være nemt at fremsøge dokumenter og stamkort 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) Det skal være nemt at fremsøge dokumenter på specifikke dokument-id er (fx et specifikt fakturanummer) (PK) Kommentar [F31]: Mere om fortrolige dokumenter, nogen vil godt have dem på listen (annonymiseret?) Side 62 af 95

63 2A A A A A A A A A A Det skal være nemt at fremsøge dokumenter der er allokeret til én bestemt bruger (PK) Det skal være nemt at fremsøge alle dokumenter som en specifik bruger har behandlet, så en bruger fx kan fremsøge egne dokumenter jf. afsnit XX, eller så en revisor kan fremsøge alle dokumenter der har været behandlet af en specifik bruger (PK) Det skal være nemt 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 (ØK) Det skal være nemt at fremsøge dokumenter ud fra datointervaller (PK) Det skal være nemt at fremsøge dokumenter ud fra beløbsintervaller (PK) Det skal være nemt at fremsøge dokumenter ud fra leverandørnavn og ud fra CVR-nr (eller anden leverandør-identifikator) (PK) Det skal være nemt at fremsøge dokumenter ud fra dokumentstatus (PK) Det skal være nemt at fremsøge et dokument ud fra en konteringssværdi der er angivet på dokumentet, eller en kombination af konteringssværdier der er angivet på dokumentet (PK) En bruger skal kunne eksportere et søgeresultat til Excel eller lignende (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Søgning på dokument og stamkortniveau i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav (2A A ) 2. Eventuelle yderligere funktioner der understøtter Søgning på dokument og stamkortniveau i IFS] Funktionalitet vedrørende Søgning på dokument og stamkortniveau er yderligere kravsat i Use case 23 i underbilag 2C. 2A.5.16 Systemkonfiguration IFS 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 Side 63 af 95

64 lokale systemadministrator, der skal udføre andre dele af brugerkonfigurationen. Det forudsættes, at IFS i stor udstrækning kan konfigureres, men at det ligeledes kan anvendes med en standardopsætning konfigureret af Tjenesteyder, således at IFS er meget simpelt at tage i brug for Kunden. 2A A A A A A A A A A A A Generelle krav til systemkonfiguration Opsætning af systemet skal kunne konfigureres af kunden (MK) Konfiguration skal nemt kunne ske i systemets brugergrænseflade (PK) De enkelte enheder/organisationer og brugere i systemet skal nemt kunne konfigureres forskelligt (PK) Brugergrænsefladen skal være konfigurerbar for den enkelte bruger (ØK) Globale systemadministratorer skal have adgang til værktøjer til at eksportere og importere opsætningsdata (PK) Lokale systemadministratorer skal have adgang til værktøjer til at eksportere og importere opsætningsdata inden for deres eget domæne, herunder brugerstamdata og -rettigheder (ØK) IFS skal lokalt kunne opsættes til altid at kræve, at der er mindst to brugere inde over afsendelse af en indkøbsordre, eller godkendelse af en faktura uden match med en tilknyttet indkøbsordre, så en rekvisitionen fx ikke kan oprettes og godkendes af den samme bruger, og så en faktura uden match med en indkøbsordre ikke kan varemodtages og godkendes af den samme bruger (ØK) En lokal systemadministrator skal nemt kunne konfigurere om den enkelte bruger har ret til se fortrolige dokumenter (ØK) En lokal systemadministrator skal nemt kunne angive flere forskellige personreferencer for den enkelte bruger, så det gælder at dokumenter automatisk kan allokeres til brugeren ud fra flere forskellige værdier, så det fx kan konfigureres at brugeren genkendes uanset om det er brugerens fuld navn, initialer eller adresse der er angivet som personreference (ØK) En bruger skal kunne anmode om, at systemet automatisk sender et nyt password til brugerens adresse (ØK) IFS skal have et dansk og et engelsk sproglag (PK) Side 64 af 95

65 2A A A A A A A A A A Valg af sproglag skal nemt kunne konfigureres på brugerniveau, og det valgte sprog skal slå igennem i alle dele af IFS, så bl.a. også log-on side, adviser og fejlmeddelelser præsenteres for brugeren på det sprog som er valgt (PK) IFS skal logge ændringer i systemkonfigurationen, og alle relevante ændringer i opsætningen skal tydeligt fremgå af loggen. Det skal tydeligt fremgå, hvilken handling der er tale om, hvem der har foretaget handlingen, hvornår handlingen er foretaget og om handlingen er udført på en anden brugers vegne med stedfortræderfunktionen. Herunder skal alle ændringer af brugeres rettigheder logges så det er muligt at følge op på ændringer i brugerrettigheder i en kontrolrapport, jf. krav X (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Generelle krav til systemadministration i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Generelle krav til systemadministration i IFS] Konfiguration af regnskaber IFS skal integrere med mange Navision Stat databaser og bogføringskredse/regnskaber. Hver Navision Stat database kan indeholde mange bogføringskredse (MK) Hver organisationsenhed i IFS skal kunne kobles til en Navision Stat bogføringskreds, således at der til organisationsenheden i IFS overføres stamdata og transaktionsdata, fra den pågældende Navision Stat bogføringskreds, som skal anvendes ved behandling af forretningsdokumenter i den pågældende organisationsenhed (PK) Hver enkelt organisationsenhed skal kun kunne kobles til én Navision Stat bogføringskreds, men forskellige organisationsenheder skal kunne kobles til den samme Navision Stat bogføringskreds (PK) Det skal fremgå tydeligt af den enkelte organisationsenhed i IFS hvilket Navision Stat regnskab enheden er koblet til (ØK) Hver enkelt Navision Stat bogføringskreds har i IFS tilknyttet et eller flere EAN-numre (MK) Den enkelte organisationsenhed i IFS skal kunne tilknyttes et eller flere EANnumre som er tilknyttet samme Navision Stat bogføringskreds som organisationsenheden (PK) Kommentar [F32]: Vi skal bede om at få beskrevet hvilke handlinger der logges, hvordan de logges og hvordan de kan tilgås Kommentar [F33]: Hvorda n modtager IFS transaktionsdata? En fil pr. EAN i bogføringskredsen, eller sendes der kun én fil på samme EAN-nr som stamdatafilen? KKP Masterdata angiver en ERP_CompanyID som udtrækkes fra regnskabets officielle EAN nummer. Der er kun én værdi pr. Navisionregnskab/Bogførings kreds. Det betyder at hvis man har organiseret sig med flere EAN numre der peger ind på IFS, så skal IFS selv koble dem sammen med det ene stamdatasæt som kommer fra det bagvedliggende Navisionregnskab. JMH: Det komplicerer tingene, skal kravsættes Kommentar [F34]: KKP. NS regnskab = NS bogføringskreds. Side 65 af 95

66 2A A A A A A A A A A Et unikt EAN-nummer må kun være tilknyttet en organisationsenhed i IFS (PK) En lokal systemadministrator skal pr. regnskab eller organisationsenhed kunne opsætte, hvilke konteringsfelter (fx dimensioner, Sag, Sagsopgave eller Budget), der anvendes og vises i IFS (PK) En lokal systemadministrator skal pr. regnskab eller organisationsenhed kunne opsætte, i hvilken rækkefølge konteringsfelterne skal vises i, i IFS (PK) En lokal systemadministrator skal pr. regnskab kunne opsætte, hvilket navn, der vises for det enkelte konteringsfelt i IFS (PK) En lokale systemadministratorer skal nemt, gældende pr regnskab eller organisationsenhed og evt. bruger, kunne lave en fleksibel opsætning af obligatoriske konteringsfelter, der skal udfyldes på et forretningsdokument for at dokumentet kan godkendes (PK) En lokale systemadministrator skal pr. regnskab eller organisationsenhed kunne definere standardkonteringsværdier, som præudfyldes på et dokument (ØK) Globale systemadministratorer skal kunne opsætte og administrere integrationen mellem de organisatoriske enheder i IFS og Navision Stat regnskaberne som beskrevet i afsnit XX (PK) Systemadministratorer og fakturamanagere mv. skal let kunne se, hvornår der sidst er opdateret stamdata fra Navision Stat pr. bogføringskreds/regnskab (ØK) En lokal systemadministrator skal kunne fravælge muligheden for automatch af (alle) ordrer med fakturaer i den enkelte organisationsenhed eller i det enkelte regnskab(øk) Processerne der dækkes af ovenstående krav (2A A og 2A A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af regnskaber i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A og 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af regnskaber i IFS] 2A Konfiguration af Adviser Side 66 af 95

67 IFS skal kunne konfigureres til automatisk at gøre brugerne opmærksomme på ændringer i IFS, der er relevante for brugerne, gennem adviseringer. 2A A A A A A Teksterne i adviseringerne skal være sigende sammenhængende og forståelige standardtekster og indeholde dybe links, så en bruger kan gå direkte til det eller de dokument(er), adviset henviser til (PK) Enhver relevant handling som IFS enten foretager automatisk eller som gennemføres af en bruger, skal kunne generere en advis 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 (PK): Der indlæses et nyt katalog Der indlæses en katalogopdatering Et forretningsdokument allokeres til brugeren Et forretningsdokument der er relevant for brugeren godkendes, bekræftes eller afvises af en leverandør eller af en anden bruger i IFS Der modtages en ordreændringsanmodning, på en ordre der er relevant for brugeren En ordre, der er relevant for brugeren, annulleres af en anden bruger i IFS En faktura automatcher med en ordre, der er relevant for brugeren Et dokument tilknyttes til et andet dokument, der er relevant for brugeren En faktura tilknyttes en ordre, der er relevant for brugeren men match kan ikke gennemføres Et dokument der er relevant for brugeren skifter status Forskellige handlinger skal have forskellige typer af adviser tilknyttet (PK) Tilbudsgiver skal i løsningsbeskrivelsen indsætte en oversigt over samtlige typer af adviser i IFS, samt angive standardteksterne for hver enkelt type advisering (PK) Indholdet af de enkelte typer adviser skal være konfigurerbart globalt, så globale systemadministratorer kan ændre i indholdet i standardteksterne (ØK) Indholdet af adviset skal kunne hente oplysninger fra IFS, der får advis en til at fremstå personlig og informerende, fx: brugernavne, dokumentid er, leverandørnavne og beløb (ØK) Kommentar [F35]: Er dette krav ok? Side 67 af 95

68 2A A A A A A A A Præferencer (regler) for modtagelse af adviser skal nemt kunne konfigureres lokalt på organisationsniveau, og på brugerniveau (PK) Det skal være nemt, at vælge mellem om en bruger skal modtage en advisering pr. relevant handling, eller om brugeren skal modtage en samlet advisering pr. dag, der dækker alle relevante handlinger (ØK) Adviser skal sendes som s til brugerne (PK) Et advis skal indeholde et dybt link til det eller de dokument(er) som adviset vedrører (PK) Lokal systemadministrator skal nemt kunne opsætte frekvens for afsendelse af adviser, der automatisk sendes som følge af en brugers manglende handling (ØK) IFS skal understøtte muligheden for manuelt at generere en advis, der kan sendes som følge af en brugers manglende håndtering af et dokument (ØK) IFS skal ikke sende et advis til en bruger, hvis der er brugeren selv, der har foretaget handlingen, som udløser advisen (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af adviser i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af adviser i IFS] 2A Informations- og fejlmeddelelser IFS 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 fejlmeddelelser, som brugeren kan forstå og tage stilling til. 2A A IFS skal vise sigende informationsmeddelelser når det er relevant. Det er fx relevant at der kommer en informationsmeddelelse, hvis et indkøb er over udbudsgrænsen (Ø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 IFS automatisk returnere en fejlmeddelelse til brugeren (PK) Side 68 af 95

69 2A A A A A A A A A A Teksterne i informations- og 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) Tilbudsgiver skal i løsningsbeskrivelsen indsætte en oversigt over samtlige standardtekster med reference til årsagen for visning af den enkelte informations- og fejlbesked (PK) Indholdet af informations- og fejlmeddelelserne skal være konfigurerbart globalt, så globale systemadministratorer kan ændre i indholdet i standardteksterne (ØK) Indholdet af fejlmeddelelserne skal kunne hente oplysninger fra IFS, der får fejlmeddelelsen til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne og beløb (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af fejlmeddelelser i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af fejlmeddelelser i IFS] Konfiguration af s til vareleverandører Som angivet i afsnit XX vil vareleverandører, der ikke er i stand til at modtage ordrer fra IFS i OIOUBL formatet, skulle have tilsendt ordrer fra IFS som e- mails. Tilsvarende kan det være relevant at der sendes en til en vareleverandør ifbm en ordreændring eller lignende. Når en ordre sendes til en leverandør fra IFS via , skal selve ordren fremgå som en PDF-vedhæftning til en (PK) Teksterne og emnelinjerne i en skal være sigende sammenhængende og forståelige standardtekster (PK) Tilbudsgiver skal i løsningsbeskrivelsen indsætte en oversigt over samtlige standardtekster med reference til årsagen for afsendelse af den enkelte til vareleverandørerne (PK) Indholdet af en skal være konfigurerbart lokalt så lokale systemadministratorer nemt kan ændre i indholdet i standardteksterne (ØK) Kommentar [F36]: Er dette et korrekt krav? Side 69 af 95

70 2A A Indholdet af en skal kunne hente oplysninger fra IFS, der får en til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne, oplysninger om de ønskede varer og beløb (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af s til vareleverandører i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af s til vareleverandører i IFS] Funktionalitet vedrørende Konfiguration af s til vareleverandører er yderligere kravsat i Use case 4 i underbilag 2C. 2A A A A A A A A A Konfiguration af Matchkriterier Konfiguration af matchkriterier skal nemt kunne opsættes lokalt af en lokal systemadministrator (PK) Automatch skal helt kunne fravælges generelt på organisationsniveau (ØK) Der skal nemt kunne opsættes generelle afvigelsestolerancer for match på organisations- eller regnskabsniveau (PK) I den enkelte organisation eller i det enkelte regnskab skal det være nemt, at opsætte afvigelsestolerancer for et specifikt katalog, prisliste, aftale og/eller leverandør, som overstyrer de generelle afvigelsestolerancer (PK) Det skal være nemt at opsætte afvigelsestolerancer på en stående ordre, som overstyrer de generelle afvigelsestolerancer (PK) Afvigelsestolerancer skal nemt kunne opsættes som specifikke beløb og/eller som procentsatser (PK) Der skal nemt kunne opsættes specifikke afvigelsestolerancer for allowance charge elementer (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af Matchkriterier i IFS i underbilag 2B (PK) Side 70 af 95

71 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af Matchkriterier i IFS] Funktionalitet vedrørende Konfiguration af Matchkriterier er yderligere kravsat i Use case 10 i underbilag 2C. 2A Konfiguration af grupper og konteringshjælp For at sikre, at brugere af IFS kun kan se og kun skal forholde sig til det data, der er relevant for brugeren, kan det være hensigtsmæssigt at brugernes adgang til data kan begrænses lokalt fx ved at brugere allokeres til grupper der begrænser medlemmernes adgang til data i den enkelte organisation. Det er ikke et krav at IFS opererer med gruppebegrebet, gruppe-begrebet anvendes alene i dette afsnit for at beskrive kundens behov for funktionalitet til systematisk og nemt at begrænse brugeres adgang til data. 2A A A A A A A En lokal systemadministrator skal pr regnskab eller organisationsenhed nemt kunne begrænse grupper af brugeres adgang til data (fx adgang til specifikke kataloger, specifikke favoritlister, specifikke punch out forbindelser, og specifikke konteringsfelter eller konteringsværdier ved berigelse af dokumenter med data) (PK) En lokal systemadministrator skal pr regnskab eller organisationsenhed nemt kunne styre grupper af brugeres prokura, så det fx er let at ændre alle kontorchefers prokura i en styrelse på en gang (ØK) Det skal være nemt for en lokal systemadministrator, at danne sig et overblik over, hvordan brugernes adgang til data er blevet begrænset af grupper eller lignende (PK) En specifik bruger skal nemt kunne tilknyttes mere end en gruppe pr. regnskab og datatype, så en bruger fx både kan være tilknyttet en gruppe, der gør at brugeren ikke kan vælge anlægskonti og en gruppe der gør at brugeren ikke kan vælge finanskonti som vedrører repræsentation (PK) IFS skal understøtte, at en lokal systemadministrator nemt kan opsætte standardelementer, for den enkelte bruger, eller for en gruppe af brugere, som udfyldes automatisk når den enkelte bruger åbner eller påbegynder arbejdet på et dokument, hvor elementerne ikke allerede er udfyldt, fx angivelse af disponent, leveringsadresse og konteringsværdier (ØK) Den enkelte aftale, leverandør, varekategori (UNSPSC) og vare skal nemt kunne tildeles konteringsværdier, på regnskabsniveau, som automatisk afledes når en vare vælges (ØK) En lokal systemadministrator skal kunne oprette en gruppe, som kan vælges som en bruger når dokumenter skal allokeres i systemet. Når et dokument Side 71 af 95

72 allokeres til denne type gruppe, skal alle medlemmerne af gruppen se dokumentet på deres oversigt over deres igangværende arbejde. Formålet med denne type af grupper er at man kan allokere et dokument til en funktion, fx et indkøbskontor, eller en fakturamanagerfunktion, hvor medarbejderne i den pågældende funktion fordeler arbejdsopgaverne internt i funktionen (ØK) 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af grupper og konteringshjælp i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af grupper og konteringshjælp i IFS] Funktionalitet vedrørende Konfiguration af grupper og konteringshjælp er yderligere kravsat i Use case 24 i underbilag 2C. 2A A A A A A A A Konfiguration af adresser IFS skal håndtere alle adresser, der anvendes i forbindelse med ordreafgivelse, som strukturerede adresser i henhold til UBL-bekendtgørelsen, så leverandørerne altid modtager fakturerings- og leveringsadresserne ensartet (PK) Systemadministrator skal nemt kunne definere standardadresser pr regnskab eller organisationsenhed (ØK) I forbindelse med ordreafgivelse skal en bruger nemt kunne anvende standardadresserne (ØK) I forbindelse med ordreafgivelse skal en bruger nemt kunne angive fritekstadresser, dvs. adresser som brugeren selv indtaster (ØK) IFS skal huske, hvilke adresser en bruger tidligere har anvendt, så en bruger nemt kan genanvende dem (ØK) En lokal systemadministrator skal på organisationsniveau og på brugerniveau nemt kunne konfigurere, at det ikke er muligt at anvende fritekstadresser (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter Konfiguration af adresser i IFS i underbilag 2B (PK) Side 72 af 95

73 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter Konfiguration af adresser i IFS] 2A.5.17 Rapportering 2A A A A A A A Det er væsentligt for effektiviseringen af statens indkøbs- og fakturahåndtering, at der kan udtrækkes data om anvendelsen af IFS, som kan anvendes til at analysere statistik, historik og opfølgningsrutiner. Systemet skal stille fleksible og brugervenlige rapporteringsmuligheder til rådighed for brugerne, i systemets egen brugergrænseflade (PK) Alle rapporter skal kunne nemt eksporteres fra systemet, til Excel, PDF og lignende, så data nemt kan viderebehandles (PK) Rapporter skal nemt kunne udskrives direkte fra IFS (ØK) En bruger skal nemt kunne gemme specifikationer af rapporter, eller rapportskabeloner, så det er let og hurtigt systematisk at udtrække data fra IFS periodisk (ØK) En lokal systemadministrator og en revisionsbruger skal nemt kunne trække en rapport over tildelte brugerrettigheder, hvor man kan se brugeropsætningen i IFS på et givet tidspunkt. Denne rapport skal indeholde alle brugeroplysninger i det domæne den trækkes for, herunder tildelte systemroller, adgangsrettigheder og prokuragrænser for den enkelte bruger i den enkelte organisatoriske enhed. Rapporten skal udtrækkes periodisk og vedlægges som bilag til den enkelte brugerinstitutions regnskabsinstruks. (PK) En lokal systemadministrator og en revisionsbruger skal i IFS kunne trække en rapport over ændrede brugerrettigheder over en periode, hvor man kan se ændringer i brugernes roller, adgangsrettigheder og prokura i en given periode. Denne rapport skal indeholde alle ændringer for alle brugere i det domæne den trækkes for den ønskede periode. Rapporten skal den lokale systemadministrator udtrække periodisk og rapporten skal godkendes og vedlægges som bilag til den enkelte brugerinstitutions regnskabsinstruks. (PK) Systemet skal kunne levere en rapport som indeholder en oversigt over match, fejlmatch og automatch for en periode som brugeren definerer. I det omfang dokumenter er fejlmatchet eller matchet, men ikke automatchet skal årsagen til det manglende match eller det manglende automatch tydeligt fremgå af rapporten, så det fx kan ses, at et automatch oprindeligt ikke har fundet sted, som følge af manglende varemodtagelse, men at automatchet efterfølgende blev gennemført efter at varemodtagelsen blev registreret. Rapporten skal anvendes til identificering af årsager for manglende automatch (PK) Kommentar [F37]: Kun nødvendigt ifbm. understøttelse af opfølgningsprocesser i systemet og revisionshensyn. Overordnet er vores rapporteringsstrategi baseret på (ØSL)DV Side 73 af 95

74 2A A A A A A En lokal systemadministrator skal nemt kunne trække en rapport eller en oversigt over aktive stedfortrædere (PK) Al forretningsdata fra IFS, inklusiv originalbilag, transaktions og kontrolspor, skal eksportere til ØS LDV med henblik på at kunden kan byge sine rapporter, som beskrevet i afsnit XX. Det er alene rene systemdata der ikke behøves eksporteret (MK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere funktioner der fleksibelt, intuitivt og brugervenligt understøtter anvendelse af Rapportering i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere funktioner der understøtter anvendelse af Rapportering i IFS] Funktionalitet vedrørende Rapportering er yderligere kravsat i Use case 25 i underbilag 2C. Øvrigt Understøtte UNSPSC standarden i den version som det anbefales at bruge i NemHandelsstandarderne (ØK) Kunden skal have adgang til en sandkasse/et testmiljø, der understøtter kundens muligheder for at supportere brugerinstitutionerne (MK) Kommentar [F38]: Få DSP til at give et eksempel. Kommentar [F39]: Lidt restancekrav der er flyttet fra andre afsnit som reelt ikke er funktionelle krav. Kommentar [F40]: KKP Vi havde noget møde om placering af indkøbsaftalekobskategorier i nogle foreslåede elementer. Det arbejde skal vel understøttes af IFS. Kommentar [F41]: Jo, men der står umiddelbart blot at man anbefaler at bruge version , da det er den eneste som er oversat. Så hvis det stadig er korrekt, er det vel denne man SKAL bruge? Kan ikke finde info vedr. UNSPSC på digst.dk. JMH: GS1 er ved at lave en ny oversættelse til dansk Kommentar [F42]: Mere om værktøjer og muligheder Kommentar [F43]: Afsnittet skal slette Side 74 af 95

75 2A.6 Ikke-funktionelle krav Følgende kapitel indeholder de tekniske og ikke-funktionelle krav til IFS. Derved forstås f.eks. arkitekturprincipper, krav til integrationerne, brugervenlighed, tilgængelighed samt lovgivningsmæssige og politiske krav. Hvor funktionelle krav beskriver funktionalitet, som IFS skal stille til rådighed, beskriver ikke-funktionelle krav egenskaberne, hvormed IFS leverer funktionaliteten. 2A.6.1 Struktur, fleksibilitet og Platform Det er kundens ønske at IFS skal være et standardsystem, der stilles til rådighed for kunden med et minimum af tilretninger. Men samtidig vil IFS 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 IFS 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 IFS skal være et eksisterende standardsystem. 2A A A IFS skal understøtte fællesoffentlige standarder. Dette betyder bl.a., at Tjenesteyder skal forholde sig til kravene i folketingsbeslutningen B103 4, i det omfang det er relevant, samt at IFS skal understøtte de fælles OIO-standarder for NemHandel i den udstrækning det er defineret i nærværende kravspecifikation (PK) Data skal vedligeholdes ét sted og genbruges på tværs af Statens systemportefølje. Dette betyder fx, at stamdata vedr. kreditorer og kontoplaner som udgangspunkt fødes og vedligeholdes i Navision Stat installationerne (PK) IFS skal fremadrettet kunne integrere med andre systemer med Webservices baseret på Digitaliseringsstyrelsens OWSA Model T 5 og OIO Serviceorienteret Infrastruktur (OIOSI). Kunden ønsker fx at det på sigt bliver muligt at overføre brugerstamdata til IFS via en webservice (PK) 4 Se: vejledning/~/media/files/arkitektur%20og%20standarder/%c3%85bne%20standarder%2 0vejledning/Vejledning_om_abne_standarder.ashx 5 ashx Side 75 af 95

76 2A A Integration mellem løsninger, internt såvel som eksternt, skal så vidt muligt foretages via samme integrationsarkitektur (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Strukturen i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Strukturen i IFS] 2A A A A A A A A A Platform IFS 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) 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 teablet 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) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Platforme i IFS i underbilag 2B (PK) Side 76 af 95

77 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Platforme i IFS] 2A Log ind og adgangsforhold Introduktion: Moderniseringsstyrelsen ønsker på sigt at etablere en moderne, fødereret model for brugerstyring, som IFS skal være forberedt på at indgå i. Med en fødereret model menes, at applikationer ikke selv har sit eget lokale brugerkatalog, hvor brugerne er oprettet og tildelt rettigheder, men at brugerens identitets- og rettighedsoplysninger formidles til applikationen eksternt fra via et såkaldt security token (billet), når brugeren logger ind. Security Tokens udstedes af en Identity Provider, som stilles til rådighed enten af Moderniseringsstyrelsen og/eller af de organisationer, som skal tilgå IFS. Det forventes, at den fødererede model for brugerstyring indfases trinvist: 1. Ved driftsstart anvendes en traditionel brugerstyringsmodel, hvor applikationen som hidtil opererer med sit eget lokale brugerkatalog, hvor brugerne oprettes og tildeles et kodeord samt rettigheder. 2. Næste trin er at brugerne kan logge ind til applikationen gennem en ekstern Identity Provider. Dette giver brugerne en oplevelse af single sign-on, samt at de ikke behøver et selvstændigt password til IFS. Brugerne skal stadig oprettes og administreres i applikationens brugerkatalog af brugeradministratorer. I denne fase etableres account-linking, således at brugerens identitet kan oversættes mellem Identity Provideren og IFS applikationens lokale brugeridentitet. 3. Det sidste trin består i, at brugernes rettigheder (udover identitet) medsendes i SAML tokens udstedt af en Identity Provider. Hermed administreres rettigheder nu i eksterne brugerkataloger (fx brugernes hjemmedomæne), og IFS applikationen har ikke længere behov for sit eget brugerkatalog eller modul til brugeradministration. Til en start forventes Identity Providere at blive stillet til rådighed af de organisationer, der ønsker at tilgå IFS (brugerorganisationer). På et senere tidspunkt forventes en SAML proxy etableret (Context Handler) enten af Moderniseringsstyrelsen eller af Digitaliseringsstyrelsen i regi af NemLog-in og fællesoffentlig brugerstyring. Uanset antallet af disse Identity Providere vil integrationen til IFS ske med samme snitflade. Krav til fase 1: 2A Adgangsforhold til IFS skal reguleres ved brug af brugernavn og password (MK) Side 77 af 95

78 2A A A A A En bruger skal kunne bestille et nyt password som IFS automatisk sender til brugerens adresse, hvis brugeren har glemt sit password (PK) Der skal kunne defineres en politik for passwords, som sikrer kvaliteten af disse eksempelvis gennem en minimumslængde, brug af store/små bogstaver, specialtegn etc. (PK) IFS skal kunne tilgås via Internettet ved anvendelse af gængse browsere, fx MS Explorer, Google Chrome, Mozilla Firefox og Safari. Tilbudsgiver skal i løsningsbeskrivelsen angive hvilke browsere, herunder hvilke versioner, der understøttes af IFS, samt tilbudsgivers politik for hvilke versioner der understøttes fremadrettet (PK) 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) 2A Sessionen skal lave en time out efter et antal minutters inaktivitet, fx efter 30 minutters inaktivitet. Timeoutperioden skal være konfigurerbar (PK) 2A A A Tilbudsgiver skal i løsningsbeskrivelsen redegøre, hvad der gemmes, når sessionen laver time out, herunder mulighed for at gemme (PK): Indkøbskurv Igangværende behandling af forretningsdokument, fx kontering Rapportvisning Søgeresultat IFS 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) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Log ind og adgangsforhold i fase 1 i IFS i underbilag 2B (PK) Side 78 af 95

79 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Log ind og adgangsforhold i fase 1 i IFS] Krav til fase 2: 2A A A A A A IFS skal understøtte log-in via en ekstern Identity Provider til applikationen, således at brugerne ikke skal logge på IFS med selvstændigt brugernavn og kodeord, og så brugerne oplever single sign-on (PK) IFS skal overholde den fællesoffentlige OIOSAML standard 6 i rollen som SAML Service Provider ved integration til eksterne Identity Providere. Det er ikke nødvendigt at medtage alle attributter fra OCES attributprofilen, men brugerens unikke ID skal som minimum kunne overføres via Subject elementet i den SAML Assertion, der modtages fra Identity Provideren (ØK) IFS skal integreres med en eller flere Identity Providere (via OIOSAMLsnitfladen), der stilles til rådighed af Moderniseringsstyrelsen og/eller de myndigheder, hvis medarbejdere skal have adgang. Integrationen konfigureres ved udveksling af SAML metadatafiler med de relevante parter. Såfremt der integreres med mere end én Identity Provider, må IFS kunne spørge brugeren, hvilken Identity Provider vedkommende ønsker at anvende til log-in, samt efterfølgende huske brugerens valg via en browser cookie eller lignende (ØK) Første gang en bruger logger på IFS via en ekstern Identity Provider, skal der etableres account linking til den lokale brugeridentitet, som findes i applikationens eget brugerkatalog. Dette gøres ved at bede brugeren om at logge på den første gang på traditionel vis (med brugernavn og kodeord), hvorefter sammenhængen mellem ID i modtaget SAML Assertion og lokal bruger ID gemmes. Herefter må brugerne ikke blive tvunget til at anvende brugernavn og kodeord ved log-in (ØK) IFS skal understøtte SAML Single Logout både som initierende part og som ikke-initierende part (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Log ind og adgangsforhold i fase 2 i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Side 79 af 95

80 2. Eventuelle yderligere forhold der understøtter Log ind og adgangsforhold i fase 2 i IFS] Krav til fase 3: 2A A A A A A IFS skal understøtte, at brugernes rettigheder modtages via en SAML Assertion udstedt af en ekstern Identity Provider. Adgangskontrollen baseres på den brugeridentitet og de rettigheder, som er angivet i brugerens SAML Assertion (ØK) IFS skal understøtte en rettighedsmodel bestående af et antal systemroller, hvortil der kan tilknyttes en eller flere dataafgræsninger, der begrænser rollens virkefelt ( todimensionelle roller). Dette kan eksempelvis være en rolle, som tillader en bestemt handling / operation, hvor dataafgrænsningen så yderligere specificerer, at den kan udføres på/for en bestemt organisatorisk enhed (ØK) IFS skal kunne modtage brugerens rettigheder udtrykt i en SAML Assertion i henhold til OIOSAML Basic Privilege Profile eller lignende. Her udtrykkes systemroller som en URI, og de tilhørende dataafgrænsninger udtrykkes som scope attributter på rolleelementet. Der vil være behov for at definere de specifikke dataafgrænsninger, som IFS understøtter (ØK) IFS skal understøtte, at en ny/ukendt bruger får adgang alene på baggrund af en modtaget SAML Assertion dvs. uden at brugeren forinden er oprettet i det lokale brugerkatalog. Hvis der er behov for at holde brugere i brugerkataloget, må applikationen selv foretage just-in-time oprettelse af brugeren i forbindelse med log-in (ØK) IFS skal publicere sine systemroller (inkl. de tilhørende URI er (Uniform Resource Identifier) samt tilhørende dataafgrænsninger, så de kan tildeles brugere i eksterne brugerkataloger (typisk brugernes hjemorganisation). Dette kan enten ske via et web-baseret eller web service interface (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Log ind og adgangsforhold i fase 3 i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Log ind og adgangsforhold i fase 3 i IFS] 7 Side 80 af 95

81 2A.6.2 2A A NemHandel Dataudvekslingen mellem Statens vareleverandører og IFS skal ske gennem Digitaliseringesstyrelsens NemHandel infrastrukturen 8. NemHandel består af OIOUBL, OIORASP og NemHandelsregisteret med tilhørende services. En teknisk introduktion til NemHandel findes her: Bemærk, selvom OIORASP er en profilering af internationale standarder, har deri praksis vist sig komplikationer mht. at sikre interoperabilitet mellem forskellige implementeringer af disse standarder. Derfor er.net og Java implementeringerne af OIORASP blevet gennemtestet, så der er sikret interoperabilitet mellem disse. Det anbefales derfor at basere NemHandel løsninger på disse biblioteker i stedet for at udvikle egne implementeringer af OIORASP profilen. Information om bibliotekerne findes her:.net: Java: De OIOUBL profiler der kan anvendes i NemHandel er beskrevet i OIOUBL Guideline G26 9. Det skal bemærkes at der er udgivet et rettelsesblad til guidelinen, som kan tilgås fra FAQen om profilerne. IFS skal overholde og anvende Digitaliseringsstyrelsens standarder for NemHandel (OIOUBL, OIORASP og NemHandelsregisteret) (MK) IFS skal som minimum understøtte følgende NemHandelsprofiler (MK): urn: (Billing Basic) Procurement-BilSim-1.0 Procurement-OrdSimR-BilSim-1.0 Catalogue-CatBas-1.0 Catalogue-CatSim-1.0 Procurement-BilSimR-1.0 Procurement-OrdAdv-BilSim-1.0 Procurement-OrdAdv-BilSimR-1.0 Procurement-PayBas-1.0 Kommentar [F44]: Definiti oner: OIOUBL+RASP = OIOSI; OIOSI + NemHandelsregisteret = NemHandel Kommentar [F45]: HSS definitionerne bør være OIOUBL+OIORASP (OIORASP blev førhen kaldt OIOSI) + NemHandelsregisteret og tilhørende services = NemHandel. Kommentar [F46]: Vi skal lige vende om I har brug for NES order only og Catalogue only en FAQ vedrørende profilerne findes her: Side 81 af 95

82 Procurement-PayBasR-1.0 Catalogue-CatExt-1.0 Catalogue-CatExtR-1.0 Reference-Utility-1.0 Reference-UtilityR-1.0 2A A IFS skal understøtte alle NemHandelsprofiler (PK) IFS skal løbende tilpasses ændringer og forbedringer i de gældende OIOstandarder for NemHandel, herunder såvel ændringer og forbedringer til forretningsdokumenter og ændringer og forbedringer til infrastruktur. Tjenesteyder skal i den forbindelse være opmærksom på (PK): 2A A A A A Revisions- og opdateringsstrategi for NemHandel-Infrastrukturen 10 - Opdateringsstrategi for OIOUBL referenceimplementationer 11 - Opdaterings- og Versioneringsstrategi for OIOUBL 12 Systemet skal validere, at modtagne dokumenter opfylder de fastsatte OIOformatkrav (PK) Opfylder et modtaget dokument ikke OIO-formatkravene, skal systemet afvise dokumentet og der skal sendes besked herom til afsenderen (PK) Systemet skal validere, at dokumenter opfylder de fastsatte OIO-formatkrav inden de afsendes (PK) Tjenesteyder er ansvarlig for at dokumentere, at IFS følger NemHandelsstandarderne (PK) Der kan opstå behov for at tilpasse IFS til ændringer i OIO- standarderne, der samtidig skal implementeres i Navision Stat. I disse tilfælde vil det være nødvendigt at begge systemer er opdaterede således at der kan ske en løbende implementering af Navision Stat ændringerne (fx indlæsning af en servicepack). Det forventes, at den normale implementeringsperiode for Navision Stat ændringer vil være 6 måneder, således at en ændring, der fx skal træde i kraft den 1/1 skal være teknisk implementeret i såvel IFS som NS senest den 1/7 (6 måneder inden ikrafttræden). Såfremt ændringer i NemHandels-standarderne kræver, at der både skal ske ændringer i IFS og Navision Stat, skal ændringerne være implementeret i IFS Kommentar [F47]: KKP Modtaget fra tredjepart. I den interne kommunikation som sker på NS profiler vil der være enkelte afvigelser eksempelvis profilangivelsen i applicationresponse Side 82 af 95

83 senest 6 måneder inden ikrafttræden for at ændringerne kan implementeres i brugerinstitutionerne inden ikrafttræden (PK) 2A A Da de enkelte Navision Stat installationer opdateres for sig, skal Tjenesteyder ved ændringer i NemHandels-standarderne sideløbende kunne understøtte to sæt af NemHandelsprofiler i den periode hvor Navision Stat installationerne bliver opdateret (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter NemHandel i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Nemhandel i IFS] 2A A A.6.3 2A OpenPeppol OpenPeppol 13 er en paneuropæisk NotForProfit organisation som står for at vedligeholde og udvikle infrastruktur og standarder til brug for elektronisk indkøb i den offentlige sektor i Europa. Tjenesteyder bør være opmærksom på at det er sandsynligt at Peppol standarderne bliver obligatoriske at anvende i løbet af kontraktens løbetid, og at det i så fald vil følge af kravene om tilpasning til NemHandelsstandarderne at IFS skal tilpasses Peppolstandarderne som en del af den almindelige driftsydelse IFS skal være tilknyttet PEPPOL infrastrukturen og understøtte en eller flere PEPPOL BIS standarder, eller tilbyde konvertering til og fra PEPPOL BIS (ØK) Integrationer IFS skal udveksle data med Statens vareleverandører, Navision Stat og ØS LDV. I det følgende beskrives kravene til de enkelte integrationer. Fokus er de forventede OIOUBL datastrømme, der skal håndteres imellem de involverede systemer, men der beskrives også alternative muligheder for dataudveksling: Tjenesteyder er ansvarlig for at sikre, at alle integrationer kan opsættes. Kunden ser helst at Tjenesteyder levere værktøjer til Kunden, der sætter kunden i stand til at opsætte integrationer mellem den enkelte Navision Stat installation og IFS, men i det omfang Tjenesteyder ikke leverer værktøjer der sætter Kunden i stand til selv at gennemfører opsætning af integrationerne mellem IFS og Navision Stat, er Tjenesteyder forpligtet til som en del af den Kommentar [F48]: Ny reference tilføjet Side 83 af 95

84 almene drift, at assistere ved opsætningen af integrationerne, herunder så alle tidsfrister i hovedtidsplanen kan overholdes (PK) 2A A Tjenesteyder skal udvikle og vedligeholde alle integrationer som en del af driftsydelsen, med bistand fra relevante parter, herunder Kundens Navision Stat- og ØS LDV-afdelinger i overensstemmelse med rammerne angivet i bilag 4 Drift, vedligehold og support og bilag 9 Samarbejdsorganisationen (PK) Ved dokumentation af integrationer skal Tjenesteyder altid tydeligt redegøre for følgende (PK): Datakilde (Fx et modul eller en service i IFS) Afsender (Fx IFS) Modtager (Fx Navision Stat) Dataformat (Fx OIOUBL) Transportprotokol (Fx OIORASP) Sikkerhed (Fx RASP) Kvittering (Fx ApplicationResponse) Frekvens (Fx med det samme eller dagligt ) 2A A A A Tjenesteyder skal desuden redegøre for hvordan evt. endpoints og profiler administreres og vedligeholdes (Fx gennem NemHandels-registeret) (PK) Tjenesteyder skal overvåge, hver enkelt integration og informere Kunden og sørge for afhjælpning, hvis der opstår fejl i en integration eller hvis en overførsel ikke er gennemført korrekt (PK) Tjenesteyder skal for hver enkelt integration tydeligt redegøre for hvilke værktøjer, der stilles til rådighed for henholdsvis Kundens globale systemadministratorer og brugerinstitutionernes lokale systemadministratorer, der kan anvendes til systematisk at følge op på, hvilke data og forretningsdokumenter der er modtaget korrekt i IFS, hvilke data og forretningsdokumenter der er modtaget, men afvist eller fejlet i IFS, samt hvilke data og forretningsdokumenter der er sendt fra IFS, og om modtager af data og forretningsdokumenter fra IFS har afvist -, kvitteret for- eller ikke svaret på overførslen (PK) Tjenesteyder skal for hver enkelt integration tydeligt redegøre for hvilke processer kunden skal anvende for at håndtere fejl og afvisninger i forbindelse med overførsel af data og dokumenter fra og til IFS (PK) Tjenesteyder skal for hver enkelt integration tydeligt redegøre for, hvilke processer og værktøjer kunden kan anvende for at afstemme data overført fra eller til IFS med data hos modtager eller afsender, så fx fakturadata i IFS kan afstemmes op mod fakturadata i Navision Stat (PK) Kommentar [F49]: KKP Her viser compliance vel blot en form for engagement i drift af løsningen. En del af problemet kan jo ligge i NS installationen, som udbyderen ikke har nogen indflydelse på. JMH: Ja, ansvarsfordelingen skal tydeliggøres Kommentar [F50]: Måske et ambitiøst krav? Tør vi stole på at vi kan klare det i LDV? Og det dækker jo ikke ordrer. Side 84 af 95

85 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Integrationer i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Integrationer i IFS] 2A Integration til Statens vareleverandører Dataudvekslingen med Statens vareleverandører skal kunne ske gennem NemHandels-infrastrukturen som beskrevet i afsnit 2A.6.2. Da Statens vareleverandører har varierende parathedsniveau i forhold til at understøtte NemHandel ønskes det, at IFS også understøtte andre former for digital kommunikation med Statens vareleverandører. Under de funktionelle krav er der stillet en række specifikke krav til værktøjer fx i form af et katalogværktøj som beskrevet i afsnit 2A og i form af systemgenererede s, som erstatning for OIOUBL dokumenter, for de vareleverandører der ikke kan modtage et givet dokument. Som en del af IFS ønskes der værktøjer, som understøtter digitale indkøb hos statens vareleverandører, uanset om de er vareleverandører af type A (fuld NemHandels-understøttelse), eller er vareleverandører af type B (minimal NemHandels-understøttelse) eller har et parathedsniveau et sted der imellem. IFS bør derfor være fleksibelt og stille egnede værktøjer til rådighed for kunden og vareleverandører, som understøtter den elektroniske indkøbsproces og som tager højde leverandørernes varierende NemHandelsparathed. Kravene skal ses som et supplement til de funktionelle krav og kravene under afsnit 2A.6.2 om NemHandel, og som en mulighed for tjenesteyder for at redegøre for øvrige standardværktøjer der følger med IFS og som understøtter den digitale indkøbsproces: 2A A Tjenesteyder skal som en del af IFS stille værktøjer til rådighed der som en naturlig del af den digitale indkøbsproces faciliterer nem kommunikation mellem en brugerinstitution og dennes vareleverandører af type A og dennes vareleverandører af Type B. Fx kunne der være tale om en portal som leverandørerne har adgang til, der gør det muligt at chatte med indkøberne i IFS (PK) Tjenesteyder skal som en del af IFS stille værktøjer til rådighed, for vareleverandører af Type A og for vareleverandører af Type B, der sikrer at data forbliver ensartet under hele den digitale indkøbsproces, så der kan opnås høj grad af automatch mellem fakturaer og ordrer mv. Fx kunne der være tale Side 85 af 95

86 2A A A A A A A om at katalogværktøjet også giver en vareleverandør mulighed for at modtage en elektronisk ordre i værktøjet og at vende ordren til en faktura der sendes retur til brugerinstitutionen (PK) IFS skal understøtte, at der for hver vareleverandør (kreditor) i IFS automatisk angives hvordan samhandelen med vareleverandøren foregår (fx om vareleverandøren modtager ordrer som s eller OIOUBL dokumenter), herunder skal det fremgå, hvis vareleverandøren anvender nogen af de værktøjer der er omfattet af krav 2A og krav 2A (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Integration til Statens vareleverandører i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Integration til Statens vareleverandører i IFS] Punch out til webshops Jf. krav 2A skal en indkøber fra IFS have mulighed for at tilgå en vareleverandørs webshop ved hjælp af punch out funktionalitet. I det følgende angives de bagvedliggende ikke-funktionelle krav til punch-out funktionaliteten: Tjenesteyder skal, som en del af ydelsen, levere funktionalitet, der giver mulighed for at foretage punch out til fx webshops og indkøbsportaler. Punch out løsningen skal i videst muligt omfang etableres ved hjælp af OIOUBL- eller øvrige OIO-standarder eller evt. eksisterende de facto standarder, hvis der ikke er OIO-standarder på området (ØK) IFS skal så vidt muligt, afhængigt af mulighederne på webshoppen, kunne sikre, at man går direkte til den relevante del af webshoppen. Fx kan der i IFS angives, at kontorstole skal indkøbes på en webshop. Her skal brugeren føres direkte til den del af webshoppen, der vedrører kontorstole og ikke til forsiden, der giver mulighed for indkøb af alle typer kontormøbler (ØK) Dataleveringen fra en webshop skal være varelinjer, der efterfølgende kan behandles på samme måde som øvrige varelinjer i IFS (ØK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Punch out til webshops i IFS i underbilag 2B (PK) Kommentar [F51]: Man kunne overveje at tilføje krav om at de kan sende til leverandørens Digitale Postkasse, når/hvis det på et tidspunkt bliver muligt. Kommentar [F52]: Mangler her noget om opslag på NemHandelsregisteret? Side 86 af 95

87 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Punch out til webshops i IFS] 2A Integration til Navision Stat 2A A A A Som tidligere beskrevet indgår, IFS som en del af den samlede systempakke Moderniseringsstyrelsen tilbyder de statslige myndigheder og selvejende institutioner på det økonomisk administrative område. Det er derfor væsentligt, at samspillet mellem IFS og Navision Stat er tilrettelagt på en måde, der giver brugerne af begge systemer den bedst mulige funktionalitet i deres daglige arbejdsopgaver. Afsnittet er bygget op så datastrømmen fra IFS til Navision Stat og datastrømmen fra Navision Stat til IFS er beskrevet hver for sig. Tekniske og forretningsmæssige kvitteringer beskrives under den datastrøm der svares på, så ApplicationResponses der sendes fra Navision Stat til IFS er fx dækket af afsnittet om, hvilke data der skal overføres fra IFS til Navision Stat. Vedligeholdelse af IFS i relation til Navision Stat er beskrevet i bilag 4: Drift-, support og vedligeholdelsesydelser. IFS skal understøtte, at integrationen kan ske til flere separate Navision installationer og regnskaber. (MK) Fra IFS til Navision Stat, generelt: Fra IFS til Navision Stat skal der overføres forretningsdokumenter og returneres ApplicationResponses, i de formater der anvendes i NemHandel. Der returneres ApplicationResponses både i form af positive og negative tekniske kvitteringer og i form af positive og negative forretningskvitteringer. Forretningsdokumenter der overføres fra IFS til Navision Stat, og ApplicationResponses der returneres skal overholde standarderne i NemHandel/skal overføres i OIOUBL format (MK) Headeroplysningerne på dokumenter modtaget i IFS, skal bevares så de fremgår uforandret når de godkendte dokumenter overføres til Navision Stat, og Schematron valideringerne skal overholdes for de godkendte dokumenter der sendes til Navision Stat (PK) IFS skal, jf. de funktionelle krav, overføre fakturaer, kreditnotaer, rykkere og kontoudtog til Navision Stat når forretningsdokumentet godkendes, eller når forretningsdokumentet accepteres eller lignende, hvis der ikke er en Kommentar [F53]: IFS skal generelt understøtte det officielt udmeldte roadmap for NS. Helt generelt gælder det, at IFS generelt skal understøtte den seneste frigivne udgave af NS samt en version ældre end den senest frigivne udgave i en overgangsperiode, da NS installationerne altid opgraderes sekventielt. Kommentar [F54]: Vi bør vel have noget om NS opgraderingsstrategi her? Kommentar [F55]: Bemærk at schematronvalideringen skal ske på basis af de officielle profiler, dvs ved modtagelse af E-bilaget fra vareleverandøren i IFS, og IKKE ifm. afsendelse fra IFS til NS, hvor udvekslingen skal ske på NS-profiler, hvortil der ikke bygges schematronvalidering. Side 87 af 95

88 2A A A A A A godkendelseshandling i workflowet for dokumentet (det kan være tilfældet for kontoudtog og for rykkere uden en betalingsanmodning) (MK) Overførslen af et forretningsdokument fra IFS til Navision Stat skal ske så snart dokumentet er godkendt eller lignende og indlæsning af returnerede ApplicationResponses skal ske så snart ApplicationResponsen er afleveret fra Navision Stat til Tjenesteyders system (PK) Hvis fakturaer, kreditnotaer og rykkere kan omkonteres i IFS, skal det omkonterede dokument fremsendes til Navision Stat sammen med et dokument der udligner det oprindelige dokument. Omkonteres der fx en faktura i IFS skal systemet fremsende en kopi af fakturaen og en kompenserende kreditnota til Navision Stat (ØK) Dokumenter der fremsendes til Navision Stat som følge af en omkontering, skal være tydeligt markeret så de ikke kan udtages til betaling i Navision (ØK) IFS skal overføre UTS-dokumenter til Navision Stat, jf. krav 2A (PK) Overførslen af data fra IFS til Navision Stat skal ske gennem NemHandelsinfrastrukturen (PK) Tekniske specifikationer og krav til integrationen er beskrevet og kravsat yderligere i bilag 2E Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Integrationen fra IFS til Navision Stat i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Integrationen fra IFS til Navision Stat] Fra Navision Stat til IFS: Fra Navision Stat til IFS overføres der Stamdata og Transaktionsdata og der skal svares med kvitteringer. Stamdata og Transaktionsdata vil typisk eksporteres fra Navision Stat via. et batchjob, der kører automatisk en gang i døgnet, samt når overførslen initieres manuelt af en bruger fra Navision Stat. Data kan 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. Nedenstående er Kundens generelle krav for Stamdata- og Transaktionsdataoverførslen fra Navision Stat til IFS. Det er kundens ønske at Kommentar [F56]: Der returneres både tekniske og forretningsmæssige application responses (fremhæv) KKP NS kan pt. sende flere applikationsresponses for samme dokument eksempelvis Teknisk modtagelseskvittering, ForretningsAfvis og ForretningsAccept. Kommentar [F57]: Og hvordan er det vi gør det i praksis? KKP. Det kræver fremsendelse af et dokument der modposterer det oprindelige dokument på alle konti og dimensioner og derefter fremsender et dokument der gen-fremfører alle oprindelige beløb på de nye konteringer. De to dokumenter skal være særligt markeret i dimensionskontostrengen og have egne dokumentnumre. Vi kan... Kommentar [F58]: Nej, der findes ikke ApplicationResponses til denne type af dokumenter. Her vil vi stille os tilfreds med en transportkvittering à la den der findes i en RASP kvittering afhængigt af om der vælges model A eller B. Kommentar [F59]: Er vel ikke helt korrekt? KKP I den eksisterende løsning kan en bruger med rettigheder i NS initiere stamdata og transaktionsdata udtræk og forsendelse. For transaktionsdata kan der vælges delta eller fuld. Side 88 af 95

89 overførsel af stam- og transaktionsdata som udgangspunkt sker som deltaoverførsler, og at der alene overføres et fuldt datasæt, for at afhjælpe fejl eller ved tilslutning af nye bogføringskredse: 2A A A A A A A A Stamdata og Transaktionsdata skal overføres fra Navision Stat til IFS (MK) IFS skal kunne modtage og indlæse en delta-overførsel af Stamdata fra hver eneste tilknyttede Navision Stat installation op til en gang i timen (PK) IFS skal kunne modtage og indlæse en fuld overførsel af Stamdata fra hver eneste tilknyttede Navision Stat installation op til en gang i døgnet (PK) IFS skal kunne modtage og indlæse en delta-overførsel af Transaktionsdata fra hver eneste tilknyttede Navision Stat installation op til en gang i timen (PK) IFS skal kunne modtage og indlæse en fuld overførsel af Transaktionsdata fra hver eneste tilknyttede Navision Stat installation op til en gang i døgnet (PK) Ved overførsel af stamdata skal evt. eksisterende stamdata ajourføres i IFS. Det indebærer, at alle ændringer (tilføjelser, sletninger, spærringer mv.) i stamdata fra Navision Stat skal slå igennem i IFS (PK) Metoden for dataudveksling, samt datasættet er beskrevet i bilag 2F (MK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Integrationen fra Navision Stat til IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Integrationen fra Navision Stat til IFS] 2A Integration til ØS LDV IFS skal kunne overføre data til ØS LDV. Data skal før overførelsen være organiseret således, at det er forretnings- og rapporteringsmæssigt muligt at arbejde videre med dem i et datavarehus. Det betyder fx at det skal være muligt at skille data, således at brugeradgangen til data kan håndteres via standard SQL brugerhåndtering. Det er vigtigt, at dette ikke opfattes som en rapport-eksport-funktion, hvor brugeren kan vælge at eksportere data i en rapport til fx ØS LDV. Samtlige relevante data skal kunne eksporteres til ØS LDV uafhængigt af rapportdefinitioner og rapportkørsler i kildesystemet for derved at få mulighed for at trække rapporter, der ikke kan trækkes i kildesystemet. Side 89 af 95

90 I underbilag 2G Integration til ØS LDV beskrives udveksling af data fra IFS til ØS LDV samt kundens krav hertil. 2A.6.4 Myndighedskrav 2A A A Tjenesteyder indestår for, at IFS og de øvrige ydelser efter Kontrakten opfylder alle relevante lovkrav og myndighedskrav således som de foreligger ved Kontraktens underskrift jf. Kontraktens pkt. 12. Tilbudsgiver bør i den forbindelse være særligt opmærksom på nedenstående: 1) Persondataloven og klassificering af data 2) Arkivloven 3) Cookiebekendtgørelsen 4) Regnskabsbekendtgørelsen 5) Statens standarder for it-sikkerhed Persondataloven og klassificering af data Persondataloven 14 gælder for behandling af personoplysninger, herunder behandling som sker ved hjælp af elektronisk databehandling. Dvs. at loven gælder, når personoplysninger behandles ved hjælp af computerteknik. Loven gælder også, når personoplysninger sendes over Internettet. IFS skal som udgangspunkt ikke anvendes til at behandle personfølsomme data, jf. Persondataloven, men det kan ikke udelukkes at Statens vareleverandører sender personfølsomme data til IFS. Der vil til gengæld være persondata i IFS. Det gælder desuden at IFS ikke skal anvendes til at behandle fortrolige, hemmelige eller yderst hemmelige data, som beskrevet i Statsministeriets sikkerhedscirkulære 15 IFS skal behandle personoplysninger i overensstemmelse med god databehandlingsskik, jf. Datatilsynets praksis. Det betyder bl.a., at Tjenesteyder skal medvirke til, at oplysninger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med loven (PK) Da data i IFS omfatter persondata må data i IFS jf. persondataloven kun opbevares indenfor EU eller i et sikkert tredjeland (MK) Kommentar [F60]: Bemærk reference mangler PIR: har indsat punkt 12 Kommentar [F61]: Hvad med Nemkontoloven og momsbekendtgørelsen? Kommentar [F62]: JSU: Tilføj bestemmelse om at leverandøren er forpligtet til, at oplyse om eventuelle brud på sikkerheden. Tilføj bestemmelse om, at der skal udleveres oplysninger om de lokationer, hvor data er placeret. Tilføj bestemmelse om, at betingelser skal gælder for underleverandører. JMH: Godkendelse ved skift af underleverandører Tilføj bestemmelse om, at leverandøren er forpligtet til at informere om alle væsentlige ændringer af den interne håndtering af persondata. Ved transmission over åbne netværk skal der være stærk kryptering. Tilføj bestemmelse om at lovvalg i kontrakten følger dansk lovgivning. Side 90 af 95

91 2A A A A A Personlige oplysninger skal kunne slettes eller anonymiseres i IFS, når det ikke længere er nødvendigt for den dataansvarlige at være i besiddelse af oplysningerne i en form, der gør det muligt at identificere den enkelte person (ØK) IFS skal understøtte funktionaliteten på OIOUBL forretningsdokumenterne, der giver mulighed for at angive fortrolighedsniveau, således at det sikres at dokumenter med følsomme oplysninger udsøges i IFS og evt. Routes til særligt sikkerhedsgodkendte brugere (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Persondataloven og klassificering af data i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Persondataloven og klassificering af data i IFS] Arkivloven I henhold til arkivloven har Statens Arkiver bl.a. til formål at sikre opbevaring af arkivalier og at stille arkivalier til rådighed for borgere og myndigheder, herunder til forskningsformål. En stor del af disse arkivalier forefindes alene som elektroniske arkivsystemer. Elektroniske arkivsystemer er Statens Arkivers betegnelse for de IT-systemer, som myndighederne anvender ved forvaltning af deres ressortområde, og dækker bl.a. over registre, databaser samt elektroniske journaler og elektroniske sags- og dokumenthåndteringssystemer. Såfremt IFS vil blive omfattet af arkivloven, skal IFS kunne udlæse de ønskede arkivalier i de formater som kræves af Rigsarkivet, Statens Arkiver 16, som administrerer loven. IFS skal udlæse data i det/de formater og på det aggregeringsniveau, som er forudsat af Statens Arkiver 17 (PK) Kommentar [F63]: Tendens, til modstrid med et krav under brugerstyring om at brugere ikke må slettes. Snittet skal fremgå tydeligt Kommentar [F64]: Vi skal klart beskrive i definitionsafsnittet at fortoligheds mærkatet ikke er det samme som at data er fortrolige ift. Statsministeriets sikkerhedscirkulære Kommentar [F65]: Ikke valideret Det er mindre sandsynligt at data er interessant for Statens Arkiver Men der er et link til ydelser ved ophør, hvor det skal beskrives hvordan leverandøren skal aflevere Statens data 16 Se: e_hensyn_i_elektroniske_arkivsystemer 17 Se: ner.pdf Side 91 af 95

92 2A Processerne der dækkes af ovenstående krav (2A ) er løsningsbeskrevet i underbilag 2B. Tjenesteyder bedes desuden løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Arkivloven i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A Eventuelle yderligere forhold der understøtter Arkivloven i IFS] 2A Cookiebekendtgørelsen Reglerne i Cookiebekendtgørelsen 18 har til formål at beskytte brugernes privatsfære. Med reglerne anlægges den betragtning, at brugernes terminaludstyr udgør en del af brugerens privatsfære, der skal beskyttes mod uretmæssig indtrængen. Terminaludstyr omfatter computere og mobile enheder som smartphones, tablets m.v., hvori der kan lagres oplysninger eller opnås adgang til allerede lagrede oplysninger. 2A A IFS skal overholde reglerne i Cookiebekendtgørelsen (PK) Regnskabsbekendtgørelsen Det statslige regnskabsvæsen er reguleret via henholdsvis Regnskabsloven og Regnskabsbekendtgørelsen 19. Da IFS indeholder regnskabsmateriale skal systemet medvirke til at brugerinstitutionerne kan leve op til de relevante krav i Regnskabsbekendtgørelsen, særligt skal tjenesteyder være opmærksom på 21, stk.1, punkt 3; 21; 43 og 44 2A A A IFS skal indeholde intakte kontrol- og transaktionsspor 20 (PK) IFS skal leve op til alle de relevante krav i regnskabsbekendtgørelsen (PK) Tjenesteyder skal dokumentere at IFS lever op til alle de relevante krav i regnskabsbekendtgørelsen, herunder (PK): hvorledes materialets nøjagtighed er sikret, hvorledes en fuldstændig og nøjagtig registrering er sikret, hvorledes automatisk genererede registreringer foretages, 18 Se: Kontrol og Transaktionsspor er defineret i Bekendtgørelse af bogføringslov kapitel 2: Side 92 af 95

93 hvorledes opbevaringen af regnskabsmateriale sker, herunder de metoder, der benyttes til opbevaring, samt hvordan regnskabsmaterialet fremfindes hvorledes brugerinstitutionerne kan gennemføre de nødvendige kontroller vedrørende anvendelsen af IFS 2A Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Regnskabsbekendtgørelsen i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Regnskabsbekendtgørelsen i IFS] 2A Statens standarder for it-sikkerhed Som en del af Statens it-portefølje skal IFS overholde de relevante krav i Statens standarder for it-sikkerhed. Kravene til sikkerhed i IFS er beskrevet i afsnit XX Sikkerhed Regeringens økonomiudvalg har truffet beslutning om, at statens institutioner skal følge ISO sikkerhedsstandarden, når den nye udgave af standarden foreligger i dansk oversættelse. Det forventes at ske i oktober Beslutningen om brug af ISO som standard for sikkerhedsstyringen i stedet for DS484 er en følge af Finansministeriets plan for enkel administration i staten. Kundens krav til Tjenesteyder vedrørende sikkerhed fremgår af bilag 8 Sikkerhed og Katastrofeberedskab. 2A.6.5 Performance, servicemål og vedligeholdelse Krav til svartider, reaktionstid og tilgængelighed er specificeret yderligere i bilag 6 Servicemål og bodsbestemmelser. Krav til vedligeholdelse, drift, support og dokumentation er specificeret yderligere i bilag 4 Drift, vedligehold, og support. 21 Styring af informationssikkerhed i staten efter ISO er yderligere beskrevet her: Side 93 af 95

94 Krav til afprøvning er specificeret i bilag 7 prøver. 2A A A A A A.6.6 2A A A A A A IFS skal være skalerbar i forhold til antal brugere og datamænger (PK) Det skal sikres, at performance hos brugere ikke påvirkes af fx rapportgenerering, katalogadministration eller integration af nye brugerinstitutioner, vareleverandører eller andre Kunder på IFS (PK) Ved afbrud i kørsler og datatransport må det ikke have indflydelse på afvikling af selve IFS-applikationen, og brugeren skal kunne arbejde videre så længe en eventuel udbedring står på (PK) Ved afbrud i kørsler og datatransport skal data ikke mistes, der skal ske logning og IFS skal således oplyse om fejl, status og hvordan brugerne kan komme videre (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Perfomance i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Performance i IFS] Historik og logning De historiske transaktions- og kontrolspor skal bibeholdes, således at lokale og globale systemadministratorer kan genskabe transaktionssporene (PK) IFS skal understøtte logning af alle data, transaktioner, godkendelser mv. så alle handlinger i IFS dokumenteres (PK) Logning forstås som registrering og beskyttelse af information om brugers (eller services ) aktiviteter således, at der i relevante tilfælde er mulighed for at etablere et transaktionsspor eller udføre andre kontroller i forhold til anvendelsen af it-systemer (PK) IFS skal understøtte fuld audit på alle forpligtende handlinger, der foretages af brugere i IFS (PK) Kunden skal selv kunne udtrækkes rapporter og foretages udsøgninger i det loggede. For disse rapporter gælder samme krav som til øvrige rapporter (PK) Når der trækkes historik, skal IFS angive personaktører ved navn (ikke rolle, initialer eller andet)(pk) Kommentar [F66]: JSU: Sikkerhedsbekendtgørelsen stiller specifikt krav om logning af al anvendelse af persondata. Registreringen skal mindst indeholde oplysning om tidspunkt, bruger, type af anvendelse og angivelse af den person de anvendte oplysninger vedrører eller det anvendte søgekriterium. Tilføj bestemmelse om at loggen skal opbevares i 6 måneder, hvorefter den skal slettes. (Men regnskabsdata skal gemmes i 5 år, og det er et hensyn der vejer tungere) Tilføj specifik bestemmelse om logning af alle afviste adgangsforsøg. (Hvis der registreres X antal afviste adgangsforsøg fra samme bruger indenfor en fastsat periode, skal denne blokeres.) 18 (skulle være noget nyt på vej). Kommentar [F67]: PIR: Navn og initialer, da der ellers kan opstå problemer ved flere brugere med samme navn Side 94 af 95

95 2A A A.6.7 2A.6.8 2A A A Tjenesteyder skal logge hvem der tilgår systemet og hvorfra. Tjenesteyder skal overvåge og løbende gennemgå denne log med henblik på at identificere forsøg på misbrug (PK) Processerne der dækkes af ovenstående krav (2A A ) er løsningsbeskrive eventuelle yderligere forhold der fleksibelt, intuitivt og brugervenligt understøtter Historik og logning i IFS i underbilag 2B (PK) 1. Processerne der dækkes af krav 2A A Eventuelle yderligere forhold der understøtter Historik og logning i IFS] Brugervenlighed Brugermanualer Tjenesteyder skal stille brugervejledning/brugermanual til rådighed for kunden (MK) Tjenesteyder skal levere materiale i form af vejledninger og manualer til IFS af høj standard, der sætter brugerne i stand til at udføre de beskrevne opgaver uden yderligere hjælp (PK) Tilbudsgiver skal i sin løsningsbeskrivelse angive hvordan den tilbudte løsning opfylder ovenstående krav (PK) [Tilbudsgiver udfylder reference til sin løsningsbeskrivelse] Kommentar [F68]: Tilføj krav 2A.6.9 Øvrige krav til brugermanualer er specificeret i bilag 4 Drift, vedligehold og support Andre ydelser 2A.7 Tidsplan mv. 2A.7.1 2A.7.2 Indledning Tidsplan Kommentar [F69]: Her skal indsættes krav der refererer til bilag 5 og 10 Kommentar [F70]: Kort afsnit med ref. Til bilag 1, 3 og 9, samt evt 11 og 12 2A.8 Compliance skema Side 95 af 95