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

25 2A selv betaler med kreditkort eller ved indkøb på Internettet, er der tale om et Udlæg, der ikke skal behandles i IFS men i STRUHS 2A IFS skal understøtte Standardkøb, Dialogbaserede indkøb, Koncernfælles indkøb, Stående ordrer, Internetkøb og Kreditkortkøb (MK) Oprettelse af rekvisitioner og afsendelse af indkøbsordrer 2A A A A Rekvirenter skal kunne oprette rekvisitioner i IFS (MK) Rekvirenter skal kunne oprette rekvisitioner som baseres både på katalogvarer, punch-out-varer og rekvirentens egen beskrivelse dvs. Fritekst-varer (PK) Systemet skal understøtte fravalg af automatch af (alle) ordrer med fakturaer i den enkelte organisationsenhed (PK) Det skal være muligt på rekvisitionstidspunktet at angive, at ordren ikke må automatches, fx hvis der er tale om en rekvisition, der ikke på rekvisitionstidspunktet kan momsangives korrekt. I så fald skal IFS ikke automatisk godkende en faktura, der matcher den pågældende varemodtagede ordre (PK) Kommentar [F37]: Der mangler muligvis et krav der specificerer at en rekvisition skal kunne oprettes/ordre afsendes uden at leverandøren er oprettet i IFS. Kommentar [F38]: JDA Husk mulighed for efterregistrering JMH: Krav vedrørende mulighed for at oprette en ordre der ikke sendes til leverandøren (etfterregistrering) vil blive tilføjet Kommentar [F39]: Det bør bemærkes, at det bestemt ikke er best practice Kommentar [F40]: Dårligt eksempel, der skal findes et andet 2A A A A A A Det skal i rekvisitionen være muligt at angive, hvis man ikke vil acceptere delleverancer (ØK) Rekvirenten skal have mulighed for at opsætte en standard indkøber, som automatisk vil være angivet på alle rekvisitioner som rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Rekvirenten skal have mulighed for at opsætte en standard disponent, som automatisk vil være angivet på alle rekvisitioner rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Rekvirenten skal have mulighed for at opsætte en standard leveringsadresse, som automatisk vil være angivet på alle rekvisitioner som rekvirenten opretter, men som rekvirenten har mulighed for at ændre på den enkelte rekvisition (ØK) Det skal være muligt at angive ønskede leveringsdatoer på en rekvisition (ØK) Det skal være muligt at tilføje eksterne noter til rekvisitionen, som efterfølgende kan redigeres og som sendes til leverandøren som en del af indkøbsordren (PK) Side 25 af 74

26 2A A A A A A A A A A A A Det skal være muligt at tilføje interne noter til rekvisitionen, som ikke efterfølgende kan redigeres og som ikke fremgår af indkøbsordren, der sendes til leverandøren (ØK) Rekvirenten skal kunne kontere rekvisitionen helt eller delvist (MK) Rekvirenten skal kunne sende en helt eller delvist konteret rekvisition videre til en Indkøber (MK) Indkøberen skal kunne færdiggøre rekvisitionen ved at ændre alle allerede angivne værdier (fx referenceperson, disponent, kontering, leveringsadresser, leveringsdatoer, eksterne kommentarer mv.), tilføje, fjerne eller redigere varelinjer og udfylde eller redigere de resterende/ manglende oplysninger i rekvisitionen (PK) Hvis de ønskede varer ikke findes i et katalog i IFS skal indkøberen kunne specificere og bestille varen gennem IFS, som tekstvarer eller via Punch-Out til en leverandørs egen webbutik (PK) Indkøber skal kunne samle flere rekvisitioner til samme leverandør til én samlet rekvisition (PK) IFS skal automatisk angive en standard referenceperson på rekvisitionen (PK) Det skal kunne konfigureres på organisationsniveau, hvem der angives som standard referenceperson, dvs. om det fx skal være rekvirent, indkøber eller disponent der som standard angives som referenceperson på den enkelte ordre (ØK) Det skal være muligt at overstyre standard referencepersonen på ordren, med en anden referenceperson (PK) Indkøberen skal kunne sende en helt eller delvist konteret rekvisition, hvor alle andre obligatoriske oplysninger er udfyldt, til godkendelse hos en Disponent (MK) En rekvisition skal kunne sendes til godkendelse hos flere disponenter inden ordren afgives, fx hvor der er tale om et indkøb til flere enheder inden for samme regnskab (PK) Disponenten skal kunne redigere og færdiggøre konteringen af de dele af rekvisitionen der er sendt til godkendelse hos disponenten (PK) Kommentar [F41]: Der kan vel godt være varer fra forskellige leverandører på en rekvisition (skal medføre flere ordrer)? Kravet har nogle konsekvenser for, hvordan fx nummerserier kan anvendes (der kan IKKE genereres et ordrenummer ved oprettelsen af rekvisitionen, hvis dette krav skal gælde) Kommentar [F42]: STPEL eller på leverandørniveau som en oplysning på kontrakt/aftalen Side 26 af 74

27 2A A A A En Disponent skal let kunne godkende eller afvise de dele af en rekvisition der er sendt til godkendelse hos den pågældende disponent (MK) Når alle disponenterne har godkendt deres del af rekvisitionen, skal rekvisitionen automatisk danne en indkøbsordre eller omdannes til en indkøbsordre, eller, hvis der er valgt varer fra mere end en vareleverandør, skal der automatisk dannes en indkøbsordre pr. vareleverandør Når alle disponenterne har godkendt deres del af rekvisitionen, og der er dannet en eller flere indkøbsordrer, skal IFS automatisk sende indkøbsordrerne til vareleverandørerne i OIOUBL format eller som s, afhængigt af, hvordan vareleverandøren er registreret i NemHandelsregistret (PK) Processen for oprettelse af en rekvisition og afsendelse af ordre skal være simple og brugervenlige (PK) Processerne for oprettelse af en rekvisition og afsendelse af ordre er beskrevet i underbilag XX 1. Processen for oprettelse af en rekvisition til afsendelse af en ordre, hvor processen er fordelt på tre forskellige brugere 2. Processen for oprettelse af en rekvisition til afsendelse af en ordre, hvor processen foretages af én bruger med rekvirent og indkøber rettigheder og én bruger med disponent rettigheder 3. Processen for samling af flere rekvisitioner til én ordre 4. Obligatoriske felter i forbindelse med oprettelse af en rekvisition og ordre afgivelse 5. Mulighederne for at se og ændre i vareleverandørens adresse i tilfælde af ordremodtagelse pr. 6. Mulighederne for opsætning af præudfyldte felter i forbindelse med oprettelse af en rekvisition og ordre afgivelse Kommentar [F43]: JDA: Det skal være muligt at efterregistrere en ordre som ikke skal sendes til leverandør PIA: Hvilke ordrer skal IKKE sendes til leveradøren? Hvad med at man kan tildele leverandøren et ordrenr. over telefonen og så oprette selve ordren efterfølgende? (Som i NS tror jeg nok) 2A Gentagede køb og stående ordrer 2A IFS skal give muligheder for let at foretage gentagne køb, fx så en rekvisition kan oprettes ud fra en tidligere rekvisition eller en tidligere ordre (PK) Side 27 af 74

28 2A A A Det skal være muligt at oprette en helt eller delvist udfyldt rekvisition på baggrund af en skabelon eller lignende, fx hvis der skal indkøbes en standard pakke af varer til en ny medarbejder (bord, stol, lampe, blomster etc.) (ØK) IFS skal understøtte indkøb på stående ordrer, fx periodiske forsyningssektorydelser eller abonnementsordninger (PK) Processerne for oprettelse af gentagede køb og stående ordrer skal være simple og brugervenlige (PK) Processerne for oprettelse af gentagede køb og stående ordrer er beskrevet i underbilag XX 1. Anbefalet proces for oprettelse af ordrer som baseres på gentagede køb 2. Anbefalet proces for oprettelse af stående ordrer 2A Behandling af ordrer hos vareleverandøren Efter at rekvisitionen er godkendt og der er sendt en ordre til vareleverandøren, kan det ske at vareleverandøren svarer med oplysninger, der skal medføre en ændring på ordren i IFS. Det kan også ske at kunden bliver opmærksom på forhold der gør at ordren skal annulleres. 2A Det skal være muligt for en bruger at annullere en ordre i IFS. Annulleringen skal medføre at ordren skifter status i IFS (PK) Kommentar [F44]: Hvad hvis ordren er også er bekræftet af leverandøren? Mon ikke vi er ude i en use case? 2A A A A Når en ordre annulleres skal IFS automatisk sende besked til vareleverandøren i et format vareleverandøren understøtter, fx via OrderCancellation dokumentet i NemHandel standarden, eller via (ØK) Vareleverandøren skal kunne sende en simpel ordrebekræftelse (OrderResponseSimple) til IFS, som automatisk skal opdatere ordren i IFS med de relevante oplysninger, om accept eller afvisning. Hvis leverandøren ikke sender ordrebekræftelsen elektronisk skal en bruger med de rette rettigheder kunne opdatere oplysningerne manuelt på ordren i stedet for. Vareleverandøren skal kunne sende en ordrebekræftelse (OrderResponse) til IFS, som automatisk skal opdatere ordren i Kommentar [F45]: Hvad skal der ske hvis leverandøren overskrider bekræftelsesdatoen? usecase!! Side 28 af 74

29 IFS med de relevante oplysninger, og evt. initiere et fornyet workflow, fx, hvis leverandøren foreslår en erstatningsvare 2A A En bruger med tilstrækkelige rettigheder skal kunne lukke en åben ordre, fx hvis faktura og ordre ikke blev matchet korrekt, eller hvis leverandøren afviser ordren pr. mail eller telefon Processerne for dialog med vareleverandører skal være simple og brugervenlige (PK) Processerne for dialog med vareleverandører er beskrevet i underbilag XX 1. Processerne for dialog med vareleverandører i forbindelse med ordreafgivelse 2. Processerne for dialog med vareleverandører på øvrige forretningsdokumenter Kommentar [F46]: JMH: Nok ikke det rette sted til denne 2A.4.10 Varemodtagelse 2A A A A A A A En varemodtager skal i IFS kunne varemodtage ud fra oplysningerne på ordren, eller ud fra oplysningerne på fakturaen, hvis der ikke er tilknyttet en ordre til fakturaen (MK) Det skal være muligt at registrere delvis varemodtagelse i systemet, også på linjeniveau (PK) En varemodtager skal kunne lukke restordrer på en ordre, hvis der ikke forventes yderligere leverancer (ØK) Det skal være muligt at varemodtage alle varer på et dokument med en enkelt handling i systemet (MK) Det skal være muligt at registrere negativ varemodtagelse i systemet, så en bruger fx kan starte med at varemodtage alle varer på et dokument, og derefter justere for enkelte ikke leverede varer (PK) Når en varemodtager foretager en varemodtagelse i IFS, skal modtagelsesdatoen registreres i IFS. Som default skal modtagelsesdatoen være dags dato (PK) Det skal være muligt at ændre en modtagelsesdato, for den enkelte varemodtagelse, på et dokument i systemet. Kommentar [F47]: Kom med et eksempel (defekte varer) Side 29 af 74

30 Modtagelsesdatoen er bestemmende for i hvilken regnskabsperiode et dokument bogføres i Navision Stat (PK) 2A A IFS skal kunne håndtere varemodtagelse af en ordre efter den tilhørende faktura er modtaget (PK) Processerne for varemodtagelse af ordre eller faktura, hvis der ikke er tilknyttet en ordre, skal være simple og brugervenlige (PK) Processerne for varemodtagelse af ordre eller faktura, hvis der ikke er tilknyttet en ordre, er beskrevet i underbilag XX 1. Processen for varemodtagelse af ordre 2. Processen for delvis varemodtagelse på ordre 3. Processen for varemodtagelse af en faktura, hvis der ikke er tilknyttet en ordre 4. Processen for delvis varemodtagelse på en faktura, hvor der ikke er tilknyttet en ordre 2A.4.11 Fakturaer Fakturabehandling i IFS skal som udgangspunkt bestå af varemodtagelse, kontering og godkendelse af en faktura. Hvis en faktura er koblet med en ordre, vil varemodtagelsen og konteringen være registeret på ordren og fakturaen kan herefter automatisk blive godkendt. I tilfælde af at fakturaen ikke kan godkendes automatisk fx pga. en afvigelse i prisen mellem ordre og faktura, skal fakturaen automatisk sendes til indkøber. Indkøber afgør hvorvidt afvigelsen er i orden, og sender herefter fakturaen til godkendelse, eller tager kontakt til leverandøren. Alternativt modtages en faktura i IFS, hvortil der ikke findes en ordre, så varemodtagelse, kontering og godkendelse skal registreres på fakturaen. IFS skal i begge tilfælde kunne opsættes til, at den samme bruger både kan varemodtage, kontere og godkende, hvis brugeren har tilstrækkeligt med rettigheder og prokura. En række af kravene til behandling af fakturaer i IFS finder også anvendelse for kreditnotaer og rykkere med gebyrer, jf. afsnit XX og afsnit XX. 2A Indlæsning af elektroniske fakturaer Side 30 af 74

31 Nedenfor er der angivet en række krav til indlæsning af fakturaer i IFS, samt krav til dokumentation af originalfakturaer. 2A A Brugerinstitutionernes vareleverandører skal kunne sende fakturaer direkte til IFS i OIOUBL format (MK) En vareleverandør skal kunne angive, hvilken brugerinstitution fakturaen skal tilknyttes og IFS skal automatisk route fakturaen til den korrekte bruger i institutionen (PK) Kommentar [F48]: Der skal være krav til hvilke betalingsmetoder IFS skal kunne håndtere. Alle betalingsmetoder, komplette og ukomplette, DirectDebit, indlands og udenlands, i og udenfor EU, og i valuta skal kunne håndteres. Der skal også forventes at modtage fakturaer fra udlandet fra Peppol til OIO. 2A A A A A A A A A A Modtagelsen af en faktura i IFS, skal være uafhængig af om leverandøren er oprettet i Navision Stat (MK) Hvis leverandøren er oprettet og overført fra Navision Stat skal IFS automatisk sikre kobling mellem faktura og leverandør ved indlæsning af fakturaen (PK) Hvis der ikke findes et stamkort på leverandøren i IFS skal det tydeligt fremgå for de brugere der behandler fakturaen i IFS (ØK) Når en faktura modtages og indlæses i IFS skal der gemmes en skrivebeskyttet kopi af originalfakturaen til revisionsmæssig brug i systemet (MK) Når fakturaen senere godkendes, skal originalfakturaen medsendes den godkendte faktura til Navision Stat (MK) Originalfakturaen skal ikke vises som et selvstændigt dokument ved søgning i IFS (ØK) Originalfakturaen skal kunne tilgås direkte fra fakturaen (PK) Originalfakturaen skal kunne vises i et brugervenligt og overskueligt stylesheet, som giver brugeren en oplevelse af genkendelighed i forhold til en papirfaktura (PK) Det anvendte stylesheet skal som minimum indeholde de oplysninger som medtages i Digitaliseringsstyrelsens til enhver tid anbefalede stylesheet. Der skal desuden være yderlige tiltag i forhold til overskuelighed og læsbarhed (PK) Processerne for indlæsning af elektroniske fakturaer, skal være simple og brugervenlige (PK) Processerne for indlæsning af elektroniske fakturaer er beskrevet i underbilag XX Kommentar [F49]: STPEL kopien skal gemmes i et databaseformat, som sikrer at der kan foretages simple datatjek på fx beløb, betalingsoplysninger mm på godkendelsestidspunktet Kommentar [F50]: KKP Jeg ved ikke om Digst anbefaler noget. Men de releaser med mellemrum eksempel stylesheets. Så der skal måske refereres til senest releasede version af eksempel stylesheets. Side 31 af 74

32 1. Processen for afvisning af fakturaer, der enten ikke overholder standarden eller er afsendt flere gange fra leverandøren. Herunder brugernes mulighed for at se disse fakturaer og årsagen til afvisning 2. Processen for håndtering af fakturaer, hvor vareleverandøren forbliver ukendt i IFS 3. Eksempel på anvendt stylesheet for visning af en fakturas elektroniske original 2A Tilknytning af elektroniske fakturaer til ordrer og automatisk routning af elektroniske fakturaer I det følgende beskrives regelsættet for, hvorhen en elektronisk modtaget faktura skal routes, samt krav til tilknytning af en modtaget elektronisk faktura til en ordre. 2A A A A A A IFS skal ved modtagelse af fakturaer automatisk forsøge at tilknyttet fakturaen til en åben ordre på baggrund af leverandør identifikator og angivet ordrenummer på fakturaen (MK) Når en faktura modtages i en organisation i IFS, skal fakturaen automatisk routes til den relevante bruger, hvis fakturaen ikke automatches med en ordre (PK) Hvis fakturaen kan tilknyttes en ordre, men ikke automatches, skal fakturaen automatisk routes til indkøberen på ordren, med mindre indkøberen er spærret, ikke (længere) har rettigheder til at behandle fakturaer eller lignende Hvis fakturaen ikke kan tilknyttes en ordre skal fakturaen automatisk routes til en bruger der matcher personreferencen på fakturaen, medmindre brugeren er spærret, ikke har rettigheder til at behandle fakturaer eller lignende Hvis fakturaen ikke kan routes til en specifik bruger ud fra en ordrereference eller en personreference, skal fakturaen routes til en fakturamanager, eller fakturamanager skal på anden vis blive opmærksom på at der er modtaget en faktura som skal behandles (PK) I forhold til at gøre en fakturamanager opmærksom på at der er modtaget en faktura, som skal behandles, skal IFS tage højde for at fakturamanager hos små brugerinstitutioner ikke kan forventes Kommentar [F51]: STPEL dette kunne ligeledes være en info på leverandørkartotektet, således at alle bilag for type X leverandører skal dirigeres til Fakturafordeler Y osv. Side 32 af 74

33 hyppigt at tilgå IFS og manuelt følge op på om der modtaget nye fakturaer (ØK) 2A Processerne for tilknytning af fakturaer til ordrer skal være simple og brugervenlige (PK) Processerne for tilknytning af fakturaer til ordrer er beskrevet i underbilag XX 4. Processen for at tilknytte en faktura til en ordre, hvis der ikke er angivet en ordrereference på fakturaen, herunder hvilke brugere der har rettigheder til denne handling 5. Processen for at frakoble en faktura fra en ordre, hvis der er sket en fejlkobling, herunder hvilke brugere der har rettigheder til denne handling 6. Kriterierne for routing af faktura, herunder angivelse af værdier der kan routes på 7. Mulighederne for at modtage flere fakturaer på samme ordre, fx ved delleveringer 2A Oprettelse af manuelle fakturaer Brugerinstitutionerne kan have behov for at oprette manuelle fakturaer i IFS, typisk fordi udenlandske leverandører, der ikke er omfattet af dansk lov, sender fakturaer med papirpost. 2A A A A Det skal være muligt at oprette manuelle fakturaer i systemet, på baggrund af modtagne papirfakturaer (MK) Det skal være muligt at afgrænse, hvilke brugere der kan oprette manuelle fakturaer i systemet, så det fx kun er brugere med rollen fakturamanager, der kan oprette manuelle fakturaer, eller så retten til at oprette manuelle fakturaer er en separat systemrolle, der kan tildeles en bruger (ØK) Manuelle fakturaer skal kunne oprettes ud fra skabeloner eller lignende i systemet (PK) Som en del af processen for oprettelse af manuelle fakturaer skal det være obligatorisk at brugeren vedhæfter en indscannet kopi af originalfakturaen, som ikke efterfølgende kan slettes (PK) Kommentar [F52]: Her skal refereres til krav for vedhæftede filer Side 33 af 74

34 2A A A A A Processen for oprettelse af manuelle fakturaer skal være klart adskilt fra workflowet for varemodtagelse og godkendelse af fakturaer, så felter låses for redigering når oprettelsen færdiggøres, svarende til hvad der er gældende for en elektronisk modtaget faktura (PK) Under oprettelsen af en manuel faktura, skal brugeren kunne gemme sit arbejde som en kladde, således at han kan afbryde oprettelsen og senere vende tilbage og færdiggøre den. Brugeren der har oprettet en manuel faktura skal have mulighed for at slette fakturaen/kladden igen, hvis fakturaen ikke er blevet godkendt, så det unikke dokumentid kan genanvendes på en ny mauelt oprettet faktura i IFS, fx hvis brugeren bliver opmærksom at der er sket en fejl ved oprettelsen af fakturaen. IFS skal understøtte oprettelse og behandling af fakturaer fra udenlandske leverandører i systemet, med mulighed for at angive alle valide valutakoder og betalingsformer både inden- og udenfor EU (PK) Processen for oprettelse af en manuel faktura, skal være simpel og brugervenlig (PK) Processerne for oprettelse af en manuel faktura er beskrevet i underbilag XX 1. Processen for oprettelse af en manuel faktura, herunder angivelse af obligatoriske felter i processen 2. Mulighederne for at den enkelte bruger kan opsætte præudfyldte felter 3. Mulighederne for redigering af manuel faktura inden godkendelse, hvis der fx er angivet forkert leverandør Kommentar [F53]: Her tænkes på fakturanummeret 2A Fakturabehandling, generelt I det følgende beskrives krav, der er generelle for behandling af fakturaer med eller uden tilknyttede ordrer. Kommentar [F54]: Det overvejes at flytte disse krav, så de står først i afsnit 2A A A IFS skal understøtte varemodtagelse, kontering og godkendelse af elektroniske fakturaer og manuelt oprettede fakturaer (MK) En bruger med tilstrækkelige rettigheder skal manuelt kunne tilknytte en faktura til en ordre (MK) Side 34 af 74

35 2A A A A A A A En bruger med tilstrækkelige rettigheder skal kunne frakoble fakturaer og ordrer. Frakobling må ikke medføre at godkendte dokumenter genåbnes (PK) En bruger må ikke kunne redigere i betalingsoplysningerne på en elektronisk modtaget faktura eller på en færdigoprettet manuel faktura (MK) En bruger må ikke kunne redigere i Faktura total inkl. moms på en elektronisk modtaget faktura eller på en færdigoprettet manuel faktura (MK) En faktura må kun kunne godkendes, hvis varen eller ydelsen er registreret som varemodtaget (MK) Godkendelsen af en faktura i IFS, skal være uafhængig af om leverandøren er oprettet i Navision Stat (MK) Hvis en faktura godkendes og sendes til Navision Stat uden at leverandøren er oprettet og overført til IFS, skal fakturaen automatisk kobles til leverandøren i IFS, når leverandøren efterfølgende overføres fra Navision Stat til IFS (PK) Godkendte fakturaer skal automatisk overføres til Navision, hvor de bogføres og udsøges til betaling (MK) Kommentar [F55]: Husk så til gengæld øredifferencer 2A Fakturabehandling af fakturaer uden tilknyttede ordre I dag modtages langt de fleste fakturaer uden at der forinden er afgivet en elektronisk ordre ( almindelige fakturaer). Selvom det forventes, at der fremover vil ske en stigning i afgivelsen af elektroniske ordrer, vil almindelige fakturaer stadig udgøre en væsentlig andel af transaktionerne. Det er derfor vigtigt, at IFS understøtter en effektiv og enkel håndtering af fakturaerne. 2A A A En fakturamanager eller en rekvirent skal kunne kontere en faktura helt eller delvist samt angive en eller flere disponenter på fakturaen (PK) Fakturaen skal kunne varemodtages jf. kravene i afsnit 2A.4.10 (PK) Når fakturaen er fuldt varemodtaget skal den automatisk sendes til godkendelse hos den eller de angivne disponenter (PK) Side 35 af 74

36 2A A A A En disponent skal kunne redigere og færdiggøre konteringen af de dele af fakturaen der er sendt til godkendelse hos disponenten (PK) En Disponent skal let kunne godkende eller afvise de dele af en faktura der er sendt til godkendelse hos den pågældende disponent (MK) Når alle disponenterne har godkendt deres del af fakturaen, skal fakturaen automatisk ændre status og afsendes til Navision Stat (PK) Processen for behandling af en faktura, skal være simpel og brugervenlig (PK) Processerne for behandling af en faktura er beskrevet i underbilag XX 1. Processen for behandling af en faktura som varemodtages og godkendes af samme person 2. Processen for behandling af en faktura som varemodtages og godkendes af to forskellige personer, herunder returflowet og afvisningsmuligheder for den enkelte bruger 3. Processen for behandling af en faktura som varemodtages af mindst tre personer og godkendes af mindst tre andre personer, herunder returflowet og afvisningsmuligheder for den enkelte bruger 2A Fakturabehandling af fakturaer med tilknyttede ordre I det følgende beskrives krav der er generelle for behandling af fakturaer med tilknyttede ordrer. 2A A A Hvis en faktura tilknyttes en ordre, skal IFS afgøre om der er match mellem oplysningerne på ordren og fakturaen (MK) Matchet skal kunne ske, hvis leverandør identifikator, angivet ordrenummer samt beløb på ordre og faktura, alle er identiske, på ordre og faktura, eller inden for en tolerancegrænse fsva total beløb (PK) Matches faktura og ordre skal IFS kontrollere, om varen er varemodtaget. Såfremt dette er tilfældet, skal den matchede Kommentar [F56]: sammenhæng en skal fremgå tydeligt uanset hvilket af de to dokumenter man står på. Kommentar [F57]: I denne kravspec anvendes følgende begreber: Tilknytning: At en faktura og ordre er knyttet sammen via en dokumentreference Match: At oplysningerne på faktura og ordrer jf. dette krav er identiske Automatisk godkendelse: Det at systemet automatisk godkender fakturaen fordi faktura og ordre er tilknyttet, matcher og der er varemodtaget Automatch: Når der er varemodtaget på ordren, og fakturaen af systemet kan tilknyttes ordren, oplysningerne matcher og fakturaen derfor kan automatisk godkendes af systemet eller mao. når systemet automatisk kan fuldføre hele flowet så snart fakturaen modtages Side 36 af 74

37 faktura automatisk godkendes og videresendes til økonomisystemet til bogføring og betaling, medmindre automatch er fravalgt på ordren eller i organisationsenheden (MK) 2A A A A IFS skal kunne automatche ved delfakturering, der ikke dækker den fulde ordre (PK) Er der ikke registreret tilstrækkelig varemodtagelse for ordren, afventes dette, før den matchede faktura automatisk videresendes til bogføring og betaling (PK) Hvis en faktura automatisk eller manuelt tilknyttes en ordre, men der ikke er match mellem dokumenterne, skal IFS tydeligt orientere den relevante indkøber om dette, samt angive årsagen til det manglende match, og orientere brugeren om, hvilke handlinger, der skal foretages (PK) Processen for håndtering af en faktura fra modtagelse til godkendelse, hvor der er fejl-match mellem faktura, ordre og varemodtagelse, skal være simpelt og brugervenlig (PK) 1. Processen for håndtering af en faktura fra modtagelse til godkendelse, hvor der er fejlmatch ud fra de fire følgende fejlscenarier: a. Ordrereference mangler b. Der er ikke foretaget varemodtagelse på ordren c. Der er en afvigelse i beløb mellem ordre og faktura d. Der er ikke fortaget varemodtagelse på ordren og der er samtidig en afvigelse i beløb mellem ordre og faktura Kommentar [F58]: Husk at beskrive muligheden for at ændre konteringen. Samt processen, hvis match er fravalgt. Kommentar [F59]: Usecase, også hvis der er ekstra linjer 2A Særligt om match af fakturaer med stående ordrer En stor del af de fakturaer, der modtages af de offentlige myndigheder vedrører stående ordrer (abonnementer, forsyningsaftaler mv.), hvor kreditoren og aftalegrundlaget er kendt på forhånd, men hvor størrelsen af den enkelte faktura ikke på forhånd kendes eksakt. Side 37 af 74

38 I mange tilfælde vil myndigheden ikke have mulighed for at påvirke beløbsstørrelsen, og det er derfor et stort ønske fra myndighedernes side, at disse fakturaer i videst mulige udstrækning kan håndteres automatisk. Eksempler på automatiseret håndtering af stående ordrer kan være at man i stedet for at matche på et ordrenummer matcher på andre kriterier som fx abonnementsnummer, kundenummer el. lign. Samtidig vil det være ønskeligt, at der kan sættes kriterier op for hvornår automatch accepteres. Det kan fx være inden for faste beløbsintervaller (hvis der er tale om en fast opkrævning, á conto-opkrævninger mv.) og/eller at fakturaen skal modtages i et særligt datointerval, så fakturaer fx kun behandles automatisk i en 2-ugers periode pr. kvartal. 2A A A IFS skal understøtte automatisk matchning af fakturaer og stående ordrer, dvs. ordrer hvor der ikke er afgivet individuelle indkøbsordrer for de modtagne fakturaer, og hvor der evt. ikke varemodtages på de stående ordrer, og match derfor skal ske ud fra andre kriterier, fx kundenummer, abonnementsnummer eller lignende IFS skal understøtte muligheder for at afgrænse matchningen, fx så match kun sker inden for fastsatte økonomiske intervaller eller datointervaller. Processen for match af faktura med stående ordrer, skal være simpel og brugervenlig (PK) Processerne for match af faktura med stående ordrer, er beskrevet i underbilag XX 1. Processen for match af faktura med stående ordrer, fra ordreoprettelse til match 2. Mulighederne for opsætning af matchkriterier på den specifikke stående ordre 2A Særligt om match af fakturaer med rabat, afgifter mv. I en række tilfælde vil fakturaer indeholde diverse rabatter, gebyrer, afgifter mv. Dette kan give anledning til vanskeligheder med at matche ordrer og fakturaer automatisk, da ordren sjældent vil indeholde de samme gebyrer mv. som fakturaen, og det samlede fakturabeløb derfor ikke svarer til ordrebeløbet. I OIOUBL-standarden er det muligt at angive afgifter mv. i særlige felter i den tekniske standard, således at fakturaen indeholder en pris for selve de leverede Side 38 af 74

39 varer/ydelser og en yderligere specifikation af afgifter, gebyrer mv. Det vil herefter være muligt at matche faktura og ordre ud fra hovedydelsen og evt. sætte kriterier op for automatisk godkendelse (og evt. kontering) af gebyrer mv. 2A IFS skal understøtte automatisk behandling af fakturaer med Allowance Charge elementer (rabatter, gebyrer) og Tax elementer (skat, afgifter og moms) (ØK) Kommentar [F60]: KKP Vær skarp på AllowanceCharge (Rabat/gebyr) vs. Tax (Skal, Afgifter, Moms). Bland dem ALDRIG sammen. 2A A A IFS skal understøtte at der kan angives intervaller for automatisk godkendelse af Allowance Charge og Tax elementer (ØK) IFS skal understøtte mulighederne for automatisk kontering af Allowance Charge elementer. (ØK) Processen for håndtering af fakturaer som indeholder Allowance Charge og Tax elementer, skal være simpel og brugervenlig (PK) Processerne for håndtering af fakturaer som indeholder Allowance Charge og Tax elementer, er beskrevet i underbilag XX 1. Processen for automatisk match af faktura med ordre, hvor fakturaen indeholder Allowance Charge og/eller Tax elementer, som ikke fremgår af ordren. Herunder hvilke krav dette stiller til opsætningen 2. Processen for automatisk match af faktura med ordre, hvor fakturaen indeholder Allowance Charge og/eller Tax elementer, som ikke fremgår af ordren. Herunder hvilke krav dette stiller til opsætningen Kommentar [F61]: Tax elementer kan ikke konteres i UBL standarden 2A.4.12 Generelt om anvendelse af IFS, dokumentbehandling og kontering I dette afsnit er der beskrevet en række generelle krav til hvad der skal gælde for brugeres anvendelse af IFS herunder generelle krav til behandling af alle typer af forretningsdokumenter og generelle krav til kontering i IFS. 2A A A Kun de funktioner, værdier og forretningsdokumenter, som ens brugerprofil giver adgang til, skal være synlige i systemet (PK) Data i IFS skal præsenteres struktureret, tydeligt og ensartet for brugerne, så brugerne let kan orientere sig og navigere i systemet (PK) Kun relevante brugere og værdier må kunne vælges ved behandling og distribution af forretningsdokumenter i systemet, Side 39 af 74

40 2A det må fx ikke være muligt at vælge en spærret dimensionsværdi ved kontering eller at sende en transaktion til godkendelse hos en bruger der er spærret, eller ikke har disponent rollen, eller som ikke har tilstrækkelig prokura til at godkende transaktionen Værktøjer til fakturamanagerrollen En fakturamanager har til opgave at sikre at alle dokumenter i en eller flere organisationsenheder behandles rettidigt, og at sikre at eventuelle problemer i et dokumentflow undersøges og udbedres Kommentar [F62]: Mangler dokumentationskrav til disse krav, skal udarbejdes 2A A A Der skal stilles værktøjer til rådighed, således at fakturamanageren kan følge op på åbne forretningsdokumenter inden for fakturamangerens domæne, fx oversigter over alle ubehandlede fakturaer, kreditnotaer mm., i brugerinstitutionen eller inden for flere brugerinstitutioner på én gang. Fakturamanagerens opfølgning og håndtering af dokumenter i IFS, skal være understøttet af fleksibel, omfattende, let og intuitiv funktionalitet, så en fakturamanager let kan gennemføre sine opgaver i systemet hurtigt og effektivt Processen for fakturamanagers fordeling af fakturaer, skal være simpel og brugervenlig (PK) Processerne for fakturamanagers fordeling af fakturaer er beskrevet i underbilag XX 1. Processen for fakturamanagers fordeling af fakturaer 2. Mulighederne for at fakturamanager kan fordele flere fakturaer til samme person i én proces 3. Processen for håndtering af fakturaer hvor fakturamanager ligeledes varetager rekvirentrollen 2A Egne dokumenter I IFS skal dokumenter kunne sendes til en bruger til behandling. Dokumenter en bruger har oprettet, dokumenter som er allokeret til en bruger, og dokumenter som en bruger har ændret betegnes her samlet som brugerens egne dokumenter. 2A Hvis en bruger opretter et forretningsdokument, skal dette gemmes som en kladde indtil der foretages en forpligtende handling. Det skal være muligt at slette oprettede kladder (PK) Side 40 af 74

41 2A A A En bruger skal let kunne få et overblik over dokumenter der ligger til behandling hos brugeren, i systemet (PK) Brugerne af systemet skal have mulighed for løbene at kunne se deres egne dokumenters status, så brugeren hurtigt og effektivt kan identificere handlingsbehov for dokumenterne, fx i tilfælde af at et dokument ikke godkendes rettidigt (PK) Processerne for håndtering af egne dokumenter, skal være simpel og brugervenlig (PK) Processerne for håndtering af egne dokumenter er beskrevet i underbilag XX 1. Processen for påbegyndelse og sletning af en dokumentkladde 2. Hvordan en bruger ser egne dokumenter i systemet 2A Samtidige operationer på forretningsdokumenter Det kan ske at mere end en bruger forsøger at tilgå og behandle et dokument samtidigt. Det kan i nogle tilfælde være acceptabelt, fx hvis forskellige disponenter ønsker at godkende forskellige linjer på et dokument samtidigt. Men det skal ikke være muligt, at to brugere forsøger at redigere de samme dele af et dokument simultant, ligesom en bruger ikke må kunne redigere oplysninger på et dokument som påvirker en anden brugers igangværende arbejde på dokumentet, uden at den anden bruger bliver gjort opmærksom på de konkrete ændringer. 2A A A Hvis mere end en bruger forsøger at åbne og/eller redigere et dokument på en gang, skal IFS sikre hensigtsmæssig afgrænsning af brugernes rettigheder til at redigere dokumentet, så den ene brugeres arbejde i dokumentet ikke kan påvirke den anden brugers arbejde i dokumentet uhensigtsmæssigt (PK) IFS skal automatisk gøre en bruger opmærksom på, hvis brugerens rettigheder, til at redigere et specifikt forretningsdokument, er begrænset som følge af at en anden bruger anvender dokumentet (ØK) Processerne for håndtering af samtidige operationer på dokumenter, skal være simpel og brugervenlig (PK) Side 41 af 74

42 Processerne for håndtering af samtidige operationer på dokumenter er beskrevet i underbilag XX 1. Hvordan bliver brugernes adgang til et dokument begrænset 2. Hvordan bliver brugeren opmærksom på den begrænsede adgang 2A Særligt om brugere med flere funktionsroller Når en bruger arbejder på et dokument skal IFS automatisk tagen hensyn til og tilpasse workflowet, hvis brugeren har flere forskellige funktionsroller 2A A A En bruger skal kunne gennemføre et helt dokumentflow i systemet, hvis brugeren har tilstrækkelig prokura og rettigheder (PK) IFS skal i dokumentflowet tage højde for om en bruger har flere roller. Brugeren skal kunne gennemføre alle de dele af flowet som brugeren har rettigheder til, uden at brugeren skal fremsende dokumentet til sig selv, eller på anden måde foretage overflødige operationer i systemet. Det skal fx være muligt at varemodtage og godkende en faktura i en handling, hvis brugeren har tilstrækkelige rettigheder og prokura (PK) Processerne for gennemførelse af et helt dokumentflow med samme bruger (med tilstrækkelig prokura og rettigheder), skal være simpel og brugervenlig (PK) Processerne for gennemførelse af et helt dokumentflow med samme bruger (med tilstrækkelig prokura og rettigheder), er beskrevet i underbilag XX 1. Processen for gennemførelse af et helt dokumentflow med samme bruger (med tilstrækkelig prokura og rettigheder) for hver enkelt dokumenttype 2. Krav til opsætning i forbindelse med gennemførelse af et helt dokumentflow med samme bruger (med tilstrækkelig prokura og rettigheder) Side 42 af 74

43 2A Lukning, afvisning og genåbning af forretningsdokumenter Det kan ske at, der opstår fejl i et indkøbsflow der gør at et dokument ikke skal færdigbehandles, fx, hvis et indkøbsforløb afbrydes uden at varen leveres, eller hvis en vareleverandør kommer til at sende et forretningsdokument til en forkert modtager. IFS skal indeholde funktionalitet der gør det muligt at håndtere fejlscenarier, så systemet ikke forurenes med åbne forretningsdokumenter, der aldrig kan færdigbehandles 2A A A A A A Alle ikke-godkendte dokumenter skal kunne lukkes/afvises, og genåbnes i systemet (handlingerne skal fremgå af dokumenternes transaktionsspor) (PK) Det skal kunne afgrænses hvilke bruger der har rettigheder til at lukke/afvise og genåbne dokumenter, så funktionen fx kun er tilgængelig for fakturamanagers (ØK) Det skal være muligt at udsøge en gruppe af dokumenter og lukke dem samtidigt, uden at man behøver at tilgå det enkelte dokument, så det fx er muligt at lukke alle åbne ordrer hvor leveringsdatoen er overskredet med mere end 3 måneder fra en samlet oversigt Ved masselukning af dokumenter, skal det være muligt at vælge alle udsøgte dokumenter på en gang og derefter fravælge enkelte dokumenter inden de resterende dokumenter lukkes én enkelt operation Godkendte dokumenter må ikke kunne genåbnes eller redigeres yderligere af en bruger i IFS, der er dog angivet undtagelser til denne regel i krav 2A.4.X.X.X og i krav 2A.4.X.X.X-X om annullering af ordrer (PK) Processerne for lukning, afvisning og genåbning af dokumenter, skal være simple og brugervenlige (PK) Processerne for lukning, afvisning og genåbning af dokumenter, er beskrevet i underbilag XX 1. Processen for lukning af ordre som aldrig blev leveret, herunder angivelse af hvem/hvilke roller der kan udføre handlingen Side 43 af 74

44 2. Processen for afvisning og genåbning af en faktura, herunder angivelse af hvem/hvilke roller der kan udføre handlingen 2A Distribution af forretningsdokumenter I det følgende er det beskrevet, hvordan ikke-godkendte forretningsdokumenter kan sendes mellem brugere i IFS. Godkendte forretningsdokumenter er pr. definition ikke allokeret til en bruger og kan derfor ikke sendes til en bruger. 2A A A A A A A A Hvis en specifik leverandør sender et dokument til et regnskab i IFS, hvor der allerede findes et dokument fra den samme leverandør med samme dokumentid (og versionsnummer fsva kataloger), skal IFS automatisk afvise dokumentet og sende en sigende fejlbesked til leverandøren enten i OIOUBL formatet eller som en , hvis leverandøren ikke er i stand til at modtage en afvisning i OIOUBL formatet (PK) Alle brugere skal kunne videresende et ikke godkendt forretningsdokument til en anden bruger med tilstrækkelige rettigheder indenfor deres egen brugerinstitution (dvs. inden for det opstillede domæne, brugeren er en del af) (PK) En bruger skal nemt kunne sende dokumenter, der endnu ikke er godkendte, mellem regnskaber som brugeren har rettigheder til (ØK) Et dokument skal kunne returneres fra en bruger, til den bruger der har sendt dokumentet til brugeren. Det skal være muligt at angive en kommentar som en del af denne proces (MK) En bruger skal altid kunne sende et ikke godkendt forretningsdokument (retur) til en fakturamanager (ØK) En fakturamanager skal altid kunne videresende et ikke godkendt dokument fra en bruger til anden bruger, uanset om dokumentet er sendt retur til fakturamanageren eller ej (PK) Videresendelse af dokumenter til en anden bruger skal kunne gennemføres uden at brugeren behøver at åbne de pågældende dokumenter (ØK) En bruger skal let kunne videresende flere dokumenter til en anden bruger på en gang, fx fra et oversigtsbillede (ØK) Kommentar [F63]: Fx fakturanummeret Side 44 af 74

45 2A A A Et dokument, der kan varemodtages, skal kunne sendes til delvaremodtagelse hos flere forskellige varemodtagere (rekvirenter) (PK) Et dokument, der kan godkendes, skal kunne sendes til delgodkendelse hos flere forskellige disponenter (PK) Processerne for distribution af dokumenter, skal være simple og brugervenlige (PK) Processerne for distribution af dokumenter, er beskrevet i underbilag XX 1. Processen for videre distribution af hver dokumenttype når et dokument modtages i en specifik status, hvem/hvilken rolle kan dokumentet sendes til? 2. Processen for flytning af et dokument fra én bogføringskreds til en anden, herunder angivelse af hvem/hvilke roller der kan udføre handlingen 3. Processen for delvis varemodtagelse og godkendelse af dokumenter, hvilket vil sige et dokument med flere rekvirenter og flere disponenter 2A Adviser og fejlmeddelelser Når en bruger modtager et forretningsdokument i IFS er det nødvendigt at brugeren bliver gjort opmærksom på at der er allokeret et dokument til brugeren som kræver handling. For brugere, der kun sjældent logger ind i IFS, er det hensigtsmæssigt, at IFS automatisk sender en advisering til brugeren, når der bliver allokeret et nyt forretningsdokument til brugeren, eller når en anden bruger foretager en væsentlig handling på et dokument som brugeren har et tilhørsforhold til. IFS skal desuden generere fejlmeddelelser, hvis en bruger forsøger at gennemføre en handling, som ikke er understøttet af dokumentflowet og/eller brugerens rettigheder. Under afsnit XX vedrørende systemkonfiguration er der angivet en række yderligere krav til adviser og fejlmeddelelser. 2A A Systemet skal automatisk generere -adviser når det er relevant (fx når et dokument allokeres til en bruger eller hvis en bruger skal mindes om behandlingen af et dokument) (PK) Det skal være muligt for en Disponent at godkende et dokument direkte fra et advis, der indeholder alle relevante oplysninger om Side 45 af 74

46 dokumentet, således at disponenten ikke behøver at logge på IFS for at godkende dokumenter 2A A A Hvis en et dokument forsøges godkendt via en advis skal IFS berigtige, at det er disponenten, der godkender dokumentet, fx gennem en single-sign-on integration eller ved et passwordprompt Hvis en bruger forsøger at gennemføre en handling som ikke er understøttet af dokumentflowet, eller som brugeren ikke har rettigheder til at udføre, skal Systemet automatisk generere (fejl)meddelelser, som kan bistå brugeren i problemløsningen. Meddelelserne skal være letforståelige og skal vejlede brugeren (PK) Anvendelsen af adviser og fejlmeddelelser, skal være simpel og brugervenlig (PK) Anvendelsen af adviser og fejlmeddelelser, er beskrevet i underbilag XX Kommentar [F64]: Henvisning til underbilag 1. Processen for håndtering af et dokument direkte fra en advis 2. Processen for håndtering af flere dokumenter direkte fra en advis 3. Eksempler på udformning af adviser 4. Angivelse af eksempler på handlinger, der kan føre til en fejlmeddelelse og herunder eksempler på disse fejlmeddelelser 2A Noter og vedhæftede filer I forbindelse med behandlingen af forretningsdokumenter i IFS kan det være nødvendigt at en bruger tilføjer forklarende tekst eller dokumentation til et dokument, så andre aktører der skal behandle dokumentet bliver vejledt i deres håndtering af dokumentet. Der sondres i denne kravspecifikation mellem interne noter, der kun må kunne ses af brugere af IFS, og eksterne noter der skal fremgå af et dokument når det sendes fra IFS til et andet system eller en vareleverandør 2A Det skal være muligt at tilføje interne noter på alle forretningsdokumenter, dvs. noter til andre brugere af IFS, så en indkøber fx kan skrive en forklaring på et dokument til en disponent Side 46 af 74

47 2A A A A A A A A A A A På alle forretningsdokumenter, der kan sendes fra IFS til vareleverandører skal det være muligt at tilføje eksterne noter dvs. noter til vareleverandører, fx jf. aftale af d.d., ønsket leveret efter 12, efter aftale med NN og lignende. Interne noter skal ikke kunne ses af brugere udenfor brugerinstitutionen. Eksterne noter skal kunne ses af såvel de interne brugere (rekvirent, indkøber, disponent m.fl.) som eksterne parter (dvs. vareleverandøren eller ØSC). Noter skal kunne angives i et fritekstfelt af passende størrelse. Interne noter må ikke kunne slettes når dokumentet er routet videre til andre fra brugeren der har angivet noten. Eksterne noter må ikke kunne slettes når dokumentet er routet videre fra IFS til et andet system eller en vareleverandør. Interne noter på dokumenter, der sendes fra en bruger til en anden bruger, skal som udgangspunkt fremgå i de adviseringsmails, der sendes til brugere som får tildelt et dokument Systemet skal kunne opsættes således, at brugere ved visse handlinger, fx ved ordreannullering eller når et dokument returneres til en fakturamanager, promptes til at skrive en obligatorisk note på dokumentet, inden handlingen kan udføres Det skal være muligt at vedhæfte en eller flere filer til alle forretningsdokumenter (PK) Funktionaliteten for vedhæftning af filer til et forretningsdokument, skal tage højde for begrænsningerne som følger af den gældende OIOUBL standard, og tydeligt orientere brugerne om disse (ØK) Vedhæftede filer skal automatisk medsendes et forretningsdokument der sendes fra IFS til en anden aktør, fx så en indscannet originalfaktura medsendes en manuelt oprettet faktura, når den manuelle faktura bliver godkendt og fremsendt til Navision Anvendelsen af noter og vedhæftning af filer, skal være simple og brugervenlige (PK) Anvendelsen af noter og vedhæftning af filer, er beskrevet i underbilag XX Kommentar [F65]: Eller en anden regnskabsafdeling Kommentar [F66]: Alle registreringer skal logges med dato og initialer Kommentar [F67]: Det skal være muligt at den bruger som har vedhæftet en fil også kan slette den igen dog ikke orginalfaktura, som er vedhæftet i forbindelse med oprettelse af en manuel faktura. Tjek også begrænsninger i UBL vedrørende flere filer Side 47 af 74

48 1. Placering og størrelse på interne noter (for IFS) i forbindelse med dokumentbehandling, herunder muligheder for at ændrer indholdet i noten. 2. Placering og størrelse på eksterne noter (for IFS) i forbindelse med dokumentbehandling, herunder muligheder for at ændrer indholdet i noten. 3. Mulighederne for at vedhæfte filer til de forskellige dokumenttyper, herunder muligheder for efterbehandling af det vedhæftede dokument 2A Berigelse af forretningsdokumenter, godkendelse af forretningsdokumenter og transaktionsspor I forbindelse med dokumentbehandling i IFS, vil en eller flere brugere ofte skulle berige et forretningsdokument med information, fx angivelse af aktører på dokumentet, leveringsadresser, datoer og sigende posteringstekster. Kontering af et forretningsdokument er også berigelse, men kravene til kontering er, i denne kravsspecifikation, angivet separat under afsnit XXX Kontering generelt. 2A A A A A Når en bruger vil berige et dokument, skal IFS på baggrund af brugerens opsætning og egenskaber angive forslagsværdier til fx indkøber, disponent, leveringsadresse, konteringsoplysninger, leveringsdato og bekræftelsesdato (PK) Alle brugere med rette adgang skal have mulighed for at redigere de relevante felter i et dokument, herunder felter hvor der er angivet forslagsværdier, indtil dokumentet er godkendt, uanset hvornår i processen dokumentet modtages eller tilgås (ØK) IFS skal automatisk angive et sigende forslag til posteringstekster på linjerne på et forretningsdokument, det kan fx som udgangspunkt være varebeskrivelsen (PK) En bruger med tilstrækkelige rettigheder skal kunne ændre posteringsteksten på en linje på et forretningsdokument, med henblik på at sikre retvisende bogføringsoplysninger i Navision, det kan fx være relevant, hvis en vareleverandørs varebeskrivelse ikke er tilstrækkeligt udspecificeret (PK) Oplysninger på dokumentlinjer som kan redigeres skal kunne redigeres for flere dokumentlinjer af gangen, så alle dokumentlinjer på en faktura fx kan beriges med den samme Side 48 af 74

49 posteringstekst på en gang, eller så en disponent kan anføres på flere forskellige linjer på en gang. 2A A A A A Når en bruger godkender et dokument eller dele af et dokument, skal systemet kontrollere om brugeren har tilstrækkelig prokura, inden godkendelsen gennemføres eller afvises af systemet (MK) IFS skal gemme et transaktionsspor på hvert dokument, hvor alle relevante handlinger der er foretaget på dokumentet tydeligt fremgår. Det skal tydeligt fremgå, hvilken handling der er tale om, hvem der har foretaget handlingen, hvornår handlingen er foretaget og om handlingen er udført på en anden brugers vegne med stedfortræderfunktionen (PK) Alle varemodtagelseshandlinger og godkendelseshandlinger på et dokument skal fremgå af transaktionssporret (MK) En bruger der står på et dokument skal herfra kunne se eller tilgå transaktionssporet for forretningsdokumentet (PK) Processerne for berigelse af forretningsdokumenter, skal være simple og brugervenlige (PK) Processerne for berigelse af forretningsdokumenter, er beskrevet i underbilag XX 1. Processen for angivelse af retvisende posteringstekst på ordre og faktura, herunder angivelse af hvem/hvilke roller der kan udføre handlingen 2. Processen for berigelse af flere dokumentlinjer på samme tid, fx valg af flere rekvirenter eller disponenter Kommentar [F68]: Vi skal bede om at få beskrevet hvilke handlinger der logges, hvordan de logges og hvordan de kan tilgås Kommentar [F69]: Endvidere skal det overvejes i hvilket omfang det bør logges andetsteds (ikke på dokumentniveau), hvem der logger ind i systemet, hvornår, og hvad de foretager sig. (ikke funktionelt krav) 2A Samspil med Navision Fakturaer, kreditnotaer, rykkere og kontoudtog overføres efter godkendelse i IFS til Navision, hvor dokumenterne skal accepteres, bogføres og betales. Det enkelte dokument behandles altså yderligere i Navision, hvorfor det kan være relevant at et dokument i IFS, der er sendt til Navision, opdateres med en række oplysninger, fx om dokumentets status i Navision 2A Når et dokument forsøges overført fra IFS til Navision skal dokumentet opdateres med oplysninger fra de tekniske kviteringer som tydeligt viser om dokumentet er afleveret korrekt eller om det er fejlet i overførslen. (ØK) Kommentar [F70]: Skal overvejes og er selvfølgelig meget afhængig af valget af transportlag Side 49 af 74

50 2A A A A Det skal være muligt for globale og lokale systemadministratorer at trække lister over dokumenter der er hhv. forsøgt sendt til Navision, afleveret korrekt til Navision og fejlet i overførslen til Navision (ØK) Hvis der for et godkendt dokument afsendt til Navision Stat modtages en application response, hvoraf det fremgår at dokumentet er blevet afvist i Navision Stat, skal dokumentet genåbnes i IFS, beriges med eventuelle oplysninger fra application responsen om årsagen til afvisningen, og distribueres til den eller de relevante bruger(e), med henblik på fornyet behandling og godkendelse. (PK) IFS skal kunne modtage transaktionsdata fra Navision, og opdatere forretningsdokumenterne med oplysninger om betalingsstatus (delvis betalt, betalt) og betalingsdato, jf. kravene i afsnit XX (PK) Funktionaliteten vedrørende integrationerne mellem IFS og Navision Stat, skal være simple og brugervenlige (PK) Integrationerne mellem IFS og Navision Stat, er beskrevet i underbilag XX 1. Processen for visning/udtræk af liste med status på alle dokumenter som er forsøgt afleveret til Navision 2. Processen for håndtering af et dokument som er afvist i Navision Stat 3. Processen for opdatering af transaktionsdata fra Navision til IFS 4. Visningen af betalingsstatus i forbindelse med søgeresultater og på det enkelte dokument Kommentar [F71]: Ikke funktionelle krav. 2A Kontering generelt 2A A Konteringen skal udføres med det enkelte regnskabs dimensionskontoplan overført fra Navision Stat (MK) Det skal være muligt at angive header-kontering på et forretningsdokument, dvs. en konteringsstreng der gælder for alle linjerne på forretningsdokumentet (MK) Side 50 af 74

51 2A A A A A A A A A A A A Det skal være muligt at ændre en angivet dimensionsværdi indtil forretningsdokumentet er godkendt (MK) Ved kontering skal en bruger kunne angive/søge efter en given dimensionsværdi ud fra enten talkoden eller beskrivelsen, alt efter brugerens præferencer (PK) Hvis konteringen på en eller flere dimensioner på en eller flere linjer, skal have en afvigende kontering fra headerkonteringen, skal det være muligt at angive afvigelsen alene ved at rette i de dimensioner på de relevante linjer som skal have en afvigende kontering (PK) Posteringslinjer skal kunne opsplittes i to eller flere konteringslinjer, der kan konteres separat, så udgiften belaster forskellige dele af regnskabet (PK) Når et dokument splitkonteres, skal systemet automatisk for hver linje angive et linje-id, så posteringerne kan styres i Navision Stat, jf. afsnit XXXX. Systemet skal understøtte automatiseret beslutningsstøtte for brugerne, fx ved hjælp af forslagskontering, konteringsskemaer, sidst benyttede værdier og bruger og enheds-specifikke begrænsninger mv. (PK) En lokal systemadministrator skal for et regnskab kunne opsætte, hvilke dimensioner det er obligatorisk at kontere på, inden dokumentet kan godkendes, og det skal tydeligt fremgå for brugerne om en dimension er obligatorisk når brugeren konterer (ØK) Når der angives en finanskonto eller et alias på et dokument skal en herfra afledt momskode vises for brugeren (PK) IFS skal understøtte direkte angivelse af momskoder, så en bruger med tilstrækkelige rettigheder, kan angive en momskode direkte eller kan ændre en momskode afledt fra en konto eller et alias (PK) Det skal i IFS brugerrettighedsmodel kunne konfigureres, hvilke brugere der har ret til at ændre momskoder (PK) IFS skal understøtte et regelsæt for gyldige konteringer overført fra Navision Stat, jf. bilag XX (PK) IFS skal understøtte anvendelsen af forskellige kontotyper overført fra Navision Stat, herunder balancekonti, varekonti og Kommentar [F72]: Dimensionsv ærdi bruges indtil videre noget bredere end det er defineret i NS, fx også om finanskonto og alias, der skal præciseres og konsistenstjekkes generelt Kommentar [F73]: Ud fra Procentfordeling eller eksakt fordeling Kommentar [F74]: Reference til det relevante integrationsafsnit. Skal nok flyttes til integrationskravene Kommentar [F75]: Hører egentlig til under systemkonfiguration, men er foreløbigt placeret her så kravene til momshåndtering står samlet Kommentar [F76]: Her tænkes foreløbigt i to alternative modeller, en hvor Navision regelsættet overføres direkte, og en hvor det overføres i en bearbejdet form, der forventes at være nemmere at håndtere for standardsystemer der ikke i forvejen har adopteret NS-regelsættet Side 51 af 74

52 2A A A A A A A anlægskonti, hvilket vil sige at en bruger skal kunne vælge fx en balance, varekonto eller en anlægskonto i stedet for en finanskonto (PK) En bruger skal ved kontering kun kunne se/angive de dimensionsværdier vedkommende har fået adgang til (PK) En lokal systemadministrator skal let kunne opsætte brugere til ikke at kunne se og anvende specifikke kontotyper, så brugeren fx ikke har adgang til balance, vare- og/eller anlægskonti (ØK) IFS skal understøtte elementerne AllowanceCharge (rabatter og gebyrer) og Tax (moms og andre afgifter der afregnes til det offentlige) i henhold til UBL-standarden (PK) IFS skal kunne håndtere AllowanceCharge elementer som en del af konteringen, hvilket vil sige at rabatter og gebyrer skal kunne konteres, hvis de er angivet på dokumenthovedet (ØK) AllowanceCharge elementer som er angivet på dokumentlinjer, skal alene vises for brugerne, da beløbet er indeholdt i linjens total (ØK) En bruger skal let, hurtigt og med et minimum af operationer med mus og/eller keyboard kunne danne sig et overblik over kontering på et forretningsdokument (PK) Processen for kontering af forretningsdokumenter i IFS skal være simpel, brugervenlig og skal kunne gennemføres med minimal anvendelse af operationer med mus (PK) Processen for kontering af forretningsdokumenter i IFS er beskrevet i underbilag XX [Leverandøren skal i underbilag XX redegøre for følgende: 1. Processen for kontering 2. Processen for opsplitning af konteringslinjer 3. Konteringshjælp i IFS, og håndtering af konteringsregelsæt overført fra Navision Stat 4. Håndtering af allowance charge og tax elementer i IFS Kommentar [F77]: Henvisning til stamdataudvekslingsformatet.. Jeg er med på at der skal strammes op på begreberne her, det sker ifbm udarbejdelsen af krav til integrationer. 2A Omkontering 2A Man skal kunne omkontere godkendte dokumenter i systemet (PK) Side 52 af 74

53 2A A IFS skal give mulighed for at godkendelsen af et omkonteret dokument kan danne et udlignende dokument for den kontering som allerede er bogført i Navision Stat (ØK) Processerne for omkontering af et dokument, skal være simple og brugervenlige (PK) 2A.4.13 Kreditnotaer Processerne for omkontering af et dokument, er beskrevet i underbilag XX 1. Processen for omkontering af en såvel ordre som faktura Behandling af kreditnotaer bør som udgangspunkt fungere på samme måde som behandlingen af fakturaer, med to undtagelser: En kreditnota bør kobles til den faktura som kreditnotaen vedrører, hvis muligt, og en kreditnota bør ikke automatches/godkendes, da en kreditnota er et tegn på at der allerede er gået noget galt i transaktionsprocessen, hvorfor det ønskes at en kreditnota altid valideres af en bruger inden den godkendes. Kommentar [F78]: Der er næppe tale om udbredt standardfunktionalitet,, og der er argumenter for at omkontering skal ske via DDI. Det overvejes om afsnittet skal slettes helt. 2A En række krav vedrørende fakturabehandling finder tilsvarende anvendelse for behandling af kreditnotaer, det drejer sig om følgende krav: 2A A A A A A A A A A A A Kommentar [F79]: Bemærk at krav og ikke finder anvendelse da der ikke er payment means på en KN Kun hvis det tilbudte system opfylder alle de underliggende krav skal tilbudsgiver angive compliance til krav 2A Er kun nogle af de underliggende krav opfyldt, skal tilbudsgiver angive delvis compliance til krav 2A og tydeligt redegøre for, hvilke af de underliggende krav, der er opfyldt, og, hvilke der ikke er, i bilag XX (PK) Side 53 af 74

54 2A A A A Ved modtagelse af en kreditnota skal systemet finde den tilhørende faktura og evt. ordre og automatisk tilknytte kreditnotaen til disse (PK) Kan kreditnota ikke automatisk tilknyttes til en faktura, skal kreditnotaen manuelt kunne tilknyttes fakturaen og evt. en indkøbsordre (PK) Modtages en kreditnota med en uønsket kobling til en ordre og/eller faktura, skal det være muligt at koble kreditnotaen fra både ordren og fakturaen (PK) Processerne for håndtering af kreditnotaer, skal være simple og brugervenlige (PK) Processerne for håndtering af kreditnotaer, er beskrevet i underbilag XX 1. Processen for håndtering af kreditnota uden kobling til faktura eller ordre 2. Processen for automatisk håndtering af kreditnota som matcher faktura 3. Processen for til- og frakobling af kreditnota med faktura og/eller ordre Kommentar [F81]: Kan kontering arves på en sigende måde på KN? Overvejes 2A.4.14 Rykkere og kontoudtog Rykkere kan modtages med eller uden et rykkergebyr, der skal betales. For rykkere med et gebyr gælder det, som for en kreditnota, at behandling af rykkeren som udgangspunkt bør fungere på samme måde som behandlingen af fakturaer, med to undtagelser: En rykker bør kobles til den faktura som rykkeren vedrører, hvis muligt, og en rykker må ikke autogodkendes, da en rykker er et tegn på at der allerede er gået noget galt i transaktionsprocessen, hvorfor det ønskes at en rykker altid valideres af en bruger inden den godkendes. Dokumentflowet for Rykkere uden et rykkergebyr og for kontoudtog bør være væsentligt simplere end flowet for fakturaer og rykkere med gebyr, da de ikke har direkte påvirkning på institutionernes regnskaber. Ud over kravene til dokumentbehandling generelt, gælder følgende krav for rykkere og kontoudtog: Side 54 af 74

55 2A A Brugerinstitutionernes vareleverandører skal kunne sende rykkere med eller uden gebyrer og kontoudtog direkte til IFS i OIOUBL format (MK) En række krav vedrørende fakturabehandling finder også anvendelse for behandling af rykkere med gebyrer, det drejer sig om følgende krav: 2A A A A A A A A A A A A A A A Kun hvis det tilbudte system opfylder alle de underliggende krav skal tilbudsgiver angive compliance til krav 2A Er kun nogle af de underliggende krav opfyldt, skal tilbudsgiver angive delvis compliance til krav 2A og tydeligt redegøre for, hvilke af de underliggende krav, der er opfyldt, og, hvilke der ikke er, i bilag XX (PK) Ved modtagelse af en rykker med eller uden gebyr skal systemet finde den tilhørende faktura og evt. ordre og automatisk tilknytte rykkeren til disse (PK) Kan en rykker med eller uden gebyr ikke automatisk tilknyttes til en faktura, skal rykkeren manuelt kunne tilknyttes fakturaen og evt. en indkøbsordre (PK) Modtages en rykker med eller uden gebyr med en uønsket kobling til en ordre og/eller faktura, skal det være muligt at koble rykkeren fra både ordren og fakturaen (PK) Indkomne rykkere uden gebyrer og kontoudtog skal automatisk fremsendes til den referenceperson, der er angivet på dokumentet. Hvis der ikke er en genkendelig personreference på dokumentet, skal dokumentet routes til en fakturamanager, eller fakturamanager skal på anden vis blive gjort opmærksom på at der er modtaget et dokument som skal behandles (ØK) Rykkere uden gebyr og kontoudtog skal kunne accepteres, eller på anden måde markeres som behandlet så dokumentet skifter status (ØK) Kommentar [F82]: Nummererin g skal verificeres, nå kravspec er ved at være færdig Side 55 af 74

56 2A A Når en rykker uden betalingsanmodning eller et kontoudtog er accepteret skal dokumentet automatisk fremsendes til Navision Stat (ØK) Processerne for håndtering af rykkere og kontoudtog, skal være simple og brugervenlige (PK) Processerne for håndtering af rykkere og kontoudtog, er beskrevet i underbilag XX 1. Processen for håndtering af rykkere, med og uden gebyr 2. Processen for håndtering af kontoudtog 2A.4.15 Forsyningsspecifikationer (UTS) 2A A A A A A A Brugerinstitutionernes vareleverandører skal kunne sende Forsyningsspecifikationer (UTS-dokumenter) direkte til IFS i OIOUBL format (MK) IFS skal kunne modtage og vise OIOUBL ForsyningsSpecifikationen (UTS), som et selvstændigt bilag til det dokument de vedrører (PK) Sammenkoblingen mellem en forsyningsspecifikation og det dokument specifikationen vedrører skal automatisk ske, uanset hvilken rækkefølge de modtages i (PK) Det skal være muligt manuelt at tilknytte en forsyningsspecifikation til et dokument, fx hvis referencen på specifikationen er forkert (ØK) I IFS skal det fremgå at faktura/kreditnota har tilknyttet UTS er, og antallet af specifikationer skal være tydeligt for brugeren, og specifikationerne skal være lette at tilgå fra fakturaen/kreditnotaen (ØK) IFS skal automatisk videresende forsyningsspecifikationer til Navision Stat (PK) Visningen af UTS en skal som minimum være i det af Digitaliseringsstyrelsen til enhver tid anbefalede stylesheet. Der skal desuden være yderlige tiltag i forhold til overskuelighed og læsbarhed (PK) Side 56 af 74

57 2A Processen for håndtering af forsyningsspecifikationer, skal være simple og brugervenlige (PK) Processerne for håndtering af forsyningsspecifikationer, er beskrevet i underbilag XX 3. Processen for håndtering af faktura med en eller flere tilknyttede forsyningsspecifikationer 4. Er processen uafhængig af tidspunktet for modtagelse af UTS en (før/efter fakturamodtagelsen) 2A.4.16 Søgning i IFS Søgning i IFS kan deles op i to typer af søgninger: Søgning på feltniveau, hvor en bruger søger efter en specifik værdi, fx en dimensionskontoværdi eller en specifik bruger, med henblik på at vælge værdien så den bliver angivet i et specifikt felt på et dokument eller stamkort; og søgning på dokumentniveau/ stamkortniveau, hvor en bruger søger efter et eller flere stamkort eller dokumenter. Ved søgning på feltniveau vil en bruger normalt alene være interesseret i at finde frem til en specifik værdi, som der søges direkte efter. En bruger, der søger efter dokumenter eller stamkort kan derimod være interesseret i at få returneret mange resultater, der opfylder et sæt af søgekriterier, og kan være interesseret i at undersøge egenskaberne for det fremsøgte nærmere, fx kan en systemadministrator fremsøge brugerstamkort, med henblik på at undersøge brugernes rettigheder nærmere. 2A Generelle krav til søgning 2A A A A A Søgemulighederne i IFS skal være fleksible, brugervenlige og omfattende (MK) IFS skal have forskellige typer af søgemuligheder, fx fritekstsøgning, quick-søgning og kompleks søgning (PK) Søgeresultater skal fremvises på en struktureret og overskuelig form, så brugerne fx får et oversigtsbillede med et dokument eller en record (fx vare) pr linje (PK) Søgeresultatet må kun vise data som brugeren har adgangsrettigheder til at se i systemet, så en bruger fx kun får returneret varer fra kataloger som brugeren har rettigheder til (PK) En bruger skal selv have mulighed for at konfigurere, hvilke datafelter der skal vises som kolonner i søgeresultater (ØK) Side 57 af 74

58 2A A A A A A A A Det skal være muligt at gemme søgninger (PK) Det skal være muligt at filtrere/sortere på søgeresultater, så man fx kan sortere et søgeresultat efter leverandørnavn og/eller betalingsdato og/eller beløb (PK) Det skal være muligt at gemme den ønskede sortering af søgeresultater (ØK) Det skal fremgå tydeligt, hvor mange resultater der er fundet af en søgning, også 0, hvis der ingen resultater er fundet, så brugeren tydeligt kan se at søgningen er gennemført (PK) Antallet af søgeresultater som systemet kan returnere, må i praksis ikke være afgrænset, antallet af søgeresultater der vises pr side må gerne være afgrænset (PK) Det skal være muligt at søge på dele af et ord (PK) Ved søgning efter en specifik værdi på feltniveau skal det være muligt at foretage en søgning på aliaser for værdien, fx så en dimensionskontoværdi kan fremsøges både ud fra talkoden og ud fra beskrivelsen, og så en bruger kan fremsøges ud fra brugernavn, brugerens fulde navn eller brugerens initialer (PK) Søgeprocesserne i IFS skal være fleksible, simple og brugervenlige (PK) Søgeprocesserne i IFS er beskrevet i underbilag XX 1. Søgeprocessen i forbindelse med dokumentsøgning, herunder angivelse af hvilke værdier der kan søges på (fx dimensionsværdier) 2. Søgeprocessen i forbindelse med varesøgning (katalog), herunder angivelse af hvilke værdier der kan søges på 3. Muligheder for behandling af søgeresultatet for henholdsvis dokumentsøgning og varesøgning 4. Muligheder for at tilpasse søgning og visning af søgeresultat på organisations- og brugerniveau Kommentar [F83]: Det er vel ok, hvis begrænsningen er en 6 cifret størrelse eller mere? Kommentar [F84]: Kan vi finde et andet ord der ikke forveksles med Alias fra Navision? 2A Varesøgning 2A Brugeren skal kunne fremsøge varer fra alle kataloger som brugeren har adgang til i et enkelt søgebillede (ØK) Side 58 af 74

59 2A A A A En bruger skal kunne fremsøge en vare i et elektronisk varekatalog ud fra alle de oplysninger der fremgår om varen i kataloget, herunder metadata om varens tilknytning til kataloget eller en aftale og de heraf afledte egenskaber Brugerne skal kunne begrænse varesøgning, baseret på varekategori, tilknytning til aftale eller favoritliste, katalog mm. IFS skal understøtte søgning ved at benytte de aliaser/metatags vareleverandørerne indsætter i katalogerne (ØK) Processen for varesøgning, skal være simpel og brugervenlig (PK) Processen for varesøgning, er beskrevet i underbilag XX 1. Processen for varesøgning med angivelse af hvilke wildcards systemet håndterer 2. Muligheder for at tilpasse visningen af søgeresultat herunder hvilke oplysninger det vil være muligt at få vist Kommentar [F85]: Igen skal vi passe på med begrebsforvirring Kommentar [F86]: Bør defineres, og evt. indarbejdes i krav 2A Søgning på dokument og stamkortniveau 2A A A A A Brugerne skal kunne åbne et dokument eller et stamkort direkte fra et søgeresultat Fortrolige dokumenter må ikke fremgå af et søgeresultat medmindre brugeren der foretager søgningen har rettigheder til at se fortrolige dokumenter (ØK) Dokumentstatus og tilhørsforhold skal tydeligt fremgå af søgeresultatet så man fx kan se at en specifik faktura er sendt til godkendelse hos en specifik disponent i en specifik organisations-enhed (PK) Det skal være muligt at fremsøge dokumenter og stamkort (fx brugere, varer og kreditorer) i systemet som er blevet spærret, afvist eller lignende, og det skal være muligt at fravælge spærrede/afviste dokumenter og stamkort i søgekriterierne (PK) Det skal tydeligt fremgå af søgeresultatet om en anden bruger anvender et dokument, som fremgår på søgeresultatet (ØK) Kommentar [F87]: Der skal stå mere om fortrolige dokumenter. Mht. visning på søgeresultater vil nogen godt have dem på listen (annonymiseret?), fx i forbindelse med support. Side 59 af 74

60 2A A A A A A A A A A A A A Det skal være muligt at fremsøge et dokument eller et stamkort ud fra en kombination af søgekriterier (PK) Det skal være muligt at fremsøge dokumenter og stamkort på en kombination af parametre, så en bruger fx kan fremsøge alle dokumenter med en af to forskellige statusser i én samlet søgning (PK) Det skal være muligt at fremsøge dokumenter på specifikke dokument-id er (fx et specifikt fakturanummer) (PK) Det skal være muligt at fremsøge dokumenter der er allokeret til én bestemt bruger (PK) Det skal være muligt at fremsøge alle dokumenter som en specifik bruger har behandlet, så en bruger fx kan fremsøge egne dokumenter jf. afsnit XX, eller så en controller kan fremsøge alle dokumenter der har været behandlet af en specifik bruger (PK) Det skal være muligt at søge efter dokumenter der har været håndteret af en bestemt bruger i kombination med en specifik handling, så en controller fx kan fremsøge alle dokumenter, der er blevet godkendt af en specifik bruger (ØK) Det skal være muligt at fremsøge dokumenter ud fra datointervaller (PK) Det skal være muligt at fremsøge dokumenter ud fra beløbsintervaller (PK) Det skal være muligt at fremsøge dokumenter ud fra leverandørnavn og ud fra CVR-nr (eller anden leverandøridentifikator) (PK) Det skal være muligt at fremsøge dokumenter ud fra dokumentstatus (PK) Det skal være muligt at fremsøge et dokument ud fra en dimensionsværdi, der er angivet på dokumentet, eller en kombination af dimensionsværdier der er angivet på dokumentet En fakturafordeler skal med én simpel søgning kunne fremsøge alle dokumenter som er i flow, dvs. dokumenter der endnu ikke er godkendt (ØK) En bruger skal kunne eksportere et søgeresultat til Excel eller lignende (ØK) Side 60 af 74

61 2A A En bruger skal efter at have fremsøgt et sæt fakturaer i IFS, kunne udskrive eller eksportere de tilhørende originalfakturaer direkte fra søgeresultatet, fx af hensyn til dokumentation til EU eller en fond (ØK) Processen for dokumentsøgning, skal være simpel og brugervenlig (PK) Processen for dokumentsøgning, er beskrevet i underbilag XX 3. Processen for dokumentsøgning med angivelse af hvilke wildcards systemet håndterer 4. Muligheder for at tilpasse visningen af søgeresultat, herunder hvilke oplysninger det vil være muligt at få vist Kommentar [F88]: Det er umiddelbart et ret krøllet krav, men det er et ønske vi har modtaget fra en række institutioner så det bør fremgå, alternativt kan vi måske finde en anden løsning (data bør kunne hentes fra ØSLDV) 2A.4.17 Systemkonfiguration IFS skal kunne konfigureres på tre niveauer: Globalt af globale systemadministratorer, lokalt (organisationsniveau) af lokale systemadministratorer og på brugerniveau. Dele af konfigurationen på brugerniveau skal den enkelte bruger selv kunne gennemføre, mens det er den lokale systemadministrator, der skal udføre andre dele af brugerkonfigurationen. Det forudsættes, at IFS i stor udstrækning kan konfigureres, men at det ligeledes kan anvendes med en standardopsætning konfigureret af Tilbudsgiver, således at IFS er meget simpelt at tage i brug for Kunden. 2A Generelle krav til systemkonfiguration 2A A A A A Opsætning af systemet skal kunne konfigureres af kunden (MK) Konfiguration skal kunne ske i systemets brugergrænseflade (ØK) De enkelte enheder/organisationer og brugere i systemet skal kunne konfigureres forskelligt (PK) Brugergrænsefladen skal være konfigurerbar for den enkelte bruger (ØK) Globale systemadministratorer skal have adgang til værktøjer til at eksportere og importere opsætningsdata (PK) Kommentar [F89]: Tidligere har vi et krav om at det skal ske i en moderne applikation, skal ensrettes Kommentar [F90]: Krav fra gl. kravspec. Der er klare fordele, men også potentielle ulemper fx ifbm support Side 61 af 74

62 2A A A A A A A A A A Lokale systemadministratorer skal have adgang til værktøjer til at eksportere og importere opsætningsdata inden for deres eget domæne, herunder brugerstamdata og -rettigheder (PK) IFS skal lokalt kunne opsættes til altid at kræve, at der er mindst to brugere inde over afsendelse af en indkøbsordre, så rekvisitionen fx ikke kan oprettes og godkendes af den samme bruger (ØK) IFS skal lokalt kunne opsættes til altid at kræve, at der er mindst to brugere inde over behandlingen af en faktura uden en tilknyttet ordre, så varemodtagelse og godkendelse fx skal foretages af forskellige brugere (ØK) En lokal systemadministrator skal kunne konfigurere om den enkelte bruger har ret til se fortrolige dokumenter (PK) En lokal systemadministrator skal kunne angive flere forskellige personreferencer for den enkelte bruger, så det gælder at dokumenter automatisk kan allokeres til brugeren ud fra flere forskellige værdier, så det fx kan konfigureres at brugeren genkendes uanset om det er brugerens fuld navn, initialer eller e- mail adresse der er angivet som personreference (ØK) En bruger skal kunne anmode om, at systemet automatisk sender et nyt password til brugerens adresse (PK) IFS skal have et dansk og et engelsk sproglag (MK) Det valgte sproglag skal slå igennem i alle dele af IFS, så bl.a. også log-on side, adviser og fejlmeddelelser præsenteres for brugeren på det sprog som er valgt (PK) Valg af sproglag skal kunne konfigureres på brugerniveau (PK) Processen for opsætning af en ny organisation, skal være simpel og brugervenlig (PK) Processen for opsætning af en ny organisation, er beskrevet i underbilag XX 1. Processen for opsætning af en ny organisation manuelt 2. Processen for opsætning af en ny organisation via et indlæsningsværktøj Kommentar [F91]: Disse krav understøtter ikke best practice, men er meget efterspurgte Kommentar [F92]: Her mangler krav om dokumentation for de mere brugerrettede dele Side 62 af 74

63 2A Konfiguration af regnskaber 2A A A A Globale systemadministratorer skal kunne opsætte og administrere integrationen mellem de organisatoriske enheder i IFS og Navision Stat regnskaberne som beskrevet i afsnit XX De tekniske krav til integrationen mellem IFS og Navision Stat er beskrevet i afsnit XX Systemadministratorer og fakturamanagere mv. skal let kunne se, hvornår der sidst er opdateret stamdata fra Navision Stat pr. bogføringskreds/regnskab Processerne for opsætning og vedligeholdelse af et regnskab, skal være simple og brugervenlige (PK) Processerne for opsætning og vedligeholdelse af et regnskab, er beskrevet i underbilag XX 1. Processen for opsætning og vedligeholdelse af et regnskab i IFS 2. Hvilke regler og funktioner bestemmes på regnskabsniveau 3. Frekvensen hvormed IFS kan modtage og indlæse stamdata fra alle statens regnskaber Kommentar [F93]: Det er fint nok, men er vel egentlig ikke en del af de funktionelle krav 2A Konfiguration af Adviser IFS skal kunne konfigureres til automatisk at gøre brugerne opmærksomme på ændringer i IFS, der er relevante for brugerne, gennem adviseringer. 2A A Teksterne i adviseringerne skal være sigende sammenhængende og forståelige standardtekster og indeholde dybe links, så en bruger kan gå direkte til det eller de dokument(er), adviset henviser til. Enhver relevant handling som IFS enten foretager automatisk eller som gennemføres af en bruger, skal kunne generere en advis til de relevante brugere. En ikke udtømmende liste over handlinger, der er relevante, og som derfor skal kunne udløse et advis til en bruger, er: Side 63 af 74

64 Der indlæses et nyt katalog Der indlæses en katalogopdatering Et forretningsdokument allokeres til brugeren Et forretningsdokument der er relevant for brugeren godkendes, bekræftes eller afvises af en leverandør eller af en anden bruger i IFS Der modtages en ordreændringsanmodning, på en ordre der er relevant for brugeren En ordre, der er relevant for brugeren, annulleres af en anden bruger i IFS En faktura automatcher med en ordre, der er relevant for brugeren Et dokument tilknyttes til et andet dokument, der er relevant for brugeren En faktura tilknyttes en ordre, der er relevant for brugeren men match kan ikke gennemføres Et dokument der er relevant for brugeren skifter status (PK) 2A A A A A A Forskellige handlinger skal have forskellige typer af adviser tilknyttet (PK) Indholdet af adviserne skal være konfigurerbart globalt så det kun er globale systemadministratorer der kan ændre i indholdet i standardteksterne (ØK) Hver type af advis skal kunne konfigureres separat (ØK) Indholdet af adviset skal kunne hente oplysninger fra IFS, der får advis en til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne og beløb (ØK) Præferencer(regler) for modtagelse af adviser skal kunne konfigureres lokalt på organisationsniveau, og på brugerniveau (PK) Det skal være muligt, at vælge mellem om en bruger skal modtage en advisering pr. relevant handling, eller om brugeren Side 64 af 74

65 skal modtage en samlet advisering pr. dag, der dækker alle relevante handlinger (ØK) 2A A A A A A Adviser skal kunne sendes som s til brugerne (PK) Et advis skal indeholde et dybt link til det eller de dokument(er) som adviset vedrører (PK) Lokale systemadministrator skal kunne opsætte frekvens for afsendelse af adviser, der automatisk sendes som følge af en brugers manglende handling (ØK) IFS skal understøtte muligheden for manuelt at generere en advis, der kan sendes som følge af en brugers manglende håndtering af et dokument (ØK) IFS skal ikke sende et advis til en bruger, hvis der er brugeren selv, der har foretaget handlingen, som udløser advisen (PK) Processerne for konfiguration af adviseringer, skal være simple og brugervenlige (PK) Processerne for konfiguration af adviseringer, er beskrevet i underbilag XX 1. Processen for konfiguration af en advis 2. Mulighederne for at tilpasse modtagelsen af adviser på organisations og brugerniveau 3. Eksempel på indholdet i en advis 2A Konfiguration af Fejlmeddelelser Ideelt set skal brugerne af IFS aldrig se en fejlmeddelelse i systemet fordi det ikke er muligt at lave fejl i systemet, fx fordi det ikke er muligt at vælge ugyldige værdier eller handlinger. 2A A Hvis en bruger alligevel skulle forsøge at gennemføre en ugyldig handling, eller hvis et teknisk problem gør at en handling ikke kan gennemføres korretkt, skal IFS automatisk returnere en fejlmeddelese til brugeren (PK) Teksterne i fejlmeddelelserne skal være sigende sammenhængende og forståelige standardtekster, og skal vejlede brugerne til at komme videre i deres brug af systemet. Side 65 af 74

66 2A A A Indholdet af fejlmeddelelserne skal være konfigurerbart globalt så det kun er globale systemadministratorer der kan ændre i indholdet i standardteksterne (ØK) Indholdet af fejlmeddelelserne skal kunne hente oplysninger fra IFS, der får fejlmeddelelsen til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne og beløb (ØK) Processerne for konfiguration af fejlmeddelelser, skal være simple og brugervenlige (PK) Processerne for konfiguration af fejlmeddelelser, er beskrevet i underbilag XX 1. Processen for konfiguration af en fejlbesked 2. Liste over samtlige fejlbeskeder i systemet 2A Konfiguration af s til vareleverandører Som angivet i afsnit XX vil vareleverandører, der ikke er i stand til at modtage ordrer fra IFS i OIOUBL formatet, skulle have tilsendt ordrer fra IFS som e- mails. 2A A A A A Når en ordre sendes til en leverandør fra IFS via , skal selve ordren fremgå som en PDF-vedhæftning til en. Teksterne og emnelinjerne i en skal være sigende sammenhængende og forståelige standardtekster Indholdet af en skal være konfigurerbart lokalt så lokale systemadministratorer kan ændre i indholdet i standardteksterne. Indholdet af en skal kunne hente oplysninger fra IFS, der får en til at fremstå personlig og informerende, fx: brugernavne, dokumentnumre, leverandørnavne, oplysninger om de ønskede varer og beløb (ØK) Processerne for konfiguration af s til vareleverandører, skal være simple og brugervenlige (PK) Processerne for konfiguration af s til vareleverandører, er beskrevet i underbilag XX Side 66 af 74

67 1. Processen for konfiguration af s til vareleverandører 2. Eksempel på inkl. PDF-vedhæftning 2A Konfiguration af Matchkriterier 2A A A A A A A A Konfiguration af matchkriterier skal kunne opsættes lokalt af en lokale systemadministrator Automatch skal helt kunne fravælges generelt på organisationsniveau Der skal kunne opsættes generelle afvigelsestolerancer på organisationsniveau Det skal være muligt i den enkelte organisation, at opsætte afvigelsestolerancer for et specifikt katalog, prisliste aftale og/eller leverandør, som overstyrer de generelle afvigelsestolerancer for organisationen Det skal være muligt på en stående ordre, at opsætte afvigelsestolerancer, som overstyrer de generelle afvigelsestolerancer for organisationen Afvigelsestolerancer skal kunne opsættes som specifikke beløb og/eller som procentsatser Der skal kunne opsættes specifikke afvigelsestolerancer fsva allowance charge og tax elementer Processerne for oprettelse og vedligeholdelse af matchkriterier, skal være simple og brugervenlige (PK) Processerne for oprettelse og vedligeholdelse af matchkriterier, er beskrevet i underbilag XX 1. Processen for oprettelse og vedligeholdelse af matchkriterier på de forskellige ordretyper 2. Muligheder for fleksibel opsætning af matchkriterier Kommentar [F94]: JMH: Det kan diskuteres om dette krav skal være der (er en afvigelse fra best practice) Side 67 af 74

68 2A Konfiguration af grupper og konteringshjælp For at sikre, at brugere af IFS kun kan se og kun skal forholde sig til det data, der er relevant for brugeren, kan det være hensigtsmæssigt at brugernes adgang til data kan begrænses lokalt fx ved at brugere allokeres til grupper der begrænser medlemmernes adgang til data i den enkelte organisation. Det er ikke et krav at IFS opererer med gruppebegrebet, gruppe-begrebet anvendes alene i dette afsnit for at beskrive kundens behov for funktionalitet til at begrænse brugeres adgang til data. 2A A A A A A A A A Systemadministratorer skal pr regnskab eller organisationsenhed let kunne begrænse grupper af brugeres adgang til data (fx adgang til specifikke kataloger, specifikke favoritlister, specifikke punch out forbindelser, specifikke disponenter og specifikke sæt af dimensionskontoværdier ved berigelse af dokumenter med data) (PK) Systemadministratorer skal pr regnskab eller organisationsenhed let kunne styre grupper af brugeres prokura, så det fx er let at ændre alle kontorchefers prokura i en styrelse på en gang (ØK) Den lokale systemadministrator skal pr. regnskab kunne opsætte, hvilke dimensioner, der anvendes og vises i IFS (PK) Den lokale systemadministrator skal pr. regnskab kunne opsætte, i hvilken rækkefølge dimensionerne skal vises i, i IFS (PK) Den lokale systemadministrator skal pr. regnskab kunne opsætte, hvilket navn, der vises for den enkelte dimension i IFS (PK) Det skal være let og brugervenligt for en systemadministrator at begrænse en bruger, eller en gruppe af brugeres adgang til data (PK) Det skal være let for en systemadministrator, at danne sig et overblik over, hvordan brugernes adgang til data er blevet begrænset af grupper eller lignende (PK) En specifik bruger skal kunne tilknyttes mere end en gruppe pr. regnskab og datatype, så en bruger fx både kan være tilknyttet en gruppe, der gør at brugeren ikke kan vælge anlægskonti og en gruppe der gør at brugeren ikke kan vælge finanskonti som vedrører repræsentation (PK) Systemadministratorer skal, gældende pr regnskab eller organisationsenhed og evt. bruger, kunne lave en fleksibel Kommentar [F95]: JDA. Felter. JMH: Enig i at det er bredere end dimensioner, skal specificeres Kommentar [F96]: Skal tilføjes et eksempel, dvs. overføres Formael skal det kunne vises som Formål Side 68 af 74

69 opsætning af obligatoriske dimensioner som skal udfyldes på et forretningsdokument for at et dokument kan godkendes (PK) 2A A A A Systemadministrator skal pr. regnskab eller organisationsenhed kunne definere standardkontoværdier, som præudfyldes på et dokument, medmindre feltet i forvejen indeholder en værdi. IFS skal understøtte en fleksibel opsætning af standardelementer, for den enkelte bruger, som udfyldes automatisk når den enkelte bruger åbner eller påbegynder arbejdet på et dokument, hvor elementerne ikke allerede er udfyldt, fx angivelse af disponent, leveringsadresse og dimensionskontoværdier (ØK) Den enkelte aftale, leverandør, varekategori (UNSPSC) og vare skal kunne tildeles dimensionskontoværdier, på regnskabsniveau, som automatisk afledes når en vare vælges (ØK) Processerne for oprettelse og vedligeholdelse af grupper og konteringshjælp, skal være simple og brugervenlige (PK) 2A Processerne for oprettelse og vedligeholdelse af grupper og konteringshjælp, er beskrevet i underbilag XX 3. Processen for oprettelse og vedligeholdelse af diverse former for grupper i systemet 4. Processen for oprettelse og vedligeholdelse af mulig konteringshjælp i systemet Konfiguration af adresser 2A IFS skal håndtere alle adresser, der anvendes i forbindelse med ordreafgivelse, som strukturerede adresser i henhold til UBLbekendtgørelsen, så leverandørerne altid modtager faktureringsog leveringsadresserne ensartet (PK) Kommentar [F97]: Vi skal også bede om at få beskrevet det indbyrdes hierarki mellem forskellige former for konteringshjælp Kommentar [F98]: Skal overvejes om vi skal have krav om leveringsadresser på linjeniveau, formatet understøtter det, men vi ved at en lang række leverandørers systemer ikke gør. 2A A A Systemadministrator skal kunne definere standardadresser pr regnskab eller organisationsenhed (ØK) I forbindelse med ordreafgivelse skal en bruger kunne anvende standardadresserne I forbindelse med ordreafgivelse skal en bruger kunne angive fritekstadresser, dvs. adresser som brugeren selv indtaster Side 69 af 74

70 2A A A IFS skal huske, hvilke adresser en bruger tidligere har anvendt, så en bruger let kan genanvende dem En systemadministrator skal lokalt og på brugerniveau kunne konfigurere, at det ikke er muligt at angive fritekstadresser Processerne for opsætning og vedligeholdelse af adresser, skal være simple og brugervenlige (PK) Processerne for opsætning og vedligeholdelse af adresser, er beskrevet i underbilag XX 1. Processen for oprettelse af nye strukturerede adresser og herunder angivelse af tilhorsforhold for den pågældende adresse 2. Mulighederne for opsætning af standard adresser 2A.4.18 Rapportering Det er væsentligt for effektiviseringen af statens indkøbs- og fakturahåndtering, at der kan udtrækkes data om anvendelsen af IFS, som kan anvendes til at analysere statistik, historik og opfølgningsrutiner. 2A A A A A Systemet skal stille fleksible og brugervenlige rapporteringsmuligheder til rådighed for brugerne, i systemets egen brugergrænseflade (PK) Alle rapporter skal kunne eksporteres fra systemet, til Excel, PDF og lignende, så data nemt kan viderebehandles (PK) Rapporter skal kunne udskrives direkte fra IFS (ØK) En bruger skal kunne gemme specifikationer af rapporter, eller rapportskabeloner, så det er let og hurtigt systematisk at udtrække data fra IFS periodisk (ØK) En lokal systemadministrator og en revisionsbruger skal i IFS kunne trække en rapport over tildelte brugerrettigheder, hvor man kan se brugeropsætningen på et givet tidspunkt. Denne rapport skal indeholde alle brugeroplysninger i det domæne den trækkes for, herunder tildelte systemroller, adgangsrettigheder og prokuragrænser for den enkelte bruger i den enkelte organisatoriske enhed. Rapporten skal udtrækkes periodisk og vedlægges som bilag til den enkelte brugerinstitutions regnskabsinstruks. (PK) Side 70 af 74

71 2A A A A A A Øvrigt En lokal systemadministrator og en revisionsbruger skal i IFS kunne trække en rapport over ændrede brugerrettigheder over en periode, hvor man kan se ændringer i brugernes roller, adgangsrettigheder og prokura i en given periode. Denne rapport skal indeholde alle ændringer for alle brugere i det domæne den trækkes for den ønskede periode. Rapporten skal den lokale systemadministrator udtrække periodisk og rapporten skal godkendes og vedlægges som bilag til den enkelte brugerinstitutions regnskabsinstruks. (PK) Systemet skal kunne levere en rapport som indeholder en oversigt over match, fejlmatch og automatch for en periode som brugeren definerer. I det omfang dokumenter er fejlmatchet eller matchet, men ikke automatchet skal årsagen til det manglende match eller det manglende automatch tydeligt fremgå af rapporten, så det fx kan ses, at et automatch ikke har fundet sted oprindeligt, som følge af manglende varemodtagelse, men at automatchet efterfølgende blev gennemført efter at varemodtagelsen blev registreret. Rapporten skal anvendes til identificering af årsager og omfanget af fejl match (PK) Al forretningsdata fra IFS skal eksportere til ØSLDV, inklusiv originalbilag, med henblik på at kunden kan byge sine rapporter, som beskrevet i afsnit XX. Det er alene rene systemdata der ikke behøves eksporteret (MK) Processerne for adgang til relevante rapporter, skal være simple og brugervenlige (PK) Processerne for adgang til relevante rapporter, er beskrevet i underbilag XX 1. Processen for adgang til rapporter indenfor en styrelse med to bogføringskredse 2. Processen for adgang til rapporter indenfor et ministerium bestående af 5 styrelser og 10 bogføringskredse 3. Processen for adgang til rapporter på tværs af alle organisationer oprettet i IFS 4. Hvilke mulige rapporter der kan trækkes Kommentar [F99]: Kravene til systemets rapporter kan forekomme beskedne, hvilket skyldes at rapportering skal kunne ske i ØSLDV, det betyder til gengæld også, at dataoverførslen til ØSLDV skal fungere inden IFS tages i brug (Der er i den forbindelse justeret i opgavefordelingen mellem Modst og tilbudsgiver, så de (ikke-funktionelle) krav til leverandøren vedr. overførsel til ØSLDV bør være simple at overholde) Kommentar [F100]: Eller elementer, hvis der er en ægte fleksibel rapportgenerator Kommentar [F101]: Lidt restancekrav der er flyttet fra andre afsnit som reelt ikke er funktionelle krav. Skal placeres andre steder Side 71 af 74

72 2A A Understøtte UNSPSC standarden (ligger det ikke i OIOformatet?) Kunden skal have adgang til en sandkasse/et testmiljø, der understøtter kundens muligheder for at supportere brugerinstitutionerne (MK) 2A Systemet skal understøtte single-sign-on, herunder SAML 2.0 standarden (PK) Kommentar [F102]: Vi havde noget møde om placering af indkøbsaftale-kobskategorier i nogle foreslåede elementer. Det arbejde skal understøttes af IFS. Kommentar [F103]: Jo det ligger i formatet, men der står umiddelbart blot at man anbefaler at bruge version , da det er den eneste som er oversat. Så hvis det stadig er korrekt, er det vel denne man SKAL bruge, skal dobbelttjekkes Kommentar [F104]: Mere om værktøjer og muligheder, herunder om det skal være globalt eller også lokalt Side 72 af 74

73 2A.5 Ikke-funktionelle krav Følgende kapitel indeholder de tekniske og ikke-funktionelle krav til IFS. Derved forstås f.eks. arkitekturprincipper, krav til integrationerne, brugervenlighed, tilgængelighed samt lovgivningsmæssige og politiske krav. Hvor funktionelle krav beskriver funktionalitet, som IFS skal stille til rådighed, beskriver ikke-funktionelle krav egenskaberne, hvormed IFS leverer funktionaliteten. Kommentar [F105]: Der skal ikke kommenteres på de ikkefunktionelle krav, afsnittet kan i sin nuværende form alene bruges til at formidle indledende tanker vedrørende struktureringen af de ikke funktionelle krav. Kommentar [F106]: Generelt indarbejder vi krav til brugervenlighed, i dokumentationskravene der afslutter, hver enkelt afsnit i den funktionelle kravspec., de brugervenlighedskrav der skal stå under de ikke-funktionelle krav er af mere teknisk karakter. 2A.5.1 2A.5.2 2A.5.3 2A.5.4 2A.5.5 2A A A A A A A.5.6 2A.5.7 2A.5.8 2A.5.9 2A.5.10 OIO standarder Arkitektur, Struktur og Platform Brugergrænseflade Log ind og adgangsforhold Integrationer NemHandel OIOSI/RASP Peppol Integration til Navision Stat Fra Navision Stat Til Navision Stat Yderligere specifikation af grænseflade til Navision Stat Integration til ØSLDV Leverandørers adgang til systemet Single-Sign-on og brugerstamdata Performance, servicemål og vedligeholdelse Sikkerhed Historik og logning Brugermanualer Myndighedskrav, relevante love mv. Kommentar [F107]: Herunder på mobile enheder som smartphones og tablets Kommentar [F108]: Herunder krav til understøttede browsere, singlesign-on, og brugerbestilling af nyt password Kommentar [F109]: Her tænkes på statens vareleverandører, fx deres mulighed for at se egne kataloger Kommentar [F110]: Hører muligvis mere til under Log in og adgangsforhold Side 73 af 74

74 2A A A Persondataloven Arkivloven Regnskabsbekendtgørelsen 2A.6 Afklaringsfase, Systembeskrivelse og tidsplan 2A.7 Compliance skema Side 74 af 74