Kravspecifikation - IFS

Transkript

1 2A Kravspecifikation - IFS

2 2A.1 INTRODUKTION TIL DET ØNSKEDE SYSTEM A.2 ARBEJDSGANGE I IFS A.3 INTRODUKTION TIL INTEGRATIONER A.4 FUNKTIONELLE KRAV A.4.1 Overordnede krav A.4.2 Koncernstruktur og administrative fællesskaber A.4.3 Brugere, roller og rettigheder A.4.4 Oprettelse af vareleverandører i IFS A.4.5 Aftaler A.4.6 Kataloger og punch-out A.4.7 Favoritlister A.4.8 Indkøbskurv A.4.9 Rekvisition og ordreafgivelse A.4.10 Varemodtagelse A.4.11 Fakturaer A.4.12 Generelt om anvendelse af IFS, dokumentbehandling og kontering A.4.13 Kreditnotaer A.4.14 Rykkere og kontoudtog A.4.15 Forsyningsspecifikationer (UTS) A.4.16 Søgning i IFS A.4.17 Systemkonfiguration A.4.18 Rapportering A.4.19 Øvrigt A.5 IKKE-FUNKTIONELLE KRAV A.5.1 OIO standarder A.5.2 Arkitektur, Struktur og Platform A.5.3 Brugergrænseflade A.5.4 Log ind og adgangsforhold A.5.5 Integrationer A.5.6 Performance, servicemål og vedligeholdelse A.5.7 Sikkerhed A.5.8 Historik og logning A.5.9 Brugermanualer A.5.10 Myndighedskrav, relevante love mv A.6 AFKLARINGSFASE, SYSTEMBESKRIVELSE OG TIDSPLAN A.7 COMPLIANCE SKEMA Side 2 af 74

3 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. Kommentar [F1]: Præciser når det ligger helt fast, hvad vi har gjort IFS skal integreres med Navision Stat samt Statens data-varehus, ØSLDV. 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 2C, eller Side 3 af 74

4 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, og IFS skal i princippet kunne benyttes af alle medarbejdere i de omfattede myndigheder og selvejende institutioner. Kommentar [F2]: Afsnittet skal være en slags light udgave af Best Practice, afsnittet er ikke skrevet, der er alene tale om lidt foreløbige input nedenfor som skal med i en eller anden form 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 nedenstående Best Practice processer, jf. Best Practice processer for digital Indkøbs- og Fakturahåndtering. Figur XX: Best Practice Procesdiagram 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: [Indsæt reference] Side 4 af 74

5 2A.3 Introduktion til integrationer Kommentar [F3]: Under udarbejdelse 2A.4 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. 2A.4.1 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. Overordnede krav 2A Systemet skal understøtte effektiv fakturahåndtering for brugerinstitutionerne (MK) Kommentar [F4]: Det kan overvejes om kravene skal stå før de funktionelle krav, da nogen af dem nærmer sig øvrige krav 2A A A A A A A A A A Systemet skal understøtte effektive digitale indkøb både med og uden elektroniske varekataloger (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) Systemet skal understøtte NemHandel og OIO-standarderne på e-handelsområdet (MK) Systemet skal integreres til Navision Stat (MK) Systemet skal integreres med statens datavarehus, ØSLDV (MK) Systemet skal være opbygget som et koncernsystem for staten, så systemet understøtte 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 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) Kommentar [F5]: Det er meget væsentligt, at der indarbejdes mekanismer i kontraktmaterialet der gør at vi kan vurdere på dette, det overvejes at svar på use cases skal leveres som videofilm Side 5 af 74

6 2A Systemet skal være sikkert og understøtte principperne i ISO27001 standarden (MK) 2A.4.2 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 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. Kommentar [F6]: Scenarier til use cases: Use case 1: Administrativt fællesskab i et ministerium Use case 2: Indkøbsfællesskab, med fælles kataloger Use case 3: Den globale supporter Use case 4: En ressortændring 2A A En global systemadministrator skal kunne oprette, ændre og spærre organisationsenheder i IFS, således at de fx kan administrere oprettelsen af en ny institution eller sammenlægning af to institutioner (PK) En global systemadministrator skal kunne opsætte og ændre den hierarkiske struktur for organisationsenhederne i IFS, således at de fx kan administrere flytningen af en institution til et nyt ministeransvarsområde (PK) Side 6 af 74

7 2A A A A A A A A En bruger skal, på den samme brugerprofil, kunne tildeles systemroller til en, flere eller alle organisationer der er oprettet i IFS (PK) En bruger skal kunne tildeles forskellige systemroller i forskellige organisationer, på den samme brugerprofil, så en bruger fx kan have se-adgang til et helt ministeransvarsområde, og rekvirentrettigheder til en enkelt organisation under ministeransvarsområdet (PK) En bruger med systemroller i flere forskellige organisationsenheder, skal kunne behandle data på tværs af organisationsenhederne, så en bruger fx kan trække rapporter for et helt ministerområde på en gang (PK) Når en bruger med systemroller i flere organisationer logger sig ind, skal alle brugerens igangværende arbejder i alle organisationer vises 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 (PK) En bruger med tilstrækkelige rettigheder skal kunne flytte et ikke-godkendt 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 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 for oprettelse og vedligeholdelse af organisationernes opsætning skal være fleksibel og brugervenlig (PK) Processerne for oprettelse og vedligeholdelse af organisationernes opsætning er beskrevet i underbilag XX Kommentar [F7]: Henvisning til underbilag skal tilføjes når strukturen ligger helt fast Side 7 af 74

8 2A Processen for oprettelse og vedligeholdelse af en Styrelse med to bogføringskredse 2. Processen for oprettelse af et organisatorisk hierarki for et ministerium bestående af syv styrelser med sammenlagt 14 bogføringskredse 3. Mulighederne for at til- og frakoble styrelser fra et ministerium i det organisatoriske hierarki 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 kravsspecifikation 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 indkøberne i organisationerne. Det er væsentligt at en indholdsansvarlig på et Kommentar [F8]: Dokumentatio nskravene i slutningen af hvert afsnit skal muligvis ændres en smule så de får en form der er som følger: Tilbudsgiver skal i underbilag XX redegøre for processerne for oprettelse og vedligeholdelse af organisationer, herunder skal der redegøres for følgende: (den nummererede liste). - Det skal bemærkes at kravene til dokumentation vil blive yderligere uddybet i bilaget løsningsbeskrivelse herunder vil der være henvisninger til specifikke use cases som tilbudsgiver skal svare på. Side 8 af 74

9 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. Kommentar [F9]: Her beskriver Best Practice at Indkøber kan have prokura til selv at godkende. I denne kravspec er man definitorisk disponent, hvis man har prokura. 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. Fakturamanager Hvis en modtaget faktura (eller andet forretningsdokument) ikke automatisk kan behandles eller sendes til den rette rekvirent, har fakturamanageren til opgave at finde den rette modtager og sende fakturaen til vedkommende. Typisk vil det også være fakturamanageren 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 9 af 74

10 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 Der skal kunne oprettes globale systemadministratorer med adgang til det samlede IFS (PK) Globale systemadministratorer skal kunne oprette lokale systemadministratorer (PK) Systemadministratorer skal kunne oprette, ændre og inaktivere brugere i systemet (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 (ØK) Funktionsrettigheder i IFS skal tildeles gennem en rollebaseret brugerrettighedsstruktur (MK) 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, Fakturamanager og Se -bruger (PK) En bruger skal kunne tildeles et sæt af systemroller i IFS som dækker en, flere eller alle forskellige funktionsroller i IFS (PK) En bruger skal kunne tildeles en ren se -rolle, som kan anvendes med henblik på support eller revision (MK) Systemadministratorer skal kunne redigere en eksisterende brugers systemroller indenfor det domæne (de organisationsenheder) systemadministratoren har rettigheder til (PK) Globale systemadministratorer skal kunne definere systemroller i IFS (ØK) Kommentar [F10]: Meget teknisk i forhold til øvrige funktionelle krav, men får foreløbigt lov at stå da de bl.a. understøtter vores tanker vedrørende moms. Kommentar [F11]: Domæne skal defineres i leverancebeskrivelsen, og den efterfølgende parentes skal slettes her) Side 10 af 74

11 2A A A A A Globale systemadministratorer skal kunne ændre og slette systemroller i IFS (ØK) Globale systemadministratorer skal kunne knytte funktionsrettigheder til en systemrolle i IFS (ØK) En systemadministrator skal kunne tildele en bruger systemroller til en eller flere organisationsenheder ud fra en skabelon eller tilsvarende, så en institution fx kan anvende et sæt standardiserede brugerprofiler som hver især består af specifikt sæt kombinationer af systemroller, prokuragrænser, og adgangsrettigheder til organisatoriske enheder (PK) Brugeradministrationen skal være placeret i et modul, der er baseret på en moderne, fuldt understøttet applikation (PK) Processerne for oprettelse og vedligeholdelse af brugere og roller skal være simple og brugervenlige (PK) Processerne for oprettelse og vedligeholdelse af brugere og roller er beskrevet i underbilag XX 1. Processen for oprettelse af en ny bruger med roller i to forskellige bogføringskredse 2. Processen for vedligeholdelse af en bruger, som flyttes fra ét ministerium til et andet Kommentar [F12]: Vil vi have at roller kan konfigurerres? Måske meget godt at flage, så vi får svar på om det er muligt eller ej. Kommentar [F13]: Det kan godt være samme brugergrænseflade som resten af systemet, pointen er, at det ikke må skulle ske i fx konfigurationsfiler eller i en brugergrænseflade der ikke er brugervenlig 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 Lokale systemadministratorer skal kunne opsætte generelle og specifikke prokuragrænser for de enkelte disponenter (MK) Specifikke prokuragrænser skal kunne opsættes på fx dimensionskontoværdier, leverandører, kataloger og produktkategorier (UNSPSC), så en IT-ansvarlig fx kun har ret til at godkende køb af IT-udstyr (PK) Side 11 af 74

12 2A A A A A Det skal være muligt 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 muligt 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 muligt at kombinere prokurabegrænsninger pr. transaktion og pr. periode, så en disponent kan tildeles begge typer af begrænsninger og så systemet kontrollerer begge typer af prokuragrænser når disponenten forsøger at godkende en transaktion (ØK) 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 for opsætning og vedligeholdelse af prokuragrænser skal være fleksible, simple og brugervenlige (PK) Processerne for opsætning og vedligeholdelse af prokuragrænser er beskrevet i underbilag XX 1. Mulighederne for fleksibel opsætning af prokuragrænser 2. Processen for opsætning af flere beløbsgrænser på forskellige dimensionsværdier for en enkelt bruger 3. Processen for vedligeholdelse af prokuragrænser afhængig af opsætning 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 let kan flyttes til en anden bruger i en kortere eller længere periode. 2A A Systemet skal have en stedfortræderfunktion (PK) En bruger, der udpeges som stedfortræder, skal overtage de roller og rettigheder eller et udsnit af disse, som den person vedkommende er stedfortræder for, er tildelt (PK) Side 12 af 74

13 2A A A A A A 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 (PK) 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 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) Den lokale systemadministrator skal kunne tildele og fjerne stedfortræder rettigheder for brugere i den eller de organisationer han er administrator for (ØK) Det skal være muligt at angive en start og en slutdato for hvornår stedfortræderrettighederne skal være tildelt (ØK) Processen for aktivering/deaktivering samt anvendelse af stedfortræder skal være simple og brugervenlige (PK) Processen for aktivering/deaktivering samt anvendelse af stedfortræder er beskrevet i underbilag XX 1. Processerne for aktivering/deaktivering af en stedfortræder både centralt og decentralt 2. Processen for anvendelse af stedfortræderfunktionen fra aktivering til og med behandling af en faktura som stedfortræder for en disponent 3. Processen for anvendelse af stedfortræderfunktionen fra aktivering til og med behandling af en faktura som stedfortræder for en indkøber med fast indkøbsrutine 2A.4.4 Oprettelse af vareleverandører i IFS Oprettelse og vedligeholdelse af vareleverandørens stamdata sker i Navision Stat. Vareleverandørens stamdata overføres efterfølgende til IFS. 2A 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øjst to sæt identifikatorer. Den ene skal altid være Side 13 af 74

14 2A A A A A kreditors juridiske enhed, eksempelvis DK:CVR eller DK:CPR, den anden identifikator kunne fx være et P-nr eller et SEnr.. OIOUBL har derudover også ZZZ som en type for udenlands handel (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 P-nr (ØK) Kombination af de to identifikatorer skal være unik for hver leverandør og Navision Stat regnskab. Det vil sige, hvis IFS allerede har modtaget en leverandør fra et specifikt Navision Stat regnskab med et 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, for samme regnskab (ØK) Det skal være muligt for en lokal systemadministrator at opsætte overførslen af vareleverandørstamdata fra Navision til de Regnskaber som den lokale Systemadministrator har adgang til i IFS (ØK) 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) Kommentar [F14]: Er nok mere et teknisk krav,, Alle valide identifikatorer skal kunne anvendes, og der skal tages højde for at PEPPOL på et tidspunkt kommer med en liste over flere landes typer af identifikatorer. Kommentar [F15]: Skal vist generaliseres og flyttes til sys. admin, eller ikke funktionelle krav, her tænkes på back-end værktøjer. Bemærk dog dokumentationskravet, hvis dette krav flyttes. 2A Det skal tydeligt fremgå i systemet, hvordan en vareleverandør, vil modtage forretningsdokumenter (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 (ØK) Krav til integrationen, herunder stamdataoverførslen, mellem Navision Stat og IFS er beskrevet nærmere under tekniske krav, jf. punkt 2A.X.X. 2A Processerne for oprettelse og vedligeholdelse af vareleverandører i IFS skal være simple og brugervenlige (PK) Processerne for oprettelse og vedligeholdelse af vareleverandører er beskrevet i underbilag XX Kommentar [F16]: Husk at definer om en application response er et forretningsdokument Kommentar [F17]: I løsningsbeskrivelsen skal der stå noget om hvordan det styres gennem, hvilken kanal leverandøren modtager dokumenter. Ved hver visning bør der i princippet blive lavet opslag i NemHandelsregisteret Kommentar [F18]: Skal udfyldes Side 14 af 74

15 1. Processen for opsætning af overførsel af vareleverandørstamdata fra Navision, herunder beskrivelse af, hvilke dele af opsætningen en systemadministrator kan gennemføre samt beskrivelse af forudsætninger og værktøjer 2. Processen for vareleverandørers oprettelse og vedligeholdelse 3. Hvilke identifikatorer der kan bruges til at skelne mellem vareleverandører 4. Hvilke konsekvenser der er for brugerne, hvis en leverandør ikke længere overføres via stamdatafilen fra Navision 5. Hvordan, og hvor information om dokumentudvekslingsmetode med den enkelte vareleverandør fremgår i IFS Kommentar [F19]: Skal specificeres eller udgå 2A.4.5 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 A A A A A A Systemet skal have et aftalemodul, der understøtter indkøbsprocessen (PK) En indholdsansvarlig skal kunne oprette nye aftaler og redigere og spærre eksisterende aftaler (ØK) IFS skal 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 let 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 at handle på aftaler når indkøbet foretages (ØK) Det skal være muligt 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, fremgå ved visning af de tilhørende katalogvarer (ØK) Side 15 af 74

16 2A A IFS skal gøre det let at følge op på, om gennemførte indkøb er sket gennem en oprettet aftale (ØK) Processerne for aftalers oprettelse og vedligeholdelse samt aftalemodulets understøttelse af indkøb skal være simple og brugervenlige (PK) Processerne for aftalers oprettelse og vedligeholdelse samt aftalemodulets understøttelse af indkøb er beskrevet i underbilag XX Kommentar [F20]: Henvisning til underbilag 2A Processerne for aftalers oprettelse og vedligeholdelse 2. Aftalemodulets understøttelse af indkøb 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 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. Kommentar [F21]: Punch-out skal defineres. Det blev kaldt link-out i den gamle kravssepcifikation. Definition fremgår af krav 2A A A IFS skal understøtte brugen af elektroniske varekataloger (MK) IFS skal 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) Side 16 af 74

17 2A A A A Vareleverandører skal have mulighed for se, hvordan deres kataloger og katalogopdateringer præsenterer sig i systemet, inden katalogerne godkendes (PK) Der skal være et godkendelsesflow for kataloger 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 webshop og trække varen/ydelsen retur til IFS til videre behandling (ØK) Globale og lokale systemadministratorer skal kunne slå punchout funktionalitet til og fra på brugerinstitutionsniveau (ØK) Kommentar [F22]: Der skal skrives noget forklaring om hvad en prisliste er Kommentar [F23]: Der skal være tekniske krav til punch-out under de ikke-funktionelle krav 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 A A A A A Brugerinstitutionernes vareleverandører skal kunne sende kataloger direkte til IFS i OIOUBL format (MK) Brugerinstitutionernes vareleverandører skal kunne indlæse kataloger i IFS via et katalogværktøj stillet til rådighed af Tjenesteyder (PK) Katalogværktøjet skal kunne konvertere kataloger fra fx kommasepareret fil, regnearks-/databasefil eller andre formater til OIOUBL (ØK) Katalogværktøjet skal være brugervenligt, effektivt og let at anvende, også for små vareleverandører uden særlige itkompetencer (PK) En vareleverandør skal kunne angive, hvilken brugerinstitution kataloget skal tilknyttes og IFS skal automatisk route kataloget til den korrekte indholdsansvarlige (PK) IFS skal 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 for indlæsning af kataloger skal være simple og brugervenlige (PK) Kommentar [F24]: JDA: systemet skal understøtte felter brugerorganisationen kravstiller til leverandøren og ikke lave yderligere begrænsninger fx på antal karakterer. JMH god pointe der skal findes et sted til dette krav, samt rette niveau i forhold til at der efterspørges et standardsystem Kommentar [F25]: Husk at værktøjet evt. skal kunne bruges til andre dokumenttyper, dvs. hvordan faciliterer IFS indkøbsprocessen (dialogen) Side 17 af 74

18 Processerne for indlæsning af kataloger er beskrevet i underbilag XX 1. Processen for en vareleverandørs ibrugtagning af katalogværktøjet 2. Processen for en vareleverandørs oprettelse af et nyt katalog på 10 varelinjer 3. Processen for en vareleverandørs oprettelse af et nyt katalog på 200 varelinjer 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 let kan se og overskue ændringer til de varer de anvender 2A A A A A A Katalogerne skal kunne opdateres løbende enten ved at overskrive eksisterende kataloger med opdaterede kataloger eller ved at opdatere enkelte elementer i eksisterende kataloger. (PK) Det skal være muligt at opdatere dele af et katalog, fx prisændringer eller udskiftning af enkelte varer (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å der fx kan håndteres, hvis der refereres til en forkert tidligere version af kataloget (Ø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 for opdatering af kataloger skal være simple og brugervenlige (PK) Processerne for opdatering af kataloger er beskrevet i underbilag XX 1. Processen for opdatering af et katalog via katalogværktøjet, herunder en angivelse af nøglen eller nøglerne til at bestemme det korrekte katalog Kommentar [F26]: JDA: Være muligt at gå tilbage og se tidligere oplysninger JMH: Godt krav, find rette sted og formulering Kommentar [F27]: Her skal gives et eksempel fx i en use case, hvor der er gledet en opdatering ud, så en henvisning til previous version ID ikke er korrekt Side 18 af 74

19 2. Graden af fleksibilitet i forhold til leverandørernes versionering af det katalog som opdateres 2A Godkendelse og publicering af kataloger 2A A A A A A A A A A A IFS skal sende et advis til en relevant indholdsansvarlig når der er indlæst et nyt katalog eller en katalogopdatering (PK) Den indholdsansvarlige skal kunne godkende kataloger og katalogopdateringer (PK) Den indholdsansvarlige skal kunne opsætte intervaller for automatisk godkendelse af katalogændringer (fx prisændringer). Intervallerne kan baseres på procenter, tidsinterval og beløb. (ØK) Den indholdsansvarlige skal kunne publicere ét katalog i en eller flere organisatoriske enheder, som den indholdsansvarlige har adgang til(pk) Den indholdsansvarlige skal 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) Den indholdsansvarlige skal kunne afvise kataloger og katalogopdateringer (ØK) Den indholdsansvarlige skal 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) Kommentar [F28]: JDA: Parametre skal kunne sættes op enkelte kataloger eller for enkelte varekategorier Kommentar [F29]: STPEL det skal fremgå tydeligt hvornår et katalog er publiceret og til hvem. Kommentar [F30]: JDA: der skal i IFS kunne opsættes advis eller påmindelse x antal dage inden udløb Side 19 af 74

20 2A A A A Den indholdsansvarlige skal i fejlmeddelelsen kunne angive årsagen til afvisningen, herunder vedhæfte eventuelle bilag mv. (ØK) En indholdsansvarlig skal både 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 kunne tilføje en tekst til enten alle varer i et katalog eller udvalgte varer. Dette kunne fx være at gøre opmærksom på ekstra leveringsomkostninger som tillægges små ordrer (ØK) Processerne for godkendelse og publicering af kataloger skal være simple og brugervenlige (PK) Processerne godkendelse og publicering af kataloger er beskrevet i underbilag XX 3. Processen for godkendelse og publicering af et fuldt katalog 4. Processen for delvis godkendelse og publicering af et katalog, herunder afvisning af den resterende del af kataloget 5. Processen for angivelse af en tekst til brugerne i forbindelse med godkendelse og publicering af et katalog og herunder mulighederne for at ændre teksten efterfølgende, samt hvordan teksten vises for brugerne 2A Visning af Kataloger og katalogvarer 2A A A A IFS skal gøre det let og intuitivt for brugerne at anvende elektroniske varekataloger (PK) IFS skal vise varekataloger på en måde, der giver et hurtigt overblik over den enkelte vare, herunder billede, beskrivelse, pris, varianter, forpakning (fx pakke á 4 stk.) mv. (PK) Det skal være muligt 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 selv kan til- og fravælge hvilke vareinformationer de vil se (ØK) Side 20 af 74

21 2A A A A A A Aftalenavn og AftaleID på et katalog, skal tydeligt fremgå for brugerne både i søgeresultat ved søgning på katalog eller varer og ved varevisning (PK) IFS skal 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 muligt 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. (PK) Mulighederne for visning af kataloger/katalogvarer skal være fleksible og brugervenlige (PK) Mulighederne for visning af kataloger/katalogvarer er beskrevet i underbilag XX 1. Mulighederne for fleksibel visning af kataloger/katalogvarer 2. Brugernes muligheder for at identificere den aftale der købes ind på og se kommentarer/tekst angivet af indholdsansvarlig Kommentar [F31]: Skal præciseres hvilke felter der menes i standarden 2A.4.7 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 Systemet skal understøtte brugen af favoritliser (MK) Rekvirenter og indkøbere skal kunne oprette, redigere og slette egne favoritlister (MK) Side 21 af 74

22 2A A A A A Der skal kunne oprettes flere favoritlister pr. organisation/enhed/rekvirent/indkøber (PK) Favoritlister skal kunne deles mellem brugere, men brugerne må ikke automatisk have adgang til alle andres 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 i en favoritliste, skal varen markeres med samtidig angivelse af den specifikke ændring (fx prisstigning eller spærring), så rekvirent/indkøber bliver opmærksom på ændringen (ØK) Processerne for oprettelse og vedligeholdelse af en favoritliste skal være simple og brugervenlige (PK) Processerne for oprettelse og vedligeholdelse af favoritlister er beskrevet i underbilag XX 1. Processen for oprettelse af en ny favoritliste 2. Processen for vedligeholdelse af en favoritliste med både tilføjelse og sletning af varer 3. Hvordan påvirkes favoritlister af en vareleverandørs opdatering og sletning af kataloger 4. Processen for deling af en favoritliste mellem flere brugere 2A.4.8 Indkøbskurv Ønskede varer skal kunne opsamles og lagres i en indkøbskurv, således at der er mulighed for at afbryde sit arbejde i en kortere periode uden at skulle starte forfra på at finde de korrekte varer eller for at lave en samlet ordre til en vareleverandør for at opnå aftalte mængde- og prisrabatter, undgå leveringsgebyrer o. lign. 2A A A IFS skal understøtte brugen af indkøbskurve (PK) Rekvirenter og indkøbere skal kunne lægge varer i en indkøbskurv i systemet (ØK) Rekvirenter og indkøbere skal i en indkøbskurv kunne, tilføje varer, justere antal ønskede varer og slette varer (ØK) Side 22 af 74

23 2A A A A A A 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 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 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 for oprettelse og vedligeholdelse af en indkøbskurv skal være simple og brugervenlige (PK) Processerne for oprettelse og vedligeholdelse en indkøbskurv er beskrevet i underbilag XX 1. Processen for at oprette og gemme en indkøbskurv 2. Hvordan påvirkes gemte indkøbskurve af en vareleverandørs opdatering og sletning af et katalog? Kommentar [F32]: Skal også fremgå som et mere generelt ikke funktionelt krav. Kommentar [F33]: Husk i Use Case at tage højde for at antallet af en vare øges løbende (adderes linjerne som de bør?) 2A.4.9 Rekvisition og ordreafgivelse Afsendelse af indkøbsordre består af flere elementer og kan involverer transition mellem 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 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. Side 23 af 74

24 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 tabel Kommentar [F34]: Er en placeholder og skal tilpasses 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. Kommentar [F35]: Foreløbig forkortelse for det nye RejsUd system 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. 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. Disse krav er primært samlet i afsnit XX men hensynet til tværgående samarbejde både inden for og imellem ministerområderne vil være gennemgående temaer i kravene. 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. Kommentar [F36]: Skal tilpasses, så der refereres korrekt 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 Side 24 af 74