Presentation laddar. Vänta.

Presentation laddar. Vänta.

- 1 - Utbildningsmaterial Modell och Process i Agresso Version B.

Liknande presentationer


En presentation över ämnet: "- 1 - Utbildningsmaterial Modell och Process i Agresso Version B."— Presentationens avskrift:

1 - 1 - Utbildningsmaterial Modell och Process i Agresso Version B

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

3 - 3 - Inledning

4 - 4 -  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. Inledning 1 Om utbildningsmaterialet  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 Målgrupp: Chefer Målgrupp: Ekonomer och administratörer Målgrupp: Redovisningsekonomer

5 - 5 - Ö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 Övergripande för samtliga utbildningstillfällenNEKK_EKH_Utformningsprinciper.doc Grundkurs 1 - Modell och process i AgressoNEKK_Utbildningsmaterial_Grundkurs 1.ppt (detta dokument) Grundkurs 2 - Systemutbildning i AgressoNEKK_Systemutbildning_Grundkurs 2.doc Fördjupningskurs Lokal systemadministration inkl. huvudbokNEKK_Utformningsprinciper_Fördjupning_Lokal systemadministration.doc NEKK_Systemutbildning_Fördjupning_Lokal systemadministration.doc Fördjupningskurs Order/fakturering och kundreskontraNEKK_Utformningsprinciper_Fördjupning_Order fakturering och utbetalningar.doc NEKK_Systemutbildning_Fördjupning_Order fakturering och kundreskontra.doc Fördjupningskurs AnläggningNEKK_Utformningsprinciper_Fördjupning_Anläggning.doc NEKK_Systemutbildning_Fördjupning_Anläggning.doc Dokument Inledning 3

6 Innehållsförteckning Inledning 3 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……..………………… SidAvsnitt 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……..……………………………..………… SidAvsnitt

7 - 7 - Om det nya ekonomisystemet (Agresso)

8 - 8 -  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 2012 till våren Avtal tecknat med Agresso sommaren  Utrullning hösten 2014 till våren 2015 i fyra olika utrullningsomgångar. Projektavslut 30 juni  Möjlighet för bolagen att använda de avtal som upphandlats av NEKK. Ett nytt ekonomisystem 1 Bakgrunden till ett nytt ekonomisystem

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

10 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. 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 medarbetare System Nekksus (2013) Delprojekt 1 Ekonomisk styrning och uppföljning av verksamheten Chefer och ekonomer 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 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 medarbetare System Horisonten ersätts med system Agresso (2015) Delprojekt 3 Ekonomihantering för effektiv ekonomi- administration medarbetare System Horisonten ersätts med system Agresso (2015) Konceptmålbild Ett nytt ekonomisystem 1

11  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. Ett nytt ekonomisystem 1 Skillnader med nytt ekonomisystem

12  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. Ett nytt ekonomisystem 1 Skillnader med nytt ekonomisystem

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

14 För åtkomst ska användaren…  Ha ett GBG3000-konto  Vara upplagd som användare i Agresso (beställs på Beställningsportalen). Inloggning och åtkomst till Agresso mm Ett nytt ekonomisystem 2 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…  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). 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. Web https://agresso.goteborg.se/agrprod Desktop https://agressoklient.goteborg.se

15 Ekonomimodell

16 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. Ekonomimodell 1

17 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 7 pos Objekt Friv 12 pos Verk Obl kkl pos Motpart Obl 4 pos Projekt Obl/Friv 1+6 pos Ekonomimodell 1 Ekonomimodellens konteringsbegrepp

18 Konteringsbegrepp och skillnader Konto Obl 4 pos Ansvar Obl 8 pos Spec (Anl) Obl/Friv 7 pos Aktao Friv 7 pos Objekt Friv 12 pos Verk Obl kkl pos Motpart Obl 4 pos Projekt Obl/Friv 1+6 pos 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. 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. 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). 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. 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. 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). Ekonomimodell 3

19  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.) Relationer och flexibla fält Ekonomimodell 3 *) Motpart och factoringbolag syns ej i förvaltningens redovisningsenhet.

20  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). Konteringsregler Ekonomimodell 2

21 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. Konteringsregler – exempel Ekonomimodell 3

22  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. Investeringsredovisning Ekonomimodell 3

23 Systemstruktur

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

25 Ö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. Systemstruktur 2

26 Ö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. Systemstruktur 2

27 Övergripande systemstruktur Koncern- företag (KC01) Förvaltningar Bolag  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) Systemstruktur 2

28 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. Systemstruktur 3

29 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. Systemstruktur 3

30 PROJEKTET Användargränssnitt DESKTOP OCH WEB “Large-användare” Använder ekonomisystemet dagligen i stor omfattning Redovisningsekonomer, centrala systemförvaltare, koncernredovisning och centrala/lokala reskontraförvaltare (ekonomienheten Intraservice). Använder ekonomisystemet för registrering av bokföringsorder, kundfakturor och/eller utbetalningar samt utdata Verksamhetsekonomer, fakturahandläggare, orderregistrerare och ekonomiadministratörer. Använder ekonomisystemet enbart för utdata och attest av bokföringsorder, kundfakturor och/eller utbetalningar Sällananvändare, enhetschefer och administratörer. 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. WEB “Medium-användare” WEB “Small-användare” Agresso Systemstruktur 2 *) 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 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. 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) … Exempel på funktioner i Web: Systemstruktur 3

32 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. 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 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 … Exempel på funktioner i Desktop: Systemstruktur

33 Huvudbok och gemensamt

34 Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- reskontra Anläggnings- reskontra BFO Försystem x x x Bokföring GL07 Huvudbok och gemensamt 2 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. Excelerator Bokförings- mall Bokföring GL07 Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Bokföring

35  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. Bokföringsorder Huvudbok och gemensamt 2

36  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. Bokföringsorder Huvudbok och gemensamt 2

37  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. Verifikationstyper och verifikations- nummerserier Huvudbok och gemensamt 3

38 VertypBenämningVernummer- serie HXMigrerade saldon från Horisonten19nnnnnnnn H0Bokföringsorder utan attest10nnnnnnnn H1Vändas utan attest10nnnnnnnn H2Bokföringsorder med attest - ankomst11nnnnnnnn H3Bokföringsorder med attest - definitiv11nnnnnnnn H8Vändas med attest – ankomst11nnnnnnnn H9Vändas med attest – definitiv11nnnnnnnn HRReversering Huvudbok11nnnnnnnn HMBokning mellan redovisningsenheter (postback)12nnnnnnnn E*, F*,G*Fakturering från försystem (samma som ordernummertyp)7xxxnnnnnnn C*Utbetalningar (FO) från försystem7xxxnnnnnnn BDManuell fakturering (ordernummertyp AA, AB, AC o AD)7xxxnnnnnnn DBManuella utbetalningar (ordernummertyp AG)7xxxnnnnnnn LA, LD, LMVerifikationer från Winst Ankomst/definitiv/Makuleringarxxxnnnnnnnn O*Betalningar kundreskontran31nnnnnnnn U*Import GL07 och GL07-AP(Personec, Utbet Rix, Pluto osv)19nnnnnnnn Verifikationstyper och verifikations- nummerserier (exempel) Den aktuella och fullständiga listan finns alltid i Agresso. Huvudbok och gemensamt 3

39 Verifikationstyper vid bokföringsorder Bokföringsorder i Desktop 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. Huvudbok och gemensamt 3 H0 H1 H2 H8

40 Verifikationstyper vid bokföringsorder Bokföringsorder i Web 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. Huvudbok och gemensamt 3 H0 H1 H2 H8

41 Verifikationstyper vid bokföringsorder Bokföringsorder via Excelerator-mall 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. Huvudbok och gemensamt 3 H0 H1 H2 H8 HM

42  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. Momskod Huvudbok och gemensamt 2

43 SymbolBetydelse 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). WD EVIS Symboler processer Huvudbok och gemensamt 2

44 Bokföringsorder utan elektronisk attest i Agresso Underlag Bokföring i huvudboken Försystem Registrera Bokföringsorder Verifikationsregistrering WD E Inläsning och ev. rättning av GL07 E D Registrera bokföringsorder i Excelerator-mall E D Underlag H0Bfo utan elektronisk attest – Web eller Desktop H1Bfo med reversering utan elektronisk attest – endast i Desktop H0Bfo utan elektronisk attest H1Bfo med reversering utan elektronisk attest HAMomsredovisning (bokas från momsrapport) HRReversering Huvudbok (genereras av systemet) HMBokning mellan redovisningsenheter (SuperBFO från 900) HXMigrering från Horisonten (inläsning av CSF) U*UA Personec Vertyper (anges vid registrering) Vertyper Huvudbok och gemensamt 2

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

46 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. Huvudbok och gemensamt 2 *) Omkontering fungerar ej på transaktion som skapats maskinellt via trigger.

47  ”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. Bokföringsperiod i Agresso Huvudbok och gemensamt 3  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 PeriodVertypKontoAnsvarProjektSpecAktAO mmMotpartStartperiodPeriodnyckelBelopp H01xxxXxxxxxxx H06730xxxx xxxxxxx Kontering av bokföringsorder i Agresso PeriodVertypKontoAnsvarProjektSpecAktAO mmMotpartBelopp H06730Xxxxxxxxxxxxxxx H01712xxxx xxxxxxx Maskinell vändning av ursprungstrans PeriodVertypKontoAnsvarProjektSpecAktAO mm Motpart Belopp RJ6730Xxxxxxxxxxxxxxx RJ1712xxxx xxxxxxx Maskinell periodiseringsverifikation i period 7, 8 och 9 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. Periodisering vid registrering av bokföringsorder direkt i Agresso Huvudbok och gemensamt 3

49  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å 1999 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 Varje redovisningsenhet i balans Huvudbok och gemensamt 3

50 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. Huvudbok och gemensamt 3

51  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 Rapporter/utdata i huvudboken Huvudbok och gemensamt 2

52  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 Periodavslut Huvudbok och gemensamt 3 *) 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 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. Felrättning vid integration från försystem Huvudbok och gemensamt 3 *) I normalfallet ska balansposter bokas om i Agresso medan resterande poster rättas via ombokningsrutinen i Personec.

54  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. Attest Övrigt 3

55 Order/Fakturering och kund

56 Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- reskontra Anläggnings- reskontra Kund ArtikelOrder Försystem x x x Fsg.order LG04 Kunder CS15 Winst Modell, struktur, systemadm Inköp Lev. fakturor Internfakturor Försäljningsorder och fakturering Orderregistrering. Fakturering Faktura distributör Extern fakturor Pappers- faktura E- faktura Swe- Faktura EDI Pappers- faktura Lokal utskrift 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…. Order/Fakturering och kund 2

57 Agresso Modell, struktur, systemadm Leverantörs- reskontra Huvudbok Order/ fakturering Kund- reskontra Anläggnings- reskontra Lev. OrderArtikel Kund Utbetalningar som ej går via Winst Orderregistrering Försystem x x x Fsg.order LG04 Kunder CS15 Fakturering & utbetkörning Faktura distributör Utbet- avisering Försystem (något enstaka) x x x Bokföring GL07 AP Nordea Utbetalning 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. Bilden innehåller animationer; visa bilden i bildspelsläge så blir det något enklare…. Order/Fakturering och kund

58 Ert ordernr: Fakturalayout Exempel Order/Fakturering och kund 2  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.

59 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. Order/Fakturering och kund 3

60  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). Kundgrupp Order/Fakturering och kund 3

61 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”. Order/Fakturering och kund 3

62  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. Inriktning attest försäljningsorder Order/Fakturering och kund 3

63 OrdernrtypKategoriHanteringVerifikationstyp AADebet/kreditIngen attest, skrivs ut av StrålforsBD ABDebet/kreditAttest, skrivs ut av StrålforsBD ACDebet/kreditIngen attest, skrivs ut lokaltBD ADDebet/kreditAttest, skrivs ut lokaltBD AGUtbetalningAttest, skrivs ut av StrålforsDB F*/G*FörsystemEn ordernummertyp per försystemF*/G* Ordernummertyper vid försäljningsorder Order/Fakturering och kund 2  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.

64 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. Order/Fakturering och kund 2

65 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. Utskrift av fakturor Order/Fakturering och kund 2

66 SymbolBetydelse 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). WD EVIS Symboler processer Order/Fakturering och kund 2

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

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

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

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

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

72  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. Förvaltningsintern och kommunintern försäljning Order/Fakturering och kund 3

73 Leverantör

74  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.) Leverantörsreskontra Leverantör 2

75 SymbolBetydelse 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). WD EVIS Symboler processer Leverantör 3

76 Öppna historiska poster Levcentralen Lokal leverantörsfakturaadministration Parkera faktura** Ändra förfallodag* Sök information Leverantörs- faktura uppdateras Reversera faktura (makulering)*** Leverantörs- faktura och huvud- bok uppdateras Underhålla öppna poster D D D DW Reversering av leverantörs- faktura E E EV E E E EV Slutkonterade, ej betalda leverantörsfakturor som ej är med i betalningsförslag *) 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. Leverantör 3 DW

77 Anläggning

78  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. Anläggningsreskontra Anläggning 2

79  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. Anläggningsreskontra - fortsättning 1/2 Anläggning 3

80  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. Anläggningsreskontra - fortsättning 2/2 Anläggning 3


Ladda ner ppt "- 1 - Utbildningsmaterial Modell och Process i Agresso Version B."

Liknande presentationer


Google-annonser