Referensgrupp 2013-01-29

1. Attest Beställning till betalning Referensgrupp 2013-01-29

2. 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.. • Dessutom kommer ett antal kontrollmoment både avseende kontrollattest och beslutsattest att vara inbyggda i systemet.

3. Betalningshantering (Intraservice, Horisonten) Attester i fakturaflödet – beställning/faktura Formaliakontroll Förvaltning (WINST) Faktura ankomst Beställare Göra Beställning Elektronisk rekvisition Kontering Kontrollattest Vara/tjänst levereras Attest av Beställning Beslutsattest Leverans- Kvittens Kontrollattest Betalnings Godkännande Betalningsattest Automatisk Matchning OK Slutkontroll Alt 1 Momskontroll Giltiga koder Sambandskontroller Beställare och beslutsattestant alltid olika personer Styrs av ”Ansvar” i kontering Formaliakontroll Styrs av ansvar i kontering Faktura ankommer Beställare Göra Beställning Elektronisk rekvisition Kontering Kontrollattest Attest av Beställning Beslutsattest Leverans- Kvittens Kontrollattest Attest av Faktura Beslutsattest Granskning av faktura Kontrollattest Betalnings- Godkännande Betalningsattest Automatisk Matchning/ Slutkontroll Ej OK Vara/tjänst levereras Alt 2 Styrs av ansvar i kontering Styrs av ordernummer/avtal + typ av fel Formaliakontroll Faktura ankommer Betalnings- Godkännande Betalningsattest Attest av Faktura Beslutsattest Granskning av faktura Kontrollattest Alt 3 – ”Vild” faktura Automatisk Matchning Ej OK Styrs av beställarreferens Styrs av ansvar i kontering Granskare och beslutsattestant alltid olika personer

4. Betalningshantering (Intraservice, Horisonten) Attester i fakturaflödet-Abonnemang Förvaltning (WINST) Betalnings Godkännande Betalningsattest Registrera abonnemang Automatisk Matchning Faktura ankommer Alt 1 Beslutsattest Styrs av regler i abonnemang Styrs av ansvar i kontering. Attest av Faktura Beslutsattest Granskning av faktura Kontrollattest Betalnings Godkännande Betalningsattest Registrera abonnemang Ej Automatisk Matchning Faktura ankommer Beslutsattest Alt 2 Styrs av regler i abonnemang Varianter på alternativ 1 Granskning av faktura Kontrollattest Betalnings Godkännande Betalningsattest Registrera abonnemang Automatisk Matchning Faktura ankommer Beslutsattest Styrs av ansvar i kontering. Betalnings Godkännande Betalningsattest Attest av Faktura Beslutsattest Registrera abonnemang Automatisk Matchning Faktura ankommer Beslutsattest

5. Betalningshantering (Intraservice, Horisonten) Attester i fakturaflö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 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

6. 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 bokningar i WINST (även balanskonton). • Organisationsträdet i Horisonten/Nekksus styr attestflödet automatiskt • Eskaleringanvänds för eskalering till beloppsgräns, för att hitta avvikande beslutsattestant (tvåhandsprincip) eller som påminnelse när förste 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 beloppsgräns på lägsta nivån måste ändå attesteras på varje nivå. • Parallell attesträtt löses genom delegering (stående eller tillfällig). Ytterligare (inledande) attest per Projekt skall vara möjlig om det finns behov* Hantera förbud mot att attestera egna kostnader. • Styrs delvis av systemet genom att beställare och attestant måste vara olika personer. I de fall beställningen gjorts av annan beställare måste beslutsattestanten själv ta initiativ till att skicka beställning/faktura vidare uppåt i hierarkin (i princip som idag). Utformningen av den praktiska hanteringen av detta pågår i samråd med VP. *Behov skall utredas vidare främst med investerande förvaltningar

7. Beslutsattesträtt per ansvar • Det finns olika sätt att bygga beslutsatteststrukturer i VP. Den modell som gäller som huvudsaklig inriktning för projektet är att beslutsatteststrukturen skall vara uppbyggd kring organisationsträdet. • Det innebär att det till varje ansvar och till varje nivå i organisationsträdet skall anges en beslutsattestant. För varje attestant skall också anges ett maxbelopp, som är den gräns per faktura/fakturarad som personen har rätt att attestera. Det är inte möjligt att ange en period (from/tom) för attesträtten i WINST utan den struktur som finns i WINST speglar alltid gällande struktur. (Önskvärt att källsystemet kan hantera datum). • Det måste finnas en attestant kopplad till varje ansvar och nivå i trädet. Samma person kan finnas både på ansvarsnivå och på överliggande nivå. • Organisationsstrukturen för attest skall överensstämma med organisationsträdet som används för uppföljning av verksamheten. • ”Ansvar” i konteringen styr beställningen/fakturan till rätt attestant. Om en faktura avser flera olika ”ansvar” skickas fakturan till de olika ansvaren ansvarsnummerordning.

8. Attest – ansvar/nivå Möjlighet finns för varje attestant att delegera sin attesträtt. Detta sker inte per ansvar utan från person till person. Förvaltning = Nivå 0 Namn på värde:134 Beskrivning: Centrum Aktiv godkännare: Axel Axelsson Högsta kostnadsgräns: obegränsat Sektor = Nivå 1 Namn på värde: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å värde:13410 Beskrivning: Johanneberg/Burås Aktiv godkännare: Jan Jansson Högsta kostnadsgräns: 500 000 Enhet = nivå 3 Namn på värde: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 värde:134101 Beskrivning: Johanneberg 2 Aktiv godkännare: Per Persson Högsta kostnadsgräns: 200 000

9. Delegering • Rätten att attestera kan delegeras till någon annan person under den ordinarie attestantens frånvaro (eller som stående back-up). Delegering kan göras till andra personer 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 attestera och båda kan göra attesteringen. • Delegeringen avser alltid en period (from/tom). • Användaren kan inte själv delegera utan detta sker centralt på respektive förvaltning. • Delgeringen kan avse 4 olika funktioner: • Attestera faktura/Attestera beställning/Leveranskvittera/Granska faktura

10. Eskalering • Organisationsträdet/attesthierarkin har flera funktioner - Eskalering • 1. 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. • 2. Tvåhandsprincipen: Om den person som gjort beställningen ä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. • 3. 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. Båda kan attestera beställningen/fakturan även efter eskaleringen är gjord. • Eftersom attestreglerna är kopplade till organisationshierarkin innebär detta att alla ändringar av ansvar/attestanter bör planeras och göras med försiktighet. Om attestanten ändras på ett ansvar/nivå kommer de beställningar/fakturor som ligger för attest inte att flyttas med automatik utan måste tas bort och skapas på nytt.

11. Attest i WINST – skillnader mot Gasell Attest 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; kan i WINST ersättas av lokala sambandskontroller, urval av konton, etc. • Möjligheten att utnyttja tillkommande attestkrav på projekt. Attestflödet styrs av organisationshierarkin – inte möjligt att själv välja attestant. Möjlighet till delegering och eskalering införs. Utanordning ersätts med betalningsattest • Betalningsattest kopplas till utbetalningen och görs centralt i Horisonten. Kontrollmoment som t ex stickprovskontroll av stora belopp eller leverantörsuppgifter kan införas. Andra kontrollmoment som ingått i utanordning såsom kontroll av periodiseringar och momsändringar läggs in i fakturaflödet . Ingen möjlighet att lägga in from/tomdatum på attesträtten i WINST. (Får hanteras i källsystemet) Attest av beställning/attest av abonnemang ersätter attest av faktura där så är möjligt.

12. Uppdatering av ansvar, organisationsträd och attester i WINST • Giltiga koddelar för konteringsdimensionerna kommer att varje natt läsas in från Horisonten till WINST. I och med att attesten i WINST skall kopplas till ansvar kan ansvarskoderna inte läsas in från Horisonten på samma sätt som övriga koddelar. Uppgift om attestant och belopp per Ansvar/nivå måste finnas med i filen som överförs till WINST.* • Inriktningen är därför att ansvar/organisationshierarki/attest importeras till WINST från Nekksusvarje natt. • I Nekksus skall det finnas en arbetsyta där administratör kan koppla attestant till ansvar/nivå i trädet samt lägga upp beloppsuppgifter och datumuppgifter. Denna arbetsyta är skild från den som används för att koppla budget/prognosuppgifter i Nekksus. • Det skall gå att spåra ändringar som görs (byte av attestant/belopp). • Det skall gå att begränsa behörigheten till att göra nyupplägg/ändringar av attestant/belopp. • Det skall vara enkelt att lägga upp och underhålla attesträtterna (byta ut person som slutar etc). * Utveckling av funktion i Horisonten för detta kan ej motiveras med tanke på kommande byte av ekonomisystem.