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