Transcript Utformningsprinciper Sammanfattande beskrivning av

Utformningsprinciper
Sammanfattande beskrivning av
tillämpning och konfiguration
i
Agresso
för
Göteborgs Stad
Version E
2014-11-09
2 (42)
Innehåll
1 Inledning .......................................................................................................................................... 4 1.1 Referenser ....................................................................................................................................... 4 2 Övergripande .................................................................................................................................. 5 2.1 2.2 2.3 2.4 2.5 En gemensam lösning ...................................................................................................................... 5 Redovisningsenhet ........................................................................................................................... 5 Modulstruktur ................................................................................................................................... 5 Typer av integrationer ...................................................................................................................... 6 Skillnad mot idag (förvaltningsspecifika integrationer) ..................................................................... 7 3 Kodsträng och konteringsregler ................................................................................................... 9 3.1 3.2 3.3 Kodsträng ......................................................................................................................................... 9 Konteringsregler ............................................................................................................................... 9 Relationer ....................................................................................................................................... 11 4 Moms ............................................................................................................................................. 12 4.1 4.2 4.3 Momskod ........................................................................................................................................ 12 Momssystem .................................................................................................................................. 12 Momsrapportering .......................................................................................................................... 12 5 Övriga viktiga begrepp i huvudboken ........................................................................................ 14 5.1 5.2 5.3 5.4 5.5 5.6 Verifikationstyp och Verifikationsnummer ...................................................................................... 14 Bokföringsperiod ÅÅÅÅMM ............................................................................................................ 14 Verifikationsdatum ÅÅÅÅMMDD .................................................................................................... 14 Transaktionstext ............................................................................................................................. 14 Leverantörs-id/Kund-id ................................................................................................................... 15 Extern transaktionskälla ................................................................................................................. 15 6 Periodisering ................................................................................................................................. 16 6.1 6.2 Periodiseringsnyckel ...................................................................................................................... 16 Startperiod ...................................................................................................................................... 17 7 Försäljningsorder blir kundfaktura ............................................................................................. 18 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 Manuell fakturering (ersätter WebbFaktura) .................................................................................. 18 Kundgrupp/kund ............................................................................................................................. 18 Externa kunder ............................................................................................................................... 20 Interna kunder (K/B/N/I-kunder) ..................................................................................................... 20 Namn och Adress ........................................................................................................................... 21 Kunder (betalningsmottagare) för utbetalning ................................................................................ 22 Betalningsvillkor, kravkod och betalningsmetod ............................................................................ 22 Ordernummertyp ............................................................................................................................ 22 Artikel/Artikelgrupp ......................................................................................................................... 23 Utgående moms ............................................................................................................................. 24 Fakturering skapar debet- och kreditfakturor ................................................................................. 24 Förvaltningsintern och kommunintern försäljning ........................................................................... 25 Sammanfattning - skillnader mellan LG04 till interna och externa kunder ..................................... 26 Utbetalningar (vid sidan av Winst) ................................................................................................. 26 Utskrift av fakturor mm ................................................................................................................... 27 Påminnelse och Dröjsmålsräntedebitering ..................................................................................... 27 Osäkra kundfordringar och konstaterade kundförluster ................................................................. 28 8 Gemensam fakturalayout ............................................................................................................. 29 8.1 8.2 8.3 Fakturahuvud ................................................................................................................................. 29 Fakturaspecifikation ....................................................................................................................... 30 Fakturafot ....................................................................................................................................... 30 9 Bokföringsorder ............................................................................................................................ 31 9.1 Moms ............................................................................................................................................. 31 3 (42)
9.2 9.3 9.4 9.5 Utbetalningar till företag och organisationer (GL07-AP). ............................................................... 31 Leverantörer/betalningsmottagare ................................................................................................. 32 Kundfakturor som inte har skapats i Agresso ................................................................................ 32 GL07 – Ifyllnadsanvisningar ........................................................................................................... 32 10 Investeringsredovisning och anläggningsreskontra ................................................................ 35 10.1 10.2 Investeringsredovisning ................................................................................................................. 35 Anläggningsreskontra .................................................................................................................... 35 11 Varje redovisningsenhet i balans ................................................................................................ 37 12 Kontroll och Attest........................................................................................................................ 38 12.1 12.2 12.3 Processer som stöder god intern kontroll ....................................................................................... 38 Attest i Winst .................................................................................................................................. 38 Attest i Agresso .............................................................................................................................. 38 13 Felrättning ..................................................................................................................................... 40 14 Ändringar/tillägg ........................................................................................................................... 41 4 (42)
1 Inledning
Detta dokument innehåller en övergripande beskrivning av de viktigaste modellfrågorna i Agresso vad gäller främst
huvudbok, order och fakturering samt kundreskontra. Dokument ska ge en grundläggande förståelse för hur
Agresso kommer att fungera på en övergripande nivå och mer detaljerat vad gäller funktioner som berör
integrationerna till och från Agresso.
Dokumentet och är under utrullningen av Agresso främst riktat till lokala projektledare samt övriga medlemmar i den
lokala projektgruppen för respektive förvaltning. Dessa har en viktig roll att driva de lokala förberedelserna och
utforma de lokala processerna utifrån de ramar som ges av den gemensamma uppsättningen av Agresso. Den
lokala projektgruppen har även uppdraget att utforma, utveckla och testa eventuella förvaltningsspecifika
integrationer till och från Agresso.
Som hjälp för utformningen av de lokala processerna kommer ett mer detaljerat material tas fram, vilket kommer att
publiceras senare under hösten 2014.
1.1
Referenser
Utöver detta dokument finns det ett antal övriga dokument som är viktiga förutsättningar för det arbete som ska
göras (publiceras på projekthemsidan i takt med att de färdigställs):
•
Utformningsprinciper fördjupningar (kommer senare i höst)
•
Bildspel och dokumentation från projekt- och stormöten.
•
Filspecifikationer:
•
•
CS15 och tabellverk d:o
•
LG04 och tabellverk d:o
•
GL07, GL07-AP, AR och tabellverk d:o
Layouter (faktura, kreditfaktura, utbetalningsavisering, påminnelse, dröjsmålsräntefaktura)
Vid fälthänvisningar i detta dokument hänvisas till respektive filspecifikation.
5 (42)
2 Övergripande
2.1
En gemensam lösning
Grundtanken vid införandet av Agresso bygger – precis som vid införandet av tidigare delar av NEKK-projektet – på
gemensamma lösningar. Utformningen av processer och funktioner i Agresso ska stödja ett gemensamt arbetssätt
och strukturen på informationen ska vara likformig och samordnad. Det tar sig t ex uttryck i att redovisningsbegrepp,
relationer (underkoder) och andra viktiga begrepp ser lika ut för alla, att kundfakturalayouten är gemensam samt att
modeller och processer för investeringsprojekt och anläggningar, kund, leverantörer och attester samordnas i så
stor utsträckning som möjligt. Systemadministrationen i systemet samt roller och behörigheter kommer utformas för
att säkerställa kommuncentral kompetens om helheten och samtidigt skapa förutsättningar för en fortsatt gemensam
utformning som inte bara kommer att kunna komma förvaltningarna inom Göteborgs Stad till del. Grundtanken med
en sammanhållen systemadministration är att endast det som ska kunna påverkas på respektive förvaltning bör/ska
kunna hanteras lokalt.
2.2
Redovisningsenhet
Varje förvaltning är en ”Redovisningsenhet” i Agresso. Samtliga redovisningsenheter utgör tillsammans den
gemensamma huvudboken för kommunen. Även om varje förvaltning är en egen redovisningsenhet ska uppsättning
och konfigurering hanteras på ett så likartat sätt som möjligt. De gemensamma regelverken är styrande och det är
endast inom ramen för dessa som lokala tillämpningar kan göras. Anledningen till uppdelning i redovisningsenheter
är främst att varje förvaltning endast ska se de koder man använder och ha möjlighet till lokala konteringsregler
(indatakontroller).
Redovisningsenheterna är namnsatta enligt nuvarande ”prefix” (utan N), dvs. 200, 131, 132 etc.
2.3
Modulstruktur
Varje redovisningsenhet består i grunduppsättningen av modulerna Huvudbok (HB), Order/Fakturering (O/F),
Kundreskontra (AR), Leverantörsreskontra (AP) och Anläggningsreskontra (AT). Leverantörsfakturahanteringen
kommer precis som tidigare att hanteras i Winst och bokföringen från huvudboken kommer som tidigare att föras
över till Nekksus för uttag av rapporter mm till verksamheten. Det kommer också att vara möjligt att ta ut
rapporter/ställa frågor från bokföringen ur Agresso. Hanteringen av leverantörsreskontran och kundreskontran (inoch utbetalningar, utskick av fakturor, påminnelser, autogiro/e-fakturahantering, inkassohantering etc.) kommer att
hanteras gemensamt som idag. Order/Fakturering (ersättaren för WebbFaktura och merparten av PC-lev) kommer
att hanteras i respektive förvaltning. Kundregister kommer att finnas i respektive redovisningsenhet medan
leverantörsregistret kommer att vara gemensamt för alla redovisningsenheterna. Anläggningsreskontra kommer att
sättas upp endast för de investerande förvaltningarna (200, 230, 392, 393, 400 och 560) samt några ytterligare –
beroende på beslut kring hantering av passiva register. Koder i Agressos huvudbok kommer att vara källa till både
Nekksus och Winst. Systemadministration kommer att hanteras både lokalt och centralt; vad som görs var kommer
att presenteras mer detaljerat under utrullningen.
6 (42)
2.4
Typer av integrationer
En stor del av informationen i huvudboken kommer från olika typer av verksamhetssystem. Integrationerna från de
lokala verksamhetssystemen kan vara av minst fyra olika typer. Innan integrationsarbetet påbörjas måste de
förvaltningar som har behov av förvaltningsspecifika integrationer till Agresso, för varje system, noga identifiera
vilken typ av integration som försystemet ska skapa. För att flytta filerna från verksamhetssystemen till Agresso
kommer stadens integrationsplattform ”Biztalk” att användas.
Integrationer av faktureringsunderlag (debet, kredit, utbetalningar):
1.
Kunduppgifter (CS15) – Upplägg av kunder i redovisningsenhetens kundregister i Agresso. Integrationen ska
omfatta de kunder som ingår i filen med försäljningsorder (LG04), dock inte de interna kunderna. När det inte är
lämpligt att skicka med CS15 från försystemet (i undantagsfall) kan de externa kunderna underhållas manuellt i
Agresso.
2.
Försäljningsorder (LG04) – som ska faktureras i Agresso. Integrationen används både för fakturor till och för
utbetalningar till kunder. Vid denna typ av integration skickar försystemet underlag till fakturan/utbetalningen.
Faktureringen sker i Agresso och i samband med det sker också bokföring i huvudboken. Denna typ av fil
kommer inte att balansera Debet/Kredit.
7 (42)
Det finns i Agresso möjligheter till manuell fakturering både av så kallade strö-/diversefakturor och av
abonnemangsfakturor (periodvisa fakturor). Denna funktion kommer att ersätta WebbFaktura. I det fall integrationen
omfattar relativt få fakturor kan detta vara ett alternativ till att ersätta befintlig integration.
Integrationer av bokföringsorder, utbetalningsuppdrag (leverantörsskulder) och kundfordringar:
3.
Bokföringsorder (GL07) – för t ex bokföring av kontantförsäljning, löner, interna fördelningar etc. Integrationen
skapar bokföring i huvudboken och ska alltid balansera D/K per verifikation i filen.
4.
Bokföringsorder med leverantörskoppling (GL07-AP) – för utbetalningar till leverantörer (företag och
organisationer) där utbetalning sker utan att en faktura erhållits från leverantören. Integrationen skapar både
bokföring i huvudboken och en leverantörsfaktura till leverantörsreskontran (AP). Filen ska alltid balansera D/K
per verifikation. Leverantören måste finnas upplagd i Agresso, manuellt eller (ev. via en CS15 fil med
leverantörsuppgifter)1. En motsvarande typ av integration används också mellan Winst och Agresso för
ankomst- och slutbokföring av leverantörsfakturor.
5.
I de fall faktureringen inte sker i Agresso utan i försystem finns det möjlighet att integrera kundfakturor (GL07AR) på samma sätt som för leverantörsfakturor. Ett fåtal sådana integrationer har hittills identifierats eftersom
utgångspunkten är att all fakturering ska ske i Agresso. Vid en sådan integration måste även kunduppgifter
uppdateras via CS15.
2.5
Skillnad mot idag (förvaltningsspecifika integrationer)
- De integrationer av fakturaunderlag som nu skickas till FUPPS ersätts vid övergång till Agresso av två
integrationer; kunduppgifter (CS15) och försäljningsorder (LG04). Detta är en skillnad mot tidigare när kund- och
fakturainformation skickades i samma fil.
- De integrationer av bokföringsinformation som tidigare skickades direkt till Horisonten ersätts nu av integration av
bokföringsorder (GL07) till Agresso.
- De övriga integrationer som tidigare skickades till PC-lev för utbetalning hanteras nu på minst två olika sätt:
•
Om de avser privatpersoner eller är regleringar av tidigare fakturerat ska de skickas som negativa
försäljningsorder med en separat ordertyp i Agresso (CS15 och LG04).
•
Om de avser företag och organisationer, som inte är kunder, ska 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.
o
Ytterligare ett alternativ för företag och organisationer är naturligtvis att företaget/organisationen
skickar en leverantörsfaktura som då hanteras via Winst.
De utbetalningar som registrerades manuellt i PC-lev tidigare kommer att hanteras som manuell negativ
försäljningsorder.
1
Detta gäller endast för integrationer, manuella utbetalningar skall hanteras via kundfakturering.
8 (42)
I takt med att förvaltningarna har gått över från Gasell till Winst har också förvaltningens PC-levutbetalningar
kopplats till Winst-flödet. Vid övergång till Agresso kommer inte ”PC-lev” att finnas kvar och utbetalningar är då inte
tänkta att hanteras via Winst utan ska i sin helhet hanteras i Agresso. Enda undantagen är utbetalningar från
ProCapita där utgångspunkten är att de även fortsättningsvis skickas direkt till Winst och kommer att
konteras/attesteras i Winst innan de förs över till Agresso för utbetalning.
9 (42)
3 Kodsträng och konteringsregler
3.1
Kodsträng
Namn
Konto
Ansvar
Projekt
Spec
(Anläggning)
AktAO
Objekt
Verk
Motpart
Agresso
internt namn
Konto
Dim 1
Dim 2
Dim 3
Dim 4
Dim 5
Dim 6
Dim 7
4p
8p
(inkl.prefix)
1+6=7p
7p
(4p i Personec)
7p
12p
(7p i Personec)
4p
4p
A0
C1
B0
N0
BF
N2
N3
N1
Antal
positioner
System id i
Agresso
Den kodsträng som används i Agresso innehåller samma konteringsbegrepp (koddelar) som dagens men
ordningsföljden skiljer sig mot tidigare. Reglerna för användning är de samma som tidigare.
Alla koddelar ska inte/behöver inte skickas med i konteringen från försystemet, (se nedan vad som gäller generellt
för respektive koddel). Förvaltningen kan dessutom utnyttja funktioner för kodkomplettering i Agresso för att göra
konteringen komplett.
Konto – konto är en obligatorisk koddel. I försäljningsorder (LG04) ges Konto av artikel och ska normalt inte skickas
med från försystemet. I bokföringsorder (GL07) är Konto alltid obligatorisk.
Ansvar – en obligatorisk koddel både i LG04 och i GL07 som kan vara lika med xxx (prefix) 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 eller vid manuell kontering.
Projekt – frivillig koddel, om transaktionen inte avser en investering (transaktion till investeringsredovisning), då
måste ett projekt som börjar på I anges.
Spec – i de fall den konterade händelsen avser en gemensam/central speckod är denna koddel obligatorisk. I annat
fall avgörs den av lokala behov.
AktAO – frivillig koddel som ersätter koddelen aktivitet och används för Arbetsorder eller Aktivitet. De gemensamma
aktiviteterna, som börjar med 9, kommer att flyttas till Spec-kod. (Personec har endast plats för 4 pos för Spec).
Verk – obligatorisk koddel för resultaträkningen. Om det alltid är ett och samma Verk som ska gälla för förvaltningen
eller per ansvar eller annan koddel kan koden sättas vid inläsningen till Agresso. Se vidare under kapitel 3.2
Konteringsregler nedan.
Motpart – obligatorisk koddel. Motpart ska inte fyllas i vid integration av försäljningsorder (LG04) eller vid
bokföringsorder med leverantörskoppling (GL07 med AP-koppling) utan endast vid vanlig bokföringsorder (GL07).
3.2
Konteringsregler
Precis som i Horisonten kan ett antal regler sättas upp för att underlätta/säkerställa konteringen. I Agresso kallas
dessa för konteringsregler. De transaktioner som kommer från försystemen måste vara godkända utifrån de
konteringsregler som gäller för redovisningsenheten som tar emot transaktionerna. Om inte, kommer transaktionen
att felfällas och måste rättas i Agresso (se vidare under felrättning) om en obligatorisk koddel saknas eller ett icke
giltigt värde angetts. Om konteringsregeln inte tillåter en koddel som skickas från försystemet kommer denna inte att
tas med in i Agresso, och transaktionen kommer inte att felfällas. I Agresso utgår konteringsreglerna alltid från konto
och de kan t ex. användas för att säkerställa att transaktionen innehåller rätt koddelar eller för att sätta värdet för
10 (42)
någon av koddelarna. Detta kan vara en hjälp till att komplettera konteringen om försystemet inte kan skicka den
kompletta konteringen.
I samband med konfigureringen av Agresso har gemensamma konteringsregler definierats för samtliga konton.
Dessa specificerar till exempel vilka koddelar som är obligatoriska/tillåtna för olika konton och vilka motparter som
ska förekomma på olika konton. För de konton som har en fast motpart kommer denna att läggas upp som fast
värde för kontot och motparten blir då alltid den bestämda motparten oavsett vad som registreras i bokföringsordern.
I Winst finns också konteringsregler (sambandskontroller). Den tekniska lösningen av sambandskontroller i Winst
fungerar inte på samma sätt som i Agresso och de två systemen har olika styrkor, bl a kan kontroller mellan andra
koddelar än konto enklare hanteras i Winst. Kodkompletteringar från någon koddel som varierar mycket är svårare
att hantera i Winst eftersom underhållet blir komplext och det i nuläget inte finns någon funktion för att föra över
konteringsregler från Agresso till Winst (något som kan komma att utvecklas senare). Motpart finns inte i Winst
varför alla kontroller som rör motpart måste finnas i Agresso. Sambandskontrollerna i Agresso och Winst måste
därför ses som en helhet. En annan aspekt på detta är också att beslutsattesten i Winst intygar rätt kontering medan
konteringsregler i Agresso kan förändra/utöka denna vid bokföring i Agresso.
Varje redovisningsenhet kan, inom ramen för de gemensamma reglerna i Agresso och Winst, utforma mer specifika
regler. I samband med att regelverket för integrationer och för manuell bokföring tas fram är det viktigt att
förvaltningen tillsammans med projektet identifierar vilka behov av regler som finns och hur dessa ska utformas för
att säkerställa att konteringsinformationen blir korrekt.
Det är också möjligt att skapa kontrollrapporter som i efterhand rapporterar eventuella felkonteringar för ombokning.
Dessa kontrollfrågor – som kan byggas så att de endast signalerar fel – kan vara ett komplement eller en ersättning
till konteringsregler.
I nedan presenteras ett antal vanliga exempel på konteringsregler som kan bli aktuella för förvaltningarna att
tillämpa:
Obligatoriska koddelar (lokala krav). De gemensamma konteringsreglerna som lagts upp definierar vilka koddelar
som är obligatoriska, möjliga att använda eller inte får användas per konto. De filer som skickas från försystemen
måste motsvara dessa krav vad gäller de obligatoriska/frivilliga koddelarna. Om integrationen innehåller en
kontering på en koddel som inte får förekomma enligt konteringsregeln kommer denna transaktion inte att felfällas
utan värdet på koddelen kommer att tas bort vid inläsningen. Om förvaltningen har krav utöver de centrala – att en
koddel som får användas ska vara obligatorisk (t ex för de förvaltningar som har AktAO obligatorisk) ska detta
läggas som en konteringsregel på berörda konton (t ex konto 3*-8*) i aktuell redovisningsenhet. Integrationerna
måste då uppfylla dessa krav för att uppdateras i huvudboken.
Fast/Förslag motpart per Konto. De gemensamma konteringsreglerna har definierat vilka motparter som är
godkända för respektive konto. I vissa fall är det endast en motpart som är godkänd och denna är då inlagd som ett
fast värde. Vid integration av LG04 och GL07-AP kommer motpart alltid att sättas från kunden/leverantören på
samtliga transaktioner i verifikationen. För momstransaktionen byts sedan till korrekt motpart via konteringsregel för
momskonton.
Om förvaltningen ytterligare vill begränsa användningen av motpart på vissa konton kan sådana konteringsregler
läggas till lokalt (via central systemförvaltare i Agresso) som då kommer att vara ett stöd vid manuell kontering.
Fast ansvar på Konto. Alla konteringstransaktioner ska innehålla ansvar, vilket kan vara ett ”riktigt” ansvar eller
prefix-koden (som är ett ansvar med 3 positioner). Det är möjligt att lägga upp en konteringsregel för förvaltningen
som gör att ansvar på balanskonton (konto 1-2) alltid sätts till förvaltningens prefix. Då behöver eventuella
transaktioner på balanskonton som kommer från integrationer eller bokföringsorder inte innehålla ansvarskod. Tänk
på att konteringar på balanskonton i Winst måste innehålla ett ”riktigt” ansvar, inte bara prefixansvaret. Om prefix
ligger fast i regeln i Agresso kommer Agresso att byta till prefix trots att konteringen i Winst gjorts på riktigt ansvar.
Fast Verk per redovisningsenhet. Om redovisningen i en förvaltning alltid ska konteras med ett fast verk kan en
konteringsregel läggas in för varje konto i redovisningsenheten. Integrationerna behöver då inte innehålla verk utan
denna sätts vid inläsningen.
11 (42)
Fast/förslag på Verk utifrån Ansvar. Om konteringen av verk kan kopplas till ansvar kan en konteringsregel
läggas upp, för varje konto (3-8), med en direkt relation mellan ansvar och verk. Integrationerna behöver då inte
innehålla verk utan denna hämtas från ansvar vid inläsning. Om relationen läggs som ”Fast” värde kommer detta
alltid att skriva över – oavsett vad som registrerats i verk från försystem eller i Winst. Om den läggs som ”Förslag”
kommer detta värde att användas endast om verk lämnats tomt i försystem eller i Winst. Vid manuell registrering
lämnas det som förslag och kan då ändras till något annat. De förvaltningar som väljer att använda denna regel
måste lägga upp direktrelationen verk på samtliga sina ansvar.
Fast/förslag på Verk utifrån Aktivitet. Om konteringen av verk kan kopplas till AktAO kan en konteringsregel
läggas upp för varje konto (3-8), med en relation mellan aktivitet och verk, under förutsättning att aktivitet är en
obligatorisk koddel för konto (3-8). Integrationerna behöver då inte innehålla verk utan denna hämtas från ansvar vid
inläsning. De förvaltningar som vill använda denna regel måste lägga upp direktrelationen verk på samtliga sina
aktiviteter.
3.3
Relationer
För varje koddel kan ett antal relationer anges (motsvarar det som i Horisonten kallas underkoder). 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 desamma som använts i GemHB. Vissa ändringar har gjorts, främst vad
gäller objekt och projekt, i samråd med de investerande förvaltningarna och med koncernredovisningen. Den
kompletta listan över vilka relationer som finns för respektive begrepp kommer löpande att uppdateras och finns
därför inte med i dokumentet. Kontakta projektet om ni har frågor kring denna.
Precis som tidigare kommer koder och relationer att vara en källa till strukturen för rapporterna i Nekksus. Varje
förvaltning kommer att för sina koddelsbegrepp behöva gå igenom sina koder och relationer och komplettera vid
behov till nya relationsvärden. Detta är en del i förberedelserna för varje förvaltning och mer detaljerade instruktioner
kommer att sändas ut för detta inför utrullningen. Även för kund, leverantör och anläggning kan relationer användas
för att koppla information till dessa begrepp. På kundbegreppet finns tre relationer (motpart, fakturatyp och A-post),
där motpart och A-post ingår i CS15. Relationen fakturatyp som anger om kunden ska ha e-faktura/Swefaktura
underhålls inte från försystemen utan via extern information. På leverantörsbegreppet finns också relationen
motpart.
12 (42)
4 Moms
4.1
Momskod
Momskoden har två viktiga funktioner. Den anger vilken %-sats som ska användas för momsberäkning vid
fakturering av en försäljningsorder. Den lagras också på försäljningstransaktionen i huvudboken och används för att
ta fram uppgift om momspliktig omsättning för respektive moms-% i samband med momsrapportering. Inriktningen
är att all momspliktig omsättning ska kunna fångas med momskod, den momspliktiga omsättningen ska inte räknas
fram ”baklänges” vid momsrapporteringen utan ska kunna hämtas från bokföringen. Momskod är därför obligatorisk
att ange vid kontering av försäljning. Vid integration eller registrering av en försäljningsorder kommer alltid momskod
att ges av artikelgrupp/artikel. När en bokföringsorder för försäljning läses in eller registreras måste momskod
anges/användaren välja momskod. Konteringsregler på kontona kommer att styra användningen av momskod så att
den är obligatorisk att ange för konton i klass 3 och för ett fåtal andra konton som kan användas för försäljning
medan momskod för övriga konton sätts till 0.
På försäljningsorder (integrerade och manuellt registrerade) kommer momsen att beräknas vid faktureringen och om
intäkter bokförs manuellt via bokföringsorder kommer momsraden att beräknas och bokföras automatiskt utifrån
momskoden på intäktskontot vid registreringen. För alla övriga konton kommer momskoden att sättas till 0 med
automatik vilket innebär att inköp inte kommer att markeras med momskod för ingående moms. Det är viktigt att den
som upprättar en bokföringsorder för försäljning använder ett konto som kräver momskod (i klass 3) så att momsen
blir automatiskt beräknad eftersom momskoden annars kommer att sättas till 0 med automatik och omsättningen då
inte kommer att bli korrekt i förhållande till utgående moms. Avstämningar måste göras löpande för att säkerställa
detta.
I Winst finns inte momskod med för kontering. För inköp med omvänd skattskyldighet måste momsen alltid beräknas
och bokföras manuellt – antingen i Winst vid kontering av faktura eller i Agresso.
Momskod
20
21
22
24
25
26
23
0
Moms-%
25
12
6
25
25
25
0
-
Beskrivning
Utgående moms, 25 %
Utgående moms, 12 %
Utgående moms, 6 %
Utgående moms egna uttag, 25 %
Utgående moms vid frivillig skattskyldighet sv
Utgående moms vid vinstmarginalbeskattning
Utgående moms, 0 %
Ingen moms, 0 %, Ingående moms eller ingen moms.
Flera momskoder kan komma att läggas till vid behov.
4.2
Momssystem
Ett ytterligare begrepp som används för momshanteringen i Agresso är momssystem. Göteborg Stad kommer att
använda denna funktion för att undvika att moms faktureras och bokförs vid faktureringen inom eller mellan
nämnder. Fältet momssystem skall dock aldrig användas vid manuell registrering. Vid integration av (LG04/GL07)
ska denna information därför inte skickas med i filen och vid manuell registrering skall fältet lämnas blankt.
4.3
Momsrapportering
Förvaltningarnas rapportering i momsapplikationen ska ske på samma sätt som tidigare men en momsrapport
kommer att skapas i Agresso som varje redovisningsenhet ska köra i samband med periodavslut och som ska
kunna fungera som underlag för rapporteringen (i huvudsak för sektion A-D i momsrapporten). När momsrapporten
körs kommer vertyper för periodiseringar, reverseringar, etc att undantas. Riktlinjer för hur reverseringar och
periodiseringar av momspliktig försäljning skall hanteras för att momsrapportering skall bli korrekt kommer att tas
13 (42)
fram av projektet. Dessutom planerar projektet att skapa rapporter som stöd för hanteringen av momsåtersökning 6
% och 5/18.
14 (42)
5 Övriga viktiga begrepp i huvudboken
Utöver konteringsbegreppen innehåller kodsträngen ett antal andra begrepp som kan användas för bearbetningar
och utsökningar.
5.1
Verifikationstyp och Verifikationsnummer
Varje verifikation i Agresso har en verifikationstyp och ett verifikationsnummer. Verifikationstypen används för att
kunna spåra varifrån transaktionerna har sitt ursprung. För transaktioner som kommer från försystem kommer
verifikationstypen att visa från vilket försystem som verifikationen har sitt ursprung.
En verifikation skapas inte förrän en försäljningsorder faktureras i Agresso varför en LG04 inte innehåller något fält
för verifikationstyp. Vid integration av bokföringsorder (GL07/GL07-AP) måste försystemet ange rätt verifikationstyp.
De verifikationstyper som ska användas framgår av tabellverket till GL07.
I en bokföringsorder med leverantörskoppling (GL07-AP) ska varje utbetalning vara en verifikation. För en vanlig
GL07 får bestämmas per försystem vad som är verifikationsnivå. I Agresso måste en verifikation balansera D/K
inom bokföringsperioden.
Verifikationsnummer sätts som ett löpnummer per redovisningsenhet. Varje verifikationstyp har inte sin egen serie
utan flertalet verifikationstyper kommer att dela verifikationsnummerserie. Verifikationsnumret sätts av Agresso vid
fakturering med en gemensam serie per redovisningsenhet för alla fakturor (som börjar med 7 och är samma som
fakturanummer) eller vid inläsning av bokföringsorder i en gemensam serie (som börjar med 19).
Manuellt registrerade bokföringsorder och verifikationer som skapas i Agresso vid olika bearbetningar eller från
kundreskontran, leverantörsreskontran eller anläggningsregistret har också egna verifikationstyper och
verifikationsnummerserier.
5.2
Bokföringsperiod ÅÅÅÅMM
I Agresso är bokföringsperiod det som avgör i vilken månad som bokföring sker. Bokföringsperiod sätts vid
fakturering och finns inte med i en försäljningsorder (LG04) från försystemet.
En bokföringsorder som görs manuellt eller kommer från ett försystem (GL07) måste innehålla information om
bokföringsperiod.
För bearbetningar som körs med automatik i Agresso kommer bokföringsperiod att hämtas från den period som har
angetts som ”aktuell period” i Agresso. Vid varje månadsslut (x antal dagar in i ny månad) byts aktuell period från
innevarande period till nästa. Det innebär inte att den tidigare är stängd utan båda perioderna är öppna parallellt tills
den tidigare av dem stängs.
5.3
Verifikationsdatum ÅÅÅÅMMDD
Verifikationsdatum visar vilken dag som verifikationen registrerats. I Webb-gränssnittet betecknas kallas detta datum
transaktionsdatum. Datumet kan ligga utanför ”Bokföringsperiod”. Verifikationsdatum sätts till dagens datum vid
fakturering och finns inte med i försäljningsorder (LG04) eftersom den ännu inte är bokförd. Vid integration av
bokföringsorder (GL07) sätts detta datum normalt till inläsningsdatumet och om det är en GL07 med kund (GL07AR) eller leverantörskoppling (GL07-AP) kommer detta datum att utgöra fakturan fakturadatum varifrån
förfallodatum beräknas om detta inte skickas från försystemet.
5.4
Transaktionstext
Transaktionstexter kan endast anges i bokföringsorder (GL07). På varje konteringsrad kan en transaktionstext
anges som blir synlig i huvudboken i Agresso. Denna kan vara gemensam för alla transaktioner inom en verifikation
15 (42)
eller unik per transaktionsrad. Om integrationen avser en utbetalning till leverantör (GL07-AP) kommer den texten
som anges i detta fält tillsammans med det som angetts som fakturanummer att vara den information som skickas
till betalningsmottagaren vid utbetalning.
I en försäljningsorder från försystem (LG04) finns inget utrymme att ange transaktionstext – denna sätts i samband
med inläsningen till Agresso, då bokföring sker, till benämningen på ordernummertypen (namn på försystem).
För en manuell fakturering kommer den text som anges i ”Extern order-id” att läggas som transaktionstext och vid
abonnemang kommer abonnemangsnumret att ligga i transaktionstexten.
När en utbetalning sker via negativ försäljningsorder kommer informationen till utbetalningsmottagaren att skickas
via en avisering till mottagaren – se vidare i kapitel 7.13.
5.5
Leverantörs-id/Kund-id
Fältet i huvudboken visar Agressos leverantörsid om verifikationen avser en leverantörsfaktura och Agressos Kundid om verifikationen avser en kundfaktura. Informationen om leverantör/kund används för att sätta rätt motpart på
transaktionen vid bokföring av leverantörsfakturor och kundfakturor.
5.6
Extern transaktionskälla
Vid integration av bokföringsorder (GL07) finns ett fält som heter Extern referens. Detta fält är synligt i transaktionen
i huvudboken och heter då ”Extern transaktionskälla.
16 (42)
6 Periodisering
Med ”Periodisera” avses i Agresso det som i Horisonten kallas ”Vändas”, dvs. när en verifikation vänds i kommande
månad medan ”Periodisering” avser när en kostnad/intäkt skall fördelas ut över flera perioder, det som i Horisonten
kallas FPER. För att hålla isär dessa två likartade begrepp bör vändning av verifikation i kommande månad istället
kallas Reversering. Reversering används också för att benämna bortbokning av ett felaktigt verifikat eller när en
klarmarkerad leverantörsfaktura skall bokas bort.
”Vändas” hanteras genom att den som registrerar den verifikation som ska vändas väljer funktionen ”Periodisera”
och gör då samtidigt som verifikationen registreras, en reversering i kommande period.
Periodisering över flera perioder hanteras genom periodiseringsnyckel och startmånad enligt beskrivningarna
nedan. När en periodiseringsnyckel anges i en transaktion kommer transaktionen att bokföras samtidigt som två
transaktioner skapas som vänder transaktionen i sin helhet mot kontona 1712/2993 (med samma koddelar om
förvaltningen inte valt att ta bort vissa av dessa genom konteringsregel på konto 1712/2993). Samtidigt kommer nya
verifikationer att skapas i de angivna månaderna som bokar ut månadens andel av totalbeloppet från kontona
1712/2993.
Det går inte att ange i Agresso att periodisering ska ske eller är förbjuden för vissa konton via konteringsregler.
Periodiseringstransaktionerna kommer att ha en egen vertyp i Agresso (RJ).
6.1
Periodiseringsnyckel
I fältet ”Periodiseringsnyckel” anges vilken nyckel som skall användas för periodisering. Denna ersätter FPER i
Horisonten och liknar den teknik som används i Winst för periodisering av leverantörsfakturor. Sättet att ange
startmånad skiljer sig mellan försäljningsorder (LG04) och bokföringsorder (GL07) varför det för LG04 finns behov
av flera periodiseringsnycklar för samma periodfördelning.
Alla nycklar som lagts upp från start bygger på att beloppet fördelas ut jämt över de framtida perioderna. Vid behov
kan nycklar med mer ojämn fördelning (t ex större andel i första period) också läggas upp.
För bokföringsorder (GL07) anger periodiseringsnyckeln över hur många månader som beloppet skall periodiseras
och används i kombination med fältet startperiod. För detta ändamål finns följande nycklar. Dessa kan också
användas i LG04 om bokföringsperioden är startmånaden.
Nyckel
Startperiod
1
100
Nästa
Nästa+1
Nästa+2
Nästa+3
Nästa+4
Nästa+5
Nästa+6
Nästa+7
Nästa+8
Nästa+9
2
50
50
3
33,33
33,33
33,33
4
25
25
25
25
5
20
20
20
20
20
6
16,67
16,67
16,67
16,67
16,67
16,67
7
14,29
14,29
14,29
14,29
14,29
14,29
14,29
8
12,50
12,50
12,50
12,50
12,50
12,50
12,50
12,50
9
11,11
11,11
11,11
11,11
11,11
11,11
11,11
11,11
11,11
10
10
10
10
10
10
10
10
10
10
10
11
9,09
9,09
9,09
9,09
9,09
9,09
9,09
9,09
9,09
9,09
9,09
12
8,33
8,33
8,33
8,33
8,33
8,33
8,33
8,33
8,33
8,33
8,33
Nästa+10
Total
100
100
100
100
100
100
100
100
100
100
100
8,33
100
För försäljningsorder (LG04)
eller vid manuell registrering av försäljningsorder finns endast fältet
periodiseringsnyckel tillgängligt och val av periodiseringsnyckel måste göras utifrån när periodiseringen skall starta.
Därför finns ytterligare ett antal nyckar som flyttar fram en respektive två månader framtagna.
17 (42)
Flyttar fram en månad:
Nyckel Startperiod Nästa
Nästa + 1 Nästa + 2
osv
101
0
100
100
103
0
33.3
33.3
33.3
104
0
25
25
25
25
106
0
16.7
16.7
16.7
16.7
16.7
16.7
112
0
8.33
8.33
8.33
8.33
8.33
8.33
100
100
100
8.33
8.33
8.33
8.33
8.33
8.33
100
Flyttar fram två månader:
Startperiod
Nästa Nästa + 1
Nästa + 2 osv
201 0
0
100
100
203 0
0
33.3
33.3
33.3
204 0
0
25
25
25
206 0
0
16.7
16.7
16.7 16.7
16.7
16.7
212 0
0
8.33
8.33
8.33 8.33
8.33
8.33
100
25
100
100
8.33
8.33
8.33
8.33
8.33
8.33
100
Samtliga varianter, dvs. fördelning över 1-12 månader, 101-112 och 201-212 finns nu upplagda (visas inte i tabell
ovan).
6.2
Startperiod
Anger vilken som är första månad vid periodisering genom att med en siffra ange hur startmånaden förhåller sig till
bokföringsperioden. Startperiod anges endast i bokföringsorder (GL07).
0 = Start i innevarande period
1 = Start i nästa period
2 = Start i nästa+1 period
3 = Start i nästa+2 period
När man gör en manuell bokföringsorder direkt i Agresso anges startperiod med ÅÅÅÅMM.
18 (42)
7 Försäljningsorder blir kundfaktura
Försäljningsorder kan komma från försystem eller registreras manuellt i Agresso. Manuell registrering kan ske både
via Agresso Web och Agresso Desktop.
Försäljningsorderna blir till debetfakturor, kreditfakturor eller utbetalningar vid en faktureringskörning i Agresso. I
samband med faktureringen sker också bokföring. För kundfordran i Agresso kommer två nya konton; 1513 (X/B/Kmotparter) och 1514 (N/I-motparter) att läggas upp.
7.1
Manuell fakturering (ersätter WebbFaktura)
För manuell registrering av försäljningsorder finns olika registreringsmetoder. Det finns, utöver en vanlig
försäljningsorder, möjlighet att utnyttja abonnemangsfakturering (periodisk faktura till samma kund för t ex. hyra eller
annan periodisk återkommande fakturering), massfakturering (exakt likadan faktura till många kunder) eller
registrering av försäljningsorder utifrån en i förväg definierad mall (artiklar och texter). Det är också möjligt att
kopiera från en tidigare registrerad försäljningsorder. I förberedelsearbetet för förvaltningen ingår att identifiera
förvaltningens behov av manuell registrering av försäljningsorder och tillsammans med projektet identifiera vilken typ
av försäljningsorderregistrering som bäst stödjer denna. Eftersom faktureringsrutinen i Agresso skiljer sig från
dagens i WebbFaktura (bl a så saknas möjligheten att använda ”grupper”) är det viktigt att identifiera vilken typ av
fakturering som görs inom förvaltningen och tillsammans med projektet identifiera särarterna för denna så att
möjligheterna i Agresso utnyttjas på bästa sätt och undvika att det blir upp till varje användare att själv ”uppfinna
hjulet”.
7.2
Kundgrupp/kund
För att en försäljningsorder ska kunna registreras måste det finnas en kund upplagd i Agresso. Kunden läggs upp
från försystemet (CS15) eller manuellt.
19 (42)
I Agresso finns ett kundregister per redovisningsenhet. I kundregistret grupperas kunderna i olika kundgrupper.
Varje försystem kommer att ha minst en kundgrupp i Agresso. Indelningen i kundgrupper styrs av försystem, men
också av betalningsvillkor och kravkod (regler för påminnelse, dröjsmålsränta mm).
Om försystemet fakturerar olika företeelser till samma kunder ska kundgruppen vara den samma – även om
försäljningsorderna skickas i olika filer. Inriktningen är att samma kund inte ska finnas i flera kundgrupper. Om
kunderna är helt olika vad gäller betalningsvillkor och kravkoder för olika filer från samma försystem bör olika
kundgrupper skapas.
Kravkod kan endast ”hänga” på kund – inte på försäljningsorder. Om samma fysiska kund skall kunna få fakturor
med olika kravkoder måste detta hanteras antingen genom
Alternativ 1
Försystemet har två kundförekomster med olika kundid och kravkod. När försystemet skickar en försäljningsorder så
måste ”söknamnet” i denna peka på rätt kundförekomst (den med rätt kravkod). En LG04 och En CS15 (där samma
fysiska kund kan finnas två gånger).
Alternativ 2
Försystemet har endast en kundförekomst. Försystemet skickar två LG04 och två CS15. I den ena skickas de
försäljningsorder som har den ena kravkoden och i den andra skickas de försäljningsorder som har den andra
kravkoden. I respektive CS15 skickas de kunder som omfattas av försäljningsorderna. Varje CS15 har sin egen
kundgrupp där kravkoden ligger och samma kund (försystem-id) kan ligga i båda kundgrupperna. Vid inläsning
riktas LG04 filen till rätt kundgrupp. Detta innebär att vi måste ta fram en ny ordernummertyp och en ny kundgrupp.
Alt 1:
Försystem A
LG04 1
Kundgrupp för Försystem A
LG04 2
Alt 2:
Försystem A
LG04 1
Kundgrupp 1 för Försystem A
LG04 2
Kundgrupp 2 för Försystem A
Kundgrupperna läggs upp manuellt i Agresso från start med förslagsvärden för betalningsvillkor och kravkod utifrån
vad som ska gälla för försystemet. Vid inläsning av kunder från försystemet (CS15) kommer betalningsvillkor och
kravkod att hämtas från kundgruppen. Ett försystem som i sin kundgrupp har kunder med olika regler för
betalningsvillkor och kravhantering ska skicka med dessa uppgifter för respektive kund i CS15.
De interna kunderna ligger i egna kundgrupper utanför försystemets kundgrupp och kommer att vara gemensamma
för alla förvaltningens försystem och manuell fakturering. Filer från försystem kan innehålla både externa och
interna kunder trots att dessa ligger i olika kundgrupper.
Alla kunder kommer att få ett Agresso Kund-id enligt beskrivning i 7.3 och 7.4. Varje försäljningsorder måste
innehålla en referens till kund. Det Kund-id som finns i försystemet används som nyckel för att koppla ihop
kunduppgift med försäljningsorder för alla externa kunder. I kunduppgiften (CS15) ligger försystemets Kund-id i
elementet ”Söknamn” och i LG04 ligger informationen i elementet ”Text 3”. Försystemets id får inte vara längre än
10 positioner. För de interna kunderna är det istället Agressos Kund-id som är nyckel och detta ska ligga i elementet
”Buyer-id” i LG04.
Försystem A
LG04
Externa kunder
Interna kunder
Kundgrupp för Försystem A
Kundgrupp – interna kunder
20 (42)
För manuell fakturering kommer separata kundgrupper att kunna användas för externa kunder och behovet av olika
kundgrupper kommer att avgöras av omfattningen av den manuella faktureringen i förvaltningen. Det är också
möjligt att använda försystemet kunder vid manuell faktureringen. En del i förberedelsearbetet inför utrullningen blir
att identifiera behov och besluta vilka kundgrupper som ska finnas.
7.3
Externa kunder
För externa kunder utgörs kundnummer i Agresso av ett löpnummer som är 10 positioner,
(”8” [fast värde, 1 pos] + ”prefix” 3 pos + löpnr 6 pos). För de förvaltningar som inte fakturerar i Agresso
(undantagsfall) och därför endast importerar kundfakturor finns möjlighet att manuellt sätta kundnummer enligt
försystemet.
Alla kunder ska också ha en uppgift om ”Motparts-kod” enligt nu gällande struktur. Varje kund har också ett
”Försystem Kund-id” (max 10 positioner) och personnummer/organisationsnummer ”hängande” som fält på
Agressos Kund-id. Dessa fält är också sökbara inom och mellan redovisningsenheter.
Kunduppgifter för externa kunder skickas från respektive försystem (CS15) tillsammans med försäljningsorder
(LG04). För externa kunder skickar försystemet sitt Kund-id som nyckel i båda filerna. Varje försystem (men inte
alltid varje fil) har en egen ”Kundgrupp”, där de kunder som tillhör försystemet kommer att finnas registrerade. Vid
inläsning kommer filerna att riktas mot den ”kundgruppen” för att rätt kunder ska kunna identifieras. Försystemets
Kund-id måste vara unikt inom respektive kundgrupp.
När kundfilen läses in i Agresso kontrolleras om kunden finns tidigare (utifrån försystemets Kund-id). Om så inte är
fallet läggs kunden upp och får ett Agresso-id. Om kunden redan finns sker endast en uppdatering av uppgifterna.
Vissa uppgifter såsom betalningsmetod kommer inte att uppdateras (annat än första gången) utan måste
underhållas manuellt eller via andra integrationer.
I grunduppsättningen av Agresso har kundgrupper skapats för befintliga försystem och dessa har namngetts från
10-99. Under arbetet med förvaltningens integrationer kommer behov av nya kundgrupper att kunna identifieras.
Kundgrupperna för försystemen är unika för hela installationen men läggs bara upp i de redovisningsenheter som
har behov av kundgruppen utifrån försystemens tillhörighet.
7.4
Interna kunder (K/B/N/I-kunder)
För interna kunder gäller andra regler:
B/K-kunder har avvikande kravkod jämfört med externa kunder och ligger därför i en egen kundgrupp.
Huvudregeln att det endast ska finnas en kundförekomst per motpartskod men vid särskilda behov kan flera Kund-id
behöva läggas upp för samma motpartskod. Dessa kommer då att få ett Agresso Kund-id som består av 6
positioner: Bxxx01-Bxxx99, respektive Kxxx01 – Kxxx99. I dialog med respektive förvaltning kommer behovet att
utredas. Motpartskoden är dock den samma som tidigare (4 pos).
För N-kunder (samtliga stadens förvaltningar) utgörs Agressos Kund-id av 4 positioner; Nxxx dvs. samma som
motpartskoden. För N-kunder ska det endast finnas en kundförekomst i Agresso för respektive förvaltning.
Styrningen av fakturan till rätt mottagare i Winst ska ske genom att namn eller mottagarkod skickas med i
försäljningsordern (LG04) som ”Er referens” varför separata Kund-id inte behövs av denna anledning.
För I-kunder utgörs Agressos Kund-id i normalfallet av 4 positioner; Ixxx där xxx är förvaltningens prefix. Det ska i
normalfallet endast finnas en I-kund upplagd per redovisningsenhet. På detta Kund-id kommer motpartskoden ”IIII”
att anges. För de förvaltningar som har behov av olika motpartskoder inom förvaltningen, (i nuläget endast 138, 392
och 610) måste det finnas ett Kund-id i Agresso per kombination av kund/lev motpart. Kund-id för dessa blir då
en kombination av Kundid/Levid. Motpartskoderna för dessa kunder läggs upp enligt den struktur som gäller idag;
138 (IQxx, IRxx, IPxx), 392 (I8xx), 610 (I5xx). När dessa kunder läggs upp bör kombinationen av motpartskoderna
21 (42)
läggas upp i namnet så att man vid manuell fakturering kan se till vilken kund/lev motpart respektive Kund-id är
kopplat.
Samtliga interna kunder (B/K/N/I) läggs upp manuellt av central systemförvaltning för varje redovisningsenhet. Om
försystemet har flera förekomster för interna kunder måste dessa översättas från försystemet till dessa
gemensamma Kund-id.
När en försäljningsorder till en N- eller I-kund faktureras kommer fakturan att skickas som en leverantörsfaktura till
Winst, se vidare under kapitel 7.12. För att fakturan ska läsas in i rätt Winst-organisation är förvaltningens GLN-kod
inlagd på alla N- och I-kunder.
För samtliga N och I kunder kommer också en motsvarande leverantörspost med samma Lev-id att läggas upp för
att interna kundfakturor och leverantörsfakturor ska kunna matchas. B och K kunder kommer däremot att ha Lev-id
från Agressos externa löpnummerserie för leverantörer.
7.5
Namn och Adress
Det kundnamn och den kundadress som skickas från försystemet kommer att vara det som presenteras på fakturan.
Namnraden ska vara max 40 positioner och skickas med fördel till Agresso med versaler och gemener (Anna
Andersson, Storgatan 1)
Adress
För varje kund ska minst en adress anges. Adressen bör också registreras med versaler och gemener.
För adress finns 3 rader att använda. (I Agresso finns 4 rader tillgängliga men endast 3 av dessa ska användas för
att adressen ska rymmas inom fönstret på kuvertet.) Om någon/några av raderna saknas flyttar Agresso upp
Postnummer och Postort för att inte visa blankrader.
•
Rad 1 ska användas för ev. c/o adress,
•
Rad 2 ska användas för ev. lägenhetsnummer
•
Rad 3 ska användas för gatuadress.
Om kunden bor i Sverige (dvs om country code i adress är SE) ska endast postnummer anges – Agresso kommer
då att komplettera med korrekt ort. Om kunden bor i annat land måste ort skickas med från försystemet (eller
registreras manuellt) och då ska fältet postnummer lämnas blankt.
Adressfältet i CS15 är 160 positioner och försystemet måste med hjälp av blanksteg anpassa adressen så att den
presenteras på rätt rader (40 positioner per rad). Om c/o och/eller lgh inte är aktuella behöver inte blanka rader
skickas med. Om kunduppgiften registreras manuellt ska raderna i adressen brytas på motsvarande sätt.
Det finns möjlighet att ange en kontaktperson hos kunden (kopplad till adressen). Om en sådan anges i elementet
”Contact name” i CS15 eller registreras vid manuell kundregistrering kommer denna kontaktperson att skrivas ut på
fakturan som ”Er referens” om ingenting annat skickas från försystemet i detta fält. Se mer i kapitel 8.
Flera adresser på samma kund
I Agresso finns möjlighet att ha flera adresser kopplade till en kund.
1. Generell
3. Faktura
4. Betalning
5. Påminnelse
Varje kund ska ha en generell adress (adresstyp 1) angiven. Alla utskick till kunden
(Fakturor/utbetalningsaviseringar/utbetalningskort och påminnelser) kommer att skickas till denna adress. Om
22 (42)
faktura/påminnelse ska skickas till annan adress ska också en adress 3 och/eller adress 5 läggas upp för kunden –
detta bör endast inträffa i undantagsfall eftersom den generella adressen finns där för fakturautskrift.
En avvikande betalningsadress måste anges om kunden skall få en utbetalning via utbetalningskort och
adressraderna överstiger 2* 35 tecken.
7.6
Kunder (betalningsmottagare) för utbetalning
I de fall utbetalning ska kunna ske till kund kan kontouppgifter registreras på kunden (annars sker utbetalningar via
utbetalningskort). Om försystemen inte har kontouppgifter måste detta kompletteras manuellt i Agresso för dessa
kunder. Det finns ett fåtal försystem där integrationen avser utbetalningar och dessa kommer i normalfallet att ha en
egen kundgrupp där kunder uppdateras via (CS15). Om bg/pg/bankkonto saknas på dessa kunder ska upplägg av
adressuppgifter på kund göras på annat sätt eftersom endast två adressrader (2*35) skickas med på
utbetalningskort. (Regler tas fram med berörda förvaltningar när behovet uppstår.)
För manuella utbetalningar kan försystemens kundgrupper eller kunder från manuella kundgruppen användas.
Betalningsadress kan då behöva kompletteras för att adress på utbetalningskort skall bli korrekt.
7.7
Betalningsvillkor, kravkod och betalningsmetod
Betalningsvillkor för faktureringen kopplas till varje kundgrupp och villkoret gäller då för alla fakturor till alla kunder i
kundgruppen om inget annat anges för kund/faktura. På alla kundgrupper som lagts in i Agresso från start har
betalningsvillkoret 30 dagar angivits. För varje integration ska förvaltningen verifiera om detta gäller eller om något
annat betalningsvillkor ska gälla för kundgruppen/försystemet. Lista över betalningsvillkor finns i tabellverk till CS15
och LG04. Eftersom betalningsvillkoren ärvs ner till kunderna inom kundgruppen ska elementet betalningsvillkor
normalt lämnas blankt i både CS15 och i LG04. Om betalningsvillkoret ska vara något annat för en faktura ska ett
avvikande betalningsvillkor anges i försäljningsordern (LG04). Det går inte att ange förfallodatum i försäljningsordern
(LG04) utan ett annat betalningsvillkor måste skickas med, t ex 1 dag eller 10 dagar. Om betalningsvillkoret ska vara
avvikande för en viss kund/-er inom en kundgrupp kan ett avvikande betalningsvillkor skickas med i kunduppgiften
(CS15).
Kravkod anger vilka reglerna ska vara vad gäller krav och räntevillkor vid utebliven betalning. Kravkoden hämtas
från kundgruppen och ärvs ner till kunderna inom denna. Om kravkoden ska vara annorlunda för någon kund i
kundgruppen kan uppgifter om avvikande kravkod skickas med i filen från försystemet (CS15).
Betalningsmetod ska alltid vara IP för externa kunder. Detta kan inte ändras på kundnivå från försystemen (fast
värde i CS15). Det innebär att om en utbetalning ska göras till kunden kommer den att ske utifrån följande ordning: 1
PG, 2 BG, 3 Bankkonto, 4 Utbetalningskort (om uppgifterna 1-3 saknas). Detta är samma ordning som gäller för
leverantörsbetalningar.
De kunder som vill betala sina fakturor med autogiro kommer att ha betalningsmetod = AG. Denna uppgift kommer
inte från försystemen utan uppdateras via autogirorutinen och ändras inte tillbaka till IP när uppdateringar läses in
från försystemet. Om en kund har anmält autogiro kommer också en eventuell utbetalning alltid att ske till det
bankkonto som anmälts för autogiro.
För att veta om kunden skall ha en e-faktura istället för en pappersfaktura finns det en relation på kunden som heter
fakturatyp. Denna underhålls inte från försystemen utan via information från fakturadistributör eller manuellt.
7.8
Ordernummertyp
Ordernummertyp är en tvåställig kod som bl a används för att styra hur en order ska hanteras; hur den ska skrivas
ut, vilka attestregler som ska gälla faktureringen, om ordern ska bli en faktura/kreditfaktura eller en utbetalning.
Försäljningsorder som kommer från försystem har en unik ordernummertyp som anger från vilket försystem som
försäljningsordern har sitt ursprung. Denna ordernummertyp skickas med i respektive LG04-fil. Till denna
23 (42)
ordernummertyp kopplas de hanteringsregler som ska gälla för nummertypen i inläsningsreglerna. Dessa
ordernummertyper har formatet F* och G*.
Vid manuell orderregistrering måste användaren välja rätt ordertyp för att få korrekt hantering av fakturan vad gäller
attest och utskrift. Dessa ordernummertyper har en två-ställig bokstavskod (AA, AB etc) .
Vid fakturering i Agresso översätts ”Ordernummertyp” till ”Verifikationstyp”. I normalfallet finns en verifikationstyp för
varje ordernummertyp. De ordernummertyper som gäller för respektive integration framgår av tabellverket till LG04.
7.9
Artikel/Artikelgrupp
När integrationen från försystemet avser en försäljningsorder (LG04) som ska faktureras i Agresso används artiklar
för att tala om vad som ska utgöra faktureringsrader. På artikel/fakturarad hänger också konteringen, varje
fakturarad kan endast ha en kontering.
De artiklar som kan användas från försystemen måste vara upplagda i Agresso med artikelkod och
artikelbenämning. Varje artikel ingår i en artikelgrupp till vilken konto och momskod finns kopplad. Genom att välja
artikel väljer man alltså vilket konto som intäkten ska konteras på och vilken moms-% som ska användas för
beräkning av momsen. I grundkonfigurationen för Agresso har ett antal gemensamma artikelgrupper/artiklar för
försäljningsorder lagts upp. Artikelgrupperna och artiklarna, som har samma artikelkod och artikelbenämning, har
betecknats utifrån konto och moms-%. Artikel 301125 innebär konto 3011 och 25 % moms. Försystemet väljer alltså
vilket konto och vilken momssats som ska gälla för respektive faktureringsrad genom att välja rätt artikelkod. (Rent
tekniskt är det möjligt att skicka med både konto och momskod i LG04 i de fall dessa skulle avvika från
artikelgruppens men detta bör inte nyttjas om inte särskilda skäl skulle tala för detta.)
Förvaltningen kan behöva lägga upp andra artiklar för försäljningsorder i Agresso än de som lagts upp från start. En
anledning kan vara att det i försystemet redan finns artiklar och då kan det vara bra att lägga upp dessa i Agresso
så att man i integrationen endast behöver ange artikelkod. Detta kan vara ett sätt att underlätta underhåll eftersom
förvaltningen själva kan ändra artikelbenämningen utan att koppla in försystemleverantören.
Det är möjligt att till en artikel i Agresso koppla en komplett kontering (ansvar, spec., verk etc.) eller delar av den
vilket också kan vara en anledning till att fler artiklar läggs upp i Agresso. Om konteringen som ska gälla för en
artikel inte finns tillgänglig eller inte är möjlig att underhålla i försystemet kan detta vara en bra lösning.
De artiklar som förvaltningarna själva lägger upp ska läggas upp i de gemensamma artikelgrupper som finns
upplagda.
Artikelbenämningen blir den text som visas på fakturaraden. Vilken text som ska presenteras avgörs via
integrationen – om endast artikelnummer finns med i LG04 kommer Agresso att presentera den artikelbeskrivning
som finns i Agresso – om försystemet skickar med en egen text är det den som visas. Om försystemen använder
någon av de ovan beskrivna gemensamma artiklarna måste försystemet skicka med den text som ska visas på
fakturaraden i elementet för artikelbenämning i LG04 eftersom artikelbenämningen inte beskriver vad som
faktureras (t ex 301125).
För varje artikel måste också anges vilken måttenhet som gäller för artikeln. Det är möjligt att ange mer än en
måttenhet när artikeln läggs upp och från start har enheterna för alla artiklar som lagts upp i Agresso angetts till ”st”
eller blank (.). När försystemet skickar en försäljningsorder är måttenhet obligatorisk att skicka med och den måste
vara en av de måttenheter som är kopplad till artikeln. Det är möjligt att lägga till andra måttenheter på befintliga
artiklar – varje förvaltning måste signalera till projektet om behovet uppstår. I ”Tabellverk för LG04” framgår de
artiklar som finns tillgängliga från start och vilken måttenhet som godkänns för respektive artikel.
De artiklar som lagts upp från start är gemensamma för samtliga redovisningsenheter men endast de som är
aktuella för respektive förvaltning/grupp av förvaltningar kommer att läggas upp i respektive redovisningsenhet. Det
innebär att varje förvaltning i samband med förberedelserna måste identifiera vilka konton som är aktuella för
fakturering i förvaltningen (både för manuell fakturering och fakturering via integration) och vilka
artikelgrupper/artiklar som därför måste finnas i redovisningsenheten. De artiklar som varje förvaltning därutöver
24 (42)
lägger upp kommer endast att finnas i den aktuella redovisningsenheten. Namnsättningen (artikelkod) för dessa
måste systematiseras utifrån förvaltningens behov.
När utbetalningar ska göras via negativ försäljningsorder ska också artiklar användas. Särskilda artiklar för detta
ändamål kommer att behöva läggas upp. Inga gemensamma artiklar har ännu lagts upp, utan behovet måste
kartläggas i samarbete med de förvaltningar som kommer att använda sig av detta. Det är viktigt att ta hänsyn till
användningen av momskod så att momshanteringen blir korrekt.
Utöver artikelraden är det möjligt att skicka med ytterligare (obegränsat antal) textrader som placeras under
artikelraden på fakturan. Dessa kan användas för att ytterligare specificera vad som faktureras. Det är också möjligt
att lägga till dessa rader direkt på artikeln i Agresso för att undvika att dessa måste skickas vid varje tillfälle. Se
vidare i kapitel 8.
Vid fakturering till en N/I-kund skall i första hand artiklar med momskod 23 användas. I det fall förvaltningen
fakturerar samma sak till både externa och interna kunder kan en artikel med annan momskod användas. Agresso
kommer då inte att skapa någon moms på fakturan och kommer att vända den moms som skapas i samband med
bokföringen av fakturan.(Alla interna (N/I)-kunder har ett uppgift om ”momssystem = MM” vilket gör att momsen
vänds bort).
7.10 Utgående moms
När en försäljningsorder (LG04) integreras ska utgående moms inte skickas med från försystemet eftersom Agresso
beräknar momsbeloppet i samband med faktureringen. Samma sak gäller vid manuell registrering av en
försäljningsorder. Beräkningen görs utifrån angiven momskod på artikelraden, som alltid ska vara 20-25 enligt tabell
under kapitel 4.1. Vid integrationen skickar försystemen normalt inte momskoden utan denna hämtas istället från
den artikel som artikelraden anger.
För 0 % moms finns två momskoder; momskod 0 och momskod 23. Vid fakturering där moms inte ska debiteras (0procent moms) måste momskod 23 användas för att fakturautskriften ska bli korrekt (för Svefaktura). Fakturering
sker alltid i försystem eller i faktureringsmodulen i Agresso och all fakturering utgår från artikel. Vilken artikel som
ska användas avgörs utifrån konto och momskod. Alla artiklar som läggs upp för momsfri försäljning kommer att ha
momskod 23 angiven med automatik vilket gör att användaren inte behöver välja momskod.
Vid manuell fakturering är det därför viktigt att användaren inte ändrar konto eller momskod från det som är angivet
för artikeln. Om artikel saknas för kombinationen konto och moms % ska en ny artikel läggas upp. För vissa konton
är endast 0-% moms tillåten – denna kontroll måste alltid göras innan en ny artikel läggs upp med annan momssats.
7.11 Fakturering skapar debet- och kreditfakturor
En försäljningsorder som är positiv leder till att en faktura skickas till kunden. En försäljningsorder kan också ha ett
negativt belopp och då kommer denna vid faktureringen att bli en kreditfaktura som skickas till kunden.
Kreditfakturor som skapats från negativa försäljningsorder från försystem kommer alltid att skickas ut till kund. Om
försystemet inte kan skapa underlag för krediteringar görs dessa istället manuellt direkt i Agresso som en negativ
försäljningsorder. I dessa fall använder man kunder i samma kundgrupp som försystemet normalt använder. När en
negativ försäljningsorder görs manuellt kan man via val av ordernummertyp också ange att kreditfakturan inte ska
skickas till kund.
Faktureringen sker genom att en faktureringskörning startas (SU13). Vid faktureringskörningen kör man normalt alla
faktureringsklara ordrar. Det är möjligt att köra faktureringen för en enskild order. Det är också möjligt att välja att
endast fakturera externa (X/B/K) eller endast interna (N/I).2 Detta möjliggör att en fil kan innehålla försäljningsorder
till både interna och externa kunder trots att faktureringen till dessa måste ske vid olika tillfällen beroende på de
datum som gäller för fakturering av interna mellanhavanden.
2
Detta görs genom urval på en relation på motpart (Exin1).
25 (42)
I de fall en kreditfaktura från ett försystem skall kvittas mot en debetfaktura finns det möjlighet för försystemet att
skicka med debetfakturans fakturanummer (Agresso-id) i försäljningsordern. I samband med faktureringen kommer
då krediten att betalas mot debetfakturan (helt eller delvis). Fakturanummer skall då ligga i Text 1 i LG04.
I samband med faktureringen kan också fakturadatum och bokföringsperiod för faktureringen anges,(om inte blir den
samma som aktuell period). Det innebär att bokföringsperiod kan bestämmas när faktureringen görs.
Försäljningsorder som kommer till Agresso någon av de första dagarna i en ny månad kan vid faktureringen styras
till föregående bokföringsperiod (om den fortfarande är öppen).
För internfakturering (N- och I-kunder) måste fakturadatum ligga inom vald bokföringsperiod. Om fakturadatum t ex
är 2014-09-02 så måste bokföringsperiod vara 201409. Detta för att leverantörsfakturan i Winst ska bli bokförd i rätt
period hos köparen. Bokföringsperiod styrs i Winst av fakturadatum; en faktura med fakturadatum i september får
bokföringsperiod 201409, om den inte anländer efter att september har stängts.
Faktureringskörningen kan göras manuellt eller maskinellt (genom att lägga körningen på klocka). I början kommer
all fakturering att ske manuellt. Innan den definitiva faktureringskörningen finns det möjlighet att köra en
testfakturering (eller köra en browserfråga som listar de fakturor som är klara att fakturera) och denna kan användas
för att kontrollera rimlighet etc. innan fakturering sker.
7.12 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). När en försäljningsorder mot en N-kund faktureras kommer denna faktura att skickas till Winst. Det är viktigt
att alla interna fakturor innehåller uppgift om mottagarkod eller motsvarande 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 (ett utläsningsfiler) som gör att fakturan
skickas till Winst och inte till Strålfors.
När det gäller I-kunder avgör varje förvaltning om det ska förekomma köp/sälj inom förvaltningen. Om så är fallet
måste varje förvaltning avgöra vilka interna kunder och leverantörer som förvaltningen har behov av och dessa
måste läggas upp som kunder och leverantörer.
I samband med faktureringen av försäljningsorder mot N- och I-kunder kommer en kundfaktura att skapas samtidigt
som kundfordran och intäkt bokförs. Denna kommer att skickas som en elektronisk faktura till Winst och kommer att
läsas in i kundförvaltningens Winst-organisation där den hanteras som en vanlig leverantörsfaktura. Om det finns en
inköpsorder som kan matchas mot fakturan kommer konteringen att ske omgående, om inte kommer det att ske en
tidsförskjutning mellan när kundfakturan bokförs och när motsvarande leverantörsfaktura slutkonteras och bokförs.
Ankomstregistrerade leverantörsfakturor kommer inte att bokföras skarpt i Agresso förrän vid månadsslutet (i
samband med att Winst stängs för ankomstregistrering). Förvaltningen måste se till att dessa fakturor slutkonteras
så snart som möjligt i Winst för att undvika differenser i internavstämningen. Vid bokslut måste alla
leverantörsfakturor från I-leverantörer vara slutkonterade för att saldot på Ex/In 6 ska vara noll
(kundfordringar/levskulder). Motsvarande gäller även N-fakturor.
Det är också viktigt att fakturering sker inom givna tidsramar. Om filerna från försystemet innehåller försäljningsorder
till både interna och externa kunder är det möjligt att köra faktureringen för dessa vid olika tillfällen genom urval på
EXINGRP (relation på motpart). Detta för att inte internfakturering ska ske efter utsatt sista datum i månaden.
Uppgift om periodisering och kontering från kundfakturor kan inte flyttas med till leverantörsfakturan i Winst
automatiskt. För att kunden ska kunna se den i Winst måste den anges som textrad på fakturan.
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). Matchning sker i en särskild betalningskörning som kommer att
hanteras av Intraservice. Matchning kommer att ske både inom förvaltning och mellan förvaltningar. Matchningen
kommer att ske i de fall samma fakturanummer finns som både kundfaktura och slutkonterad leverantörsfaktura för
de kunder/leverantörer som har betalningsmetod IN.
B/K kunder har inte betalningsmetod IN och kommer att betalas som externa fakturor.
26 (42)
7.13 Sammanfattning - skillnader mellan LG04 till interna och externa kunder
Hänvisning till filspecifikation LG04.
LG04
Innehåll - kund X
Innehåll - Kund B/K
Innehåll - Kund N/I
<agrlib:Text1>
Ref till debetfaktura (i
kreditfaktura)
Ref till debetfaktura (i
kreditfaktura)
Ref till debetfaktura (i
kreditfaktura)
<agrlib:Text2>
Blank
Blank
Blank
<agrlib:Text3>
Försystemets Kund-id
Blank
Blank
<agrlib:Text4>
Försystemets
referensnummer
Försystemets
referensnummer
Försystemets
referensnummer
<agr:BuyerNo>
Blank
Agresso Kund-id
Agresso Kund-id
<agr:Accountable>
Köparens referenskod.
Köparens
referenskod.
Abonnemangsnummer /
mottagarkod / annan
referens – ska alltid
lämnas för att fakturan ska
skickas till rätt granskare i
Winst.
<agr:BuyerProductCode>
Artikelkod
Artikelkod
Artikelkod
<agrlib:TaxCode>
Momskod - ska normalt
vara blankt - hämtas från
artikel
Momskod - ska
normalt vara blankt hämtas från artikel
Momskod - ska normalt
vara blankt - hämtas från
artikel,
<agrlib:AllocationKey>
Periodiseringsnyckel
Periodiseringsnyckel
Periodiseringsnyckel
<agrlib:Info>
Textrad
Textrad
Textrad - kan utnyttjas för
att överföra information om
periodisering och
kontering
7.14 Utbetalningar (vid sidan av Winst)
I de fall en utbetalning ska göras till en kund eller privatperson (och det inte rör sig om en utbetalning av en
kreditfaktura eller ett eventuellt plussaldo/kundtillgodohavande) ska dessa hanteras via negativa försäljningsorder
med en avvikande ordernummertyp. Dessa utbetalningar hanterades tidigare i PC-lev. Det är endast ett fåtal
försystem som skickar sådana utbetalningar via integration. Merparten av dessa registreras manuellt i PC-lev idag
och kommer att registreras i Agresso via manuell orderfakturering (negativt belopp).
Dessa utbetalningar kommer att läggas upp i kundreskontran som en negativ faktura på samma sätt som en
kreditfaktura men kommer att betalas ut via ordinarie leverantörsbetalningsrutin på angiven förfallodag (utifrån
betalningsvillkor för kunden/eller angivet i försäljningsordern). Det krävs en utbetalningskörning (betalningsförslag
och betalningsbekräftelse) körs av förvaltningen för att utbetalningarna skall vara klara för utbetalning. I samband
med detta kommer också betalningsattest att utföras för utbetalningarna.
För utbetalningar till kund kommer en avisering att skapas som skickas till kunden för att ange vad beloppet som
kommer att utbetalas avser. Av artikeltext och textrader ska framgå vad utbetalningen avser. Aviseringen kommer i
27 (42)
princip se ut som en kreditfaktura och på aviseringen kommer ett OCR-nummer att anges. När utbetalningen görs
kommer detta OCR-nummer att anges som referens. Ingen övrig betalningsinformation kan skickas med på
utbetalningskortet.
I de fall försystemet skickar utbetalningar ska en motsvarande (CS15) finnas för registrering av kunder. De
försystem som skickar utbetalningar kommer att ha en egen kundgrupp för dessa. När en kund registreras ska
också kundens pg/bg/bankkonto registreras om utbetalning skall ske till konto. Om försystemet inte kan skicka
kontonummer kan detta registreras manuellt.
När utbetalning ska ske av en kreditfaktura eller ett plussaldo ska detta hanteras direkt via kundreskontran.
7.15 Utskrift av fakturor mm
Samtliga fakturor som kommer från försystem kommer som tidigare att skrivas ut via externt printhus (fn Strålfors).
Debetfakturor kommer att ha en inbetalningsavi; kreditfakturor och utbetalningsaviseringar kommer att skrivas ut
utan avi.
För fakturor som skapats manuellt kommer det att vara möjligt att (i undantagsfall) välja lokal utskrift (genom att
välja en viss ordernummertyp). Detta kan vara tillämpligt när bilagor ska bifogas med en faktura. En lokalt utskriven
faktura kommer att skrivas ut utan inbetalningsavi. Det kommer att vara möjligt att göra det även för enstaka fakturor
från försystem.
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 varifrån fakturan kan hämtas vid eventuella frågor
kring fakturan och kan skrivas ut om kunden vill ha en fakturakopia. Det finns också en rutin för att köra en
fakturakopia som skrivs lokalt (med överskrift ”Fakturakopia”) och en möjlighet att köra fakturakopior via Strålfors
(utan överskrift fakturakopia). Den sistnämnda är till för att vid behov kunna köra om en fakturautskriftsfil.
Påminnelser kommer också att skrivas ut av printerföretaget. Dessa kommer också att innehålla inbetalningsavier.
Dessa kommer inte att kunna visas i dokumentarkivet.
Dröjsmålsräntefakturor kommer också att skrivas ut av printerföretaget. Dessa kommer också att innehålla en
inbetalningsavi
7.16 Påminnelse och Dröjsmålsräntedebitering
Hantering av påminnelser och dröjsmålsräntor avgörs av kravkoden på kundgruppen/kunden. Det går inte att ändra
kravkod på en enskild faktura.
Påminnelser kommer att skickas ut enligt nuvarande kravrutiner för fakturor som överstiger 50 kronor och kommer
att skickas om fakturan är obetald 7 dagar efter förfallodag. Påminnelsen kommer att innehålla en inbetalningsavi
och det kommer att vara möjligt att påföra en påminnelseavgift (bestäms per kravkod). Denna kommer då att ingå i
påminnelsen och bokföras direkt vid påminnelsekörningen. Påminnelsen blir en ny faktura med ett nytt OCRnummer. Detta OCR-nummer är lika långt som OCR-numret för en faktura (13p). Kunden kan välja fakturans eller
påminnelsens OCR vid betalning.
Påminnelser kommer att skickas både för vanliga fakturor och för räntefakturor. Påminnelse skickas också för öppna
kreditfakturor. Kreditfakturor tas med vid påminnelsen
Obetalda fakturor under 50 kronor kommer inte att påminnas och förvaltningen måste löpande rensa bort obetalda
sådana genom att ange dessa med W och hantera dem enligt rutin för konstaterade kundförluster.
En obetald påminnelseavgift kommer att påminnas igen om den överstiger lägsta belopp för påminnelse och går
därefter till inkasso. Om kunden betalar ursprungsfakturan vid påminnelse och alltså inte betalar påminnelseavgiften
måste denna skrivas bort manuellt. Om någon förvaltning skall använda sig av påminnelseavgift bör undre gränsen
för när en faktura påminns anpassas till denna. Kommer det att läggas en påminnelseavgift på påminnelseavgifen?
28 (42)
Referensen från fakturan kommer att skrivas ut på påminnelsen och förvaltningen kan bestämma om fältet ”Vår
referens” på påminnelsen utöver detta skall ha en för förvaltningen gemensam referens i huvudet på påminnelsen
(som läggs i företagsuppgiften i Agresso).
Dröjsmålsränta kommer att hanteras något annorlunda än tidigare. Dröjsmålsräntor faktureras en ggr/månad på en
separat dröjsmålsräntefaktura och varje förvaltning sköter själv denna fakturering. Det kommer inte att vara möjligt
att föra över dröjsmålsräntan till nästa faktura istället för att fakturera separat. Lägsta belopp för
dröjsmålsräntefakturor är 50 kr. Dröjsmålsräntan bokförs vid faktureringskörningen, på en fast kontering per
redovisningsenhet (anges i konteringsregel för detta konto för förvaltningen). Vid dröjsmålsräntefakturering är det
möjligt att först köra ett förslag som visar vilka belopp som uppfyller kriterierna för fakturering. I samband med detta
kan belopp som inte ska faktureras parkeras eller tas bort.
Det går inte att automatiskt kreditera en dröjsmålsräntefaktura utan en kreditorder måste göras där en artikel för
dröjsmålsränta väljs.
Betalningsvillkoren för dröjsmålsräntor är 30 dagar.
”Vår referens” på dröjsmålsräntefakturor kommer att vara en gemensam för förvaltningen (samma som för
påminnelse).
Alla fakturor för vilka påminnelse har skickats kommer att överföras till inkasso om de efter ytterligare 14 dagar inte
är betalda (om kunden har en kravkod som säger att inkasso skall hanteras). Inkassokörning kommer att göras från
intraservice. Förvaltningen har möjlighet att ”parkera” en faktura som inte skall påminnas och/eller skickas till
inkasso. Dessa ”parkerade” fakturor måste följas upp löpande av förvaltningen3. Förvaltningen kan också vid behov
justera förfallodag eller lägga in en anståndsdag om man har gjort en överenskommelse med kunden om en
fördröjning av inbetalning. Flyttas förfallodagen kommer påminnelse- och inkassoprocess och
dröjsmålsränteberäkning att justeras utifrån det nya förfallodatumet. Om anståndsdatum läggs in kommer
påminnelse- och inkassoprocess att justeras utifrån detta datum men dröjsmålsränta beräknas efter ursprunglig
förfallodag.
7.17 Osäkra kundfordringar och konstaterade kundförluster
Intraservice kör varje vid varje månadsskifte en rutin för osäkra kundfordringar. Denna rutin söker ut alla externa
fakturor som är påminda och fortfarande obetalda 365 antal dagar efter fakturans förfallodag, och bokför dessa som
osäkra fordringar på konto 1593 Kredit och 7352 med övriga koddelsvärden från intäktstransaktionen. Rutinen tar
också hänsyn till eventuella delbetalningar. Rutinen körs varje månadsskifte och vid varje tillfälle bokförs
förändringar sedan föregående månadsskifte. Momsen påverkas inte i denna rutin.
För att skriva bort kundfordringar gör förvaltningen löpande en körning för konstaterade kundförluster. I denna
körning tas fakturor som har markerats för bortskrivning bort (status W eller T) bort ur reskontran samtidigt som
bokföring för dessa skapas. Fordringar som skickats till inkasso och där inkassobolaget återrapporterat att fordran är
slutreglerad kommer att sättas i status T. För att manuellt markera bortskrivning skall status på fakturan ändras till
W. Detta kan göras av förvaltningen (användare med viss roll).
Förvaltningen skall löpande köra förslag för kundförluster. Från detta förslag kan fordringar tas bort som inte skall
skrivas ner. I samband med detta skapas ett meddelande om att ett förslag körts (via funktionen intellAgent i
Agresso) till den hos förvaltningen som har attesträtt för kundförluster. Denna person skall då köra
bortskrivningsbekräftelse och fordringen blir avskriven och kundförlust bokförs i debet på konto 7351, motpart
hämtas från kund och övrig kontering kan ärvas från intäkt eller sättas fast för RE via konteringsregel för konto 7351.
Utgående moms reverseras också i samband med denna bokning.
Rollen att köra förslag och bekräftelse skall tilldelas olika personer för att säkerställa kontroll.
3
En reklamationskod ”EJ” skall samtidigt anges som anger skälet till varför fakturan parkerats.
29 (42)
8 Gemensam fakturalayout
Fakturalayouten kommer att vara gemensam för alla förvaltningar. Det är viktigt att varje försystem som skickar
försäljningsorder/kunduppgifter identifierar vilka fält i filen som kommer att presenteras på fakturan och beslutar
användningen av dessa så att fakturan blir så tydlig och komplett som möjligt. Vid särskilda behov kan det i
undantagsfall vara möjligt med en viss särhantering av fakturan hos printerföretaget. Detta kan t ex gälla när det
finns fast text som lämpar sig att trycka på baksidan av fakturan. Viktigt blir då att dessa undantag lätt kan definieras
med hjälp av artikelnummer, förvaltning, etc. (information som måste finns med i filen till printerföretaget).
I utgångsläget kommer endast fakturor med svensk text att produceras. Om behovet uppstår finns det möjlighet att i
framtiden sätta upp fakturalayouter där fasta texter skrivs på engelska.
8.1
Fakturahuvud
Datum = Fakturadatum= sätts vid faktureringen i Agresso i normalfallet till dagens datum.
Kundnummer = Kundnummer i Agresso.
Fakturanummer/OCR-nummer = OCR-nummer som bygger på Agressos fakturanummer med påhäng av längd
och checksiffra. Fakturanummer kommer att vara ett löpnummer ur en löpnummerserie per redovisningsenhet som
inleds med 7 och förvaltningens prefix. Fakturanummer kommer att vara samma som verifikationsnummer.
Förvaltningens adress kommer att visas till vänster om kundadressen. Adressen hämtas från företagsuppgiften i
Agresso. Adressens placering avgörs av att den ska visas på bästa sätt vid ev. retur av posten när adressaten inte
kan identifieras. Namnet hämtas ifrån fältet ”Rubrik” i Företagsuppgiften. Denna kan på så sätt sättas till
Förvaltningens namn.
Kundens namn och adress hämtas från kundregistret.
Vår referens: Detta fält ska ge kunden information om vem som kan kontaktas för frågor. Om förvaltningen vill visa
information i detta fält kan det fyllas på två olika sätt från integrationen;
1. Försystemet skickar med ”användar-id i Agresso” för den som ska stå som referens i fältet ”Responsible”. Vid
fakturautskrift kommer då användarens namn att anges i klartext tillsammans med det telefonnummer som
registrerats för användaren i Agresso. Försystemet måste då ha information om användar-id för de personer som
ska kunna vara referenser. Förvaltningen kan också lägga upp ”dummyanvändare” som försystemet kan hänvisa till
i det fall man vill att referensen skall vara någon annan än en Agresso-användare. Dessa användare skall då ha
användar-id i formatet ZZprefix+7pos.
2. Försystemet kan skriva ett namn/telefonnummer i klartext. Fältets längd är då max 25 tecken.
Om informationen i ”Vår referens” måste vara mer omfattande finns möjligheten att lämna detta fält tomt och istället
använda något av fälten ”Fakturatext” eller ”Bottentext” för detta ändamål.
Vårt ordernummer: Här skrivs Agressos försäljningsordernummer ut.
Er referens: Om försystemet har information om vem som ska vara mottagare av fakturan anges denna här. Det
kan vara ett namn, en mottagarkod, abonnemangsnummer etc. För fakturor till privatpersoner lämnas fältet i
normalfallet blankt. Om förvaltningen har lagt in en kontaktperson på kundens adress kommer den personens namn
att skrivas ut i detta fält för alla fakturor där försystemet inte skickar någon annan information.
Ert ordernummer: Om försystemet har information om kundens ordernummer ska detta anges här. När Winst
kommer att användas för beställningar mellan förvaltningar kan detta fält bli viktigt för att uppnå ordermatchning.
30 (42)
8.2
Fakturaspecifikation
Överst på fakturan visas överskrifterna: Fakturan avser, antal, enhet, a-pris, Moms%, Moms och Belopp. Varje
fakturarad kommer att innehålla alla dessa uppgifter - även om någon av dem är 0. Notera också att Belopp på rad
avser belopp exklusive moms. Totala beloppet inklusive moms kommer att presenteras längst ner på fakturan.
Försystemet kommer att för varje artikel skicka information om antal, enhet och totalbelopp exkl moms. A-priset
kommer alltid att beräknas av Agresso. Tänk på det om fakturaraden avser flera enheter med olika enhetspris.
Under överskriften kommer en fast Fakturatext att visas. Denna text kan vara max 255 tecken. Fakturatexten läggs
upp i Agresso och kopplas till fakturan i samband med faktureringen. Det går inte att styra radbrytning i fältet när
texten läggs upp utan detta måste anpassas efter test av utskrift (beror på typsnitt och teckenstorlek). Detta fält kan
användas för mer omfattande information om vem som ska kontaktas vid frågor eller annan – för fakturorna
gemensam information. Varje redovisningsenhet kan definiera sina egna texter men dessa registreras i en
gemensam tabell varför detta görs av central systemförvaltare. Försystemet ska alltså inte skicka med denna text.
Under Fakturatexten visas Huvudtext. Informationen i detta fält ska gälla hela fakturan och ska ange vad fakturan
avser. Det finns endast en huvudtext per faktura. Försystemet skickar i normalfallet med det som ska stå på denna
rad. Informationen på denna rad ska kunna skickas med vid eventuellt vidareskick av fakturan till inkasso.
Informationen i huvudtext kan vara mera allmän, t ex Barnomsorg men kan också rymma annan mer för fakturan
specifik information såsom period, person etc. Tänk på att försystemet måste skicka med huvudtexten precis som
den ska skrivas ut – med både fast och variabel text. Fältet är max 2 rader * 60 tecken och försystemet måste
anpassa texten med blanksteg så att utskriften blir korrekt.
Om försystemet inte skickar med någon huvudtext finns det möjlighet att lägga en för förvaltningen fast huvudtext i
Agresso i ett fält som heter DEF_SO_LONG_INFO1. Samma information kommer då att visas på alla fakturor. Detta
fält är endast 25 positioner. För en förvaltning med begränsad fakturering kan detta vara ett alternativ att använda.
Under huvudtexten presenteras de olika Artikelraderna. Varje artikelrad från försystemet blir en fakturarad med
antal, enhet, a-pris, moms och belopp. Till varje artikelrad kopplas också en kontering vilket innebär att varje unik
kontering måste vara en egen artikelrad; viktigt att ta hänsyn till om det är ett totalbelopp som faktureras.
För varje försystem måste identifieras vad som är en artikel. Samma artikel (artikelkod) kan förekomma på flera
rader med olika text. På fakturan visas endast artikelbenämning medan försystemet skickar både artikelkod och
benämning. Artikelbenämningen kan vara max 35 positioner för att ge plats till antalskolumnen.
Under varje artikelrad kan ett obegränsat antal textrader läggas. Varje sådan textrad kan vara 60 positioner och
försystemet skickar dessa – och kan med hjälp av blanksteg styra hur texten ska visas. Det är också möjligt att
lägga in specrader direkt på artikeln vilket kan vara ett alternativ för de förvaltningar som har återkommande
spectexter som är kopplade till unika artiklar. Dessa specrader läggs då in i på artikeln i redovisningsenheten och
behöver inte skickas med i LG04-filen.
Om en blankrad ska skapas mellan artiklar/textrader löses det bäst genom att en textrad läggs in med ett
sekvensnummer utan att någon text anges. Det går också att lägga in en punkt (.) i raden, och Strålfors kommer
alltid att ta bort en ensam punkt (.) vid utskrift.
Längst ner i fakturaspecifikationen finns en Bottentext. Det finns endast en bottentext per faktura. Bottentexten är
precis som huvudtexten max 2*60 positioner och ska skickas med från försystemet. Bottentexten bör användas för
referens till försystem (ordernummer och/eller kundnummer) om det underlättar för kunden att denna visas på
fakturan. I en förvaltning med begränsad fakturering finns det möjlighet att lägga fast bottentext i Agresso i fältet
DEF_SO_LONG_INFO2. Detta fält har max 25 positioner.
8.3
Fakturafot
Längst ner på fakturan visas fasta fakturauppgifter. Dessa är gemensamma för samtliga förvaltningar och fakturor.
Det finns möjlighet för förvaltningen att välja att visa sitt eget telefonnummer istället för stadens gemensamma. Detta
kommer då att gälla för samtliga förvaltningens fakturor. Förvaltningens telefonnummer ska då registreras i
företagsuppgiften i Agresso.
31 (42)
9 Bokföringsorder
Bokföringsorder kan göras manuellt i Agresso, via ”Excelerator”-mallar eller läsas in från försystem. Bokföringsorder
kommer att registreras direkt i Agresso i större utsträckning än idag. Vid registrering i Agresso kommer konteringen
att kontrolleras direkt vid registreringen och den som registrerar får också hjälp av konteringsregler så att rätt
koddelar visas. Det går också att skapa mallar som kan återanvändas vid registrering för att underlätta
registreringen. ”Dagrapporten” kommer vid övergång till Agresso att hanteras som en sådan. Det går dock inte att
klippa och klistra vid registreringen av dessa mallar.
Om behov finns att klistra in transaktioner från annat underlag och antalet transaktioner är omfattande kan
bokföringsorder via Excelerator-mall underlätta vid registrering. Möjlighet ges då att klistra in transaktioner i mallen
från ett annat underlag (det går ej att klistra in från annat underlag när man gör bokföringsordern direkt i Agresso).
Ifylld Excelerator-mall måste sedan föras över till Agresso och först i samband med denna inläsning sker kontroll av
giltiga koder etc. I och med att det inte finns kontroller i själva mallen bör Excelerator-mall användas i begränsad
omfattning. Enbart användare av Agresso Desktop kommer ha tillgång till Excelerator-mallarna för bokföringsorder
(pga. tekniska begränsningar är Excelerator-mallarna ej åtkomliga för Web-användare).
Bokföringsorder med reversering i nästa period (”vändas”) med elektronisk attest kan enbart göras via Exceleratormall (vertyp H8). Om denna vertyp används direkt i Agresso kommer den automatiska vändningen att bli fel.
För integration av löner, kontantförsäljning, fördelningar etc. ska filen till Agresso ha GL07-format. Filen innehåller
alla de fält som finns på en bokföringstransaktion i huvudboken och varje verifikation ska balansera D/K. I en vanlig
GL07 ska motpart anges, märk dock att för de konton som har en fast motpart finns det en konteringsregel som
lägger ut rätt motpartskod – även om en annan kod registreras.
9.1
Moms
Om en bokföringsorder integreras från ett försystem sker ingen automatisk momsberäkning. När en bokföringsorder
(GL07/GL07-AP) som avser momspliktig försäljning, t ex från system för kontantförsäljning eller en utbetalning som
skall reducera försäljning, skickas till Agresso skall momsbeloppet finnas med som en konteringsrad i respektive
verifikation. För att hanteringen i Agresso skall bli korrekt skall den konteringsrad som genererat den utgående
momsen förses med momskod (20-22) och utgående momstransaktionen skall förses med momskod och
ursprungskonto. Se vidare i avsnitt 9.4 och tabellverk till GL07. Alla övriga konteringsrader i bokföringsordern
(GL07/GL07-AP) skall ha momskod 0.
När en BFO som innehåller bokningar på intäktskonton registreras manuellt i Agresso kommer momstransaktionen
att beräknas automatiskt utifrån momskoden som anges på intäktstransaktionen. Denna kan vara fast (när man
använder ett konto som endast kan ha en momssats (t ex 369*) eller anges av den som registrerar BFO. Om ingen
moms skall utgå skall momskoden anges till 23 (moms 0%).
9.2
Utbetalningar till företag och organisationer (GL07-AP).
De försystem som tidigare skickade filer till PC-lev för utbetalningar till företag och organisationer ska nu istället
skicka en fil med bokföringsorder med leverantörskoppling (GL07-AP). Undantagna är ProCapita som skickar filer till
Winst. I princip innebär detta att en leverantörsfaktura och bokföring av denna skapas för varje utbetalning. I filen
ska Agressos Lev-id anges som betalningsmottagare – alltså inte den leverantörsidentitet som finns i försystemet. I
transaktionstexten ska den information som utöver leverantörsfakturanumret ska skickas till leverantören anges. När
utbetalning görs kommer fakturanummer och transaktionstext att skickas med till betalningsmottagaren enligt nedan:
Betalning till PG eller BG; fakturanummer + transaktionstext max 10*35 tecken
Betalning till bankkonto; fakturanummer + transaktionstext max 11 tecken
Betalning via utbetalningskort; fakturanummer + transaktionstext max 10*35 tecken
32 (42)
Nedan, i kapitel 9.5, finns en ifyllnadsanvisning för de olika typerna av transaktioner som en GL07 fil kan innehålla. I
en GL07-AP ska motpart inte registreras – den ska hämtas från motpartsuppgiften som finns på leverantören, (av
den anledningen måste Lev-id skickas med i alla transaktioner).
Andra utbetalningar skall inte hanteras via bokföringsorder utan skall hanteras som negativa försäljningsorder,
betalas via Winst eller i undantagsfall betalas via internetbank.
I det fall förvaltningen tillämpar självfakturering gentemot sina leverantörer skulle ett alternativ vara, att istället för att
göra utbetalning via GL07-AP, upprätta en negativ faktura via försäljningsorderrutinen. Regelverket för
självfakturering säger att en sådan hantering måste föregås av avtal om självfakturering med leverantören, att
faktura ska vara benämnd ”självfaktura” och att separat nummerserie ska finnas per leverantör. I nuläget finns ingen
sådan faktureringsrutin uppsatt i Agresso men om förvaltningen identifierar ett sådant behov kan en sådan lösning
komma att skapas.
9.3
Leverantörer/betalningsmottagare
Samtliga leverantörer läggs i Agresso upp i ett för alla redovisningsenheter gemensamt leverantörsregister. Id för
externa leverantörer består av ett löpnummer 6 positioner 100000 – 999999. Merparten av leverantörerna läggs upp
av Ekonomienheten på Intraservice i samband med att leverantörsfakturor läses in.
I det fall förvaltningen skickar utbetalningar från försystem (GL07-AP) och behöver lägga upp nya
betalningsmottagare måste upplägg av leverantör göras av Intraservice innan leverantören kan användas för
registrering av utbetalningsuppdrag.
Alla svenska leverantörer ligger i en och samma leverantörsgrupp. Samtliga externa leverantörer har
betalningsmetod IP och prioritetsordningen för utbetalning till leverantörer är densamma som för kunder.
För leverantörsskulden i Agresso kommer nya konton att läggas upp; 2513 (X/B/K) och 2514 (N/I) för
leverantörsskuld och 1623/1625 för ankomstregistrerade fakturor d:o.
För interna leverantörer (N och I) – som endast ska användas vid förvaltningsintern/kommunintern försäljning (se
kapitel 7.11) är Lev-id samma som Kund-id. De interna leverantörerna ligger i en egen leverantörsgrupp som har
betalningsmetod IN för att kunna kvittas mot motsvarande kundfakturor.
Följande relationer används på leverantör:
Motpart (obligatorisk), Winst, Factoringbolag (Endast i KC01)
5/18 (flagga för att markera leverantörer som skall tas med i beräkning av 5/18, i respektive RE)
9.4
Kundfakturor som inte har skapats i Agresso
I undantagsfall görs inte faktureringen i Agresso utan färdiga kundfakturor läses in till kundreskontran och bokförs i
samband med detta. För att göra detta ska GL07 med kund-koppling GL07-AR användas. För varje kundfaktura
anges kontering, Kund-id, kundfakturanummer/OCR-nummer och förfallodag. Om förfallodag lämnas blank skapas
förfallodag utifrån kundens betalningsvillkor. Verifikationsdatum betraktas som fakturadatum. Påminnelser och
dröjsmålsräntor kan skapas enligt ordinarie rutiner i Agresso också för dessa fakturor.
9.5
GL07 – Ifyllnadsanvisningar
Nedan presenteras en sammanställning av hur GL07 (med eller utan AR/AP-koppling ska fyllas i för var och en av
de olika transaktionstyperna som ingår).
GL07-AR – för import av kundfakturor och bokföring d:o
GL07-AP – för import av levfakturor/utbetalningar och bokföring d:o
33 (42)
GL07 – för import av bokföring
<agrlib:TransType>
Transaktionstyp
<agrlib:Description>
Transaktionstext
<agrlib:Status>
<agr:TransDate>
Verifikationsdatum
Om integrationen avser
leverantörsfakturor/utbetalningar
– skuldtransaktionen
Om integrationen avser
kundfakturor fordringstransaktionen
AP/AR
Transaktioner för
ingående eller
utgående moms.
Alla övriga
transaktioner
TX
GL
Text till betalningsmottagare
Valfri
Valfri
N
Överförings datum. Blir
fakturadatum för kund/levfakturor.
N
Överförings datum.
Blir fakturadatum för
kund/levfakturor.
Kod för
periodiseringsnyckel
Antal månader till
start räknat från
Period
Ev. referens till
försystem
Belopp i SEK
Belopp i SEK
Konto
<agrlib:AllocationKey>
Periodiseringsnyckel
<agr:PeriodNo>
Startperiod
Blank
N
Överförings datum.
Blir fakturadatum för
kund/levfakturor.
Blank
Blank
Blank
<agr:ExternalRef>
Extern referens
<agrlib:Amount>
<agrlib:CurrAmount>
<agrlib:Account>
Konto
<agr:Dim1>
Ansvar
Ev. referens till försystem
Ev. referens till
försystem
Belopp i SEK
Belopp i SEK
Konto för moms.
<agr:Dim2>
Projekt
<agr:Dim3>
Spec
<agr:Dim4>
AktAO
<agr:Dim5>
Objekt
<agr:Dim6>
Verk
Belopp i SEK
Belopp i SEK
Blank (1513/1514 från kundgrupp,
2513/2514 från leverantörsgrupp)
Blank (från konteringsregel för
fodring/skuldkontot)
Ansvar
Blank
Normalt blank och
ges då från
konteringsregel
Blank
Blank
Blank
Speckod
Blank
Blank
AktAO kod
Blank
Blank
Objektkod
Blank
Blank
<agr:Dim7>
Motpart
Blank (hämtas från kund/leverantör)
Blank (XSXX hämtas
från konteringsregel
på kontot).
<agrlib:Currency>
Valuta = SEK
Valuta = SEK
Verkkod – kan
utelämnas om denna
kan sättas av
konteringsregel.
Om verifikationen har
AR/AP transaktioner
ska motpart lämnas
blank och hämtas då
från leverantör.
Om det är en GL07
och kontot har ett fast
värde kan fältet
lämnas blankt –
annars ska korrekt
motpart anges.
Valuta = SEK
Projektkod
34 (42)
<agrlib:TaxCode>
Blank
<agrlib:TaxSystem>
<agr:Account2>
Blank
Blank
<agr:BaseAmount>
Blank
<agr:BaseCurr>
Blank
<agrlib:ApArType>
<agrlib:ApArNo>
P (lev-faktura)/R (kundfaktura)
Kund-id/Lev-id (Agressos)
<agrlib:InvoiceNo>
Kundfakturanummer
/Levfakturanummer - sätts av
försystem
Förfallodatum.
Om detta lämnas blankt räknas
förfallodatum fram från
betalningsvillkor på
kunden/leverantören.
Verifikationsdatum räknas som
fakturadatum.
Obligatoriskt för kundfaktura. Om
det är en utbetalning ska detta fält
vara tomt. Om OCR-nummer anges
kommer detta att bli
utbetalningsreferens.
<agrlib:DueDate>
<agrlib:BacsId>
För utgående moms =
2*,
för ingående moms =
0
Blank
Om konto = Utgående
moms ska det konto
som momsen
beräknats på anges,
Ska vara det konto
som finns i tillhörande
GL-trans. Annars
blank.
Om konton fyllts i
ovan ska här anges
belopp som momsen
beräknats på =
samma som Amount i
GL-transen. Annars
blank.
Om konton fyllts i
ovan ska här anges
belopp som momsen
beräknats på =
samma som Amount i
GL-transen. Annars
blank.
P/R
Kund-id/Lev-id
(Agressos) obligatoriskt om
verifikationen
innehåller AR/APtransaktion. Annars
blank.
Blank eller
kund/levfakturanumm
er.
Blank
För konton som
genererar utgående
moms = 2*,
för övriga konton = 0
Blank
Blank
Blank
Blank
Blank
Blank
P/R
Blank eller Kund/Levid (Agressos) obligatoriskt om
verifikationen
innehåller AR/APtransaktion.
Blank eller
kund/levfakturanumm
er.
Blank
35 (42)
10 Investeringsredovisning och anläggningsreskontra
10.1 Investeringsredovisning
I Agresso finns ingen särskild delmodell för investeringsredovisning utan denna hanteras i huvudboken tillsammans
med övriga bokföringstransaktioner. Precis som i GemHB är det konteringen på ett projekt som inleds med ”I” som
gör att transaktionen identifieras som en investeringstransaktion. När en sådan bokföring kommer till huvudboken
kommer en så kallad ”TT-trigger” att sätta igång en bearbetning i Agresso 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. 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 som gör att dessa
transaktioner kan sorteras bort när investeringsredovisningen ska sökas ut ur Agresso. Dessa triggrar kommer att
läggas in i de investerande förvaltningarnas redovisningsenheter. När triggern sätts upp definieras regler för hur
bokföringen av pågåendekontot ska skapas och vilka koddelar den ska innehålla för respektive förvaltning.
10.2 Anläggningsreskontra
För de investerande förvaltningarna finns ett Anläggningsregister (AT) som utgör en specifikation av de
anläggningar som redovisas i balansräkningen. Även om de investerande förvaltningarna har sitt eget
anläggningsregister i Agresso är det möjligt att ta ut rapporter på en summerad nivå – tvärs över de olika
anläggningsregistren.)
I anläggningsregistret är alla anläggningar kopplade till anläggningsgrupper. Dessa anläggningsgrupper är
gemensamma för samtliga investerande förvaltningar. Till anläggningsgrupperna kopplas konto men också 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 Akt/AO och Objekt.
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,
Akt/AO och Objekt 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).
För varje typ av anläggning finns det i kontoplanen 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.
Förändringar i anläggningsregistret betraktas som olika händelser och dessa händelser kan alltid spåras för varje
anläggning. Alla händelser ger upphov till konteringar men inte på separata konton utan händelserna kan användas
som begrepp för rapportering av förändringar i AT. Följande händelser kan vara aktuella: Aktivering,
Avskrivningar/Upplösning, Kalkylmässiga räntor, Nedskrivningar/återföring av nedskrivning, Delning av
anläggningar, Sammanslagning av anläggningar, Omklassificering – (byte av anläggningsgrupp), Överföring inom
och mellan förvaltningar, Försäljning, Utrangering.
Vid försäljning av en anläggning kommer försäljningsintäkten att bokföras manuellt. Dessutom ska
försäljningsintäkten 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 som både styrs till kontot för bokfört värde) i huvudboken. I samband med att
uppgifter om försäljningen läggs in ska också uppgift om motpart anges (för att koncerninterna försäljningar ska
36 (42)
kunna fångas). Om försäljningen har inneburit en realisationsförlust måste försäljningsinkomsten och d:o bokförda
värden flyttas manuellt från konton i klass 3 till konton i klass 7.
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 inte aldrig göras manuella
bokföringstransaktioner på de konton som är kopplade till AT.
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.
37 (42)
11 Varje redovisningsenhet i balans
Eftersom 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. Exempel på när ICtriggers kommer att användas är t ex vid betalning av kund- och leverantörsfakturor, när reskontrorna påverkas i
respektive 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. Flera företeelser som ska flytta belopp
mellan redovisningsenheter kan komma att identifieras senare under projektet.
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.
I de fall då så kallad ”super- BFO” ska bokföras med redovisningstransaktioner i olika redovisningsenheter ska
motbokning alltid ske mot 1999. Denna typ av bokföringsorder kan endast göras via en Excelerator-mall och
kommer från start endast att användas av redovisningsenhet 900.
38 (42)
12 Kontroll och Attest
12.1 Processer som stöder god intern kontroll
Alla processer som hanteras i Agresso berör bokföring och ibland också in- och utbetalningar varför de måste
omgärdas med en hantering som säkerställer god intern kontroll. Projektet ansvarar för att definiera vilka aktiviteter
som ingår i dessa processer och att dokumentera dessa. För de olika processerna ska det också beskrivas hur
rutinerna bör utformas, vilka kontrollmoment som ska ingå och vilka rapporter/utdata som finns som hjälp för detta.
Varje förvaltning ansvarar sedan för tillämpningen av dessa för sin redovisningsenhet utifrån förvaltningens behov
och storlek/komplexitet.
En del i att säkerställa dessa processer är hanteringen av attester. Projektet kommer att tillämpa Göteborg Stads
nya attestregler på de processer som utformas i Agresso och kommer att erbjuda en möjlighet att använda sig av
elektronisk attest i Agresso för vissa flöden. Elektronisk attest i Agresso är bara en del i det som skapar intern
kontroll. Även andra kontroller, rutiner och dokumentation behövs för att säkerställa processerna.
12.2 Attest i Winst
Attest av beställningar och leverantörsfakturor kommer att hanteras i Winst. Uppgift om ansvar och attestanter
kommer även efter övergången till Agresso, att som nu, hämtas in till Winst från Nekksus.
12.3 Attest i Agresso
Försäljningsordrar (kundfakturor (deb/kred) och utbetalningar) och bokföringsordrar kommer att kunna attesteras
elektroniskt i Agresso4 och attesten görs då i Agresso Web. Om attest ska ske för en försäljningsorder (LG04)
innebär det att attesten ska ske innan faktureringen görs i Agresso.
När den elektroniska attesten används är det viktigt att det tydliggörs vilken typ av attest som avses. I Göteborg
Stads nya attestregler används begreppen kontrollattest, beslutsattest och betalningsattest och om elektronisk attest
görs måste det definieras vilken av dessa attester som görs. Det är också viktigt att identifiera vilka kontrollsteg som
ingår i attesten. Vid manuell registrering av försäljningsorder och bokföringsorder i Agresso kan också moment i
kontrollattesten anses utföras.
Det attestflöde som kommer att finnas i Agresso kommer inte att vara uppbyggt på samma sätt som i Winst och
användarna av Agresso är mycket färre än de som har tillgång till Winst. Utgångspunkten blir därför att attesten skall
göras av ett fåtal personer (främst ekonomiavdelningarna) och det kommer att göra att de elektroniska attesterna i
Agresso i vissa fall måste kombineras med andra attester.
Från start kommer användandet av elektronisk attest i Agresso att begränsas till en hantering som bygger på att
personer som ska kunna attesteras tilldelas en roll som attestant för förvaltningen och 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 eg. massattest) och ger inte en överblick över utförd
faktureringen, varför utdata lämpar sig bättre för kontroller av om faktura saknas eller har fel belopp.
Det är främst personer på förvaltningarnas ekonomiavdelningar som kommer att vara attestanter och den attest som
görs kommer därför oftast att vara en kontrollattest. Beslutsattesten förutsätts som huvudinriktning var gjord
manuellt på underlag, via avtal eller överenskommelse eller i försystem. Attesten i Agresso kan också vara en
beslutsattest om det är fåtal personer inom en förvaltning som har befogenhet att göra denna. I dessa fall kan det
vara personer i förvaltningsledningen som har rollen som attestant och i större förvaltningar kan det finnas fler än en
attestgrupp för försäljningsordrar (t ex en per sektor).
4
Även leverantörsupplägg attesteras men dessa hanteras helt inom intraservice.
39 (42)
Betalningsattesten för utbetalningar via Agresso (vid sidan av Winst) kommer inte att hanteras elektroniskt utan att
utföras manuellt och kontroller och attester skall göras på förvaltningen i kombination med andra kontroller hos
Intraservice.
Projektet kommer att presentera attestflöden som kan användas i kombination med andra kontroller och
förvaltningarna har på så sätt möjlighet att välja olika ambitionsnivåer för hanteringen av attest i Agresso beroende
på t ex vilka attester som görs i försystem och på underlag, vem som utför registrering, antalet fakturor, graden av
automatisering av fakturering etc. Attestflödet kan definieras per försystem för integrerade försäljningsorder och
bokföringsorder, per förvaltning vad gäller utbetalningar till kund medan användaren väljer om uppgiften skall gå på
attest för manuellt registrerade försäljnings-/bokföringsorder.
Projektets rekommendation vid utrullningen är att försäljningsorder från försystem anses beslutsattesterade i
försystemet och därför inte ska behöva attesteras i Agresso och att även manuella debetkundfakturor skall hanteras
utan elektronisk attest i Agresso medan manuella kreditfakturor och utbetalningar går i attestflöde (kontroll eller
beslutsattest).
Utformningen av förvaltningens attestflöde för försäljningsorder och bokföringsorder är en del i det
förberedelsearbete som respektive förvaltning ska göra innan driftstart.
40 (42)
13 Felrättning
Felrättning av felfällda filer från försystem måste hanteras per redovisningsenhet.
•
Kund/leverantör (CS15) – felaktiga kunder (obligatoriska uppgifter saknas/fel format etc.) stannar för
underhåll i Agresso – korrekta kunder läses in. Rättning av felaktiga kunder görs i underhållsbilden innan
motsvarande fil med försäljningsorder läses in.
•
Försäljningsorder (LG04) – felaktiga försäljningsordrar (kund saknas/kan inte identifieras, felaktiga begrepp
eller koder eller kontering som inte uppfyller ställda konteringsregler för kontot) stannar för underhåll i
Agresso medan korrekta ordrar läses in. Felaktiga ordrar måste rättas i underhållsbilden innan fakturering
av dessa kan ske (filtrering på bunt, ordernummertyp etc).
•
Bokföringsorder GL07-AP från försystem (Varje fil innehåller en eller flera verifikationer)
Felaktiga verifikationer stannar i underhållsbild och rättas där medan godkända läses in i Agresso.
•
Bokföringsorder (GL07) från försystem eller via exceleratormallar – (varje fil innehåller en eller flera
verifikationer). Felaktiga verifikationer rättas via underhåll i Agresso (Bunt-id+Försystemkod är nyckel).
•
Bokföringsorder (GL07) från Personec – felfällda transaktioner bokförs mot felkonto. Rättas ej i
underhållsbild.
•
Slutkonteringar från Winst – eventuellt felaktiga verifikationer stannar i underhållsbild och rättas där.
För integration av bokföringsordrar finns möjlighet att välja att - istället för att rätta i underhållsbild - låta eventuella
fel läggas på felkonto (på samma sätt som för Personec). Detta måste i så fall bestämmas för respektive integration.
Behörigheten till underhållsbilder för att utföra rättning skall vara begränsad eftersom stadens alla felfällda
ordrar/verifikationer/kunder ligger i samma tabell och misstag kan göras. Det kommer att vara en viktig arbetsuppgift
att löpande kontrollera, följa upp och rätta felfällda transaktioner.
41 (42)
14 Ändringar/tillägg
Följande ändringar/tillägg är gjorda sedan version A av dokumentet publicerades.
Datum
Ändring/Tillägg
Ansv
I version
2014-03-22
Tillägg av kapitel 14 Ändringar/Tillägg
EH
B
2014-03-22
Kap 3.1 – OBS att prefix måste ingå i ansvarskod
EH
B
2014-03-27
Kap 4.1 Momskoder tillagda
EH
B
2014-03-27
Kap 5.6 – Ändrad formulering
EH
8
2014-03-22
7.13 Tillägg om mottagarkod på interna fakturor
EH
B
2014-03-22
7.16 Text om påminnelse och dröjsmålränta utökad
EH
B
2014-03-24
9.4 Kapitel om kundfakturor som inte har skapats tillagt
EH
B
2014-03-24
9.4 blir 9.5
EH
B
2014-03-22
9.5 Ifyllnadsanvisning GL07-AP utökad med AR
EH
B
2014-04-10
9.1 Moms – automatisk beräkning av moms vid manuell registrering
EH
C
2014-04-23
4.1 Momskoder – tillägg
EH
C
2014-05-03
6.1 Periodiseringsnycklar
EH
C
2014-05-06
2.4 Tillägg om CS15
EH
C
2014-05-20
1.1 Tillägg av filspecifikationer för GL07-AR och GL07
EH
C
2014-05-22
I hela dokumentet – mindre språkförändringar, sidbrytning, korsreferenser
SW
C
2014-09-16
2.5 Ny bild för PC-lev
EH
D
2014-09-16
3.2 Konteringsregler – mindre förtydligande
EH
D
2014-09-16
4.3 Momssystem – momssystem undviker moms på interna fakturor
EH
D
2014-09-16
5.2 Bokföringsperiod ÅÅÅÅMM – tillägg om aktuell månad.
EH
D
2014-09-16
5.4 Transaktionstext – mindre tillägg om Extern order ref.
EH
D
2014-09-16
6 Periodisering – mindre tillägg om reversering
EH
D
2014-09-16
I hela dokumentet – borttag av manuell registrering av utbetalning via bokföringsorder.
EH
D
2014-09-16
7.4 Förvaltningsinterna kunder – kombination av kund/lev
EH
D
2014-09-16
7.5 Betalningsadress måste anges
EH
D
2014-09-16
7.9 Artiklar (interna kunder och momssystem)
EH
D
2014-09-16
7.11 Mindre ändring av urval vid fakturering och borttag av krav på Lev-id i LG04
EH
D
2014-09-16
7.12 Mindre tillägg om utläsningsfilter
EH
D
2014-09-16
7.13 Borttag av Lev-id i Text 2 i GL04
EH
D
2014-09-16
7.16 Påminnelser (förtydligande)
EH
D
2014-09-16
8.1 Fakturalayout (Dummyanvändare och antal positioner i fast text)
EH
D
2014-09-16
9 Bokföringsorder, tillägg om registrering i Agresso
EH
D
2014-09-16
9.2 Utbetalningar till organisationer – förtydligande om text till betalningsmottagare
EH
D
2014-09-16
9.3 Upplägg av betalningsmottagare görs av IS
EH
D
2014-09-16
12 Attest – ny formulering
EH
D
42 (42)
2014-09-16
13 Felrättning – ny formulering
EH
D
2014-09-16
Mindre textjustering i hela dokumentet
EH
D
2014-10-31
5.2 Ändring till Extern order-id
EH
E
2014-11-09
6.1 Periodnycklar 101-112 och 201-212 komplettering
EH
E
2014-10-14
8.2 Förtydligande om fakturalayout
EH
E
2014-10-17
7.2 Förtydligande kring kundgrupper
EH
E
2014-11-09
7.4 Kundnummer på förvaltningsinterna kunder
EH
E
2014-10-22
7.11 TIllägg av Text 1 i LG04
EH
E
2014-10-22
7.13 TIllägg av Text 1 i LG04
EH
E
2014-10-22
7.15 Tillägg under kreditfaktura
EH
E
2014-10-27
7.16 Ej möjligt att kreditera räntefaktura
EH
E