Utbildningsmaterial Modell och Process i Agresso

En presentation över ämnet: "Utbildningsmaterial Modell och Process i Agresso"— Presentationens avskrift:

1 Utbildningsmaterial Modell och Process i Agresso
Version B

2 Det här dokumentet har följande historia…
Datum Kommentar Version A, visades vid grundkurs 1 den 27 november Version B, visades vid grundkurs 1 den 27 november, fel korrigerade

3 Inledning

4 Om utbildningsmaterialet
Inledning 1 Om utbildningsmaterialet Det här dokumentet beskriver övergripande hur det nya ekonomisystemet (Agresso) är utformat och uppsatt för förvaltningarna i Göteborgs Stad. Utbildningsmaterialet ska bidra till en ökad förståelse för utformningen av informationsmodell och processer i systemet som komplement till den grundläggande systemutbildningen (grundkurs 2) i Agresso. Målgrupp för utbildningsmaterialet är ekonomer, administratörer och andra användare av ekonomisystemet och de deltagare som deltar på grundkurs 1 - modell och process i Agresso. Utbildningsmaterialet lyfter fram de mest centrala delarna inom systemlösningen som vidare beskrivs i utformningsprinciperna och dess vidhängande fördjupningsdokument. För fördjupad förståelse hänvisas till dessa dokument. Utbildningsmaterialet är nivå-indelat (1/2/3) vilket framgår av symbolen längst upp till höger i respektive bild. Nivå 1 riktar sig till chefer på olika nivåer i organisationen och andra som önskar sig en sammanfattning av förändringen, nivå 2 till ekonomer och administratörer samt nivå 3 till redovisningsekonomer. Via visa/dölj bild i Powerpoint så kan bildspelet anpassas till målgrupp eller lokala behov. 1 Målgrupp: Chefer 2 Målgrupp: Ekonomer och administratörer 3 Målgrupp: Redovisningsekonomer

5 Inledning 3 Övrig dokumentation Detta dokument beskriver på en övergripande nivå hur Agresso kommer fungera men är inte tänkt att ge en fullständig bild av systemlösningen. Inom Agresso finns t.ex. än mängd funktioner, processer och andra begrepp som inte beskrivs i dokumentet. Vid behov av att fördjupa sig i utformningen av Agresso finns ett antal ytterligare dokument enligt tabellen nedan. Dokumenten publiceras på projekthemsidan i takt med att de färdigställs. Observera att dokumenten kan komma att uppdateras under utrullningen; den senaste versionen återfinns alltid finns på projekthemsidan. Utbildningstillfälle Dokument Övergripande för samtliga utbildningstillfällen NEKK_EKH_Utformningsprinciper.doc Grundkurs 1 - Modell och process i Agresso NEKK_Utbildningsmaterial_Grundkurs 1.ppt (detta dokument) Grundkurs 2 - Systemutbildning i Agresso NEKK_Systemutbildning_Grundkurs 2.doc Fördjupningskurs Lokal systemadministration inkl. huvudbok NEKK_Utformningsprinciper_Fördjupning_Lokal systemadministration.doc NEKK_Systemutbildning_Fördjupning_Lokal systemadministration.doc Fördjupningskurs Order/fakturering och kundreskontra NEKK_Utformningsprinciper_Fördjupning_Order fakturering och utbetalningar.doc NEKK_Systemutbildning_Fördjupning_Order fakturering och kundreskontra.doc Fördjupningskurs Anläggning NEKK_Utformningsprinciper_Fördjupning_Anläggning.doc NEKK_Systemutbildning_Fördjupning_Anläggning.doc

6 Innehållsförteckning
Inledning 3 Innehållsförteckning Avsnitt Sid Avsnitt Sid Inledning ……………………………………………………………………… Om utbildningsmaterialet…………………………………………………….. Övrig dokumentation…………………………………………………………. Innehållsförteckning……………………………………...…………………… Om det nya ekonomisystemet………………………..…………………… Bakgrunden till ett nytt ekonomisystem ……………………………………. Syftet med ett nytt ekonomisystem……………………..…………………... Konceptmålbild…………………………………………....………………….. Skillnader med nytt ekonomisystem…………………….………………….. Målgrupper………………………………………………...………………….. Inloggning och åtkomst till Agresso mm.…………………...……………… Ekonomimodell.…………………..…………………..……………………... Ordlista ekonomimodell.…………………..…………………..……………... Ekonomimodellens konteringsbegrepp.…………………...………………. Konteringsbegrepp och skillnader.…………………...…………………….. Relationer och flexibla fält.…………………..………………………………. Konteringsregler.…………………...…………………...……………………. Investeringsredovisning.…………………...…………………...……………. Systemstruktur.…………………..…………………..………………………Övergripande systemstruktur.…………………..…………………..………. Saldotabeller.…………………..…………………..…………………………. Skillnad integrationer från verksamhetssystem.…………………..………. Användargränssnitt.…………………..…………………..………………….. Web-gränssnittet.…………………..…………………..…………………….. Desktop-gränssnittet.…………………..…………………..………………… Huvudbok och gemensamt.…………………..…………………..………. Bokföring ………………………………...…………………..……………….. Bokföringsorder.…………………..…………………..……………………… Verifikationstyper och verifikationsnummerserier……..………………….. Verifikationstyper vid bokföringsorder……..………………………………. Momskod……..……………………………..………………………………… Bokföringsorder utan elektronisk attest i Agresso……..…………………. Bokföringsorder med elektronisk attest i Agresso……..…………………. . 1-6 4 5 6 7-14 8 9 10 11-12 13 14 15-22 16 17 18 19 20-21 22 23-32 24-27 28 29 30 31 32 33-54 34 35-36 37-38 39-41 42 44 45 Omkontering och reversering……..………………………………… Bokföringsperiod i Agresso……..……………………………..……. Periodisering vid registrering direkt i Agresso……..……………… Varje redovisningsenhet i balans……..……………………………. Blanketter……..……………………………..……………………….. Rapporter/utdata i huvudboken……..……………………………… Periodavslut……..……………………………..…………………….. Felrättning vid integration från försystem……..…………………… Attest……..……………………………..…………………………….. Order/Fakturering och kund……..……………………………….. Försäljningsorder och fakturering……..…………………………… Utbetalningar som ej går via Winst……..………………………….. Fakturalayout……..……………………………..…………………… Kundbegreppet……..……………………………..…………………. Kundgrupp……..……………………………..………………………. Tekniker för manuell försäljningsorder……..……………………… Inriktning attest försäljningsorder……..……………………………. Ordernummertyper vid försäljningsorder……..…………………… Artikelgrupp och artikel……..……………………………………….. Utskrift av fakturor……..……………………………..……………… Kundfakturor (D/K) utan elektronisk attest……..………………….. Kundfakturor (D/K) med elektronisk attest……..………………….. Utbetalningar till kund utan elektronisk attest……..………………. Utbetalningar till kund med elektronisk attest……..………………. Utbetalning av kreditfakturor/kundtillgodohavanden……..………. Förvaltningsintern och kommunintern försäljning……..………….. Leverantör……..……………………………..……………………… Leverantörsreskontra……..……………………………..…………... Lokal leverantörsfakturaadministration……..……………………… Anläggning……..……………………………..…………………….. Anläggningsreskontra……..……………………………..………….. 46 47 48 49 50 51 52 53 54 55-72 56 57 58 59 60 61 62 63 64 65 67 68 69 70 71 72 73-75 74 76 77-80 78-80

7 Om det nya ekonomisystemet (Agresso)

8 Bakgrunden till ett nytt ekonomisystem
1 Bakgrunden till ett nytt ekonomisystem En del av Stadens nya ekonomikoncept (”NEKK”) och ett led i samordningen av stödprocesser och stödsystem Omfattar samtliga förvaltningar i Göteborgs Stad. Ersätter dagens Horisonten och en mängd kringliggande ekonomiapplikationer såsom PC-lev, WebbFaktura, WebbBFO, Dagrapport och Fupps. Upphandling av nytt ekonomisystem genomförd hösten till våren Avtal tecknat med Agresso sommaren 2013. Utrullning hösten 2014 till våren 2015 i fyra olika utrullningsomgångar. Projektavslut 30 juni 2015. Möjlighet för bolagen att använda de avtal som upphandlats av NEKK. 8

9 Syftet med ett nytt ekonomisystem
1 Syftet med ett nytt ekonomisystem Med ett nytt ekonomisystem vill staden uppnå: Minskade underhålls- och utvecklingskostnader Effektiva verksamhetsprocesser Möjliggöra utveckling mot önskvärda roller Sammantaget ska nytt ekonomisystem skapa förutsättningar för staden som helhet för en effektiv ekonomiadministration. 9

10 Nytt ekonomikoncept (NEKK)
Ett nytt ekonomisystem 1 Konceptmålbild Nytt ekonomikoncept (NEKK) Bättre förutsättningar för planering och styrning av ekonomin och inköpen i staden med hjälp av gemensam teknik och arbetssätt. Delprojekt 1 Ekonomisk styrning och uppföljning av verksamheten Chefer och ekonomer 5 000 medarbetare System Nekksus (2013) Delprojekt 2 Beställning till betalning med inköp och fakturor i samma system (e-handel) medarbetare System Gasell ersätts med system Winst (2014) Delprojekt 3 Ekonomihantering för effektiv ekonomi-administration 1 000 medarbetare System Horisonten ersätts med system Agresso (2015)

11 Skillnader med nytt ekonomisystem
Ett nytt ekonomisystem 1 Skillnader med nytt ekonomisystem Ett nytt och standardiserat ekonomisystem (Agresso) som ersätter Horisonten och en mängd ekonomiapplikationer (PC-lev, WebbFaktura, WebbBFO, Dagrapport och Fupps). Ny funktionalitet för huvudbok, kundreskontra, order och fakturering, leverantörsreskontra och anläggningsreskontra. Nya processer där framför allt flödena för kundfakturering och utbetalningar (ersättaren till WebbFaktura och PC-lev) kräver ett ändrat arbetssätt. Gemensamma processer/informationsmodell för anläggningsredovisning. En förändrad och gemensam kodsträng baserat på Agresso standard, som också möjliggör kommande utveckling. Två nya användargränssnitt: Agresso Web för verksamhetsekonomer, orderregistrerare, fakturahandläggare m.fl. Agresso Desktop för redovisare, central systemförvaltning m. fl. 11

12 Skillnader med nytt ekonomisystem
Ett nytt ekonomisystem 1 Skillnader med nytt ekonomisystem Förvaltningar som egna redovisningsenheter i Agresso för att enklare kunna se sin egen data och ha sina egna konteringsregler. Gemensam information och regler som underhålls i koncernföretaget KC01 vilket styr/försörjer samtliga redovisningsenheter med ex. gemensamt leverantörsregister, konteringsbegrepp och gemensamma begreppsvärden. Agresso som komplement till Nekksus för utdata/ rapporter men med ett tydligare fokus på rapporter för den löpande redovisningen och bokslut. Uppdatering av data sker mer direkt genom att användaren triggar olika körningar (ej nattliga körningar/batchar). Ny driftmodell där Agresso tillhandahålls som en molntjänst från systemleverantören (drift och underhåll) och där Staden betalar en månatlig kostnad per användare för att använda systemet. Ytterligare moduler (ex. tid- och projekt, serviceorder och lager) går att avropa på option i avtalet med Agresso och en flera andra utvecklingsmöjligheter. 12

13 Målgrupper Agresso beräknas ha ca 1 000 användare Ekonomer
Ett nytt ekonomisystem 1 Målgrupper Agresso beräknas ha ca användare Ekonomer Administratörer (Fakturahandläggare, orderregistrerare m. fl.) Koncernredovisning/ Stadsledningskontoret Intraservice (support, central systemförvaltning, gemensamma kund-/levflöden) 13

14 https://agresso.goteborg.se/agrprod
Ett nytt ekonomisystem 2 Inloggning och åtkomst till Agresso mm Web Desktop För åtkomst ska användaren… Ha ett GBG3000-konto Vara upplagd som användare i Agresso (beställs på Beställningsportalen). För åtkomst ska användaren… Ha ett GBG3000-konto Vara upplagd som användare i Agresso och ha ett AD-konto i leverantörens Citrix-miljö (beställs på Beställningsportalen). Citrix Reciver installerat på sin dator (beställs via Mina Verktyg). Skrivare Agresso nyttjar användarnas vanliga lokala skrivare. Om utskrifter från Desktop-klienten inte fungerar skall användaren lägga ett supportärende till Servicedesk på Intraservice för att få rätt drivrutin. För åtkomst ska användaren vara anslutet till Stadsnätet via fast anslutning, trådlös anslutning eller via VPN. Stöd för SSO, SingelSignOn, vilket innebär att användaren kommer direkt in i applikationen via länken.

15 Ekonomimodell

16 Ordlista ekonomimodell
1 Ordlista ekonomimodell Konteringsbegrepp: Motsvarigheten till koddelar. De begrepp som finns tillgängliga vid kontering av bokföringstransaktioner i Agresso. Valbara begreppsvärden inom resp. konteringsbegrepp underhålls antingen kommuncentralt (ex. begreppsvärden för konto och motpart) eller lokalt på förvaltningen (ex. begreppsvärden för ansvar och projekt). Relationsbegrepp/relationer: Motsvarigheten till underkoder. Hänger alltid på ett konterings- begrepp och används för att gruppera/summera olika begreppsvärden för utdata. Valbara värden inom resp. relation underhålls antingen kommuncentralt eller lokalt på förvaltningen. Begrepp: Ett samlingsnamn som antingen kan syfta på ett konteringsbegrepp eller ett relationsbegrepp. Begreppsvärde: Ett samlingsnamn som syftar på de unika och valbara värden som antingen finns i ett konteringsbegrepp eller i ett relationsbegrepp/relation. Ibland används relationsvärde för att precisera att det är värde inom ett relationsbegrepp/relation som åsyftas. Konteringsregler: Motsvarigheten till indatakontroller, kodkomplettering och/eller sambandskontroller. Regler som sätts upp i Agresso för att underlätta/säkerställa kontering. Utgår alltid från konto.

17 Ekonomimodellens konteringsbegrepp
1 Ekonomimodellens konteringsbegrepp Samtliga förvaltningar i Göteborgs Stad har en ny och gemensam kodsträng i Agresso: 8 konteringsbegrepp med vidhängande relationer för gruppering/summering till utdata. Stödjer flerdimensionell redovisning. Visas även i Nekksus; i rapporter och vid budget/prognos. Baseras på Agresso standard, vilket möjliggör utveckling och förenklar vid uppgraderingar. Kommuncentralt ägande och underhåll av gemensamma begrepp och relationer. Lokalt ägande och underhåll av lokala begreppsvärden (upplägg under egen meny i Agresso). Konto Obl 4 pos Ansvar Obl 8 pos Spec (Anl) Obl/Friv 7 pos Aktao Friv Objekt Friv 12 pos Verk Obl kkl 3-8 Motpart Projekt 1+6 pos

18 Konteringsbegrepp och skillnader
Ekonomimodell 3 Konteringsbegrepp och skillnader Obligatoriskt i alla trans-aktioner. Vid integrationer av försäljningsorder (LG04) ges Konto av artikel och ska normalt inte skickas med från försystemet. Om transaktionen avser en investering (transaktion till invest-eringsredovisning) ska ett projekt som börjar på I anges. I övrigt fall är begreppet frivilligt. Placeringen som tredje begrepp möjliggör att Agressos modul för tid- och projekt kan an-vändas (ingår ej i NEKK-införandet). Frivillig koddel som ersätter koddelen aktivitet och används för Aktivitet eller Arbetsorder. Placering möjliggör att Agressos modul för serviceorder kan användas (ingår ej i NEKK-införandet). Obligatoriskt i alla transaktioner. Motpart ska inte fyllas i vid integration av försäljningsorder (LG04) eller vid bokförings- order med leverantörskoppling (GL07 med AP-koppling). Konto Obl 4 pos Ansvar Obl 8 pos Spec (Anl) Obl/Friv 7 pos Aktao Friv Objekt Friv 12 pos Verk Obl kkl 3-8 Motpart Projekt 1+6 pos Obligatoriskt i alla transaktioner. Kan vara lika med xxx (förvaltningsprefix) för balanskonton eller ett specifikt ansvar för resultatkonton. För balanskonton kan ansvarskoden sättas med hjälp av en konteringsregel i Agresso och behöver då inte anges av försystemet. Obs; tänk på att prefix alltid ska ingå i ansvarskod från försystem liksom vid manuell kontering. I de fall den konterade händelsen avser en gemensam/central speckod är detta begrepp obligatoriskt. Begreppet innehåller nu också de gemensamma koder som tidigare fanns i Aktivitet och som började med en 9:a. I annat fall avgörs begreppet av lokala behov. Begreppet används även för transaktioner från anläggningsregistret (som då ej kan konteras med en vanlig speckod). Obs; Personec har endast plats för 4 pos för Spec. Vid integrationer kan Verk- koden sättas vid inläsningen till Agresso under förutsättning att det alltid är ett och samma Verk som ska gälla för förvaltningen eller per ansvar eller annan koddel.

19 Relationer och flexibla fält
Ekonomimodell 3 Relationer och flexibla fält En relation är i Agresso motsvarigheten till underkod i Horisonten. En relation hänger alltid på ett konteringsbegrepp och används för att gruppera/summera olika begreppsvärden för utdata. Precis som tidigare kommer koder och relationer att vara en källa till strukturen för rapporterna i Nekksus. Vilka relationer som gäller för respektive konteringsbegrepp har fastställts utifrån gemensamma och lokala behov. De relationer som ska användas i Agresso är i huvudsak de samma som tidigare. Även för kund, leverantör och anläggning kan relationer användas för att koppla information till dessa begrepp. På t.ex. kundbegreppet finns tre relationer - motpart, fakturatyp och A-post - och på leverantörsbegreppet* finns relationerna motpart, factoringbolag och Fem18 (den sistnämnda används för momsrapportering i SDN). Flexibla fält är ett alternativ till relationer, vilket ger möjligheten att definiera extra fält för registrering och utdata. I Stadens uppsättning av Agresso används flexibla fält för att t.ex. visa viss specifik information på kundbilden och leverantörsbilden (förfallna kundfakturor, betalda kundfakturor mm.) *) Motpart och factoringbolag syns ej i förvaltningens redovisningsenhet.

20 Ekonomimodell 2 Konteringsregler Konteringsregler syftar till att säkerställa kvalitet i bokföringen och effektivitet vid kontering. Konteringsregler kan antingen vara gemensamma (gäller för samtliga redovisningsenheter) eller lokala (gäller enbart för den egna förvaltningen). I Agresso utgår konteringsregler alltid från konto. Kontrollerna slår igenom på olika sätt: Vid registrering i Agresso kontrolleras direkt mot konteringsreglerna. Det går inte att godkänna en verifikation som strider mot en konteringsregel. Vid inläsning från försystem eller Excelerator sker kontrollen först vid inläsning. Transaktionerna måste vara godkända utifrån konteringsreglerna. Om inte, felfälls de som huvudregel och måste rättas i Agresso. Winst och Agresso har olika modeller men kompletterar varandra i ett kontrollperspektiv. Konteringsregler i Agresso underhålls av central systemförvaltning (med möjlighet att titta på reglerna lokalt).

21 Konteringsregler – exempel
Ekonomimodell 3 Konteringsregler – exempel I Agresso utgår konteringsregler alltid från konto där följande typregler finns: Vilka koddelar som skall (S), får (V) eller inte får användas. Att ett visst koddelsvärde skall anges fast (F) eller som förslag för kontot. Om ett visst koddelsvärde skall vara fast/förslag för kontot beroende på ansvar eller annan koddel (så kallad direktrelation), t ex att Verk sätts från Ansvar (innebär att Verk måste anges för alla Ansvar). Om ett visst koddelsvärde skall ligga inom vissa intervall. Om man kan boka manuellt på kontot. Om momskod måste anges av den som registrerar eller sätts fast. Det går inte att ställa krav på att periodisering skall/inte får användas.

22 Investeringsredovisning
Ekonomimodell 3 Investeringsredovisning Ingen särskild delmodell för investeringsredovisning i Agresso utan denna hanteras i huvudboken tillsammans med övriga bokföringstransaktioner. Kontering på projekt med inledande ”I” identifierar transaktionen som en investeringstransaktion. Vid bokföring på I-projekt triggas en bearbetning ”TT-trigger” som skapar en ombokning med två transaktioner där den ena vänder ursprungstransaktionen och den andra skapar en ny bokföringstransaktion på ett pågåendekonto i balansräkningen (1170 eller motsvarande). Transaktionen på pågåendekontot kommer att innehålla projektkoden och vissa övriga koddelar. Verifikationen som vänder bokföringen kommer att få en separat verifikationstyp (HI) som gör att dessa transaktioner kan sorteras bort när investeringsredovisningen ska sökas ut ur Agresso. TT-triggern kommer att läggas in i de investerande förvaltningarnas redovisningsenheter. Triggern kommer att se likadana ut för samtliga förvaltningar. Den exakta konteringen avgörs sedan per förvaltning genom att konteringsregeln för aktuellt konto utformas enligt redovisningsenhetens önskemål.

23 Systemstruktur

24 Övergripande systemstruktur
2 Övergripande systemstruktur Bilden visar informationsflöden mellan olika system inom och utanför NEKK-konceptet. Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Personec x NEKK Nekksus Modell, struktur, systemadm Budget, prognos Utfall. analys Leverantörsfakturor Kunder & Fsg.order Internfakturor Bokföringsorder Utfallstransaktioner Löneinfo på individnivå/personalstatistik Leverantörer Koder, begrepp, relationer Koddel Ansvar Attestanter Koder, begrepp, relationer Försystem x Winst Modell, struktur, systemadm Avtal Inköp Lev.fakturor Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- Anläggnings-

25 Övergripande systemstruktur
2 Övergripande systemstruktur Varje förvaltning är en egen redovisningsenhet i Agresso. Ingår i koncernföretaget KC01 där bl.a. gemensamt leverantörsregister och gemensamma begreppsvärden underhålls. Varje redovisningsenhet består av modulerna Huvudbok (HB), Order/Fakturering (O/F), Kundreskontra (AR), Leverantörsreskontra (AP) och för vissa även Anläggningsreskontra (AT). Samtliga redovisningsenheter utgör tillsammans den gemensamma huvudboken för kommunen. Varje förvaltning ser enbart sina egna lokala begreppsvärden och de som är gemensamma. Koder i Agressos huvudbok kommer att vara källa till både Nekksus och Winst. Bokföringen från huvudboken förs som idag över till Nekksus för uttag av rapporter mm till verksamheten.

26 Övergripande systemstruktur
2 Övergripande systemstruktur Leverantörsfakturahanteringen hanteras i Winst på samma sätt som idag. Order/Fakturering (ersättaren för WebbFaktura och merparten av PC-lev) hanteras i respektive förvaltning. Kundregister finns i respektive redovisningsenhet medan leverantörsregistret är gemensamt för alla redovisningsenheterna. Anläggningsreskontra finns endast för de investerande förvaltningarna samt för ett fåtal andra fackförvaltningar. Möjligt för ex. kommuncentrala användare att bokföra och ta ut rapporter över flera redovisningsenheter. Systemadministration kommer att hanteras både lokalt på förvaltningen och kommuncentralt.

27 Övergripande systemstruktur
2 Övergripande systemstruktur Samtliga förvaltningar egna redovisningsenheter i Agresso, som är namnsatta enligt nuvarande ”prefix” utan ”N”, dvs. 131, 200 etc. Koncernföretaget KC01 är styrande för respektive redovisningsenhet när det gäller t.ex.: Funktioner och utformningen av de olika modulerna Konteringsbegrepp och gemensamma relationer Gemensamma begreppsvärden, gemensamma relationsvärden Gemensamma konteringsregler Gemensamt leverantörsregister Gemensamma rapporter/utdata Gemensamma verifikationstyper och verifikationsnummerserier Central systemförvaltning tillser att gemensamma uppgifter från KC01 görs tillgängliga till varje redovisningsenhet (genom utkopiering) Koncern- företag (KC01) Förvaltningar Bolag

28 Systemstruktur 3 Saldotabeller I Göteborgs stads uppsättning av Agresso finns följande saldotabeller som är skapade specifikt för Göteborgs stad. ATINTCST - Import av investeringstransaktioner. Används för att fånga och hålla reda på vilka projekttransaktioner som ligger och väntar på aktivering samt vilka transaktioner som är aktiverade. GBGMS - Göteborgs vy för momstransaktioner. Används för att fånga momstransaktioner till momsrapporten. GBGRE - Saldotabell per redovisningsenhet. Används till att söka aggregerade transaktioner per redovisningsenhet. Går via browser att fråga över alla redovisningsenheter.

29 Skillnad integrationer från verksamhetssystem
Systemstruktur 3 Skillnad integrationer från verksamhetssystem Integrationer av fakturaunderlag som i Horisonten skickats till FUPPS ersätts av två integrationer med Agresso; kunduppgifter (CS15) och försäljningsorder (LG04). Integrationer av bokföringsinformation (t. ex. Personec) sker genom integration av bokföringsorder (GL07) till Agresso. Övriga integrationer som tidigare skickades till PC-lev för utbetalning hanteras nu enligt följande: Om de avser privatpersoner eller är regleringar av tidigare fakturerat ska de skickas som negativa försäljningsorder med en separat ordernummertyp i Agresso (CS15 och LG04). Om de avser företag och organisationer, som inte är kunder: Företaget/organisationen skickar en leverantörsfaktura som då hanteras via Winst. Förvaltningen skickar ett utbetalningsuppdrag med leverantörsuppgifter till Intraservice för inskanning. Hantering sker via Winst på samma sätt som för en leverantörsfaktura. Detta sätt skall också användas vid delbetalning av faktura. De skickas som bokföringsorder med leverantörskoppling (GL07-AP). I dessa fall måste betalningsmottagaren (leverantören) läggas upp manuellt eller via en fil motsvarande CS15. De utbetalningar som registrerades manuellt i PC-lev tidigare kommer att hanteras som manuell negativ försäljningsorder. De PC-levutbetalningar som tidigare integrerats med Winst ersätts av Agresso-flödet enligt ovan.

30 Användargränssnitt Agresso
Systemstruktur 2 Användargränssnitt Agresso har två olika gränssnitt mot användaren; Web (åtkomligt via webbläsaren) och Desktop (åtkomligt via ”program”/ikon på fjärrskrivbord). Användare i Desktop har per automatik tillgång till Web. Priset som staden betalar till systemleverantören varierar per användarkategori (large/medium/small*) enligt avtalet med Agresso. Använder ekonomisystemet dagligen i stor omfattning Redovisningsekonomer, centrala systemförvaltare, koncernredovisning och centrala/lokala reskontraförvaltare (ekonomienheten Intraservice). PROJEKTET Agresso DESKTOP OCH WEB “Large-användare” Använder ekonomisystemet för registrering av bokföringsorder, kundfakturor och/eller utbetalningar samt utdata Verksamhetsekonomer, fakturahandläggare, orderregistrerare och ekonomiadministratörer. WEB “Medium-användare” Använder ekonomisystemet enbart för utdata och attest av bokföringsorder, kundfakturor och/eller utbetalningar Sällananvändare, enhetschefer och administratörer. WEB “Small-användare” *) Staden erlägger en månatlig avgift till systemleverantören utifrån antalet användare; Large (540 kr per användare), Medium (273 kr), Small (235 kr) enl. nuvarande prislista. Ekonomimodellen för hur Staden kommer fakturera förvaltningarna för nyttjandet av ekonomisystemet är vid ej klar (per ).

31 Systemstruktur 3 Web-gränssnittet Riktar sig till verksamhetsekonomer, administratörer, fakturahandläggare, orderregistrerare med flera. Ett modernt webb-gränssnitt som är åtkomligt via webbläsaren. Används för att attestera bokföringsorder och försäljningsorder. Användare med enbart web kategoriseras antingen som small- eller medium-användare enligt avtalet med Agresso. Användare i Web får per automatik inte tillgång till Desktop. Exempel på funktioner i Web: Bokföringsorder Titta på begrepp och begreppsvärden Registrera försäljningsorder exkl. abonnemang Registrera kund Attest Skriva ut fakturakopia Underhålla kundfakturaposter Rapporter (huvudbok, kundcentralen, leverantörscentralen, anläggningsregister) …

32 Desktop-gränssnittet
Systemstruktur 3 Desktop-gränssnittet Riktar sig till redovisningsekonomer och användare som arbetar mycket i ekonomisystemet. Innehåller fler funktioner än webb-gränssnittet (dock ej attest som enbart finns i Web). Åtkomlig via fjärrinloggning (Citrix). Användare med Desktop får per automatik tillgång till Web. Användare med Desktop kategoriseras alltid som en Large-användare enligt avtalet med Agresso. Exempel på funktioner i Desktop: Räntefaktura Osäkra kundfordringar och kundförluster Inläsning av filer från försystem Ändra förfallodag på leverantörsfakturor Underhåll av fasta register, vertyper, perioder mm Inbetalningar och utbetalningar Påminnelse och inkasso Upplägg av interna kunder (B/K/N/I), artikelgrupper, kundgrupper, leverantörer, användare och roller … Bokföringsorder via Excelerator Funktion för kontoavstämning Begreppsvärden (upplägg/underhåll) Periodavslut (rapporter och körningar) Lägga upp artiklar Abonnemang Fakturering Utbetalningskörning

33 Huvudbok och gemensamt

34 Bokföring Bokföringsorder kan antingen göras
Huvudbok och gemensamt 2 Bokföring Bokföringsorder kan antingen göras direkt i Agresso, via registrering i Exceleratormall som sedan importeras till Agresso eller via inläsning från försystem som skickar bokföringstransaktioner till Agresso. Försystem x Bokföring GL07 Excelerator Bokförings-mall Bokföring GL07 Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- Anläggnings- BFO

35 Huvudbok och gemensamt
2 Bokföringsorder Bokföringsorder i Agresso kan göras i både Web och Desktop. Bokföringsorder via Excelerator-mall och inläsning från försystem går enbart göra med hjälp av Desktop. I Agresso används inte begreppen Debet och Kredit vid registrering utan tecken på beloppet (+/-) avgör ”sida” i bokföringen. Positiva belopp är Debet och negativa belopp är Kredit. En verifikation måste alltid balansera i Debet/Kredit inom en period. Vid registrering direkt i Agresso kontrolleras konteringen automatiskt mot konteringsregler och giltiga koder. Vid registrering via Excelerator-mall och försystem sker dessa kontroller först vid inläsning till Agresso. Bokföringsmallar kan enkelt skapas och åter- användas vid registrering i Agresso. Bokföringsmall kommer t.ex. användas vid ”Dagrapport”. Det går dock inte att klippa och klistra i dessa mallar.

36 Huvudbok och gemensamt
2 Bokföringsorder Vid registrering i Agresso aktiveras vändas när verifikationen registreras och användaren trycker på ”knappen” Periodisera. Användaren får då en fråga om i vilken period vändning skall ske och när bokföringen uppdateras skapas en verifikation i innevarande period och en verifikation med omvänt tecken i den period som valts för vändning. ”Periodisera” ska inte förväxlas med ”periodisering”. Periodisering innebär att dela upp en bokföringspost över flera perioder och har inget med vändas att göra. Bokföringsorder via Excelerator-mall kan underlätta om antalet transaktioner är omfattande och det finns behov att klistra in rader från annat underlag. Ifylld Excelerator-mall förs över till Agresso. Då det inte finns kontroller och konteringsregler i själva mallen bör Excelerator-mall användas i begränsad omfattning. Bokföringsorder för elektronisk attest med vändas kan enbart göras via Excelerator-mall (vertyp H8). Om denna vertyp används direkt i Agresso kommer den automatiska vändningen inte göras.

37 Verifikationstyper och verifikations- nummerserier
Huvudbok och gemensamt 3 Verifikationstyper och verifikations- nummerserier Vertyp används för att kunna urskilja vilken typ av bokföringsorder som registrerats eller från vilket försystem som verifikationen/transaktionerna har sitt ursprung. En verifikation balanserar alltid D/K i en period. Vid periodisering (tidigare Fper) skapas nya verifikationer i de framtida månaderna (en per period). Buntnummer används vid fil-inläsning, men finns inte i huvudboken. Ett attestflöde kan kopplas per vertyp varför olika vertyper krävs om olika attestflöden finns. Verifikationer med olika vertyp delar i vissa fall verifikationsnummerserier. För kundfakturor är fakturanummer samma som verifikationsnummer. Verifikationsnummer från Winst fortsätter på samma sätt som tidigare. Vid attest kommer bokföringsorder att kunna vara ”ankomstregistrerade” eller ”definitiva”. Dessa två status har olika vertyper. Vid registrering av bokföringsorder i Web används namnet verifikationspost istället för verifikationstyp, men dessa begrepp är i grunden samma sak.

38 Verifikationstyper och verifikations- nummerserier (exempel)
Huvudbok och gemensamt 3 Verifikationstyper och verifikations- nummerserier (exempel) Den aktuella och fullständiga listan finns alltid i Agresso. Vertyp Benämning Vernummer-serie HX Migrerade saldon från Horisonten 19nnnnnnnn H0 Bokföringsorder utan attest 10nnnnnnnn H1 Vändas utan attest H2 Bokföringsorder med attest - ankomst 11nnnnnnnn H3 Bokföringsorder med attest - definitiv H8 Vändas med attest – ankomst H9 Vändas med attest – definitiv HR Reversering Huvudbok HM Bokning mellan redovisningsenheter (postback) 12nnnnnnnn E*, F*,G* Fakturering från försystem (samma som ordernummertyp) 7xxxnnnnnnn C* Utbetalningar (FO) från försystem BD Manuell fakturering (ordernummertyp AA, AB, AC o AD) DB Manuella utbetalningar (ordernummertyp AG) LA, LD, LM Verifikationer från Winst Ankomst/definitiv/Makuleringar xxxnnnnnnnn O* Betalningar kundreskontran 31nnnnnnnn U* Import GL07 och GL07-AP(Personec, Utbet Rix, Pluto osv)

39 Verifikationstyper vid bokföringsorder Bokföringsorder i Desktop
Huvudbok och gemensamt 3 Verifikationstyper vid bokföringsorder Bokföringsorder i Desktop H0 Används för vanlig bokföringsorder utan elektronisk attest. Används för bokföringsorder med ”vändas” utan elektronisk attest. Användaren skall alltid välja ”Periodisera” när denna vertyp används. Vändningen får vertypen H1. Användaren väljer i vilken period vändningen skall ske. Används för vanlig bokföringsorder med elektronisk attest. Vid registrering väljs ”Ankomstregistrering”. Definitivbokföringen får vertyp H3 och är den som ses i bokföringen. Användaren kan inte välja ”Periodisera” vid registrering av bokföringsorder med vertyp H2 (vändas ej möjlig). Kan inte göras i Desktop eller Web utan enbart genom bokföringsorder i Excelerator-mall (används där för ”vändas” med elektronisk attest). Om en H8 trots allt registreras kommer den att hanteras som en H2, alltså utan vändning. H1 H2 H8

40 Verifikationstyper vid bokföringsorder Bokföringsorder i Web
Huvudbok och gemensamt 3 Verifikationstyper vid bokföringsorder Bokföringsorder i Web H0 Används för vanlig bokföringsorder utan elektronisk attest. Används för bokföringsorder med ”vändas” utan elektronisk attest . Om vändas registreras via Web måste dessa vändas ”manuellt” i kommande månad antingen genom manuell registrering (med vertyp H1) eller genom att reversering (reverseringsförslag och bekräftelse) körs. Reverseringen erhåller vertyp HR. Används för vanlig bokföringsorder med elektronisk attest. Vid registrering välja ”Ankomstregistrering”. Definitivbokföringen får vertyp H3 och är den som ses i bokföringen. Användaren kan inte välja Periodisera vid registrering av en sådan. Kan inte göras i Desktop eller Web utan enbart genom bokföringsorder i Excelerator-mall (används där för ”vändas” med elektronisk attest). Om en H8 trots allt registreras kommer den att hanteras som en H2, alltså utan vändning. H1 H2 H8

41 Huvudbok och gemensamt
3 Verifikationstyper vid bokföringsorder Bokföringsorder via Excelerator-mall H0 Används för vanlig bokföringsorder utan elektronisk attest. Används för bokföringsorder med ”vändas” utan elektronisk attest. Kommer alltid att vända bokningen i kommande period. Vändningen får vertypen H1. Används för vanlig bokföringsorder med elektronisk attest, ingen vändning. Används för bokföringsorder med ”vändas” och elektronisk attest. Definitivbokningen får vertyp H9. Vändningen kommer alltid att få vertyp H9 (och går ej på ny attesteras). Används av vissa kommuncentrala användare för bokföring över flera redovisningsenheter. H1 H2 H8 HM

42 Huvudbok och gemensamt
2 Momskod Används för utgående moms och anger vilken momssats som skall gälla. Obligatorisk på försäljningskonton. För övriga konton är momskod alltid 0. På varje momskod hänger ett konto för utgående moms. Vid registrering av försäljningsorder anges alltid belopp exklusive moms. Agresso beräknar moms med automatik vid fakturering. Intäktskontot får också momskod vilket gör att momspliktig omsättning kan räknas fram även om samma intäktskonto används för olika momssatser (viktigt för momsrapporten) Vid registrering av bokföringsorder ska momskod anges om bokföringsordern innehåller utgående moms (ex. dagrapporter, försystem för kontantförsäljning). Automatisk beräkning av utgående moms vid registrering direkt i Agresso (ej automatiskt vid bokföringsorder via Excelerator). Interimsbokningar av intäkter skall bokföras med momskod 0 och konton med fast momskod kan då inte användas.

43 Symboler processer Symbol Betydelse i detta sammanhang
Huvudbok och gemensamt 2 Symboler processer Symbol Betydelse i detta sammanhang Input (underlag, försystem), lagring (kundregister), output (kundfaktura, utbetalningsavisering) Aktivitet i Agresso. Rapport, browser-fråga i Agresso. Användargränssnitt; Web (W) och/eller Desktop (D). Vem som utför aktiviteten; Ekonomiavdelningen (E) och/eller verksamheten (V). Intraservice (IS). W D E V IS

44 Bokföringsorder utan elektronisk attest i Agresso
Huvudbok och gemensamt 2 Bokföringsorder utan elektronisk attest i Agresso Registrera Bokföringsorder Verifikationsregistrering W D E Underlag Bokföring i huvudboken Vertyper (anges vid registrering) H0 Bfo utan elektronisk attest – Web eller Desktop H1 Bfo med reversering utan elektronisk attest – endast i Desktop Försystem U* UA Personec Inläsning och ev. rättning av GL07 E D Registrera bokföringsorder i Excelerator-mall E D Underlag Vertyper H0 Bfo utan elektronisk attest H1 Bfo med reversering utan elektronisk attest HA Momsredovisning (bokas från momsrapport) HR Reversering Huvudbok (genereras av systemet) HM Bokning mellan redovisningsenheter (SuperBFO från 900) HX Migrering från Horisonten (inläsning av CSF)

45 Bokföringsorder med elektronisk attest i Agresso
Huvudbok och gemensamt 2 Bokföringsorder med elektronisk attest i Agresso Registrera Bokföringsorder Ankomst W D E Attestera bokföringsorder W E Köra definitiv- bokföring (EI03) E D Underlag Bokföring i huvudboken Vertyper (anges vid registrering) Vertyper H2 Bfo med elektronisk attest (ankomst) H9 Bfo med reversering och elektronisk attest (definitiv) H3 Bfo med elektronisk attest (definitiv) Försystem Vertyp U* Inläsning och ev. rättning av GL07 E D Registrera bokföringsorder i Excelerator-mall E D Underlag Vertyper H2 Bfo med elekttronisk attest (ankomst) H8 Bfo med reversering och elektronisk attest (ankomst)

46 Omkontering och reversering
Huvudbok och gemensamt 2 Omkontering och reversering Funktionerna omkontering eller reversering används när en registrerad verifikation måste korrigeras. Möjlighet finns att rätta den felaktiga verifikationen i sin helhet eller per transaktionsrad. Omkontering används när man vill backa någon eller några transaktioner i en verifikation och ersätta dem med en eller flera andra*. Reversering innebär att en verifikation helt eller delvis (utpekade transaktioner) vänds bort med en ny verifikation. För att göra en reversering måste ett reverseringsförslag och en reverseringsbekräftelse köras innan reverseringen är färdig. Reverseringsverifikatet får till skillnad från omkontering en egen vertyp (HR för huvudbokstransaktioner och LR för leverantörsfaktura). En reversering går inte ut på attest. Både omkontering och reversering genererar en ny verifikation med den felaktiga verifikationen som underlag. Möjlighet finns att ta ut listor som visar vilka omkonteringar och reverseringar som gjorts för uppföljning i efterhand. *) Omkontering fungerar ej på transaktion som skapats maskinellt via trigger.

47 Bokföringsperiod i Agresso
Huvudbok och gemensamt 3 Bokföringsperiod i Agresso ”Period” ÅÅÅÅMM används för att avgöra i vilken period som verifikationen bokförs. Aktuell period sätts i systemet och är den period som ges som förslag. Utöver bokföringsperiod skall också verifikationsdatum/transaktionsdatum anges. Detta kan vara registreringsdag (förslag) men kan också vara annat datum, t ex betalningsdag vid dagrapport/kassarapport. ”Period” kan även sättas från försystemet vid integration av bokföringsorder (GL07). Verifikationsdatum blir det datum filen läses in i Agresso. Vid integration av försäljningsorder (LG04) blir transaktionsdatum det datum filen läses in i Agresso. Vid fakturering av försäljningsorder sätts sedan ”Period”, vilket blir bokföringsperioden för intäkten och utgångspunkt för periodisering (baserat på den nyckel som angetts).

48 Periodisering vid registrering av bokföringsorder direkt i Agresso
Huvudbok och gemensamt 3 Periodisering vid registrering av bokföringsorder direkt i Agresso Kontering av bokföringsorder i Agresso Period Vertyp Konto Ansvar Projekt Spec AktAO mm Motpart Startperiod Periodnyckel Belopp 201306 H0 1xxx Xxxx xxxx 6730 xxx 201307 3 9 000 Maskinell vändning av ursprungstrans Period Vertyp Konto Ansvar Projekt Spec AktAO mm Motpart Belopp 201306 H0 6730 Xxxx xxxx xxx 1712 9 000 Maskinell periodiseringsverifikation i period 7, 8 och 9 Period Vertyp Konto Ansvar Projekt Spec AktAO mm Motpart Belopp 201307 RJ 6730 Xxxx xxxx xxx 3 000 1712 Vilka konteringsbegrepp som visas avgörs av konteringsregel för kontot. I bokföringsorder via Excelerator hanteras startmånad på annat sätt genom att man anger hur många perioder framåt, från bokföringsperiod räknat, som periodiseringen ska starta.

49 Varje redovisningsenhet i balans
Huvudbok och gemensamt 3 Varje redovisningsenhet i balans Då varje förvaltning är en redovisningsenhet krävs att bokföringen alltid är i D/K balans inom varje redovisningsenhet I de fall bokföring måste ske mellan enheter ska konto 1999 användas för att skapa balans i respektive enhet. Konto 1999 ska alltid vara noll för staden som helhet. Bokningarna på ska skapas maskinellt och detta görs med hjälp av så kallade ”IC-triggers”. Tekniken bygger på att ursprungsbokningen sker i en redovisningsenhet och att denna i sin tur skapar en motsvarande bokning i en annan redovisningsenhet – baserat på information i ursprungstransaktionen. IC-triggern föregås i normalfallet av en TT-trigger som genererat den bokning på 1999 som ska skapa motbokningen. För att skapa dessa TT-trigger och IC-trigger måste de kombinationer av konto, koddelar, och vertyper etc., som ska generera triggrarna vara unika. Ex på när IC-triggers kommer att användas är vid betalning av kund- och leverantörsfakturor, när reskontrorna påverkas i resp. redovisningsenhet medan likviderna bokförs på bankkontot i redovisningsenhet 060 eller när kalkylmässiga räntor bokförs mellan investerande förvaltningar och finans. Denna teknik innebär att varje förvaltning kommer att ha en D/K-avstämd balansräkning, där skillnaden mellan övriga tillgångar och skulder/eget kapital kommer att finnas på konto 1999.

50 Huvudbok och gemensamt
3 Blanketter Följande blanketter kommer att finnas i nytt utseende, anpassade till Agresso. Blanketterna kommer att finnas tillgängliga i stadens ekonomihandbok (flik Agresso). Kundfakturaunderlag – för kundfaktura debet och för vanlig kredit. Ny kodsträng och övriga uppgifter krävs. Utbetalningsorder – för utbetalning till kund. Ny kodsträng och ev andra uppgifter Inbetalningsredovisning – För kontantkassor. Ny kodsträng. Bokföringsorder – när en bokföringsorder upprättas i organisationen och skickas till ekonomiavdelningen för inregistrering. Handkassa – hanteringen av handkassa förändras så till vida att utbetalningar nu skall göras via order/fakturering och kundreskontran. För att inte behöva fakturera en mängd rader på en faktura skall handkassan bokföras via en bokföringsorder och motbokas ett avräkningskonto varifrån sedan utbetalningen görs. Det kommer att finnas en artikel upplagd som motsvarar detta avräkningskonto.

51 Rapporter/utdata i huvudboken
Huvudbok och gemensamt 2 Rapporter/utdata i huvudboken Alla begrepp och begreppsvärden är sökbara. I Agresso finns både standardrapporter med fasta kolumner/inställningar och browserfrågor som medger en större flexibilitet vad gäller urval, kolumner och inställningar. Rapporter från start: Fråga verifikation Fråga saldotabell Resultaträkning Balansräkning Investeringsrapport Momsrapport Interna mellanhavanden

52 Huvudbok och gemensamt
3 Periodavslut Aktiviteter per dag, vilka återfinns under menyposten ”Egen meny” i Agresso. Menyposten är tillgänglig för lokala systemförvaltare huvudbok. Exempel på aktiviteter under Egen meny: Uppbokning av ankomstregistrerade leverantörsfakturor (SU14)* Momsrapportering Avstämning förvaltningsinternt Öppna kommuninterna poster Kontroll av signalerade poster (ska även ske löpande) Med mera… Periodstängning och öppning av ny period hanteras centralt för alla redovisningsenheter *) Ankomstregistrerade leverantörsfakturor kommer inte att bokföras skarpt i Agresso förrän vid månadsslutet (när Winst stängs för ankomstregistrering). Under perioden (innan månadsslutet) syns de som A-poster i Agresso.

53 Felrättning vid integration från försystem
Huvudbok och gemensamt 3 Felrättning vid integration från försystem Felrättning av felfällda filer från försystem hanteras per redovisningsenhet. Felaktigheter rättas som huvudregel i underhållsbilden i Agresso (undantag är bokföringsorder från Personec där felfällda transaktioner läses in och bokförs mot felkonto, varvid felen ska rättas i särskild ordning*). Rader kan felfällas som följd av att t.ex. obligatoriska uppgifter saknas eller inte kan identifieras, felaktiga be- greppsvärden, kontering som strider mot konteringsregel. Vid integration av försäljningsorder och kunduppgifter signaleras enbart felfällda rader. De som är godkända går in i Agresso (hela filen stoppas alltså inte). Vid integration av bokföringsorder (GL07) från försystem eller vid överföring från Excelerator-mall stoppas felaktiga verifikationer i sin helhet. Behörigheten till underhållsbilder för att utföra rättning är begränsad eftersom stadens alla felfällda rader ligger i samma tabell och misstag lätt kan göras. En viktig arbetsuppgift på förvaltningen blir att löpande kontrollera, följa upp och rätta felfällda transaktioner. *) I normalfallet ska balansposter bokas om i Agresso medan resterande poster rättas via ombokningsrutinen i Personec.

54 Övrigt 3 Attest Systemet kommer erbjuda elektronisk attest för försäljningsorder (kundfakturor och utbetalningar), bokföringsorder och ny/ändrad leverantör. Elektronisk attest finns även för attest av koncerninterna kunder (B/K/N/I) och utbetalningar med positivt belopp (dvs. negativa försäljningsordersorder som registrerats med felaktigt tecken). Utgångspunkten är att elektronisk attest i Agresso görs av ett fåtal personer (främst ekonomiavdelningarna) på förvaltningen. Attest utförs alltid i Agresso Web (ej i Desktop). Vid elektronisk attest i Agresso ska varje förvaltning definiera vilken av typ av attester som utförs (kontrollattest, beslutsattest eller betalningsattest) och vilka kontrollsteg som ingår i attesten. Attesten i Agresso bygger på att attestanterna tilldelas en viss attest-roll i systemet. De ”uppgifter” som ska attesteras styrs till personer med dessa roller. Agresso kan på olika sätt kontrollera att det är olika personer som registrerar och attesterar när så krävs (antingen genom rolltilldelning eller 2-stegs attestflöde). Attestfunktionalitet i Agresso är fokuserad på attest av varje enskild uppgift (ej massattest) och ger inte en överblick över ex. utförd faktureringen, varför utdata lämpar sig bättre för kontroller om faktura saknas eller har fel belopp. En ”arbetsledare” ska utses för varje attestant vid 2-stegsattest av bokföringsorder. Arbetsledaren hanterar ärenden som eskalerats i systemet då t.ex. attestanten och registreraren varit samma person. En användare kan inte vara arbetsledare för sig själv.

55 Order/Fakturering och kund

56 Modell, struktur, systemadm
Försäljningsorder och fakturering Order/Fakturering och kund 2 Försystem x Fsg.order LG04 Kunder CS15 Den stora mängden kundfakturor/ försälj-ningsorder görs i försystemet och läses sedan in i Agresso där fakturering sker. Externa fakturor går vidare till faktura-distributör för utskrift och utskick till kund medan interna fakturor går till Winst. Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Fakturering Faktura distributör Extern fakturor Pappers- faktura E- Swe- EDI Lokal utskrift Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- Anläggnings- Kund Artikel Order Orderregistrering. Winst Modell, struktur, systemadm Inköp Lev. fakturor Internfakturor

57 Fakturering & utbetkörning
Order/Fakturering och kund 2 Utbetalningar som ej går via Winst Utbetalningar som ej går via Winst hanteras oftast som en negativ försäljningsorder i Agresso via direktregistrering i Agresso eller via inläsning från försystem. Vid fakturering och utbetalningskörning genereras utbetalningsavier. I något fall finns även försystem som skickar utbetalningsfiler mot huvudbok och leverantörsreskontran. Försystem (något enstaka) x Bokföring GL07 AP Försystem x Fsg.order LG04 Kunder CS15 Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- Anläggnings- Lev. Order Artikel Kund Fakturering & utbetkörning Faktura distributör Utbet- avisering Orderregistrering Nordea Utbetalning

58 Fakturalayout Exempel
Order/Fakturering och kund 2 Fakturalayout Exempel Gemensamma layouter för kundfaktura (debet/kredit), utbetalningsavisering, påminnelse och räntefaktura. Flera fält i kundfakturan kan användas på olika sätt av förvaltningarna för att tillgodose lokala behov av information till kunderna. Ert ordernr:

59 Kunden till vilken fakturan eller utbetalningen skickas
Order/Fakturering och kund 3 Kunden till vilken fakturan eller utbetalningen skickas Kundnummer för externa kunder är 10 positioner och utgörs av ett löpnummer per redovisnings- enhet. Kundnumret inleds med en 8 och ”prefix”. Kund-id för koncerninterna kunder är B*/K*/Nxxx/I* (endast en förekomst av koncerninterna kunder). Organisationsnr/Personnr: Obligatorisk uppgift. Sökbart inom och mellan redovisningsenheter. Fiktiva personnummer ska ej användas. Om fältet är blankt anges ”saknad” i systemet. Vid skyddad identitet används det personnummer som Skattemyndigheten har utfärdat. Adress (c/o, lgh, gatuadress, postnummer ger automatiskt korrekt ortsnamn) Motpartskod – relation på kund För kunder som skall kunna ta emot utbetalning måste bankuppgifter finnas samt betalningsadress om den vanliga adressen är för lång för utbetalningskortet.

60 Order/Fakturering och kund
3 Kundgrupp En gruppering av kunder med samma fordringskonto, betalningsvillkor och kravkod Betalningsvillkor (ex. 30 dgr netto) Kravkod anger regler för påminnelser, räntefakturering och inkasso Varje försystem har sin egen kundgrupp för externa kunder (10-99) Koncerninterna kunder grupperas i fyra kundgrupper (B1, K1, N1, I1). Skall användas både för försystem och manuell fakturering För manuell fakturering finns minst en kundgrupp i varje redovisningsenhet men flera kan skapas (MA- M9) – varje förvaltning avgör behov. Betalningsvillkor, kravkod och betalningsmetod kan ändras på kundnivå (även för integrationer).

61 Tekniker för manuell försäljningsorder
Order/Fakturering och kund 3 Tekniker för manuell försäljningsorder Vanlig försäljningsorder – alla uppgifter fylls i, ny order skapas varje gång, går att kopiera från tidigare. Mallorder – mallar skapas för olika typer av fakturering som innehåller artiklar, huvudtext och bottentext - vid fakturering väljs kund och sedan tillämpas mallorderns uppgifter – vilka kan ändras vid behov. Massförsäljningsorder – exakt likadan faktura till många kunder. Urval av kunder baseras på enstaka kundnummer (eller en gruppering via relation) Abonnemangsorder – återkommande fakturering med fast frekvens av samma belopp till en kund, t ex hyra eller serviceavtal. Abonnemangsorder går enbart att hantera i Desktop (ej i web). Vid integration skapas alltid ”vanlig försäljningsorder”.

62 Inriktning attest försäljningsorder
Order/Fakturering och kund 3 Inriktning attest försäljningsorder Elektronisk attest sker av försäljningsorder – ej av faktura. Elektronisk attest i Agresso kommer inte att göras av alla försäljningsordrar. Ingen elektronisk attest av nyupplägg/ändring av kunduppgift. Färre användare i Agresso varför elektronisk attest i Agresso mer har karaktär av kontrollattest (alltså ej samma attestanter som i Winst). Rätten att attestera i Agresso styrs ej utifrån kontering i försäljningsorder utan tillhörighet till attest-rollen OFATT. Alla användare i förvaltningen som är kopplade rollen OFATT kan attestera i Agresso. I större förvaltningar kan det finnas en OFATT-roll per sektor. Samtliga användare med samma OFATT-roll ser alla ordrar som skall attesteras i Agresso.

63 Ordernummertyper vid försäljningsorder
Order/Fakturering och kund 2 Ordernummertyper vid försäljningsorder Ordernummertyp är en 2-ställig kod som bl a används för att styra hur en order ska hanteras; hur den ska skrivas ut, om elektronisk attest ska göras, om ordern ska bli en faktura/kreditfaktura eller en utbetalning. Ordernummertyp anges vid registrering av försäljningsorder eller via försystemet vid integration av försäljningsorder (LG04). Vid fakturering i Agresso översätts ”Ordernummertyp” till ”Verifikationstyp”. Varje försystem som skickar försäljningsorder (LG04) har sin egen ordernummertyp. För dessa sker normalt ingen elektronisk attest och utskrift via Strålfors. Ordernrtyp Kategori Hantering Verifikationstyp AA Debet/kredit Ingen attest, skrivs ut av Strålfors BD AB Attest, skrivs ut av Strålfors AC Ingen attest, skrivs ut lokalt AD Attest, skrivs ut lokalt AG Utbetalning DB F*/G* Försystem En ordernummertyp per försystem

64 Artikelgrupp och artikel
Order/Fakturering och kund 2 Artikelgrupp och artikel Artikelgrupp – samling artiklar med likartad behandling (intäktskonto och momskod) I Agresso är artikelgrupperna namngivna som en kombination av konton och momssats. Ex innebär konto 3011 med 25% moms. Till varje artikelgrupp kan en eller flera artiklar kopplas. Artikelgrupperna är gemensamma för staden men endast de som förvaltningen valt ut visas i resp. redovisningsenhet. De kombinationer som använts under 2013 finns upplagda från start – nya behov kan dyka upp under arbetet med integrationer och förberedelser för manuell fakturering. Artikel – används vid fakturering och motsvarar en fakturarad. Artikelkod (anges på försäljningsorder) och benämning (visas på fakturan) Artikeln ärver konto och momskod från artikelgruppen – övrig kontering kan kopplas till artikel Enhet - obligatorisk (en eller flera) Pris – ej obligatoriskt Vid start finns en artikel per artikelgrupp upplagd med samma kod/benämning som artikelgruppen, dvs Förvaltningarna kan vid behov lägga till egna artiklar i dessa.

65 Utskrift av fakturor Extern utskrift
Order/Fakturering och kund 2 Utskrift av fakturor Extern utskrift Samtliga fakturor från försystem kommer som tidigare att skrivas ut via externt printhus (för närvarande Strålfors). Debetfakturor kommer att skrivas ut med en inbetalningsavi medan kreditfakturor och utbetalningsaviseringar kommer att skrivas ut utan avi. Påminnelser och dröjsmålsfakturor kommer också att skrivas ut av printerföretaget. Dessa kommer också att innehålla inbetalningsavier. Intern utskrift Manuellt skapade fakturor kommer i undantagsfall att kunna skrivas ut lokalt (viss ordernummer- typ), men utan inbetalningsavi. Detta kan vara tillämpligt när bilagor ska bifogas med en faktura. Det kommer även att vara möjligt att välja lokal utskrift för enstaka fakturor från försystem. Dokumentarkiv Alla fakturor både externa och interna som skapas i Agresso (debet-, kredit-, dröjsmålsräntefakturor och utbetalningsaviseringar) kommer att sparas i ett dokumentarkiv. Påminnelser som skrivs ut externt, kommer inte att kunna visas i dokumentarkivet.

66 Symboler processer Symbol Betydelse i detta sammanhang
Order/Fakturering och kund 2 Symboler processer Symbol Betydelse i detta sammanhang Input (underlag, försystem), lagring (kundregister), output (kundfaktura, utbetalningsavisering) Aktivitet i Agresso. Rapport, browser-fråga i Agresso. Användargränssnitt; Web (W) och/eller Desktop (D). Vem som utför aktiviteten; Ekonomiavdelningen (E) och/eller verksamheten (V). Intraservice (IS). W D E V IS

67 Kundfakturor (D/K) utan elektronisk attest
Order/Fakturering och kund 2 Kundfakturor (D/K) utan elektronisk attest W D Registrera ny/ändrad kund Kundregister Kundgrupp Mx E V Underlag Utskrivna/ Bokförda fakturor W D D Registrera försäljningsorder Fakturera försäljningsorder Leverantörs- faktura i Winst E V Rapporter för kontroll E Rapporter för kontroll Ordernummertyp AA, AC D Inläsning och ev. rättning av försäljningsorder Försystem E D Inläsning och ev. rättning av kunduppgifter Kundregister Kundgrupp 10-99 E

68 Kundfakturor (D/K) med elektronisk attest
Order/Fakturering och kund 2 Kundfakturor (D/K) med elektronisk attest W D Registrera ny/ändrad kund Kundregister Kundgrupp MA E V Underlag Utskrivna/ Bokförda fakturor W D W D Registrera försäljningsorder Attest av försäljningsorder (1-steg) Fakturera försäljningsorder Leverantörs- faktura i Winst E V Rapporter för kontroll E V* E Rapporter för kontroll Ordernummertyp AB, AD D Inläsning och ev. rättning av försäljningsorder E Försystem D Inläsning och ev. rättning av kunduppgifter Kundregister Kundgrupp 10-99 E

69 Utbetalningar till kund utan elektronisk attest
Order/Fakturering och kund 2 Utbetalningar till kund utan elektronisk attest W D Registrera ny/ändrad kund Kundregister Kundgrupp MA Uppföljning av ändrade kunduppgifter* E V E W D Underlag Kontrollera kunduppgifter Utskrivna/Bokförda Utbetalnings- aviseringar E V W D D Registrera försäljningsorder Fakturera försäljningsorder E V Rapporter för kontroll E Rapporter för kontroll D D Ordernummertyp AG Betalnings- förslag (IP) Betalnings- förslag och bekräftelse (AG) D E IS Inläsning och ev. rättning av försäljningsorder Rapporter för kontroll D Betalnings- bekräftelse (IP) E Försystem E D D W D Betalningsfiler till bank/BGC Inläsning och ev. rättning av kunduppgifter Registrera kontonr och betalnings- adress Kundregister Kundgrupp 10-99 Uppföljning av ändrade kunduppgifter* IS E E V E *) Kontonr och namn

70 Utbetalningar till kund med elektronisk attest
Order/Fakturering och kund 2 Utbetalningar till kund med elektronisk attest Registrera ny/ändrad kund W D E V Kundregister Kundgrupp MA Uppföljning av ändrade kunduppgifter** E Kontrollera kunduppgifter E V W D Underlag Utskrivna/Bokförda Utbetalnings- aviseringar Rapporter för kontroll Registrera försäljningsorder W D E V Ordernummertyp AG Attest av försäljningsorder (1-steg) W E V* Rapporter för kontroll Fakturera försäljningsorder D E D D Betalnings- förslag (IP) Betalnings- förslag och bekräftelse (AG) Inläsning och ev. rättning av försäljningsorder E D E IS Rapporter för kontroll D Betalnings- bekräftelse (IP) Försystem E Inläsning och ev. rättning av kunduppgifter E D Registrera kontonr och betalnings- adress E V W D D Kundregister Kundgrupp 10-99 Uppföljning av ändrade kunduppgifter** E Betalningsfiler till bank/BGC IS **) Kontonr och namn

71 Utbetalning av kreditfakturor/ kundtillgodohavanden
Order/Fakturering och kund 3 Utbetalning av kreditfakturor/ kundtillgodohavanden W D Kontrollera och ev. registrera ändrad Kunduppg. Kundregister Kundgrupp MA Kundgrupp 10-99 Uppföljning av ändrade kunduppgifter* E V E Underlag D D D D Betalnings- förslag (IP) Betalnings- bekräftelse (IP) Betalnings- förslag och bekräftelse (AG) Betalningsfiler till bank E E IS IS *) Kontonr och namn

72 Förvaltningsintern och kommunintern försäljning
Order/Fakturering och kund 3 Förvaltningsintern och kommunintern försäljning Internt köp/sälj till annan nämnd eller inom förvaltningen skickas från försystem som en vanlig försäljningsorder (LG04) eller registreras som manuell försäljningsorder i Agresso. Interna kunder och leverantör läggs upp och underhålls av central systemförvaltning, Intraservice. I samband med faktureringen av försäljningsorder mot N- och I-kunder kommer en kundfaktura att skapas och skickas till Winst där den hanteras som vanlig leverantörsfaktura samtidigt som kundfordran och intäkt bokförs. Viktigt att alla interna fakturor innehåller uppgift om mottagarreferens i fältet för ”Extern referens” för att fakturan ska skickas till rätt granskare i Winst. Det är en uppgift på kunden som gör att fakturan skickas till Winst och inte till Strålfors. Faktureringen av försäljningsorder mot I-kund Varje förvaltning avgör om det ska förekomma köp/sälj inom förvaltningen. Varje förvaltning ska då även bestämma vilka interna kunder och leverantörer som förvaltningen har behov av. Dessa måste läggas upp som kunder och leverantörer i Agresso. De interna kunderna (N och I) kommer att ha betalningsmetod IN vilket gör att fakturorna kommer att matchas mot varandra (när leverantörsfakturan är klar i Winst). B/K kunder har inte betalningsmetod IN och kommer att betalas som externa fakturor.

73 Leverantör

74 Leverantörsreskontra
2 Leverantörsreskontra Leverantörsregistret är gemensamt för samtliga redovisningsenheter. Alla förvaltningar har tittarbehörighet till leverantörsregistret via leverantörscentralen. Registret underhålls av Ekonomienheten, Intraservice, som utför registrering och attest vid nyupplägg och ändring av leverantör. Vid behov av ny/ändrad leverantör ska förvaltningen skicka supportärende till Servicedesk. De flesta uppläggen/ändringarna kommer dock att inkomma via skanningen av leverantörsfakturor. Vid utbetalning till leverantör ska förvaltningen skicka ett utbetal- ningsuppdrag med leverantörsuppgifter till Servicedesk för inskan- ning. Hantering sker via Winst på samma sätt som för en leveran- törsfaktura. Detta sätt skall även nyttjas vid delbetalning av faktura. Utbetalning till kund som görs via kundreskontran skickas efter den utbetalningskörning som görs av förvaltningen. Utbetalningarna skickas i samma fil som leverantörsutbetalningar (hanteras av Ekonomienheten). Ekonomienheten svarar även för all övrig utbetalningsadmin- istration (inkl. utbetalningskörning av AG, utbetalningsförslag och bekräftelse, betalningsfil, signering i bank, återredovisning mm.)

75 Symboler processer Symbol Betydelse i detta sammanhang
Leverantör 3 Symboler processer Symbol Betydelse i detta sammanhang Input (underlag, försystem), lagring (kundregister), output (kundfaktura, utbetalningsavisering) Aktivitet i Agresso. Rapport, browser-fråga i Agresso. Användargränssnitt; Web (W) och/eller Desktop (D). Vem som utför aktiviteten; Ekonomiavdelningen (E) och/eller verksamheten (V). Intraservice (IS). W D E V IS

76 Lokal leverantörsfakturaadministration
3 Lokal leverantörsfakturaadministration D Parkera faktura** Underhålla öppna poster E Leverantörs- faktura uppdateras D E Ändra förfallodag* Slutkonterade, ej betalda leverantörsfakturor som ej är med i betalningsförslag E D Reversering av leverantörs- faktura Reversera faktura (makulering)*** Leverantörs- faktura och huvud- bok uppdateras E E W D W D Sök information Öppna historiska poster Levcentralen E V E V *) Detta kan göras i Agresso från det att fakturan är Klar i Winst till dess att fakturan finns med på ett betalningsförslag. Ändringar före detta skall hanteras i Winst. **) Innebär att fakturan inte kommer att betalas. När status åter ändras till N (normal) kommer fakturan att gå med till betalning. När en faktura parkeras skall en orsakskod anges. ***) Innebär att fakturan bokas bort med omvänd kontering. Reversering av faktura kan göras av lokal systemförvaltare eller motsvarande på förvaltningen. Reversering ska göras om fakturan aldrig ska betalas. Det är viktigt att skriva en kommentar i Winst om detta görs eftersom det i Winst kommer att se ut som om fakturan har gått till betalning.

77 Anläggning

78 Anläggningsreskontra
2 Anläggningsreskontra Anläggningsregister (AT) kommer enbart finnas för investerande förvaltningar (och även för ett fåtal ytterligare fackförvaltningar med passiva anläggningsregister). I AT är alla anläggningar kopplade till anläggningsgrupper, vilka är gemensamma för samtliga investerande förvaltningar. Till anläggningsgrupperna kopplas konto samt förslag till avskrivningstid. Kontot ärvs alltid till anläggningarna i anläggningsgruppen medan avskrivningstiden kan ändras på respektive anläggning. Under tiden som ett investeringsprojekt är pågående finns det i huvudboken som ett investeringsprojekt. Inte förrän projektet aktiveras kommer det att uppdateras i anläggningsregistret. Vid aktivering kommer transaktionerna på pågåendekontot att aktiveras, dvs. vändas bort från pågåendekontot och istället bokföras som anläggningstillgångar på kontona för anskaffningsvärden. Det är möjligt att delaktivera ett projekt genom att göra ytterligare urval på koddelarna Konto, AktAO och Objekt.

79 Anläggningsreskontra - fortsättning 1/2
3 Anläggningsreskontra - fortsättning 1/2 När en anläggning aktiveras kopplas den alltid till en anläggningsgrupp och kommer att bokföras på det konto som gäller för anläggningsgruppen (för anskaffningsvärdet). På anläggningen kommer dessutom koddelarna Ansvar, AktAO och Objekt komma att finnas angivna som förslag, baserat på konteringen på de transaktioner som aktiverats. Den kontering som anges på anläggningen är den kontering som kommer att användas för att kontera händelser som skapas i anläggningsregistret (avskrivningar, bokfört värde etc) – så till vida konteringsregeln inte säger något annat. För varje typ av anläggning finns det endast två konton i balansräkningen – Anskaffningsvärden (1011 etc.) och Ackumulerade avskrivningar (1019 etc.). På resultaträkningen finns som tidigare konton för avskrivningar, nedskrivningar, försäljningar, bokförda värden och räntor. Kontona som används för anläggningstransaktioner är gemensamma för samtliga förvaltningar men förvaltningarna kan välja vilka koddelar utöver konto som ska användas för kontering av händelserna ovan och kan också med hjälp av konteringsregler välja att bokföra på en annan nivå än den ursprungliga konteringen av utgiften för investeringen, t ex ange ett fast ansvar för alla avskrivningar etc. I normalfallet ska det aldrig göras manuella bokföringstransaktioner på de konton som är kopplade till AT.

80 Anläggningsreskontra - fortsättning 2/2
3 Anläggningsreskontra - fortsättning 2/2 Motpart kommer alltid att sättas till XXXX för transaktioner på pågående projekt och på de transaktioner som skapas från anläggningsregistret. I de fall försäljningar sker till ett koncernföretag ska en ombokning av bokfört värde (RR) till korrekt motpart ske (detaljerna för detta är ännu inte fastställda). Vid försäljning av en anläggning kommer försäljningsintäkten att bokföras manuellt och ska läggas in i AT. Från AT kommer då transaktioner som motsvarar bokfört värde att skapas (försäljningsintäkt och reavinst/förlust) i huvudboken. Motpart ska anges (för intern eliminering). Om försäljningen har inneburit en realisationsförlust måste försäljningsinkomsten och bokförda värden flyttas manuellt från konton i klass 3 till konton i klass 7.