Veileder for implementering av ny kontoplan fra 01.01.2013 Gjennomgang av menypunkter i Agresso og mulige endringsbehov Kari Buer, Høgskolen i Østfold Terje Aandalen, UNINETT Innholdsfortegnelse 1. Innledning... 2 2. Endringsbehov under menypunktet Kodeplan i «Agresso Felles»... 3 2.1. Kontoplan... 3 2.1.1. Visning av korrekt Kontotekst i Browser-spørringer... 4 2.2. Kontogrupper... 6 2.3. Konteringsregel... 7 3. Endringsbehov under menypunktet Begreper og relasjoner i «Agresso Felles»... 8 3.1. Begreper... 8 3.2. Begrepsverdier... 9 3.3. Relasjoner... 10 3.4. Begrep pr relasjon... 11 3.4.1. Relasjonsverdier i kontogruppestrukturen... 11 3.4.2. Relasjonsverdier for overføring av konti til Basware... 13 3.4.3. Relasjonsverdier for andre KONTO-relasjoner... 13 4. Endringsbehov under menypunktet Faste registre i «Agresso Felles»... 15 4.1. Firmaopplysninger... 15 4.2. Bankkonti og Betalingsbank... 16 5. Endringsbehov under menypunktet «Agresso økonomi»... 17 5.1. Registrene Trigger og Regel for automatpostering... 17 5.2. Triggere for å realisere forpliktelsesmodellen... 17 5.3. Triggere mot konsernkontoen Norges Bank... 19 5.4. Årsavslutningstriggere... 20 6. Endringsbehov under menypunktet «Anleggsverdiregnskap»... 22 1
6.1. Anleggskonti... 22 6.2. Anleggsgruppe... 23 6.3. Anleggsmiddel... 25 7. Endringsbehov under menypunktet «Agresso Logistikk Ordre/Fakturering»... 26 7.1. Artikkelgrupper... 27 7.2. Artikkel... 28 8. Endringsbehov under menypunktet «Agresso Planlegger»... 29 8.1. Autopostering... 29 8.2. Transaksjonsregel... 30 9. Sluttord fra forfatterne... 30 1. Innledning På oppdrag fra universitets- og høgskolesektorens kontoplangruppe har forfatterne utarbeidet denne veiledningen. Den er ment å gi hjelp til å implementere sektorens nye kontoplan som skal gjelde fra 01.01.2013. Den er utarbeidet med henblikk på de institusjonene som UNINETT drifter Agresso for. En ny kontoplan påvirker ikke bare selve kontoplan-registeret i Agresso, men også en rekke andre registre som denne veiledningen vil vise. Rekkefølgen på endringene i de ulike registrene er ikke nødvendig å utføre slik denne veiledningen legger opp til, men er en av flere mulige framgangsmåter. Endringene i selve kontoplanregisteret er selvsagt det som må komme først av alt, men ellers står man nokså fritt. Tidspunktet for når endringene gjennomføres er heller ikke knyttet til noe bestemt tidspunkt, annet enn at fristen for å ta i bruk selve kontoplanen er for alle transaksjoner som skal bokføres på regnskapsåret 2013. Litt avhengig av hvilke behov og muligheter den enkelte institusjon har, vil det meste av implementeringen kunne utføres i god tid før 01.01.2013. Noen endringer må vente til visse føringer er sluttført for regnskapsåret 2012. I dokumentet er det vist en rekke eksempler på skjermbilder som er hentet fra en del forskjellige høgskoler/universiteter pr dags dato. De viser derfor ikke nødvendigvis registrene slik de kommer til å se ut etter at endringene er gjennomført. Forfatterne garanterer ikke for at feil og unøyaktigheter ikke kan forekomme i veiledningen. Tilbakemeldinger på den slags og andre synspunkter på veiledningen mottas gjerne. En typisk hovedmeny i Agresso ser ut som nedenfor. 2
2. Endringsbehov under menypunktet Kodeplan i «Agresso Felles» 2.1. Kontoplan En ny kontoplan som den som nå foreligger på 4-siffernivå, anbefaler vi implementeres som beskrevet nedenfor. Siden innslagene i eksisterende kontoplan har blitt til gjennom en årrekke, og hos de fleste har gjennomlevd flere større endringer, inneholder kontoplanregisteret langt flere innslag enn de som er aktive. Nedenfor er vist et utsnitt av en typisk del av en kontoplan i Agresso. Med en aktiv konto menes en konto hvor dagens dato ligger mellom Periode_ fra og Periode _til og der kontoen i tillegg har status N. Alle andre konti (les: rader) anses som inaktive (kan ikke benyttes til postering). Før man starter med å legge inn den nye kontoplanen bør man forsikre seg om at de aktive kontiene virkelig er aktive, og rydde opp i eventuelle avvik. For eksempel bør alle aktive konti ha Periode_til satt til 209912 og ha status N. Finnes det konti med Status N som har en Periode_ til som er eldre enn 201200, bør disse få endret status til C. 3
Den nye kontoplanen har på flere områder i stor grad sammenfall med gjeldende (aktiv) kontoplan. På andre områder vil det være større endringer. For en del kontis vedkommende vil det være ny anvendelse av eksisterende konti. I tillegg kommer noen helt nye kontokoder. Ny bruk av en eksisterende konto(kode) representerer en særskilt utfordring i Agresso. Det skal vi komme tilbake til. Nye konti som ikke eksisterer fra før (dvs. har en kontokode som ikke finnes) registreres på en ny rad med korrekt Beskrivelse (hent korrekt beskrivelse ved å bruke Copy+Paste fra regnearket). Er det avklart hvilken konteringsregel kontoen skal ha, velges den fra nedtrekksmenyen. Hvis den skal ha en ny regel som det vil ta litt tid å etablere, kan den midlertidig gis en annen regel. Gjerne da en nyopprettet, helt enkel regel som man for eksempel kan benevne Ny kontoplan 2013. Da er det enkelt senere å sjekke om alle konti har fått tildelt reelle regler. Hvis kontoen ligger innenfor en eksisterende Kontogruppe (kolonnen Gruppe), velges den fra nedtrekksmenyen. Hvis den skal tilhøre en ny gruppe, må den nye kontogruppa først registreres i bildet Kontogrupper (mer om det nedenfor). Periode_fra settes til 201301 (resultatkonti), og Periode_til settes til 209912. For balansekonti vil periode 201300 kunne brukes dersom balansen skal konverteres etter overføring til periode 201300. Med mindre det er en ny reskontrokonto som skal etableres (den nye kontoplanen skal ikke inneholde noen slike), skal Type settes lik GL. Status settes til N. Dersom kontoen som skal registreres er en der kontokoden har vært benyttet tidligere, må først den forrige utgaven endres slik at Periode_til settes til 201212 (evt. 201213 dersom man har 13 regnskapsperioder). Det er da klart for å registrere en ny rad med samme kontokode, slik som beskrevet over for en ny konto. Rekkefølgen her er viktig da Agresso ikke tillater overlapp i perioder mellom to rader med samme kontokode. Agresso har den særskilte egenskapen at alle beskrivelser lagres i et separat register ved siden av selve kontoplanregisteret. Beskrivelsesregisteret inneholder kun en tekst for hver kontokode, og er altså ikke versjons- eller datostyrt. I praksis virker det slik at det er beskrivelsen til den kontokodelinjen som sist ble endret, som blir tatt vare på. Når man legger inn en ny rad der det allerede finnes en kontokode som er i bruk, vil derfor normalt den nye beskrivelsen bli gjort gjeldende. For å få tilbake den gamle beskrivelsen (som er det vi ønsker inntil regnskapet pr 31.12.2012 er rapportert, dvs helt til 15.02.2013), må man derfor utføre en eller annen oppdatering på den aktive kontokoderaden. For eksempel kan man endre status til C, lagre og deretter endre tilbake til N og lagre. Alternativt kan man legge inn et punktum til slutt i beskrivelsen på den gamle kontoen og lagre. På den måten er man sikret å oppnå riktig kontonavn ved rapportering for 2012. 2.1.1. Visning av korrekt Kontotekst i Browser-spørringer I browserspørringer i Agresso lar det seg gjøre med litt triksing å hente riktig beskrivelse ut fra hvilken periode man er innenfor. Nedenfor er vist et eksempel på hvordan det kan gjøres. Først et tenkt eksempel på en ny bruk av konto 3010: 4
Utfordringen her er å få fram korrekt kontotekst for eksempel ved Spørring bilag. I en browserspørring der man utvider datagrunnlaget med kolonner fra selve kontoplanen lar det seg gjøre, slik eksemplet nedenfor viser. Her tar vi med de tre kolonnene Per.fra, Per.til og Beskrivelse fra Kontoplanregisteret i Oppsettfanen. For demonstrasjonsformål viser vi også Kode/Tekst på Konto slik at forskjellen i resultat kommer tydelig fram. I fane 2 Søkebet angir vi søkebetingelsene som normalt. For tydelighets skyld er kolonnen Periode renavnet til Bokføringsperiode i Fane 1, og den vises derfor slik også i Fane 2. 5
Resultatfanen vil da vise korrekt Beskrivelse for bilag ført i henholdsvis 2012 og 2013, mens Konto(T) kun viser beskrivelsen fra den raden i Kontoplanen som sist ble oppdatert. 2.2. Kontogrupper Kontogruppe-registeret i Agresso inneholder alle spesifikasjoner av kontoplan-strukturen på alle nivåer over 4-siffernivået. Dette er altså ett felles register for 1-, 2- og 3-siffernivå i tillegg til inndeling i Balanse- og Resultat-konti. Dette registeret benyttes i Agresso sine standard-rapporter som GL03 og GL09. Kontogruppene må kontrolleres og revideres noe som eventuelt kan vente til all rapportering for 2012 er ferdigstilt. Dette gjøres i menyvalget for Kontogruppe og endringsbildet ser ut som bildet nedenfor. Kontroller at Beskrivelse for de ulike 1-, 2- og 3-sifferverdiene er riktig angitt ift. ny kontoplan. Det er ingen endringer i selve strukturen eller tilhørende kolonner for Nivå, Klasse, Type og Mult(iplikator). Kontogrupper som ikke er benyttet i den nye kontoplanen (for eksempel 101 i bildet under) kan gjerne slettes. Det er viktig at det er sammenheng i angivelse av Nivå, Klasse og Gruppe. Nivå B tilsvarer 3-siffernivå, Nivå C 2-siffernivå osv. I kolonnen Klasse skal Gruppebetegnelsen for nivået over være angitt. Det kan være fornuftig å ta en full kontroll på at dette registeret er korrekt satt opp. 6
2.3. Konteringsregel Det kan være nyttig å gå gjennom registeret for Konteringsregler når en større endring av kontoplanen skal gjennomføres. For nye konti og konti som får ny anvendelse må man uansett vurdere hvilken konteringsregel som skal anvendes, jfr. pkt. 1.1. Et eksempel på en konteringsregel er vist nedenfor. 7
Det vil føre for langt å gå gjennom alle muligheter som ligger i dette registreringsbildet her. Er det uklarheter eller ønsker om å få vite mer om hva betydningen av de ulike feltene er, ta gjerne kontakt med UNINETT. Konteringsreglene representerer et meget sentralt register i Agresso, og er det som i praksis både implementerer den valgte økonomimodellen og sørger for at avgiftskoder og OA-koder for lønn og reiser kommer med når de skal. Det kan i det minste være greit å kontrollere om det er konteringsregler som ikke er i bruk, og deretter endre status til Parkert eller Terminert på disse. 3. Endringsbehov under menypunktet Begreper og relasjoner i «Agresso Felles» Her er det 3-4 registre som bør kontrolleres og evt. endres: 3.1. Begreper I registeret Begreper kan det være behov for å kontrollere oppsettet av 4 begrepsdefinisjoner som er relatert til en rapporteringsstruktur knyttet til kontoplanen. De 4 begrepene er vist nedenfor: Begrepet KONTO inneholder selve kontoplanen på 4-siffernivå og blir oppdatert fra bildet Kontoplan. Begrepet KONTOKDE skal inneholde kontoplanen på 3-siffernivå, KONTOGRP representerer 2- siffernivået og KONTOKLS 1-siffernivået. I dette bildet ser vi at kolonnen Eier inneholder en referanse til begrepet på nivået over for to av begrepene ( KONTOKDE har KONTOGP som eier og KONTOGRP har KONTOKLS som eier). Dette er en 8
såkalt direkte-relasjon i Agresso og innebærer at når en begrepsverdi skal registreres, for eksempel en KONTOKDE, så må samtidig tilhørende KONTOGRP angis. Eksempler på dette vises i pkt. 2.2. Direkte relasjoner er mer effektive ved bruk i spørringer enn de ordinære relasjonene (pkt. 2.3). Begrepene KONTOKLS, KONTOGRP og KONTOKDE hører ikke til standard Agresso-installasjon, men er blitt opprettet særskilt i vår sektor for å forenkle en del spørringer i Agresso mot kontostrukturen på et aggregert nivå, såkalt 1-, 2- og 3-siffernivå. Denne strukturen er ofte benyttet i en rekke Browserog Excelerator-spørringer, selv om den strengt tatt ikke er nødvendig å anvende lenger. Den ble etablert for mange år siden, og mulighetene i Browser og Excelerator som har kommet til etter hvert har forsåvidt gjort denne strukturen overflødig. Men siden den er nokså innarbeidet i sektoren, skal vi her vise hva som må gjøres av vedlikehold. 3.2. Begrepsverdier I registeret Begrepsverdier kan det være behov for å utføre noen oppdateringer, og i det minste kontrollere at enkelte begreper har de riktige verdier og betegnelser. 9
Disse 3 begrepene er altså en parallell til registeret Kontogruppe (pkt. 1.2 over), og skal inneholde verdier og beskrivelser for en komplett spesifikasjon av de 3 nivåene slik kontoplanen angir. Ovenfor er vist eksempler på innholdet i disse registrene. Som vi ser her inneholder begrepsverdiene til KONTOGRP og KONTOKDE en kolonne for eierbegrepet (KONTOKLS og KONTOGRP). Her bør det kontrolleres at korrekt verdi på nivået over er angitt. 3.3. Relasjoner Selv om det allerede er opprettet direkterelasjoner for begrepene på 2 av de 3 nivåene, har det i tillegg blitt etablert ordinære Relasjoner mellom disse begrepene og selve KONTO-begrepet. KONTO har en relasjon til KONTOKDE, KONTOKDE til KONTOGRP og KONTOGRP til KONTOKLS, se definisjoner nedenfor. 10
Noen institusjoner har lagd en relasjon fra KONTO og direkte til Nivå 1, KONTOKLS, som et tillegg til eller erstatning for de tre relasjonene overfor. Dersom man ofte rapporterer kun på 1-siffer-nivå, kan man med fordel benytte denne relasjonen. Det vil effektivisere spørringene i vesentlig grad, siden det ikke blir nødvendig for Agresso å gå via de mellomliggende relasjonene. Det krever selvsagt at man lager sine spørringer slik at denne relasjonen benyttes. 3.4. Begrep pr relasjon 3.4.1. Relasjonsverdier i kontogruppestrukturen For å lage sammenhengen mellom begrepsverdiene til begrepene som inngår i en Relasjon, må det legges inn verdier i registeret Begrep pr relasjon. 11
Nedenfor er vist eksempler på hvordan dette anbefales lagt opp for relasjonene i pkt. 2.3: Det viktige her er for hver verdi på ett nivå (for eksempel Kontokode 120) å legge inn en og kun en rad i tabellfeltet der man skriver 120* i Verdi_fra-kolonnen. Ved lagring vil det resultere i at skjermbildet vil se ut som over. Det sikrer at alle konti som starter med sifrene 120 blir knyttet til KONTOKDE 120. Dersom det er registrert enkeltstående verdier (rader) på noe sted i dette registeret, bør de radene slettes og erstattes av en og kun en rad, se eksempel før og etter nedenfor: 12
3.4.2. Relasjonsverdier for overføring av konti til Basware Alle som benytter Basware for håndtering av inngående faktura skal ha satt opp en relasjon mellom begrepet INVOICE og KONTO. Det er kun for verdien 1 av INVOICE at det skal finnes rader i Begrep pr relasjon. Denne relasjonen benyttes av grensesnittet mellom Agresso og Basware til å begrense hvilke konti (og konteringsregler) som overføres fra Agresso til Basware med jobben T101. Et typisk utsnitt av et oppsett som fungerer, er vist nedenfor. Det bør kontrolleres og evt. legges inn endringer her slik at konti som er nye eller har fått endret betydning i ny kontoplan blir hensyntatt. 3.4.3. Relasjonsverdier for andre KONTO-relasjoner Dersom det er lagt opp andre relasjoner mot begrepet KONTO, må man gå gjennom og sjekke om det er behov for endringer. Et typisk relasjonsoppsett hos en høgskole kan se slik ut: 13
De fleste av disse relasjonene er neppe i bruk lengre, og kan sikkert fjernes. Men de som måtte være i bruk, må man vedlikeholde etter at kontoplanen er lagt inn. Et særlig tilfelle å være oppmerksom på er relasjonen mellom KONTO og ROLEID. Denne relasjonen vedlikeholdes vanligvis under menypunktet Adgangskontroll under Felles, og kan benyttes til å begrense tilgangen til bestemte konti for brukere knyttet til bestemte roller (i Systemadministrasjon). Noen institusjoner benytter dette bevisst for å hindre innsyn til visse konti for spørrebrukere og andre. Et lite tips er å benytte Spørring relasjoner og begreper for å få avdekket mangler i relasjonsstrukturene. Det er svært viktig å unngå hull og mangler, siden det kan medføre at rapporteringen blir mangelfull. Et eksempel på en slik spørring er vist nedenfor. 14
4. Endringsbehov under menypunktet Faste registre i «Agresso Felles» Her er det tre menypunkter som bør kontrolleres og evt. endres: 4.1. Firmaopplysninger På flik 5 Konti i Firmaregisteret er det angitt en del konti med spesialfunksjoner i Agresso. Det bør kontrolleres om det er blitt endringer i kontiene som er angitt her, slik at oppsettet må revideres. Eventuelle endringer som følge av ny kontoplan må ikke gjennomføres før all bokføring som kan berøre disse kontiene er utført for regnskapsåret 2012. Normalt skal det neppe være noe problem i praksis. Kontoen for Aktivering kostnad benyttes av Agresso til periodisering av kostnader når en postering knyttes til en periodiseringsnøkkel (i Basware eller Agresso). I den nye kontoplanen er en generell konto for periodiserte kostnader ikke spesifisert. Det finnes en for forskuddsbetalt leie (1701) og en for andre forskuddsbetalte kostnader (1799). Hvilken av disse som velges, evt. om man velger å opprette en ny i en ledig 3-siffer gruppe, vil vi ikke ta stilling til her. Det er et regnskapsfaglig spørsmål som ligger utenfor denne veiledningens formål. 15
4.2. Bankkonti og Betalingsbank Registeret Bankkonti må revideres helt i henhold til den nye kontoplanen, og det må også opprettes ny konto i banken for refusjoner fra NAV. Her er vist et utsnitt av registeret (F9+F7 fra selve registerbildet): Strengt tatt er det kun nødvendig her å holde oversikt over de bankkonti som benyttes ved automatiserte transaksjonsfiler til/fra bank. Dvs. alt som har med remittering og OCR-innlesing å gjøre. Banktransaksjoner som kommer fra forsystem (FS eller SAP) går som en helt ordinær hovedboks-postering, og krever ikke at tilhørende bankkonti er registrert i dette registeret. Men ønsker man en komplett oversikt her, er det selvsagt ikke noe i veien for det. Det som er viktig er altså hvilke bankkonti som skal anvendes til remittering/ocr-innlesing i Agresso, og hvilke kontokoder som disse bankkontiene er knyttet til. De automatiserte banktransaksjonene settes opp i registeret Betalingsbank, som er en kobling mellom registeret Bankkonti og banktransaksjonstypen: I eksemplet over er det benyttet samme bankkonto (DNBNOK) til Leverandør og Kunde ut. Kunde inn har en annen konto (DNBINNØK). DNBNOK er knyttet til konto 1931, mens DNBINNØK er knyttet til konto 1922. De andre kontiene er enten gamle definisjoner eller representerer konti som det ikke er automatikk knyttet til. Hvis man ønsker det, kan man kan klargjøre for den nye kontoplanen i god tid ved å lage helt nye innslag i Bankkonto-registeret, for eksempel DNBUTNY mot konto 1941 og DNBINNNY mot konto 1931. Det er altså fullt mulig å lage flere innslag i dette registeret mot samme bankkonto. Som poengtert over er det automatikken som styres av registeret Betalingsbank som det blir viktig å endre ved overgang til ny kontoplan. Så snart utbetalinger og innbetalinger skal registreres på nytt regnskapsår, må man endre koblingen til de nye Bankkonti-betegnelsene her. 16
Alternativet til dette er å vente med å endre Bankkonti-registeret til ny bankkonto umiddelbart før første gang det skal bokføres banktransaksjoner på nytt regnskapsår. 5. Endringsbehov under menypunktet «Agresso økonomi» 5.1. Registrene Trigger og Regel for automatpostering Disse registrene finner man under Hovedbok i Agresso Økonomi, og representerer registre som det er meget viktig blir endret på korrekt måte og til korrekt tidspunkt ved overgang til ny kontoplan. Kort fortalt blir triggere og regler for automatposteringer benyttet til å utføre posteringer automatisk i Agresso på grunnlag av andre posteringer som blir utført. Det typiske eksemplet som forhåpentligvis alle institusjoner har iverksatt er triggere og regler som utfører postering av anleggsaktiveringer og tilhørende avskrivinger, slik at Statens såkalte forpliktelsesmodell automatisk blir ivaretatt. Men det kan også være at den enkelte institusjon har definert triggere for andre formål. For eksempel er det etter hvert flere høgskoler som automatisk utfører tilleggsposteringer mot konsernkontoen hos Norges Bank vha automatposteringsmulighetene i disse registrene. Disse to tilfellene behandles særskilt nedenfor. Men det er viktig å kontrollere alle triggerdefinisjoner som finnes, og gjerne rydde i triggere som ikke er i bruk lenger. Det er viktig å være klar over at det kan finnes definert triggere med andre typer enn TT (transaks sjonstriggere) og YE (årsavslutningstriggere) som er de mest vanlige i bruk. Det finnes også triggertyper som heter PR, IC og B-BZ (sjekk Hjelp for nærmere forklaring). 5.2. Triggere for å realisere forpliktelsesmodellen Nedenfor er vist et eksempel på trigger og regel for aktivering av anleggsmidler med en transaksjonstrigger (Triggertype TT) som heter XAKT: 17
Triggersiden lister alle aktiveringskonti. Når det føres en transaksjon mot en av disse kontiene, vil triggeren generere nye posteringer slik som regel-delen av triggeren er satt opp. For eksempel vil en postering mot 1200 her alltid generere en tilsvarende postering på 3910 og en motpostering på 2150. Siden den nye kontoplanen inneholder en del endringer i anleggskontiene, vil det være behov for å endre triggersiden av XAKT-triggeren (for eksempel med den nye kontoen 1202). Kontien på regelsiden av XAKT er ikke endret i ny kontoplan. Triggeren for avskrivinger i henhold til forpliktelsesmodellen heter typisk XAVS og kan se slik ut: 18
Merk her at det er kun 15 rader på triggeren XAVS, mens det er 16 rader på XAKT. I dette tilfellet er det korrekt, da aktiveringer mot 1130 ikke skal avskrives. Men i utgangspunktet er dette en enkel måte å kontrollere at de to triggerne er konsistent satt opp. Den nye kontoplanen har en endring som gjør at også regelsiden av XAVS må endres. 3950 er nå kontoen for utsatt inntektsføring av avskrivningene, mot 3930 i den gamle kontoplanen. Det er derfor meget viktig å endre dette registeret på det korrekte tidspunktet, slik at alle avskrivinger for 2012 er utført før dette registeret endres. Og endringen må selvsagt skje før første avskriving i 2013 gjennomføres. Siste avskriving i 2012 utføres erfaringsmessig et godt stykke ut i januar, og det kan være en risiko for at det vil bli avglemt å gjennomføre denne endringen. En sikrere metode vil være å legge opp en helt ny trigger (kall den for eksempel AVS3) som skal gjelde fra periode 201301 (feltet Periode fra på regelen), og sette feltet Periode til på den gamle triggeren til 201212. En slik omlegging kan utføres når som helst. Husk i så fall at både Trigger- og Regel-registeret må registreres med den nye triggeren. 5.3. Triggere mot konsernkontoen Norges Bank En slik transaksjonstrigger kan for eksempel se slik ut: Her vil posteringer mot for eksempel 1932 også bli bokført mot 1961, samtidig som 1932 vil bli kreditert (rad 2 i regelen der det står O(pprinnelig) i kolonnen F). I triggeren er det lagt på en begrensning slik at det kun er bilag med bilagsart IP som vil bli trigget (zoom eller dobbeltklikk på aktuell rad i triggerdefinisjonen). Alle andre føringer mot 1932 vil ikke bli automatpostert mot 1961. Siden det er flere endringer i den nye kontoplanen mhp. bankkonti, vil det være nødvendig å gjøre noe med trigger-siden av slike automatposteringer. 1961 har samme betydning som før, slik at regelsiden ikke blir berørt. I enda større grad enn ved anleggstriggerne må man her være påpasselig med å endre triggerne på korrekt tidspunkt, eller evt. lage nye som får effekt fra 201301, og samtidig stenge de gamle fra 201212. 19
5.4. Årsavslutningstriggere Årsavslutningstriggere(triggertype YE) benyttes i forbindelse med overføring av Inngående balanse (IB). Siden IB-overføringen ikke skjer før en god stund etter at regnskapet er avlagt, har man god tid til å gå gjennom disse for å gjøre nødvendige korreksjoner. IB-overføringen for 2013 blir i seg selv et særskilt kapittel, siden det er nokså mange endringer i balansekontiene. Her kan det bli aktuelt å benytte et spesialopplegg, der IB-en blir overført vha konverteringsscript som lages av UNINETT i samarbeid med sektoren. Et slikt opplegg må diskuteres nærmere, og konklusjonen foreligger ikke i skrivende stund. Dersom et konverteringsopplegg blir løsningen for 2013, er det ikke nødvendig å revidere triggerne for overføring av IB før etter at konverteringen er foretatt, dvs. først for IB-overføring 2014. Som det fremgår på skjermbildene nedenfor, så har sektoren endret kontoplan noen ganger, jfr. alle radene med status C. Disse kan man for øvrig slette, slik at triggerbildet blir litt mer ryddig. En M i statuskolonnen betyr at det er lagt på et mer spesifikt kriterium i zoom-bildet. 20
Det kan gjerne lages flere YE-triggere. Det er i så fall viktig at ingen triggere overlapper i hvilke konti de behandler. Eksemplet nedenfor viser en trigger som foretar overføringer fra alle MVA-kontiene til konto 2741 Skyldig MVA, slik at manuelle overføringer ikke blir nødvendig. Eksempel: 21
6. Endringsbehov under menypunktet «Anleggsverdiregnskap» I denne modulen er det i utgangspunktet to registre som blir berørt, nemlig Anleggskonti og Anleggsgruppe. I tillegg vil selve Anleggsmiddel-registeret kunne bli berørt. 6.1. Anleggskonti Dette registeret må oppdateres slik at alle konti som skal benyttes i anleggsmodulen blir gjort kjent for de andre registrene og tilhørende funksjonalitet i denne modulen. Siden det er en del anleggskonti som er endret i den nye kontoplanen, må dette revideres: 22
6.2. Anleggsgruppe Når Anleggskonti-registeret er oppdatert, må endringer som skal reflekteres i Anleggsgrupperegisteret iverksettes. De fleste, sannsynligvis alle anleggsgrupper må revideres med det nye oppsettet av avskrivningskonti i 38- og 60-serien. I tillegg vil det være enkelte endringer i 12-serien som gjør at anleggsgruppeoppsettet må forandres også her. Det vil for de fleste sannsynligvis gjelde konto 1202 for Forsknings- og laboratorieutstyr, der det tidligere har vært benyttet 1284. Hvis man velger å beholde de gamle anleggsgruppe-angivelsene i den nye kontoplanen, vil det ikke være behov for å gjøre noe med selve Anleggsregisteret. Ethvert anlegg vil følge den gruppa det er tilknyttet og endringene i kontoangivelser vil automatisk bli gjort gjeldende for alle anlegg som er knyttet til den gruppa som det gjøres endringer på. Før endring: 23
Etter endring (kun vist de nye balansekontiene): En helt annen situasjon oppstår dersom det opprettes en ny anleggsgruppe for konto 1202, slik at alle eksisterende anlegg mot gruppe LAB i eksemplet ovenfor skal gis ny gruppetilhørighet. Endring av gruppe på et eksisterende anlegg er låst for endring av vanlige Agresso SUPER-brukere, men kan utføres med SQL-script av UNINETT. For alle anlegg som må overføres til ny balansekonto (alle LAB-anlegg, for eksempel) anbefales det å lage nye anleggsnummer for overføring av saldi fra de gamle anleggene og deretter stenge disse. Se mer om dette i neste kapittel. For de anleggene som fortsatt skal være på samme balansekonto vil avskrivningene komme på riktig resultatkonto gjennom den revideringen som foretas på den enkelte anleggsgruppe. Endringene som nevnt over må ikke gjennomføres før alle avskrivinger for 2012 er gjennomført, og de må selvsagt være utført før de første avskrivingene utføres i 2013. Av hensyn til nye anlegg som skal aktiveres på en ny konto i 2013 (for eksempel konto 1202), så må denne endringen være på plass før det kan aktiveres noe på et slikt anleggsmiddel. Her er oversikt over endringer på kontogruppe 60 og 38 (venstre kolonne er dagens konti) alle anleggsgrupper må revideres: 24
6.3. Anleggsmiddel Som nevnt tidligere anbefales det for alle anlegg som må overføres til ny balansekonto (alle LABanlegg, for eksempel) å lage nye anleggsnummer for overføring av saldi fra de gamle anleggene og deretter stenge disse. Noen institusjoner har en navneregel for anleggsmidlene der en del av navnet henviser til anleggsgruppa (eg. anleggskontoen) som de tilhører. Anlegg som skal flyttes fra en gruppe til en annen må derfor få nye betegnelser for å samsvare med navnestandarden. I slike tilfeller kan UNINETT lage et SQL-script som enten foretar navneendringen direkte på det enkelte anleggsmidlet, alternativt sørger for å få opprettet helt nye anlegg for å erstatte de som ikke lenger har et gyldig navn. Om man velger å gjennomføre en slik navneendring selv manuelt eller automatisert vha UNINETT avhenger av hvor mange anlegg det er snakk om. Et eksempel på et anlegg som har et nummer som kan konverteres med et script er vist nedenfor: 25
7. Endringsbehov under menypunktet «Agresso Logistikk Ordre/Fakturering» I denne modulen er det i utgangspunktet ett register som blir direkte berørt, og det er registeret Artikkelgrupper. I tillegg kan en mye utbredt navnestandard innebære en revisjon av en rekke artikler i Artikkelregisteret: 26
7.1. Artikkelgrupper Et typisk oppsett i vår sektor for artikkelgruppene er at det finnes en artikkelgruppe for hver inntektskonto som det er aktuelt å bokføre et salg mot. Artikkelgruppa gis da samme betegnelse som inntektskontoen den er knyttet mot, og beskrivelsen av artikkelgruppa gis samme beskrivelse som kontoen (gammelt oppsett øverst, nytt nedenfor): 27
Siden det er nokså omfattende endringer i salgskontodelen av kontoplanen, må man gå gjennom alle artikkelgrupper for revidering. For eksempel er Leieinntekter lokaler, avgiftspliktig nå lagt til konto 3033. Det må da opprettes en ny artikkelgruppe for det. Den gamle artikkelgruppa bør få endret status til Sperret så snart 2012 er ferdigfakturert. 7.2. Artikkel I sektoren har det vært gjennomført en navneregel der artiklene gis navn etter artikkelgruppa (og dermed kontoen) den er knyttet til. Et eksempel er vist nedenfor. Ved behov for flere artikler mot samme gruppe/konto gir denne navneregelen et løpenummer, slik at neste artikkel for eksempel kan benevnes 3021-1. 28
Når kontoen og dermed gruppa flyttes i den nye kontoplanen, må artikkelen også oppdateres, eller aller helst lages på nytt som i dette tilfellet. Den gamle artikkelen må selvsagt settes til status Sperret, slik at den ikke blir feilaktig benyttet. I tillegg vil det være greit å gå gjennom absolutt alle artikler som er laget for å stenge andre som ikke lenger skal brukes. 8. Endringsbehov under menypunktet «Agresso Planlegger» Også Agresso Planlegger benytter de tabeller og registre som ligger i Agresso. I Planlegger er det to faste registre som benytter seg av kontoplanen, og som i utgangspunktet må revideres. Dette gjelder Autopostering og Transaksjonsregel: Det er store endringer i lønnskontiene, så her må det gjøres endringer i kontotilknytninger både i transaksjonsreglene og autoposteringer. Blant annet feriepenger skal ha flere konti fra 2013. 8.1. Autopostering Et typisk autoposteringsoppsett kan se slik ut for en budsjettversjon for 2012. I en versjon som skal gjelde 2013, må denne regelen erstattes av to på grunn av to ulike feriepengekonti, 5081 for faste stillinger og 5181 for midlertidige stillinger. Har man startet budsjettprosessen for 2013 på gammel 29
kontoplan, vil det også bli nødvendig å oppdatere budsjettversjonen med å kjøre jobben PL217 - Oppdatering autoposteringer etter at endringen i selve registeret er utført. 8.2. Transaksjonsregel Et eksempel på en transaksjonsregel er vist nedenfor. Transaksjonsreglene er knyttet til en bestemt budsjettversjon, og det er kun for budsjettversjoner som går mot 2013 som det er behov for å sjekke for endringsbehov: 9. Sluttord fra forfatterne Tenk på at alle nye resultatkonti må være tilgjengelig for bokføring i 2013 en god stund før vi er ferdig med regnskap 2012 og rapporteringen til KD/DBH/andre. Det er derfor viktig at alle kontobeskrivelser vi har i 2012 beholdes frem til det er gjort. Lag gode konverteringsoversikter på alt som flyttes og sørg for å ha de tilgjengelig for revisjonen når den tid kommer. Halden/Trondheim, 06.11.2012 Kari Buer Terje Aandalen 30