Version A 2013-04-22

1. Utformningsprinciper Beställning till betalning i Winst Version A2013-04-22

2. Innehåll – Version A • Kontering i Winst 2.0 Bild 3 - 24 • Roller i Winst 2.0 Bild 25 - 32 • Attest och Delegering Bild 33 - 49 • Beställnings och fakturaflöde i Winst 2.0 Bild 50 - 71 • Tillgång att se fakturor och sekretesshantering Bild 72 - 80 NEKK BtB |Utformningsprinciper Version A

3. Kontering i Winst

4. Övergripande kodstruktur i Winst • Kodsträngen i Winst innehåller följande koddelar: • Kodstängen är gemensam för alla och alla koddelar visas även om förvaltningen inte använder vissa av dem. Konto och Ansvar är alltid obligatoriska. Motpart ingår ej. • Koddelsvärden (exkl ansvar) för respektive förvaltning läses över från Horisonten varje natt via integration mellan Horisonten och Winst. • För konto och verk kan förvaltningen genom underkoder i Horisonten styra vilka koddelsvärden som skall föras över till Winst. (Samma som för Gasell) • För övriga lokala koddelsvärden (exkl ansvar) förs alla giltiga värden över. (Särskilda regler vid månads/årsskiften – se vidare på bilder om bokföringsdatum.) • Koddelsvärden för ansvar förs över till Winst varje natt genom en integration mellan Winst och Nekksus, tillsammans med attestreglerna. • Period fr o m och Antal perioder används för periodisering, giltiga värden för dessa läggs upp direkt i Winst av central systemadministration. • För lokala koddelar visas koddelsvärdena utan prefix för alla koder förutom för ansvar. För ansvar ingår prefixet som en inledande del av koden. NEKK BtB |Utformningsprinciper Version A

5. Övergripande kodstruktur i Winst • Koddelsvärdena i Winst anges med beteckningarna F1-F7 och H1. F anger att det är en ”flat” struktur och H att det är en ”hierarkisk” struktur. • För varje organisation = förvaltning är F1-F7,H1 översatta till ”riktiga” koddelsnamn. Dessa är gemensamma för alla förvaltningar och motsvarar kodsträngen i GemHB förutom koddelen Motpart som ej visas utan alltid sätts vid inläsning i Horisonten. (Hämtas där från leverantörsuppgifter.) • I vissa fall, t ex vid sambandskontroller kommer begreppen F1-F7,H1 att visas istället för det riktiga namnet. • ”Obligatorisk” anger om koddelen är obligatorisk i samtliga konteringar. Dessa inställningar kan vara olika för förvaltningen men konto och ansvar skall vara obligatoriska för samtliga. NEKK BtB |Utformningsprinciper Version A

6. Övergripande struktur i Winst • Alla förvaltningar ligger i samma ”installation” av Winst 2,0. • Leverantörsregistret är gemensamt för alla förvaltningar (precis som i Horisonten). Eventuella regler kopplade till en leverantör kommer därför att beröra alla förvaltningar. • Varje förvaltning (prefix) är en egen ”Organisation” i Winst. • Varje lokal användare är kopplad till en organisation och kommer bara att se denna medan centrala systemadministratör kommer att se alla organisationer och även de bolag som använder Winst. • Koddelslistorna för de olika koddelarna är unika per organisation, dvs varje förvaltning äger sin egen kontoplan, aktivitetslista etc. och användaren kommer bara att se dessa värden vid kontering. • När en beställning skickas till leverantör blir den en order. Ordrar numreras löpande med en gemensam nummerserie för hela installationen. Ordernummer inleds med AA och därefter ett löpnummer på 7 siffror. NEKK BtB |Utformningsprinciper Version A

7. Kontering och verifikationsnummer • Ankomstkontering • Sker när en faktura har passerat ankomsthanteringen, (när fakturan har passerat status ”Leverantör ej angiven” och ”Fakturainformation måste kontrolleras”). Fakturan åsätts ett verifikationsnummer (en serie per organisation) som är ett löpnummer som inleds med respektive förvaltnings prefix. • Kontering sker av moms (1677), levskuld (2511) och okonterat (1621) • Vid inläsning i Horisonten sker komplettering med motpart utifrån leverantör. NEKK BtB |Utformningsprinciper Version A

8. Kontering och verifikationsnummer • Slutkontering • Slutkontering sker när en faktura blir ”Klar”, (efter beslutsattest). • Verifikationsnummer vid slutkontering blir samma som vid ankomstkontering. • Vid slutkontering bokas beloppet på 1621 bort och ersätts med korrekt kontering från fakturan. • Vid inläsning i Horisonten sker komplettering med motpart utifrån leverantör. • I textfält i Horisonten anges samma text som idag. • En eventuell förändring av förfallodag som gjorts i Winst går över till Horisonten i samband med slutkontering. • Information om att en faktura är makulerad skickas till Horisonten tillsammans med slutkonteringarna. • En faktura får aldrig byta leverantör eller organisation när den är inläst första gången. Makulering och ny inläsning i korrekt förvaltning och på korrekt leverantör skall alltid ske. Se vidare i rutinbeskrivning. NEKK BtB |Utformningsprinciper Version A

9. Hantering av moms • Kontering av moms • Fakturans moms syns som en konteringsrad på fakturan, konto 1677. Raden är låst och kan inte ändras. Konteringen innehåller endast konto – inga andra koddelar kan förekomma. • Om momsbeloppet skall ändras – för att t ex endast halva momsen är avdragsgill skall användaren som konterar lägga in en minusrad på konto 1677 på den belopp som momsen skall minskas med. • När en manuell kontering av moms gjorts (bokning på 1677) kommer fakturan att skickas till administratör för kontroll innan den blir Klar för slutbokning och betalning. • En beställning som avser kostnader där momsen inte är fullt avdragsgill skall aldrig leveranskvitteras innan fakturan ankommer. Leveranskvittensen måste också göras så att ordermatchning inte uppstår för att momsen skall kunna omkonteras. NEKK BtB |Utformningsprinciper Version A

10. Hantering av moms • Kontroll vid inläsning • Till varje leverantör kan en högsta och lägsta moms-% anges. En faktura som avviker mot denna kommer då att stoppas i ankomsthanteringen för kontroll. Dessa gränsbelopp är gemensamma per leverantör för hela installationen. Vid start har samtliga leverantörer gränserna lägst = 0% och högst = 26% angivna. • Avvikande gränser kan läggas in för specifika leverantörer om det är möjligt att identifiera regler som gäller för samtliga förvaltningar.. • En faktura med 100% moms kommer att stanna vid inläsningen för kontroll, den skickas därefter till granskning hos den som är referens på fakturan och är därefter klar – ingen attest krävs på moms. • Det är också möjligt att för en leverantör ange att endast en viss andel av momsbeloppet skall läggas ut som moms, dvs om det finns en leverantör vars moms alltid är avdragsgill till 50% skulle detta kunna läggas som en regel vid inläsningen. Gemensamma regler måste dock gälla för samtliga förvaltningar. NEKK BtB |Utformningsprinciper Version A

11. Kommentarer till beställning och faktura • I beställningar kan interna kommentarer göras i ett fält för beskrivning av beställningens syfte. Det går dock inte att bifoga en fil till en beställning. • På ordern – när den visas under leveranskvittens – går det att lägga till en kommentar. Denna kommentar kommer att vid fakturahanteringen. • På en faktura kan kommentarer lämnas - tryck på knappen ”Kommentar” och en kommentarsruta öppnas. I kommentarsfältet till en faktura kan också en fil bifogas. • En kommentar som är gjord kan inte tas bort – kommer att synas genom hela fakturaflödet. (En fil kan tas bort). • Kommentaren skall användas för information till konteringen och fakturan men också som en flödeskommentar för att skicka meddelanden/frågor mellan personerna som hanterar en faktura. När en faktura skickas till annan person utanför det egentliga flödet eller bakåt i flödet är det obligatoriskt att skriva en kommentar. Systemet kräver det inte när man skickar till annan granskare eller returnerar till annan granskare. NEKK BtB |Utformningsprinciper Version A

12. Kommentar till vissa konton • För vissa konton och vissa typer av kostnader är det obligatoriskt att bifoga uppgift om syfte, deltagare etc. Den kommentar som görs på en beställning följer inte med till fakturan och det är inte heller möjligt att bifoga en fil till en beställning som blir synlig tillsammans med fakturan. • Detta innebär att beställningar som görs för den typ av kostnader som skall konteras på dessa konton (representation, etc) aldrig skall leveranskvitteras innan fakturan kommer så att automatisk ordermatchning undviks. I samband med att fakturan då hanteras kan kommentar och/eller fil bifogas till fakturan. Det är också möjligt för betsällarenatt efter att orderna har skickats till leverantör (efter attest), gå in och göra en kommentar på ordern (under leveranskvittens). Denna kommentar kan då fungera som påminnelse när fakturan skall hanteras. • För de konton som kräver kommentar kommer en påminnelse att visas för användaren om att kommentar måste lämnas när han/hon använder kontot vid kontering av en beställning eller faktura. • Det finns ingen möjlighet att ange en radtext vid konteringen. NEKK BtB |Utformningsprinciper Version A

13. ARBETSMATERIAL Principer för bokföringsdatum i Winst • Huvudregel • Fakturor ankomstbokförs när formaliakontroll av fakturan har gjorts. • Fakturor slutbokförs när fakturan är ordermatchad/attesterad (klarmarkerad) och konteringskontroll har gjorts i Winst. • I normalfallet blir fakturadatum på fakturan bokföringsdatum både för ankomstbokföring och för slutbokföring, gäller både för e-fakturor och scannade fakturor. (Undantag kan uppstå vid månadsskiften för fakturor som ankommer eller slutkonteras efter att Winst stängts). NEKK BtB |Utformningsprinciper Version A

14. Principer för bokföringsdatum i Winst, forts • .Vid månads/årsbokslut blir hanteringen enligt följande: • Ankomstbokföring av fakturor i Winst utgår från fakturadatum och kopplas till kalendermånad. Detta innebär att fakturor med fakturadatum i gammal månad i normalfallet ankomstbokförs i gammal månad medan fakturor med fakturadatum i ny månad alltid ankomstbokförs i den nya månaden. En faktura som har fakturadatum i ny månad kommer alltså alltid att slutbokföras i ny månad – om kostnaden avser tidigare månad, måste en upplupet-bokning göras. • I Winst finns en stängningstabell där man för varje månad definierar vilken dag Winst stänger. Datumet anger: • vilken som är sista dag för ankomstbokföring i gammal månad för faktura med fakturadatum i gammal månad • vilken som är den sista dag som en faktura, som har ett fakturadatum före månadsskiftet, måste ordermatchas/attesteras för att slutkonteringen skall komma med i bokföringen i den gamla månaden. • Stängningstabellen är gemensam för samtliga förvaltningar och datum för respektive månad bestäms centralt. I följande exempel är antagandet att stängning sker den 3:dje. (Horisonten kan vara öppen längre än detta datum). De stängningsdatum per månad som kommer att gälla för respektive år anges av koncernredovisning i ekonomihandboken. NEKK BtB |Utformningsprinciper Version A

15. Principer för bokföringsdatum i Winst, forts • Vid månads/årsbokslut blir hanteringen enligt följande, forts: • Leverantörsfakturor som har ett fakturadatum i den gamla månaden kommer att ankomstbokföras på den gamla månaden fram till dess Winst stänger, därefter kommer ankomstbokföring att ske i maj trots att fakturan har ett fakturadatum i april. • Fakturor som ankomstbokförts i gammal månad och som slutkonteras innan Winst stänger kommer att slutbokföras på gammal månad. En faktura med fakturadatum i april som attesteras senast 3:e maj kommer att bokföras i april. Sker attestering den 4:e eller senare kommer denna istället att bokföras i maj. • Sker ankomst- eller slutkontering av en faktura med fakturadatum i gammal period efter att Winst har stängts blir bokföringsdatum alltid den första dagen, som Winst öppnar i ny månad, dvs. dag 4. De datum som Winst är öppen i ny månad kommer alltså aldrig att användas som bokföringsdatum. • Bokföringsdatum på fakturan i Winst(syns i fliken fakturahuvud) sätts till fakturadatum när fakturas läses in. När sista attestant accepterar fakturan (när den blir klarmarkerad), uppdateras datumet utifrån stängningstabell enligt reglerna ovan. • Detta innebär också att konteringskoder som stängs vid ett månads/årsskifte måste skickas till Winst även under de dagar i ny månad som bokföring kan ske på gammal månad. Detta kan i sin tur innebära att användaren konterar på dessa koder på en faktura som avser ny månad. En sådan faktura kommer då att felfällas vid inläsningen i Horisonten och måste rättas där. NEKK BtB |Utformningsprinciper Version A

16. Principer för bokföringsdatum i Winst, forts • Överföring till Horisonten: • Överföring till Horisonten av ankomst och slutkonterade fakturor kommer att ske en gång varje natt. Detta gäller även för de dagar i ny månad som det är möjligt att bokföra på den gamla månaden. Dvs om en faktura attesteras under dessa dagar kommer kostnaden inte att finnas bokförd i huvudboken förrän nästkommande dag. • Fakturor kommer att läsas in till Winst varje natt och 2 ggr under dagen. • Förfallodatum • Förfallodatum kommer att sättas enligt följande: • Scannande fakturor – Fakturans ankomstdatum + 30 dgr blir förfallodatum – sätts vid scanningen. • E-fakturor – Det förfallodatum som angetts av leverantören blir förfallodatum blir förfallodatum • Utbetalningsuppdrag (PC-lev, Bida, ProCapita) – Förfallodag = angiven utbetalningsdag från försystemet. NEKK BtB |Utformningsprinciper Version A

17. Skillnad mot idag • Förvaltningen kan inte styra bokföringsdatum • I Gasell finns möjlighet att välja bokföringsdatum i samband med utanordningen – I Winst styrs detta av fakturadatum och stängningstabell. Detta innebär att förvaltningen inte kan styra bokföringsdatum på en faktura även om Huvudboken i Horisonten är öppen. • Bokföringsdatum för ankomstbokföring är fakturadatum • I Gasell styrs bokföringsdatum för ankomstbokföring av fakturans registreringsdatum, förutom de tre första arbetsdagarna i ny månad då fakturan tillbakadateras till gammal månad. I Winst styrs detta av fakturadatum och det gemensamma regelverket för stängning. • Samma tidplan för alla • I Gasell kan förvaltningen ha avvikande tidplan för stängning. I Winst gäller samma stängningstabell för samtliga förvaltningar. NEKK BtB |Utformningsprinciper Version A

18. Exempel bokföringsdatum Viktigaste skillnad mot idag Bokföringsdatum för ankomst och slutbokföring är samma om inte Winst är stängd. Förfallodatum för scannade fakturor kommer att räknas fram utifrån ankomstdatum. NEKK BtB |Utformningsprinciper Version A

19. Periodisering i Winst • Periodisering beskrivs i Winst genom koddelarna ”Startperiod” och ”Antal månader”. Startperioden anges som 00 =Start i innevarande månad, 01=Start nästa månad, 02=Start om två månader. Antal anges som antal 1-12. Periodisering kan maximalt göras över 12 månader. • Översättning till Fper kommer att ske i Winst innan överföring till Horisonten. Denna teknik innebär att det inte går att styra flera andelar till samma månad (ange att en månad skall ta en större del av kostnader) för samma konteringsrad. I så fall måste konteringen delas upp på flera rader. • Vid översättningen tar Winst hänsyn till bokföringsdatum enligt reglerna i stängningstabellen vilket innebär att en faktura aldrig kan få en ogiltig startperiod. (Varken i konteringskontrollen i Winst eller på vänteregistret.). Detta innebär att utfallet av periodiseringen är beroende av bokföringsdatumet och alltså inte alltid blir som man har tänkt. • I samband med varje stängningsdatum kan lokal systemadministratör ta ut rapporten ”Fakturatransaktioner totalt” där ej klarmarkerade fakturor vid stängning kan sökas ut och åtgärdas i de fall de har felaktig periodisering. • Sambandskontroller kan skapas mellan Konto och Startperiod så att vissa konton alltid kräver att periodisering sker när kontot används. Denna kontroll kommer att gälla både beställning och faktura. Respektive förvaltning avgör om detta behov finns. NEKK BtB |Utformningsprinciper Version A

20. Periodisering i Winst • En gemensam sambandskontroll läggs in som förbjuder startmånad 00 i kombination med Antal perioder = 1. . Det är inte heller tillåtet att använda periodisering på en faktura som konteras på ett I-projekt. • Om en faktura inte kunnat ordermatchas kan beställaren (i sin roll som fakturagranskare) komplettera konteringen (från beställningen) med korrekt periodisering. För en vild faktura görs kontering på from/tom av fakturagranskaren. Attestanten skall i normalfallet inte ändra ”startperiod” när han/hon gör beslutsattest(men har möjlighet att göra detta). • Det finns också utrymme för startperiod och antal perioder i konteringen för beställning. Periodisering bör endast fyllas i för en beställning när beställaren är säker på att fakturan kommer att anlända så att startperioden inte blir i en kommande månad om leverantören inte fakturerar i tid. Attestanten kan ändra/lägga till periodisering om beställaren inte gjort detta. (Rutinen bör dock vara att skicka tillbaka för felrättning). NEKK BtB |Utformningsprinciper Version A

21. Teknik för periodisering i Winst NEKK BtB |Utformningsprinciper Version A

22. Vilken information kan säkerställa rätt periodisering • I samband med stängning av Winst (och tidigare) bör ett antal utdatarapporter tas ut som stöd för att avgöra om bokslutet har belastats med rätt kostnader. • Beställning/order som är leveranskvitterade men ej matchade mot faktura. • Ankomstbokförda ( i gammal månad) men ej slutkonterade fakturor. – Påminnelse/uppbokning av kostnader. • I Winst finns rapporter för att söka ut alla fakturor och alla ordrar per förvaltning. Denna information kan tas över i excel och användaren kan sedan selektera utifrån sina behov. • Beställning/order som ej är leveranskvitterad – Kommer inte att vara så användbar eftersom den kommer att visa alla ej leveranskvitterade beställningar/order – inte bara de som är aktuella för bokslutet. • Rensningsrutin för beställningar/ordrar som ej leveranskvitterats – där fakturan har hanterats i manuellt flöde måste tas fram. • Dessutom måste kontroller/uppföljning göras i Horisonten/Nekksus, bl a kontoanalys för att hitta kostnader som avser framtida perioder. NEKK BtB |Utformningsprinciper Version A

23. Hur säkerställa krav på korrekt kontering? • Beställaren - Kontrollattestant • Tryck ”fakturera ej” vid leveranskvittens, vilket gör att faktura går manuellt flöde istället för att ordermatchas. • Om leveranskvittens inte gjorts eller om ordermatchning ej är OK kommer fakturan tillbaka till beställaren som då 1. kan skicka fakturan för extrakontroll till någon som kan hjälpa till med kontering eller 2. överlåta kontrollattesten till någon annan • Fakturagranskare - faktura utan order • - Kontrollattestant • Favoriter – varje användare kan ange de koddelsvärden som skall vara favoriter. Dessa läggs högst upp i listan. • Senast använda kod - de senast använda koderna syns tillsammans med favoriter överst i listan för respektive koddel • Förval – varje användare kan lägga upp en förvalt värde för respektive koddel som läggs ut i konteringen som förslag. • Sambandskontroller – endast giltiga kombinationer, kodkomplettering etc. (Definieras av respektive förvaltning) • Urval - endast de konton och verk som förvaltningen vill visa i Winst är synliga. • Påminnelse om att fylla i kommentar för vissa konton - säkerställer korrekt hantering av uppgifter kring representation etc. • Skicka fakturan på extrakontroll hos någon annan för att fråga om kontering • Överlåta kontrollattesten på någon annan granskare som gör konteringen. • Fakturan går till automatisk konteringskontroll efter beslutsattest om momskonteringen ändrats. • Beslutsattestant • Beställaren/granskaren har haft konteringshjälp när de konterat beställningen/fakturan. • Skicka fakturan till annan person för extrakontroll - vid osäkerhet. • En attestant kan ändra en kontering (inkl. periodisering) som beställare eller fakturagranskare har gjort i samband med attesten. Bör dock som huvudregel skicka tillbaka fakturan. • Kopia av tidigare order kan användas för de vanligaste inköpen som innehåller korrekt kontering. • Mappning mellan konto och artikel (UNSPSC-koppling) • Favoriter – varje användare kan ange de koddelsvärden som skall vara favoriter. Dessa läggs högst upp i listan. • Senast använda kod - de senast använda koderna syns tillsammans med favoriter överst i listan för respektive koddel • Förval – varje användare kan lägga upp en förvalt värde för respektive koddel som läggs ut i konteringen som förslag. • Sambandskontroller – endast giltiga kombinationer, kodkomplettering etc. (Definieras av respektive förvaltning) • Urval - endast de konton och verk som förvaltningen vill visa i Winst är synliga. • Påminnelse om att fylla i kommentar för vissa konton. (önskemål) Beställning Faktura Alla involverade måste ha god förståelse för kontering/periodisering! Inte bara ekonomiavdelningen. NEKK BtB |Utformningsprinciper Version A

24. Hur fungerar sambandskontrollerna? • Sambandskontroller i Winst: • Unika per förvaltning • Alltid mellan två dimensioner • Kan ej utgå från ”underkoder” i HorisontenTre regler • Förbjuder – spärrar ogiltig kombination • Kräver – om ”ett till ett” värde ger denna regel en automatkontering, t ex ansvar ger verk. • Begränsar – ”får bara kombineras med” • * - anger obligatorisk koddel • Motpart ej med i kodsträng i Winst • Konto och ansvar alltid obligatoriska – utan sambandskontroll • Centrala sambandskontroller gör verk obligatorisk för konto 3-8 NEKK BtB |Utformningsprinciper Version A

25. Roller i Winst 2.0

26. ”Vanliga användare” på förvaltningen Beställning eller faktura med avvikelse mot order Faktura utan order eller abonnemang med avvikelse Beställare Fakturagranskare • Skapar och konterar beställning • Leveranskvitterar* • Granskar och hanterar faktura vid avvikelse mellan order och faktura • Vissa utsedda beställare kan genomföra förnyad konkurrensutsättning • Granskar, konterar och hanterar en faktura, som ej föregås av en beställning/order (vild faktura) • Granskar och hanterar faktura vid avvikelse mellan abonnemang och faktura Attestant • Attesterar beställning • Attesterar faktura utan order • Attesterar faktura vid avvikelse mot order/abonnemang. • Attesterar abonnemang (ej i Winst) • Den som har gjort beställningen får hantera fakturan vid avvikelse • Beställare är också fakturagranskare • Kan se sina beställningar/ordrar och tillhörande fakturor** • Styrs utifrån ansvaret enligt attest- och organisationsträd i Nekksus • Om kontering sker på flera ansvar så sker attest i sekvens • Kan se sina attesterade fakturor** • Faktura utan order styrs med mottagarkod • Fakturagranskaren kan skicka faktura vidare till annan användare för kontroll innan godkännandeeller överlåta rätten att godkänna. • Kan se sinafakturor** * En normal beställare leveranskvitterar sina ordrar. Extra leveranskvitterare kan utses som kan leveranskvittera andras ordrar. ** En användare ser alltid de ordrar/fakturor som man skall/har hanterat. Det finns också möjlighet att ge användaren tillgång till samtliga förvaltningens fakturor. NEKK BtB |Utformningsprinciper Version A

27. Lokal fakturaadministratör Lokal fakturaadministratör – A41(alla /merparten på ekonomiavdelningen) • Fakturahantering i Winst • Hanterar/rättar fakturor som stannat i formaliakontroll vid inläsning (Fakturainformation måste kontrolleras) • Distribuerar fakturor utan giltig referens/mottagarkod (Granskare ej angiven) • Makulerar, ändrar förfallodag, ändrar flöde på fakturor på uppdrag av granskare eller attestant. • Kontrollerar alla fakturor där moms har justerats vid konteringen, (Kontering ej kontrollerad). • Påminner och följer upp förvaltningens fakturor/ordrar • Kan se förvaltningens alla fakturor, alla ordrar och beställningar som skickats till attest • Kunna se sekretessfakturor – (kan anges per person inom gruppen.) • Kunna hantera andras fakturor –(ej attest)* och ordrar (leveranskvittens) • Övriga uppgifter – utanför Winst • Utbildning och användarsupport • Upplägg av utbetalningsmottagare i PC-lev *Skall ha delegation att hantera andras fakturor. NEKK BtB |Utformningsprinciper Version A

28. Lokal systemadministratör Lokal systemadministratör A-43 Fåtal personer per förvaltning (ekonomiavdelning/upphandlingsavdelning) • Fakturahantering i Winst • Hanterar/rättar fakturor som stannat i formaliakontroll vid inläsning (Fakturainformation måste kontrolleras) • Distribuerar fakturor utan giltig referens/mottagarkod (Granskare ej angiven) • Makulerar och ändrar förfallodag på fakturor på uppdrag av granskare eller attestant. • Kontollerar fakturor där moms har justerats vid konteringen – (Kontering ej kontrollerad) • Påminner och följer upp förvaltningens fakturor/ordrar • Kan se förvaltningens alla fakturor, alla ordrar och alla beställningar som skickats till attest. • Kunna se sekretessfakturor – (kan anges per person inom gruppen.) • Kunna hantera andras fakturor och ordrar (leveranskvittens). • Administration i Winst • Användaradministration, nyupplägg och underhåll** • Administration av mottagarkoder • Lägger upp lokala avtal, kataloger och forumlär • Lägger upp och underhåller abonnemang • Registrerar delegeringar • Skapar rapporter i rapportgenerator? • Övriga uppgifter – utanför Winst • Utbildning och användarsupport • Anmäler ärenden till central systemförvaltning • Underhåller attestträdet i Nekksus – separat behörighet i Nekksus *Skall ha delegation att hantera andras fakturor **En högre behörighet kan aldrig ges till en användare än den som man själv har. NEKK BtB |Utformningsprinciper Version A

29. Central fakturaadministratör Central fakturaadministratör (Levgruppen) • Fakturahantering i Winst • Hanterar fakturor som inte kan kopplas till en leverantör (Leverantör ej vald) • Kan se hela stadens fakturor. • Skapar rapporter i rapportgenerator. • Övriga uppgifter • Upplägg av nya leverantörer/betalningsmottagare i Horisonten/Scannit NEKK BtB |Utformningsprinciper Version A

30. Central systemadministratör Central systemadministratör - Systemadministration • För samtliga • Underhåller stängningstabell • Administration av gruppstruktur och roller enligt gemensamma principer • Underhåller grunddata för organisation (samtliga) enligt gemensamma principer • Lägger upp centrala och lokala sambandskontroller • Administrera fakturaleverantörsregister enligt gemensamma principer* • Underhåller grunddata för ordermatchning • Registrerar och tilldelar nya adresser. • Uppdaterar systemmeddelanden, genvägar och välkomsttext • Administrerar avvikande mappning av UNSPSC och konto • Kan göra men skall normalt utföras av respektive förvaltning • Användaradministration, nyupplägg och underhåll • Administration av mottagarkoder • Lägger upp lokala avtal, kataloger och formulär • Lägger upp och underhåller abonnemang Kan registrera delegeringar – görs normalt av förvaltningens administratör * T ex sekretessmarkering på uppdrag av XX NEKK BtB |Utformningsprinciper Version A

31. Central systemadministratör, forts Central systemadministratör -, forts • Fakturahantering i Winst(Behörighet men skall inte löpande göras.) • Kunna se och hantera alla andras fakturor* • Övriga uppgifter • Felsökning/Felhantering av integrationer • Felsökning av kommunikation med leverantör (EDI) • Support till lokala systemförvaltare Skall ha delegation att hantera andras fakturor. NEKK BtB |Utformningsprinciper Version A

32. Generell gruppstruktur i Winst 2.0 CSFadmingroup Gruppindelning skall ej användas för att kontrollera användarnas organisationstillhörighet. Istället skall fältet ”Tillhör H1” på användarkortet användas 40 tecken. OBS – Använd ej kod som står för ansvar eller organisationsnivå då detta kommer att ge denna kod som förval för användaren. Central systemadministratör LEVGRUPP Central fakturaadministratör FÖRVALTNING Lokala systemadministratörer Lokala fakturaadministratörer Standard • Vanliga användare • Beställare • Attestanter • Fakturagranskare Begränsad • Tittare • Controllers • Revisorer • etc NEKK BtB |Utformningsprinciper Version A

33. Attest och delegering i Winst

34. Nytt regelverk för attest Begrepp i förslag till nytt regelverk: • Kontrollattest • Beslutsattest • Betalningsattest (tidigare benämnt utanordning) Ur Winst´s perspektiv innebär detta: • Kontrollattest – görs av den som gör beställning, leveranskvitterar eller granskar faktura. Kan ske vid olika tillfällen – både före och efter beslutsattest. • Beslutsattest – görs av den som attesterar beställning/faktura • Betalningsattest – görs av den som verkställer betalningen (görs i Horisonten av Intraservice). Ersätter utanordning och är begränsad till attest kring betalningen, ej till kontering/förenligt med verksamheten eller liknande. • Både kontrollattest (”skicka beställning”, ”leveranskvittens OK” och ”acceptera faktura”) och beslutsattest (”godkänna beställning” och ”acceptera faktura”) är aktiva funktioner i flödet (knapptryckningar) kopplade till en viss person. Dessutom kommer ett antal kontrollmoment både avseende kontrollattest och beslutsattest att vara inbyggda i systemet och granskare/attestant kan begära hjälp av annan person för att kunna utföra sitt uppdrag. NEKK BtB |Utformningsprinciper Version A

35. Tre olika attester i nya regler • Kontrollattest • varan är mottagen eller att tjänsten är utförd enligt den beställning som gjorts • fullständiga uppgifter har lämnats på fakturan/underlaget till exempel avseende adress (fakturaadress och leveransadress), pris, volym, tidpunkt för leverans eller utförd tjänst, betalningsvillkor, rabatter med mera • utgiften inte tidigare har belastat verksamheten • fakturan/motsvarande är rätt beräknad • händelsen är rätt konterad • uppgifterna på fakturan eller motsvarande underlag överensstämmer med beställningen, avtal eller annan överenskommelse avseende pris, volym, kvantitet och kvalitet • lagstadgad formalia är korrekt, exempelvis avseende F-skattsedel och VAT-nummer. • Beslutsattest • händelsen stämmer överens med verksamhetens uppdrag • personen som har beställt varan eller tjänsten är behörig och har hållit sig inom ramen för sin behörighet • underlagen till händelsen är kompletta, exempelvis dokumentation vid direktupphandling • händelsen är rätt konterad • händelsen belastar rätt redovisningsperiod • fakturan/motsvarande är granskad och kontrollattesterad. • Betalningsattest • behörig person har beslutsattesterat händelsen • rätt betalningsmottagare angivits • fatta beslut om utbetalning. NEKK BtB |Utformningsprinciper Version A

36. Betalningshantering (Intraservice, Horisonten) Attester i BtB-flödet – beställning/faktura Formaliakontroll Alt 1 – Attest av beställning med matchning mot faktura Förvaltning (WINST) Faktura ankomst Beställare Skapa Beställning Elektronisk rekvisition Kontering (Skicka) Kontrollattest Vara/tjänst levereras Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Betalnings Godkännande Betalningsattest Automatisk Matchning OK Auto slutkontroll Momskontroll Giltiga koder Sambandskontroller Styrs av ”Ansvar” i kontering Beställare och beslutsattestant alltid olika personer Formaliakontroll Alt 2 – Automatisk ordermatch ej OK Styrs av ansvar i kontering Beställare Avvikelsehantering Granskning av faktura (Acceptera) Kontrollattest Faktura ankommer Beställare Skapa Beställning Elektronisk rekvisition Kontering (Skicka) Kontrollattest Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Betalnings- Godkännande Betalningsattest Attest av Faktura (Acceptera) Beslutsattest Automatisk Matchning/ Slutkontroll Ej OK Vara/tjänst levereras Auto slut kontroll Fakturan går till beställare. Styrs av ”Ansvar ” kontering Formaliakontroll Fakturagranskare Granskning/ Kontering av faktura (Acceptera) Kontrollattest Attest av Faktura (Acceptera) Beslutsattest Faktura ankommer Betalnings- Godkännande Betalningsattest Alt 3 – Faktura utan order - ”Vild” faktura Auto slut kontroll Styrs av ”Ansvar ”i kontering Styrs av beställarreferens Granskare och beslutsattestant alltid olika personer NEKK BtB |Utformningsprinciper Version A

37. Betalningshantering (Intraservice, Horisonten) Attester i BtB-flödet Abonnemang Förvaltning (Winst) Betalnings Godkännande Betalningsattest Registrera abonnemang Används ej innan attest på abonnemang är elektronisk Faktura ankommer Automatisk Matchning Auto slutkontroll Alt 1 Beslutsattest Styrs av regler i abonnemang Styrs av ansvar i kontering. Granskning av faktura Kontrollattest Attest av Faktura Beslutsattest Betalnings Godkännande Betalningsattest Registrera abonnemang Faktura ankommer Ej Automatisk Matchning Auto slutkontroll Beslutsattest Alt 2 Samma hantering som för avvikelsehantering vid ordermatchning (Alt 2) Varianter på ovanstående – Abonnemanget till för att ge förslagskontering Styrs av regler i abonnemang Styrs av ansvar i kontering. Granskning av faktura Kontrollattest Attest av Faktura Beslutsattest Betalnings Godkännande Betalningsattest Registrera abonnemang Faktura ankommer Automatisk Matchning Auto slutkontroll Beslutsattest Inställningar kan göras så att fakturan går till kontrollattest och/eller beslutsattest även om matchning är ok. NEKK BtB |Utformningsprinciper Version A

38. Betalningshantering (Intraservice, Horisonten) Attester i BtB-flödet-Utbetalningsunderlag Försystem och applikationer Förvaltning (WINST) Attest kon- trolleras mot Gasells attestregister 80% Registrering/ Kontering Beslutsattest av Utbetalnings underlag PC-lev Styrs av Gasells attestregler Automatisk Matchning OK Betalningshantering (Horisonten) Betalnings Godkännande Betalningsattest Auto slut kontroll Om attest är gjord Attesterat underlag Beslutsattest Överföring till WINST som 1.Konterad order 2.Faktura Attest Bida Beslutsattest Registrering/ kontering av Utbetalnings underlag BIDA (IoFF) Om attest inte är gjord Automatisk Matchning OK Attest Beslutsattest Styrs av ansvar i kontering Registrering av Utbetalnings underlag Procapita Förvaltningen gör valet om attest görs i Pc-lev som tidigare eller om man vill gå över till attest i Winst. De utbetalningsorder som inte är attesterade i PC-lev kommer att gå ut för attest i Winst. NEKK BtB |Utformningsprinciper Version A

39. Beslutsattest i Winst - Utformning - sammanfattning Beslutsattesträtt per ansvar och i enlighet med organisationsträd • ”Ansvar” i konteringen styr till beslutsattestant – innebär att ”Ansvar” blir en obligatorisk koddel för samtliga konteringar i Winst (även balanskonton). (Gäller ej momskonto) • Organisationsträdet i Nekksus styr attestflödet automatiskt och ansvar/organisationsträd och attesträtt hämtas från Nekksus varje natt. • Eskaleringanvänds för eskalering till beloppsgräns, för att hitta avvikande beslutsattestant (tvåhandsprincip) eller som påminnelse när ordinarie attestant ej attesterat inom givna tidsintervall • Beloppsgränser (begränsade eller obegränsade) skall definieras per attestant – avgörs av respektive förvaltning. • Attest av belopp som överstiger attestantens beloppsgräns går vidare till attestant med rätt belopp, men attest måste göras på varje nivå på vägen dit. • En beställning/faktura som avser flera attestanter går till dessa i beloppsordning (störst belopp går först) – ej parallellt. • Parallell attesträtt löses genom delegering (stående eller tillfällig). Delegering måste vara godkänd och kan endast registreras i Winst av lokala systemförvaltare. • En inmatning skapas i Nekksus där utsedda personer inom respektive förvaltning uppdaterar attestant per ansvar och nivåbegrepp, from/tomdatum och beloppsgränser. • Utbetalningsunderlag som attesteras i PC-lev följer attestregler i Gasell. (Dessa måste alltså finnas kvar så länge PC-lev används). NEKK BtB |Utformningsprinciper Version A

40. Attest – ansvar/nivå Möjlighet finns att delegera attesträtt enligt särskild rutin.Detta sker inte per ansvar utan från person till person. Förvaltning = Nivå 0 Namn på nivå:134 Beskrivning: Centrum Aktiv godkännare: Axel Axelsson Högsta kostnadsgräns: obegränsat Sektor = Nivå 1 Namn på nivå:1341 Beskrivning: Utbildning Aktiv godkännare: John Johansson Högsta kostnadsgräns: 1 000 000 Ansvar Namn på konteringsvärde:1341211 Beskrivning: Hallandsgatans förskola Aktiv godkännare: Anna Andersson Högsta kostnadsgräns: 80 000 Område = Nivå 2 Namn på nivå:13410 Beskrivning: Johanneberg/Burås Aktiv godkännare: Jan Jansson Högsta kostnadsgräns: 500 000 Enhet = nivå 3 Namn på nivå:134100 Beskrivning: Johanneberg 1 Aktiv godkännare: Anna Andersson Högsta kostnadsgräns: 80 000 Ansvar Namn på konteringsvärde:1341212 Beskrivning: Skånegatans förskola Aktiv godkännare: Bertil Bertilsson Högsta kostnadsgräns: 40 000 Ansvar Namn på konteringsvärde:1341222 Beskrivning: Rudedamsgatans förskola Aktiv godkännare: Karl Karlsson Högsta kostnadsgräns: 80 000 Enhet = nivå 3 Namn på nivå:134101 Beskrivning: Johanneberg 2 Aktiv godkännare: Per Persson Högsta kostnadsgräns: 200 000 NEKK BtB |Utformningsprinciper Version A

41. Beslutsattesträtt per ansvar • Det finns olika sätt att bygga beslutsatteststrukturer i Winst. Den modell som valts innebär att beslutsattest och attestordning skall vara uppbyggd kring organisationsträdet. Organisationsstrukturen för attest kommer därmed att överensstämma med organisationsträdet som används för uppföljning av verksamheten. Det kan vara så att nya ansvar måste skapas för att kunna hantera beslutsattest. Viktigt tänka på konsekvenser för Nekksusdär flera ansvar kräver budget/prognos. • Det innebär att det till varje ansvar och till varje nivå i organisationsträdet skall anges en beslutsattestant. Samma person kan finnas både på ansvarsnivå och på överliggande nivå. • För varje attestant skall också anges ett maxbelopp, som är den gräns per beställning/faktura som personen har rätt att attestera. Detta kan vara ett angivet belopp eller ett värde som anger obegränsad attesträtt. Det är totalbeloppet per ansvar och beställning/faktura som testas mot attesträtt. • I Winst finns ingen from/tomdatum för attesträtt utan regelverket i Winst speglar alltid det för dagen (kalenderdagen) gällande. Hantering av tom och fromdatum måste därför ske i Nekksus. I Nekksus kommer alla nyupplägg och förändringar av attesträtt att loggas och vara möjlig att ta ut i rapporter. • ”Ansvar” i konteringen styr beställningen/fakturan till rätt attestant. Om en beställning/faktura avser flera olika ”ansvar” skickas fakturan till de olika ansvaren i beloppsordning. NEKK BtB |Utformningsprinciper Version A

42. Beslutsattesträtt per ansvar, forts • Om ett ansvar byter attestant vid ett månadsskifte kommer den nya attestanten att anges som attestant redan från första dagen i månaden. Det innebär att även de fakturor som ännu inte skickats till den gamla attestanten och som avser den gamla månaden skall attesteras av den nya attestanten. • Vem som skall attestera en faktura avgörs av Winst när fakturan skickas från godkännaren till attestanten. (När beställaren skickar beställningen eller när fakturagranskaren ”accepterar fakturan”.) Även om attestanten ändras efter detta kommer den som stod angiven som attestant när fakturan skickades att vara den som kan attestera beställningen/fakturan. En utveckling är beställd av Winst som innebär att fakturor som ligger hos en attestant med status ”att attestera” skall flyttas till ny attestant om attestanten för ansvaret ändras. I avvaktan på att denna genomförs måste rutin finnas där lokal systemadministratör skickar tillbaka fakturor som finns hos denna attestant till granskare för att de istället skall kunna hanteras av den nya attestanten. • Eftersom attestreglerna är kopplade till organisationshierarkin innebär detta att alla ändringar av ansvar/attestanter bör planeras och göras med försiktighet och eftertanke. NEKK BtB |Utformningsprinciper Version A

43. Eskalering • Organisationsträdet/attesthierarkin har flera funktioner • Hierarki på beloppsgränser: Om en attestant på ett ansvar har en begränsad beloppsgräns angiven kommer en beställning/faktura med högre belopp att eskaleras uppåt i organisationsträdet till dess en person med tillräcklig beloppsgräns hittas. Attestering måste dock göras av alla i flödet, även de som har lägre belopp än vad fakturan anger. Om samma person finns både på ansvar och överliggande nivå behöver inte denne attestera på varje nivå utan endast på den högsta beloppsgränsen. (Om eskalering enligt punkt 3 nedan träder in utgår krav på attest på alla nivåer.) • Tvåhandsprincipen: Om den person som gjort beställningen/granskat fakturan är attestant på det ansvar som finns i konteringen kommer beställningen/fakturan att eskaleras uppåt i hierarkin till dess en annan person återfinns som skall göra attesten. • Eskalering vid ej åtgärdad aktivitet: Om en attestant (eller den som han/hon har delegerat till) inte attesterat i linje med åsatta tidsgränser kommer fakturan att skickas vidare uppåt i hierarkin. Ordinarie attestant kan attestera beställningen/fakturan även efter det att eskaleringen är gjord. (beställning 1 dag (24 timmar) / faktura 10 dagar (arbetsdagar vilket innebär att lördag/söndag ej räknas). Samma antal dagar gäller för alla förvaltningar. Tidräkningen för eskalering utgår från när attestanten fick beställningen/fakturan för attest. (Se vidare angående påminnelser.) • En faktura som är markerad som ”under utredning” kommer ej att eskaleras eller påminnas. (önskemål om utveckling så att även dessa omfattas av påminnelse). • Viktigt att löpande attestera för att undvika eskalering. NEKK BtB |Utformningsprinciper Version A

44. Delegering • Med delegering avses att överlåta rättigheter från en person till en annan person– Ej avgränsat till visst ansvar. Den person som man delegerar till måste finns upplagd som användare i Winst. • Rätten att attestera kan delegeras till någon annan person under den ordinarie attestantens frånvaro (eller som stående delegation). Delegering kan göras och ärvs alltid vidare i flera led. Om attesträtten är delegerad får både ordinarie attestant och den/de delegerade, uppgift om att det finns beställning/faktura att beslutsattestera, och båda kan göra beslutsattesteringen. Om en attestant har öppnat beställningen/fakturan kan inte någon annan attestant öppna den samtidigt. En användare som öppnat en beställning/faktura och sedan varit inaktiv i 60 minuter blir automatiskt utloggad och låser inte längre beställningen/fakturan. • Det framgår i attestantens ”beställnings- /fakturaöversikt” om attestanten är ordinarie attestant eller om man har fått beställningen/fakturan via delegering. • Delegeringen avser alltid en period (from/tom). • Delegeringar registreras i Winst, inte i Nekksus. Användarens aktuella delegeringar visas på startsidan. Alla aktiva, tidigare och kommande delegeringar loggas och kan tas ut i rapporter. • Användaren kan inte själv delegera utan detta sker centralt på respektive förvaltning (av lokal systemadministratör). Projektet skall ta fram förslag till rutin för att administrera begäran om registrering av delegering. NEKK BtB |Utformningsprinciper Version A

45. Delegering • Delgeringen kan avse 4 olika funktioner: - Attestera faktura (beslutsattest)- Attestera beställning (beslutsattest)- Leveranskvittera (kontrollattest)- Granska faktura (kontrollattest) • Delegeringen av dessa 4 funktioner kan göras för en eller för flera funktioner oberoende av varandra. • Genom att delegera ”granska faktura” kan man möjliggöra att fler personer kan hantera varandras fakturor. • Delegering av beslutsattest av faktura och beställning skall vara beslutad i enlighet med stadens/förvaltningens riktlinjer innan lokal systemadministratör skall registrera dessa. • Delegering av leveranskvittera och granska faktura skall också godkännas enligt fastställd rutinoch skall registreras av lokal systemadministratör. • Möjligheterna till delegering ger stora möjligheter men måste göras på ett planerat sätt för att bibehålla kvalitet i kontrollerna och en kontrollerad atteststruktur. NEKK BtB |Utformningsprinciper Version A

46. DELEGERINGAR Betalningshantering (Intraservice, Horisonten) Attester i BtB i flödet – beställning/faktura Formaliakontroll Alt 1 – Attest av beställning med matchning mot faktura Förvaltning (WINST) Faktura ankomst Beställare Skapa Beställning Elektronisk rekvisition Kontering (Skicka) Kontrollattest Vara/tjänst levereras Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Betalnings Godkännande Betalningsattest Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Automatisk Matchning OK Auto slutkontroll Momskontroll Giltiga koder Sambandskontroller Styrs av ”Ansvar” i kontering Beställare och beslutsattestant alltid olika personer Formaliakontroll Alt 2 – Automatisk ordermatch ej OK Styrs av ansvar i kontering Beställare Avvikelsehantering Granskning av faktura (Acceptera) Kontrollattest Beställare Avvikelsehantering Granskning av faktura (Acceptera) Kontrollattest Faktura ankommer Beställare Skapa Beställning Elektronisk rekvisition Kontering (Skicka) Kontrollattest Beställare Avvikelsehantering Granskning av faktura (Acceptera) Kontrollattest Attest av Beställning (Godkänn) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Betalnings- Godkännande Betalningsattest Beställare Leverans- Kvittens Kontrollattest Attest av Beställning (Godkänn) Beslutsattest Attest av Faktura (Acceptera) Beslutsattest Automatisk Matchning/ Slutkontroll Ej OK Vara/tjänst levereras Attest av Faktura (Acceptera) Beslutsattest Beställare Leverans- Kvittens Kontrollattest Attest av Beställning (Godkänn) Beslutsattest Auto slut kontroll Attest av Faktura (Acceptera) Beslutsattest Fakturan går till beställare. Styrs av ”Ansvar ” kontering Formaliakontroll Fakturagranskare Granskning/ Kontering av faktura (Acceptera) Kontrollattest Fakturagranskare Granskning/ Kontering av faktura (Acceptera) Kontrollattest Attest av Faktura (Acceptera) Beslutsattest Fakturagranskare Granskning/ Kontering av faktura (Acceptera) Kontrollattest Faktura ankommer Betalnings- Godkännande Betalningsattest Attest av Faktura (Acceptera) Beslutsattest Alt 3 – Faktura utan order - ”Vild” faktura Attest av Faktura (Acceptera) Beslutsattest Auto slut kontroll Styrs av ”Ansvar ”i kontering Styrs av beställarreferens Granskare och beslutsattestant alltid olika personer NEKK BtB |Utformningsprinciper Version A

47. Beslutsattest – skillnader mot idag Beslutsattest kopplas enbart till ansvar, övriga koddelar kan inte användas för begränsning. • I Gasell kan attesterna begränsas med hjälp av alla koddelar. • I praktiken i många fall ett sätt att uttrycka sambandskontroller; dessa kan i Winst ersättas av lokala sambandskontroller, urval av konton, etc. Beslutsattestflödet styrs av organisationshierarkin – inte möjligt att själv välja attestant. Möjlighet till delegering och en styrd eskalering införs. Utanordning ersätts med betalningsattest • Betalningsattest kopplas till utbetalningen och görs centralt i Horisonten av Intraservice. Betalningsattesten skall omfatta kontrollmoment som t ex stickprovskontroll av stora belopp eller leverantörsuppgifter Andra kontrollmoment som ingått i utanordning såsom kontroll av periodiseringar och momsändringar läggs in i fakturaflödet eller får ersättas av efterkontroller i Horisonten/Nekksus. . Attesträtt per ansvar/organisationsnivå för Winst skall registreras i Nekksus Attest av beställning/attest av abonnemang ersätter attest av faktura där så är möjligt. Attestregler för PC-lev kvarstår i Gasell. NEKK BtB |Utformningsprinciper Version A

48. ARBETSMATERIAL Beslutsattest av ”egna kostnader” Hantera förbud mot att attestera egna kostnader • Där denna typ av kostnader uppstår frekvent bör det finnas unika ansvar som någon annan person alltid skall attestera. T ex separat ansvar för förvaltningschefens kostnader som nämndordförande skall attestera. • Hanteringen styrs delvis av Winst genom att beställare och attestant måste vara olika personer. • En utveckling av Winst är beställd* som skall möjliggöra för en attestant, som bedömer att han/hon inte skall attestera för att beställningen/fakturan avser egna kostnader, att kunna ”trycka på en knapp – Egna kostnader” vilket flyttar beställningen/fakturan uppåt i attesthierarkin (direkt eskalering). • I avvaktan på denna utveckling gäller följande: • Attest av beställning: • Om någon annan beställt varor/tjänster som avser den som är attestant på ett ansvar skall attestanten avvakta med attest (1 dag) och låta beställningen eskalera till nästa attestant i kedjan. • Om man inte kan avvakta eskalering finns möjligheten att inte göra leveranskvittens, vilket leder till att fakturan inte ordermatchas och måste hanteras manuellt enligt rutinen för faktura. • :* Skall finnas tillgänglig vid driftsättning. NEKK BtB |Utformningsprinciper Version A

49. ARBETSMATERIAL Beslutsattest av ”egna kostnader”, forts • Attest av faktura: • Om attestanten får en faktura för attest som avser egna kostnader skall han skicka tillbaka fakturan till granskaren, genom att ”returnera till granskare” och samtidigt skriva en kommentar om att fakturan avser ”egna kostnader”. Granskaren väljer i sin tur attestanten som granskare, genom att använda knappen ”ange annan granskare”. Fakturan kommer då att gå tillbaka till attestanten med status ”granskning ej utförd”. Attestanten blir då istället granskare och den som gör kontrollattest.(Attestanten accepterar fakturan = granskning utförd/kontrollattest.) Eftersom granskare och attestant inte kan vara samma person kommer fakturan då att skickas för attest uppåt i attestträdet.Om fakturagranskaren uppmärksammar förhållandet redan vid granskningen kan han/hon välja att direkt överlåta kontrollattesten till attestanten genom att använda knappen ”välj annan granskare”. Attestanten gör då kontrollattest och nästa nivå i attesthierarkin gör beslutsattest. • Attestanten kan också välja att avvakta med attest av fakturan (10 dagar) och vänta på att eskalering inträffar. (Kan endast användas om förfallodatum tillåter detta.) NEKK BtB |Utformningsprinciper Version A

50. Beställnings och fakturaflöde i Winst