SSA-T Bilag 1 – Kundens kravspesifikasjon For Lønns- og regnskapssystem
SSA-T Bilag 1 – Kundens kravspesifikasjon For Lønns- og regnskapssystem
SSA-T Bilag 1 – Kundens kravspesifikasjon
Innhold
2. Beskrivelse av Virksomheten 5
3. Prosjektets målsettinger og overordnede krav 9
4. Føringer for besvarelse av kravspesifikasjonen 10
Krav dekkes i standard løsning 10
Ref. til kommentar, informasjon, evt. forbehold i vedlegg 10
Inngående faktura og leverandørreskontro 17
Utgående faktura og kundereskontro 20
Bank, remittering og bankavstemming 23
SSA-T Bilag 1 – Kundens kravspesifikasjon
Timeregistrering og -oppfølging 32
Reiseregninger og utgiftsrefusjon 35
6. Teknologiske og ikke-funksjonelle krav 36
Krav til databehandleravtale 39
8. Krav til etableringsprosjektet 40
Krav til prosjekt- og fremdriftsplan 40
Krav til testing og godkjenning 40
Krav til organisering av etableringsprosjektet 41
SSA-T Bilag 1 – Kundens kravspesifikasjon
1. Innledning
Bakgrunn
AtB som selskap er stadig under utvikling og har vokst betraktelig siden oppstart 2009. Dette som følge av flere ansvarsområdet, deriblant fylkessammenslåing 01.01.2018, hvor AtB i tillegg har fått ansvar for buss og bil (for bestillingstransport og individuelt tilrettelagt skoleskyss) i Region Nord i Trøndelag, tidligere Nord-Trøndelag fylkeskommune. I tillegg kan mye av veksten knyttes til et helhetlig og attraktivt kollektivtilbud som har gitt en stor økning i reisende.
Kunden har besluttet å anskaffe et nytt regnskapssystem med tilhørende lønns- og inkassotjenester for å dekke virksomhetens behov – spesielt med tanke på videre vekst.
Formål med dokumentet
Dette dokumentet vil utgjøre basis for kravspesifikasjonen og peker på kontekst, bakgrunn, behov og overordnede mål med systemet. Inngående forståelse er kritisk for Leverandør.
Kontrakt
Dette dokumentet vil danne grunnlag for kontraktuell forpliktelse for leveranser, og vil bli vedlegg til endelig avtale med valgt Leverandør. Svar skal gis på kontraktsform og følger Statens Standardavtaler (Utviklings- og tilpasningsavtalen (SSA-T)) hvor dette dokumentet vil utgjøre
«Bilag 1 – Kundens kravspesifikasjon». For nærmere beskrivelse – se konkurransegrunnlaget.
2. Beskrivelse av Virksomheten
AtBs virksomhet
AtB er et aksjeselskap som har ansvaret for planlegging, koordinering, markedsføring og kjøp av rutegående kollektivtrafikk i Trøndelag. AtB har gått fra å defineres seg som et kollektivselskap til et «mobilitetsselskap».
AtB er ikke selv operatørselskap, men kjøper transporttjenester av flere transportselskaper som utfører den daglige driften. I tillegg til ordinær rutetransport har AtB ansvaret for skolekjøring i Trøndelag, samt bestillingstransport.
Selskapet eies 100 % av Trøndelag fylkeskommune. Billettpriser fastsettes av Trøndelag fylkeskommune og hovedfinansieringskilder til AtB er tilskudd fra fylkeskommunen i tillegg til billettinntekter. I 2017 hadde selskapet en omsetning, billettinntekter og tilskudd, på 1,5 MRD. Ca 50 % av billettinntektene kommer i form av tilskudd. Billettinntektene fra passasjerer kommer gjennom billettsystemet Ebit, Mobillett, salgskontor, billettmaskiner på holdeplass, betaling om bord på buss og skoleskyss. Salg fra salgskontor kan enten være AtB sitt kundesenter eller utvalgte kiosker. Siden AtB selv ikke er operatørselskap må salg om bord på bussen inndrives i ettertid fra den aktuelle operatør.
AtB har ikke vedtaksmyndighet for skoleskyss, enten den er ordinær eller går under Individuell Tilrettelagt skoleskyss. Trøndelag Fylkeskommune fatter vedtakene og AtB er ansvarlig for administrering av skoleskyssen. Ut fra fattet vedtak fakturer AtB skoler og kommuner for skoleskyssen.
Kjøp av rutetjenester gjøres gjennom anbud. AtB administrerer i dag buss by, buss region, trikk, hurtigbåt, ferge. I tillegg gjennomføres Individuell Tiltrettelagt skoleskyss og bestillingstransport i hovedsak med drosje. Til sammen er det i overkant av 25 kontrakter med operatører. Alle kontrakter i gamle Sør-Trøndelag er bruttokontrakter, der AtB bl.a. har inntektsansvaret. Alle kontrakter i gamle Nord-Trøndelag er nettokontrakter, der operatør sitter med inntekts- og markedsansvaret.
Kunden har skattefritak.
For ytterligere informasjon – se xxx.xxx.xx.
2.1.1 Organisasjonskart
AtB er delt inn i 4 avdelinger, med 4 seksjoner pr. avdeling.
Eksisterende løsninger
Følgende figur viser eksisterende systemer som skal erstattes eller integreres mot og dataflyt mellom disse. For nærmere detaljer, se Bilag 3.
2.2.1 Viktige tema
AtB er opptatt av at Systemet skal være effektivt og intuitivt. Det skal håndtere alle regnskapsprosesser som beskrevet og bør på en enkel måte samhandle med andre systemer.
AtB rapporterer hver måned til styret og eier. Alle avdelingsdirektører og seksjonsledere har økonomiansvar, herunder budsjettering. AtB er derfor avhengig av gode rapporteringsmuligheter som alle med økonomiansvar bruker.
2.2.2 Nøkkeltall
Følgende nøkkeltall gir en indikasjon på omfanget i dag med oversikt over antall brukere, transaksjoner etc. i dagens systemløsning ila. ett kalenderår. Budsjettert 2018-nivå legges til grunn:
a. Antall inngående faktura: Totalt 7000.
b. Antall utgående faktura: Totalt ca. 6500.
c. Antall bilag bokført (inkl. Lønn og avskrivninger): Totalt ca. 10000.
d. Antall brukere regnskapsmodul:
SSA-T Bilag 1 – Kundens kravspesifikasjon
Totalt ca. 4stk.
e. Antall brukere rapportmodul: Totalt ca. 25stk.
f. Antall brukere faktura godkjenning: Totalt ca. 40stk.
g. Antall brukere timeregistrering og utleggsrefusjon/reiseregning: Totalt ca. 100stk.
h. Antall saker til purring/inkasso (estimert for 2019)
Totalt ca. 3000, hvorav ca 50 % anslås å gå fra purring til inkasso
SSA-T Bilag 1 – Kundens kravspesifikasjon
3. Prosjektets målsettinger og overordnede krav
Hovedmål
Kundens primære ønske med systembyttet er raskere og mer effektiv transaksjonshåndtering, økt grad av automatisk datafangst og datagjenbruk, og dermed hurtigere og mer hensiktsmessig rapportering til brukere og beslutningstakere. Xxxxxx ønsker å utvikle sin økonomifunksjon fra transaksjonsorientering til å bli en strategisk forretningspartner i virksomheten. Dette innebærer distribuerte løsninger for rapportering, status og spørring. Rapporteringen skal være tilpasset ulike nivå og med ulik funksjonalitet og ha god brukervennlighet.
Med ulike systemer (både egne og kundebaserte løsninger) blir det utfordrende å fortløpende samle og sammenstille data for «kontinuerlig» rapportering. Data kommer fra ulikt hold til ulik tid og har ulik grad av fullstendighet og kvalitet mellom periodeavslutningene.
Vesentlige målsetninger ved ny løsning vil være:
• Effektivisering av arbeidsprosesser, slik at man flytter ressursbruk fra registrering og avstemming, til overvåkning, analyse og kontroll. Dette muliggjøres vha.:
o Automatisering av transaksjoner / få stoppunkter
o Mindre tidsbruk på manuelle avstemminger og kontroller
o Automatisering av integrasjoner med øvrige systemer
o Automatisering av samling og analyse av data
o Enklere distribusjon av styringsinformasjon og resultater ut til resten av organisasjonen
o Lettere manøvrering og fleksibel arbeidsflyt i systemet
• Rapportering som effektivt sammenstiller følgende informasjon:
o Regnskaps- og budsjettall
o Timer fra timeregistreringssystemet og lønnsinformasjon
• Fleksibel løsning som understøtter virksomhetens vekstambisjoner og mulige omstruktureringer
• Budsjettering, periode- og årsprognose
• Fordeling, periodisering, avsetning
AtB har en ambisjon om å ta i bruk ny teknologi, som f.eks. software-roboter, digitale medarbeidere (chatbots), etc. for å bidra til å realisere disse målsetninger.
SSA-T Bilag 1 – Kundens kravspesifikasjon
4. Føringer for besvarelse av kravspesifikasjonen
Leverandøren skal beskrive et helhetlig løsningsforslag som forklarer hvordan utfordringene til Kunden kan løses i tillegg til å fylle ut de to kolonnene til høyre for tekstbeskrivelsen av hvert krav. Utover dette bes Leverandøren beskrive forutsetninger, presiseringer og utdypende forklaringer i egne vedlegg som angitt. De to aktuelle kolonnene i kravtabellene skal tolkes som følgende:
Krav dekkes i standard løsning
Ja – svar her betyr at kravet dekkes i eksisterende standardløsning, og at det ikke er behov for tilpasninger.
Tilpasning/utvikling – svar her betyr at kravet dekkes ved hjelp av tilpasning/utvikling. Løsningen skal beskrives i kommentarkolonnen eller i vedlegg, og prises særskilt
Nei – svar her betyr at det må lages en tilpasning, og/eller at det er planlagt en framtidig standardløsning som skal dekke behovet. Ved nei skal kommentarkolonnen fylles ut videre med forklaring, i tillegg til at tilleggskostnader skal prises særskilt slik at tilpasningens kostnad fremkommer tydelig av besvarelsen.
Ref. til kommentar, informasjon, evt. forbehold i vedlegg
Her gis en henvisning til riktig vedlegg i Leverandørens tilbud hvor det er angitt forklaring og tilleggsinformasjon (hvis noen). Dette kan være forutsetninger, presiseringer og/eller nærmere beskrivelse av løsningsforslag. Det påregnes at det er behov for at Leverandør oppgir tilleggsinformasjon spesielt på de punkter som eventuelt krever tilpasninger. Det er også tillatt å foreslå alternativ løsning / arbeidsmåte for B-krav dersom Leverandør mener dette vil være fordelaktig for AtB.
5. Funksjonelle krav
Dette kapittelet inneholder Kundens funksjonelle krav, som Leverandøren skal besvare i Bilag 2.
Generelle krav
5.1.1 Bakgrunn
De krav som beskrives i dette kapittelet gjelder generelt for den nye løsningen. Kunden venter seg et moderne, fullintegrert og effektivt System, som naturligvis understøtter alle aktuelle lover og forskrifter. Systemet skal bidra til økt effektivitet, ha god rolle- og tilgangsstyring, og stille med de søke- og rapporteringsmuligheter man kan forvente av et nytt system.
Xxxxxx ønsker selv å ivareta rollen som systemadministrator, og enkelt kunne endre både oppsett og tilganger selv. Man ønsker å kunne styre tilgangen for enkelte brukere, og for enkelte transaksjonstyper. Det skal være lett å sette opp egendefinerte regler, slik at man kan minimere det manuelle arbeidet med transaksjonene.
5.1.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet tilfredsstiller gjeldende, formelle krav i aktuelle lover og forskrifter, herunder bokføringsloven med tilhørende forskrift, merverdiavgiftsloven, norsk god regnskapsskikk (GAAP/NRS) og andre lover og forskrifter som stiller krav til økonomi- og regnskapssystem. | M | ||
2 | Systemet skal ha funksjonalitet som sikrer muligheter for sporing av transaksjoner iht. kravene i gjeldende lovgivning, dvs. at det er en entydig henvisning til dokumentasjon av enkelttransaksjoner. | M | ||
3 | Alle endringer i faste registre, masterdata, tabeller og dimensjoner skal loggføres med knytning til bruker slik at endringen kan etterprøves. | M | ||
4 | Relasjonen mellom kontostreng og rapportering skal ivareta endringer som gjøres (historikk og sporbarhet), eksempelvis ved endring av dimensjonsstruktur. | M | ||
5 | Systemet har mulighet til å styre brukertilganger på rollenivå, og gi ulike typer rettigheter til ulike roller/brukergrupper. | B | ||
6 | Muligheten til å gjøre endringer i faste registre, tabeller og dimensjoner bør tilgangsstyres. | B |
7 | Systemet har drilldown-funksjonalitet slik at det er mulig å bla seg helt ned til innskannet bilag fra konto, reskontro, rapporter og øvrige oppslagsvinduer/søkevinduer. Samt bevege seg f.eks. fra bilagstransaksjon over til Leverandør | M | ||
8 | Systemet har funksjonalitet for å lage forhåndsdefinerte regler for hvilke felter og dimensjoner i bilaget som skal fylles ut (pr. transaksjonstype, pr. konto m.m.) slik at markør automatisk hopper over uaktuelle felter/dimensjoner. Evt. endre rekkefølge av felter. | B | ||
9 | Det bør være mulig å angi obligatoriske felt for Leverandør, kunde og anleggsregister, konto, osv. | B | ||
10 | Ved registrering av informasjon bør det tilstrebes å måtte registrere så lite som mulig manuelt for hver gang, men nok til at man effektivt kan gjenfinne informasjonen. | B | ||
11 | Systemet skal sørge for at brukeren lagrer masterinformasjon ett sted, én gang. | M | ||
12 | Systemet har mulighet for å enkelt koble dokumenter (.pdf, MS-Office, .jpg, etc.) mot masterdata/sentrale registre i løsningen, for eksempel anlegg, kunde, Leverandør, etc. Gjerne via drag-and-drop. | B | ||
13 | Systemet har som minimum norsk språkversjon | M | ||
14 | Systemet skal ha en lett tilgjengelig online hjelp og lett tilgang på hurtigtast-info. | M | ||
15 | Systemet skal ha en enkel søkefunksjon for oppslag mot faste og registrerte data i løsningen tilgjengelig for alle moduler/vindu. | M | ||
16 | I søkefunksjonen skal brukeren selv kunne velge hva det skal søkes på og hva som skal vises i søket. | M | ||
17 | Systemet bør ha funksjonalitet for å registrere bilag ved bruk av funksjonstaster/hurtigtaster | B | ||
18 | Det bør være gode muligheter for notater på de sentrale registre, slik som kunde, Leverandør, anlegg, etc. | B | ||
19 | All utskrift skal være identifisert og tidsstemplet. | M | ||
20 | Systemet har funksjonalitet for å eksportere all data til Excel for videre bearbeiding. Dette gjelder både faste data, registre og spørringer/rapporter generert av systemet. | M |
21 | Det skal være mulighet for å importere bilag/transaksjoner på Excel-format uten manuelle registreringer i systemet. Eksempelvis via Excel-mal eller innkopiering | M | ||
22 | Systemet skal ha mulighet for å lese inn fil for felles oppdatering av sentrale registre (for eksempel muligheter for filinnlesing for oppdatering av postnummer i kunderegister). Eksempelvis via Excel-mal eller innkopiering | M | ||
23 | Direkte overføring fra systemet til Altinn | B | ||
24 | Systemet bør enten kunne inneha egen, faglig regelverkstøtte, eller kunne integreres med faglige oppslagsverk, for eksempel Sticos, InfoTjenester, o.l. Det er ønskelig å kunne gjøre egne, kundespesifikke tilpasninger på beskrivelsene. Leverandøren bes beskrive sin anbefalte modell, og evt. tilby tredjepartsløsning som opsjon. | B | ||
25 | Systemet skal håndtere ulike valuta. | M | ||
26 | Ved bokføring skal valutakurs kunne endres manuelt etter at transaksjonen er registrert slik at systemet automatisk gjør en rekalkulering basert på endringen før bilaget blir endelig bokført. | M | ||
27 | Systemet skal ha støtte for innhenting av valutakurser (eksempelvis fra en bank). Det vil være nødvendig med automatiske/daglige valutakursinnlesinger. | M | ||
28 | Leverandøren beskriver kort historikk for løsninger som Leverandøren tilbyr ifm. denne avtalen, inkl. alder på disse og teknologi løsningene er basert på. | B | ||
29 | Leverandøren beskriver sitt målbilde for løsningene Leverandøren tilbyr ifm. denne avtalen. | B | ||
30 | Leverandøren anbefaler løsninger (moduler/tjenester/funksjoner) Kunden ikke spesifikt har kravstilt, men som Leverandøren kan levere og mener kan være relevant for Kunden. Det bør tydelig framgå hvilke fordeler anbefalte løsninger gir Kunden. Dette kan eventuelt være bruk av software-roboter, digitale medarbeidere (chatbots), etc. | B |
Leverandøren bes prise slike tillegg separat, slik at Kunden kan velge å se bort ifra foreslåtte løsninger i evalueringen. |
Økonomimodell og hovedbok
5.2.1 Bakgrunn
Kunden er en virksomhet i vekst, og det er vesentlig at det nye lønns- og regnskapssystemet er robust og fleksibelt nok til å understøtte dette. Ny løsning skal bidra til å effektivisere regnskapsfunksjonen i forhold til dagens prosesser. I forbindelse med utskiftning av lønns- og regnskapssystem er det viktig å definere kontostrengen slik at denne ivaretar registrering og rapportering av vesentlige styringsdata og økonomidata innad i virksomheten og til eksterne aktører.
Det følgende er en enkel forklaring av AtBs økonomimodell:
Hovedbok
Hovedbokskonto
Dimensjoner
Avdeling
Prosjekt
Underprosjekt
OperatørID
Hovedbok: følger kontoplan for aksjeselskaper (NS 4102) og operer derfor innen kontoserien til denne (kontonummer 1000-8999), i tillegg til nummerserien 9000-9999. Benytter 4-sifret kontoserienummer p.t., men har mulighet til å utvide til kontonummerserie med høyere antall siffer.
Avdeling: Kunden har ulike områder i sin drift som nødvendiggjør regnskapsføring med avdelinger. I tillegg til administrasjonens 22 avdelinger/seksjoner består denne dimensjonen også av 17 kjøreområder (hvert kjøreområde omfatter én eller flere kontrakter), som gir totalt 39 verdier under denne dimensjonen. Denne dimensjonen utvides stadig med nye verdier for å imøtekomme rapporteringsbehov. Dette er p.t. en obligatorisk verdi ved bokføring mot resultatkontoer (kontonummerserie 3000-8999).
Prosjekt: Kunden har ulike prosjekter til enhver tid. Denne dimensjonen utvides stadig med nye verdier etter hvert som det er behov for prosjektoppfølging i bedriften, og benyttes i all hovedsak mot resultatkontoer.
Underprosjekt: I tillegg til prosjektene har Kunden også behov for å registrere data mot diverse underprosjekter. Denne dimensjonen utvides stadig med nye verdier etter hvert som det er behov for rapportering av data på dette nivået, og den benyttes i all hovedsak mot resultatkontoer.
OperatørID: I forbindelse med inntektssikring benytter Kunden denne dimensjonen for å holde rede på mellomværendesituasjoner med sine operatører, som er deres ID-nummer i det ene billettsystemet. Denne dimensjonen utvides stadig med nye verdier etter hvert som det er behov for oppfølging av mellomværendesaldoer, og den benyttes både for balanse- og resultatkontoer.
Se for øvrig hovedbokutdrag i eget vedlegg.
5.2.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemets dimensjonsstruktur og kontostreng skal kunne ivareta virksomhetens registrering og rapporteringsstruktur iht. økonomimodellen nevnt i 5.2.1 | M | ||
2 | Systemets hovedbok og tilhørende registre skal på en fleksibel måte kunne håndtere fremtidig endringer i organisasjonsstrukturen. | M | ||
3 | Systemet skal ha mulighet for å sette opp egendefinerte konteringsregler, eksempelvis mot valg av bilagsart, valg av hovedbokskonto o.l.. | M | ||
4 | Systemet bør ha funksjonalitet for å automatisk kunne postere virksomhetsinterne transaksjoner mellom aktive dimensjoner (avdelinger, prosjekt osv.) | B | ||
5 | Systemet skal ha støtte for å kunne lage konteringsoppsett for fordeling av interne kostnader | M | ||
6 | Et materiell, en ansatt eller annen ressurs bør være henført til en default «hjemmeavdeling». Mange ressurser utfører aktiviteter for flere avdelinger. Løsningen bør ha funksjonalitet for å fordele denne type kostnader på flere avdelinger. | B | ||
7 | Løsningen har kraftfull funksjonalitet rundt balansesiden av regnskapet. Løsningen har funksjonalitet for å håndtere mellomregninger, avsetninger, tilbakeføring av avsetninger, likviditet, kortsiktige poster, o.l. | B |
8 | Systemet skal kunne håndtere 12 regnskapsperioder pr. regnskapsår | M | ||
9 | Det skal være mulig å etablere ulike antall og format av bilagsserier etter f.eks. følgende spesifikasjon: - Inngående faktura - Manuelle bankbilag - Lønnsbilag - Manuelle bilag - Utgående faktura | M | ||
10 | Systemet skal ha funksjonalitet for både manuell og automatisk bilagsnummertildeling | M | ||
11 | Ved manuell inntasting av bilagsnummer, kontrollerer systemet at angitt bilagsnummer er gyldig ut fra forhåndsdefinerte verdier. | M | ||
12 | Systemet skal ha funksjonalitet for å sperre enkelte hovedbokskonti for manuelle føringer. | M | ||
13 | Systemet skal ha funksjonalitet for å kunne gjennomføre en automatisert differansekontroll for hvert bilag, slik at man ikke får registrert bilag med konteringsavvik. Dette gjelder både ved manuell bilagføring, samt der data kommer fra en ekstern kilde | M | ||
14 | Systemet skal automatisk kunne oppdatere inngående balanse på nytt år ved føring av transaksjoner på gammelt år som påvirker utgående balanse for gammelt år | M | ||
15 | Systemet bør ha funksjonalitet for å laste opp diversebilag som .pdf knyttet til bilaget i regnskapet. | B | ||
16 | Systemet skal ha funksjonalitet for å importere/lime inn ferdige posteringer fra Excel/CSV etter fastsatt mal (transer over flere perioder). | M | ||
17 | Det skal være mulighet for å endre bokførte dimensjonsverdier uten å måtte opprette korrigerende bilag. | M | ||
18 | Systemet skal ha mulighet for å kunne sette opp minimum 10 dimensjoner. Som et minimum skal bilagslinjer, hovedbok-, kunde-, Leverandør-, produkt- og anleggsregister kunne gjøre oppslag mot disse og ta med seg valgt verdi til den linjen det gjøres oppslag fra. Eksempel på bruk av en dimensjon er til avdelingsregnskap og prosjektregnskap. | M | ||
19 | Systemet skal kunne angi en standardverdi for hver dimensjon i henholdsvis registrene for hovedbok, kunder, leverandører, produktnummer og driftsmiddelregister (som et minimum av registre). Når en verdi fra en av | M |
disse registrene blir benyttet i eksempelvis bilagsføringen skal standardverdien settes inn automatisk, men kunne overskrives hvis en annen verdi ønskes brukt. | ||||
20 | Systemet skal som et minimum , i hovedbokregisteret, angi at hver av dimensjonene skal ha en obligatorisk verdi ved føring mot kontoen. Eksempelvis hvis en dimensjon er kalt «Avdeling» skal det i hovedbokregisteret la seg angi at ved føring mot denne kontoen i bilagsregistreringen så vil bilagskontrollen stoppe postering av bilaget hvis verdi i Avdelingsfeltet mangler. | M |
Inngående faktura og leverandørreskontro
5.3.1 Bakgrunn
Kunden har en relativt stabil leverandørmasse. De siste årene har omfanget av leverandører økt betydelig som følge av nye ansvarsområder til Kunden. Ny løsning skal bidra til effektivisering av inngående faktura, både for attestanter og regnskapsavdelingen. Kunden har i dag flere ansatte med økonomiansvar (attestanter), som er ansvarlig for godkjenning av faktura og i enkelte tilfeller kontering av faktura.
Kunden har i dag et eget system for mottak av faktura, kontering, oppsett av attestasjonsflyt og sende på flyt for godkjenning. Inngående faktura blir sendt til scanning hos Leverandøren før de gjøres tilgjengelig digitalt til fordeling i Systemet for Kunden. Alle ansatte med økonomiansvar har tilgang til dette. Godkjente faktura overføres/importeres automatisk til regnskapssystemet for remittering.
5.3.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet har kontrollfunksjon som forhindrer registrering av samme fakturanummer to ganger på samme Leverandør | M | ||
2 | Remitteringsstatus skal fremkomme i leverandørreskontro. Dette kan for eksempel være: - Ikke betalt/Åpen post - Sendt til betaling (remittert), men ikke mottatt returfil fra bank - Betalt | M |
3 | Ved delbetaling av faktura bør systemet ha mulighet til å remittere rest på faktura når det blir aktuelt. | B | ||
4 | Systemet bør ha funksjonalitet for å automatisk unnta delbetalte fakturaer fra remitteringsforslag frem til restbeløp blir bestemt remittert | B | ||
5 | Systemet skal ha funksjonalitet for å knytte valuta til Leverandør i leverandørregisteret slik at systemet automatisk velger riktig valuta ved scanning av inngående faktura. | M | ||
6 | Det bør være mulighet for å registrere flere kontaktpersoner på Leverandøren, og gode notatmuligheter tilhørende denne. | B | ||
7 | Systemet bør kunne sende kontoutdrag på e- post | B | ||
8 | Systemet bør ha løsning for enkel viderefakturering av inngående faktura | B | ||
9 | Systemet inneholder egen integrert funksjonalitet for anleggsregister hvor transaksjoner går fra finansregnskap til anleggsregister eller motsatt (f.eks. kun nødvendig å registrere faktura en gang) | M | ||
10 | Alle inngående faktura, uavhengig av opprinnelsesland og valuta, skal inn i fakturagodkjenningssystemet og håndteres på lik linje med norske. | M | ||
11 | Systemet beregner automatisk agio evt. disagio vedrørende fakturaer i utenlandsk valuta | B | ||
12 | Systemet bør kunne sende flere typer bilag/dokumenter på godkjenningsflyt enn faktura. | B | ||
13 | Systemet skal ha funksjonalitet for å registrere bilag ved bruk av funksjonstaster/hurtigtaster. Høyere antall relevante effektive snarveier verdsettes | B | ||
14 | Fakturagodkjenning/kontering bør kunne gjøres på nettbrett eller smarttelefon | B | ||
15 | Tilbudt løsning håndterer inngående fakturaer i utenlandsk valuta med automatisk omregning til NOK på grunnlag av forhåndsdefinert valutakurs. | M | ||
16 | Systemet har kontrollfunksjon som forhindrer registrering av samme fakturanummer to ganger på samme Leverandør | B |
17 | Systemet skal ha funksjonalitet for å knytte valuta til Leverandør i leverandørregisteret slik at systemet automatisk velger riktig valuta ved scanning av inngående faktura. Om dette løses ved OCR eller andre metoder legges det ingen føringer for så lenge Xxxxxx ikke trenger å tolke dokumentene selv. | M | ||
18 | Alle registerdata i attestasjonshierarkiet skal stamme fra et sentralt register | M | ||
19 | Systemet har funksjonalitet for at noen fakturaer skal kunne gå inn i systemet uten attesteringsrutine f.eks. husleie. Mulighet for differensierte (rollebaserte) godkjenningsrutiner. | M | ||
20 | Godkjenningshierarkiet har rollestyring av attestanter og muligheter for at den enkelte selv kan sette inn stedfortreder ved behov. | M | ||
21 | Systemet bør ha mulighet for å sende kopi av innscannede dokumenter/bilag til eksterne e- poster, med kommentar. Det verdsettes mulighet for at tilbakemelding fra denne registreres automatisk i systemet. | B | ||
22 | For hvert scannede dokument/bilag skal det finnes følgende funksjonalitet: - Vise alle vedlegg til faktura - Laste opp vedlegg til dokumentet - skrive ut bilaget (PDF) - kommentere på bilaget. Følger bilaget permanent. - Status og hendelseslogg - Zoome inn og ut på bilaget | M | ||
23 | Systemet skal ha mulighet for redistribuering av allerede ferdige attesterte dokumenter/bilag. | M | ||
24 | Systemet bør tilby mulighet for attestasjon av bilagslinjer | B | ||
25 | Systemet bør ha mulighet for automatisk purring av ikke attesterte bilag etter egendefinerte tidsintervall | B | ||
26 | Systemet bør ha mulighet for å ta ut en oversikt over alle dokumenter/bilag som ikke er ferdigbehandlet (grunnleggende info om dokumentet, samt attestanten den ligger hos). Oversikt bør kunne tas ut i Excel | B | ||
27 | Systemet skal ha en komplett arkivfunksjon med full søkemulighet for alle inngående fakturaer/dokumenter som har blitt sendt til attestering | M |
28 | Systemet bør ha mulighet for å kunne begrense/tilgangsstyre enkelte bilag i arkivet. | B | ||
29 | Systemet har en fullintegrert inngående faktura-løsning, hvor Leverandøren håndterer mottak av faktura påe-post/pdf og EHF. | M | ||
30 | Systemet skal ha mulighet til å automatisk foreslå videre godkjenningsflyt iht. et predefinert, generisk godkjenningshierarki når Xxxxxx selv utfører den manuelle fordelingen/kontering. | M | ||
31 | Systemet bør ha mulighet for automatisk forslag av godkjenningsflyt basert på historisk mønster. | B | ||
32 | Systemet bør ha mulighet til å automatisk sende disse videre på godkjenningsflyt iht. et predefinert, generisk godkjenningshierarki. | B | ||
33 | Systemet bør ha mulighet for å laste opp filer for scanning | B | ||
34 | Systemet bør ha mulighet for egenstyrt brukeradministrasjon | B | ||
35 | Systemet skal ha tilgang til bl.a. hovedbok, reskontroer, avgiftskoder og dimensjoner for oppslag | M | ||
36 | Systemet har en gjenkjenningsgrad/ tolkegrad på over 95 % på scannede bilag. Om dette løses ved OCR eller andre metoder legges det ingen føringer for. | M |
Utgående faktura og kundereskontro
5.4.1 Bakgrunn
Kunden har en til dels stor, men oversiktlig kundeportefølje. Kundemassen har økt de siste år og nesten doblet seg fra 01.01.2018 som følge av blant annet fylkessammenslåing. Kundeporteføljen består i all hovedsak av kommuner, fylkeskommuner, offentlige organer, private bedrifter, organisasjoner og lag. Ny løsning skal bidra til effektivisering og være så papirløs som mulig.
Systemet må oppfattes som enkelt og oversiktlig.
Kunden sender i dag de fleste faktura via EHF og epost (PDF-filer), med store vedlegg i PDF- format. De fleste vedlegg legges inn på fakturaen uavhengig av distribusjonsmetode. Flere kunder mottar samme faktura hver måned og det bør derfor være mulig å legge inn fast/gjentagende fakturering. Det skal være enkel og krysse faktura mot innbetaling.
5.4.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, | Referanse til Leverandørens kommentar, beskrivelse eller |
Tilpasning/ utvikling, Nei) | evt. forbehold til kravet i vedlegg | |||
1 | Det skal framgå av kundereskontro hvilken status enhver kunde har, f.eks.: - Ikke forfalt - Purret - Sendt til inkasso - Under arbeid med purre/inkasso/renteforslag | M | ||
2 | Enkelte statuskoder bør kunne sperre for bokføring/fakturering på Kunden | B | ||
3 | Reskontro i systemet skal minimum vise: Dato, forfallsdato, åpne poster og alle poster. I tillegg bør reskontro vise beløp i valuta, valutakurs, beløp i NOK | M | ||
4 | Det skal være mulighet for å kunne drille ned på enkelte bilag fra kunderegisteret | M | ||
5 | Det bør være mulighet for å registrere flere kontaktpersoner på Kunden og gode notatmuligheter tilhørende denne. For eksempel notater i forbindelse med betalingsutsettelse. | B | ||
6 | Det skal være mulig, på en enkel og smidig måte, å søke opp og hente inn alle nødvendige opplysninger fra andre registre (f.eks. kunderegister, historiske fakturaer) knyttet til faktureringsprosessen. | M | ||
7 | Systemet skal ha en distribusjonsfunksjonalitet som støtter utgående faktura via EHF, PDF og papir. | M | ||
8 | Systemet har funksjonalitet som gjør det mulig å utstede utgående faktura i utenlandsk valuta | B | ||
9 | Systemet har funksjonalitet for registrering av både manuelle innbetalinger og OCR-innbetalinger (betalinger med KID-nummer) i norsk og utenlandsk valuta | B | ||
10 | Systemet skal ha mulighet til å opprette manuelle faktura basert på fritekst. | M | ||
11 | Systemet har funksjonalitet for kryssing av innbetalinger mot utfakturerte beløp. Krysningshistorikk framkommer i reskontro. | M | ||
12 | Systemet har funksjonalitet for å foreta purring, herunder kjøre ut purreliste på grunnlag av forfallsdato. Det er mulig å | B |
overstyre purreliste manuelt, både på Kundenivå og fakturanivå | ||||
13 | Det er enkelt å legge inn fakturamaler (”faste oppdrag”), slik at samme faktura blir generert automatisk etter nærmere fastsatte tidsintervaller (f.eks. ved fakturering av husleie hver måned). | B | ||
14 | Det bør være mulig å kopiere tidligerefaktura som forslag til ny faktura. | B | ||
15 | Systemet tildeler Kundenummer og fakturanummer automatisk på grunnlag av forhåndsdefinerte nummerserier | M | ||
16 | Det bør være muligheter for enkelt å kunne redigere fakturaoppsettet | B | ||
17 | Betalingsbetingelser kan legges inn som fast opplysning. Disse bør kunne overstyres på fakturanivå (uten at de faste betalingsbetingelsene overskrives) | M | ||
18 | Innbetalinger som ikke stemmer med faktura bør fremkomme på avviksrapport (rapport som kommer etter hver OCR- innlesing (KID-nummer)). | B | ||
19 | Faktura som er effektuert skal arkiveres i opprinnelig form. Xxxxxx fakturaoppsett skal det fremdeles kunne skrives ut original fakturakopi («Arkiv»-funksjon) | M | ||
20 | Faktura skal kunne inneholde flere varelinjer / artikler, med eventuelle data fra ulike dimensjoner | M | ||
21 | Systemet skal ha mulighet for å sette opp egne produktnummer, som er knyttet til hovedbokskontoer, og hvor det i produktregisteret lar seg angi en standardverdi for alle dimensjoner i bruk, samt standard avgiftskode. | M | ||
22 | Systemet bør kunne utstede kreditnota mot en tidligere faktura («fakturareferanse»), og vice versa, ved generering av ordre/fakturering, og dermed motregnes fakturareferansen hvis den står som åpen post. | B |
Kundeoppfølging og inkasso
5.5.1 Bakgrunn
Kunden ønsker en enkel og effektiv måte å iverksette og følge opp purre- og inkassosaker til Leverandøren. Det vektlegges positivt at det er en integrasjon mellom regnskapssystemet og inkassotjenesten hvor poster kan unntas purring og inkasso på utvalgte post- og Kundenivå før et utvalg genereres. Oppgjør fra purre- og inkassoprosesser bør i større grad skje automatisk og ikke generere merarbeid for Kunden.
Kunden styrer i dag purre- og inkassoprosedyrene fra regnskapsprogrammet, som har en integrasjon til Leverandørens inkassotjeneste, hvor åpne poster kan unntas purring og/eller inkasso både på post- og Kundenivå før et utvalg genereres. All purring og inkasso blir utført av Leverandøren, så det eneste Kunden gjør er å generere utvalget og sende det inn til inkasso- tjenesten. Når et utvalg er sendt inn til inkassotjenesten kan Xxxxxx styre purre-/inkassostatusene direkte fra regnskapsprogrammet slik at man der kan stoppe/utsette purring og/eller innkreving om ønskelig.
5.5.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet bør ha en mulighet for integrasjon mot en inkassotjeneste, hvor det enkelt lar seg gjøre å sitte i Systemet og sende saker til purring/inkasso, samt se og håndtere statuser for de innsendte fordringene. | B | ||
2 | Systemet bør ha mulighet for å unnta enkeltfakturaer og/eller hele kunder fra purre- og inkassogang, ved generering av purre- /inkassoliste. | B |
Bank, remittering og bankavstemming
5.6.1 Bakgrunn
Kunden verdsetter en enkel og oversiktlig løsning for remittering og bankavstemming. I dag utføres remittering minimum 2 ganger pr. uke, etter Xxxxxxx eget ønske. Hver remittering blir elektronisk signert 2 ganger; ved generering av betalingsforslag og ved innsending av dette forslaget fra regnskapssystemet til banken. Det kreves ingen innlogging i bank ved remittering. Bankavstemming foretas ved månedsslutt. Kunden har i dag Danske Bank.
5.6.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal ha funksjonalitet for remittering av betalingsfiler, mottak av returfil bank og automatisk matching og bokføring av betalinger. Dette forutsetter en direkte kobling/integrasjon mellom Systemet og Kundens bankforbindelse. | M |
2 | Systemet bør ha en integrert løsning for kunne gjøre en automatisk bankavstemming. | B | ||
3 | Systemet skal ha mulighet for å sende åpne poster (både kunde- og leverandørposter) til remittering. Denne remitteringen skal kunne utføres utenom bankens standardsignering på transaksjoner, slik at godkjent remitteringsinformasjon fra systemet kan sendes direkte til banken etter signering i systemet selv. Dette for å slippe å gå inn i nettbank for å signere allerede godkjente betalinger. | M | ||
4 | Når bankbilag føres skal det være mulig å slå opp mot fakturanummeret uten å lete opp reskontronummeret. | M | ||
5 | Systemet skal kunne foreta utbetalinger til andre land (valuta) | M | ||
6 | Ved remitteringsforslag så skal det være mulig å merke de betalingene som ikke skal være med på en enkel måte, samt avregne faktura mot kreditnotaer | M | ||
7 | Remittering skal kunne kjøres i sekvensielle steg, (f.eks. remitteringsforslag, endring, kjøring) slik at man har kontroll og sporbarhet | M | ||
8 | Systemet skal ha funksjonalitet for å kunne delbetale faktura ved remittering (manuelt gå inn og overstyre) | M | ||
9 | Systemet bør ha mulighet for å ikke remittere restbeløp på delbetalte fakturaer, før dette angis eksplisitt av bruker, ved å angi nytt beløp som skal delbetales. | B | ||
10 | Systemet skal ha funksjonalitet for betaling i valuta via remittering | M | ||
11 | Systemet skal ha funksjonalitet for kryssing av utbetalinger mot fakturaer. Krysningshistorikk framkommer i reskontro. Dette gjelder både norske og utenlandske leverandører. | M | ||
12 | Mulighet for å unnta faktura fra remittering | M | ||
13 | Systemet må ha funksjon for dobbel signering/godkjenning av betalingsforslag før de går til remittering. | M | ||
14 | Remittering bør ikke kunne utføres av én person alene, men må godkjennes elektronisk av to ulike personer. | B |
Merverdiavgift
5.7.1 Bakgrunn
En større mengde av transaksjonene til Kunden foregår på nivået med lav avgiftssats, som har medført en del periodiseringssituasjoner ved endringer av denne satsen over de siste årene. I forbindelse med bl.a. billettoppgjør fra sine operatører utfører også Xxxxxx en del fakturering som ikke skal inkluderes i skattemeldingen for mva. Kunden har i dag liten grad av import av varer, men kjøper en del tjenester og programvare fra utlandet. Foruten dette har ikke Xxxxxx noen forhold som avviker fra en ordinær registering og betaling av merverdiavgift til myndighetene.
5.7.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet har funksjonalitet for å håndtere inngående merverdiavgift og utgående merverdiavgift i henhold til gjeldende lover og forskrifter | M | ||
2 | Systemet håndterer flere satser for MVA | M | ||
3 | Det er mulig å definere flere MVA-koder for ulike fordelingsnøkler ved fordeling av inngående merverdiavgift | M | ||
4 | Det er enkelt å endre standard MVA-satser i systemet. Endringen skal kunne være datostyrt. | M | ||
5 | Systemet bør kunne sette en standard MVA- kode pr konto, men det skal være mulig å overstyre denne manuelt. | B | ||
6 | Det bør være mulig å kjøre ut rapport som viser sum pr. MVA-kode pr. hovedbokskonto og som vil være avstembar mot terminoppgaver. | B | ||
7 | Systemet skal registrere beløp som brutto (dvs. inkl. MVA) ved bilagsregistering. Systemet beregner automatisk evt. MVA på grunnlag av angitt MVA-kode. | M | ||
8 | System skal registrere beløp som netto (dvs. eks. mva) ved fakturering. System beregner automatisk eventuell mva på grunnlag av angitt mvakode, samt brutto beløp | M |
9 | Systemet bør kunne overføre omsetning (MVA- oppgave) automatisk til Altinn. | B | ||
10 | Systemet bør kunne bestemme korrekt avgiftssats ved bokføring/fakturering ved bruk av bilagsdatoen/ordredatoen, ikke nødvendigvis kun via datoen bilaget blir bokført på/fakturadato. | B |
Driftsmidler
5.8.1 Bakgrunn
Kunden har i dag et driftsmiddelkartotek, med driftsmidler i flere kategorier. Anleggsregisteret bør være oversiktlig og intuitivt, samt at de fleste operasjoner bør skje automatisk. Kunden har i dag ingen objekter som faller inn under finansiell leasing. Kunden har skattefritak.
5.8.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal ha mulighet for å opprette kategorier/typer (bygg, maskiner, inventar mv.) etter behov | M | ||
2 | Systemet skal ha funksjonalitet for automatisk tildeling av anleggsnummer innenfor driftsmiddelgruppe ved opprettelse av nytt anleggsmiddel. Dette skal kunne overstyres. | M | ||
3 | Et driftsmiddel kan flyttes mellom ulike grupper. Historikk bør bli med ved slike flyttinger | B | ||
4 | Bør være mulig å legge inn skattemessig saldogruppe ved aktivering og skattemessig avskrivningssats | B | ||
5 | Systemet har automatisk beregning av avskrivninger månedlig etter gitte avskrivningssatser. Disse kan kontrolleres og evt. endres før oppdatering i hovedbok/anleggsregister. Dette skal skje etter angivelse av dato | M | ||
6 | Levetid/avskrivningssats skal kunne endres | M |
7 | Systemet har funksjonalitet for automatisk gevinst-/tapsberegning med bokføringsbilag og postering ved salg/utrangering av anleggsmiddel. | B | ||
8 | Systemet kan registrere påkostninger på driftsmiddelet. Muligheter for å angi om dette skal følge angitt levetid på driftsmiddelet eller forlenge avskrivningstiden. Alle posteringer på et objekt skal fremgå à la en reskontro / konto. | M | ||
9 | Systemet beregner regnskapsmessige (lineære) avskrivninger | M | ||
10 | Systemet har mulighet for å beregne skattemessige avskrivinger(saldoavskrivninger) | B | ||
11 | Systemet har mulighet for å simulere avskrivninger frem i tid | B | ||
12 | Systemet har mulighet for intern avskrivingsprofil på driftsmidlene. Med dette menes f.eks. kostnadsfordeling på dimensjonsverdier etter angitt fordelingsnøkkel. | M | ||
13 | Systemet registrerer og håndterer leasede objekter. Det bør være lik kategorisering, og like rik informasjon og funksjonalitet for leasede objekter som for egeneid materiell. | B | ||
14 | Systemet gir oversikt over leasingforpliktelser fram i tid på like linje med avskrivningsobjekter. | B | ||
15 | Systemet har funksjonalitet for at leasingobjekter har ulik levetid og leasingtid. | B | ||
16 | Spørring/oppslag er mulig på alle felter i anleggsregisteret der verdiene er knyttet til et register | M | ||
17 | Rapport som viser oversikt over alle driftsmidler. Rapport bør vise: - Driftsmiddelnr. og navn - Anskaffelesekost IB - Tilgang i perioden - Avgang i perioden - Anskaffelseskost UB - Akk. Avskrivning IB - Periodens avskrivning - Periodens nedskrivning - Tilbakeførte avskrivninger avgang - Akk. Avskrivninger UB - Anskaffelesesår - Avskrivningssats (i % eller år) - Fremtidige avskrivinger | B |
18 | Rapporten bør kunne tas ut pr. konto, saldogruppe eller anleggsgruppe | B |
Rapportering og analyse
5.9.1 Bakgrunn
Gode rapporteringsverktøy og fleksible rapporter er svært viktig for Kunden. Kunden har i dag en egen online rapportmodul som benyttes av økonomiavdeling og ansatte med økonomiansvar.
Denne har mulighet for tilgangsstyring slik at Kunden kan tilpasse hva hver enkelt bruker har mulighet for å gjøre oppslag på og hvilke rapporter som skal være tilgjengelig for dem. Intuitive løsninger og brukervennlighet vektlegges.
Regnskapssystemet skal ha et bredt utvalg av standardrapporter og de bør være fleksible for å vise den informasjon Kunde har behov for. Det er viktig for Xxxxxx at rapporter kan skrives til andre programmer, eksempelvis Excel.
5.9.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Det skal være mulig å kjøre ut standard regnskapsrapporter med valgfrie perioder uavhengig av regnskapsår. - Saldobalanse - Balanse - Resultat | M | ||
2 | Alle rapporter skal enkelt kunne sendes til utskrift samt eksporteres til minimum Excel og PDF-format. | M | ||
3 | Systemet har et bredt utvalg av standardrapporter som bør understøtte regnskapsførers hverdag og bidra til kontroll og effektiv arbeidsprosess. Blant annet leveres systemet med: - Rapport som viser eventuelle hull i bilagsnummerserie - Resultat- og balanserapporter med sammenligningstall fjorår og budsjett - Resultatrapport på dimensjonsnivå - Omsetningsrapport pr. Leverandør (i år og sammenligning med fjorår). Denne rapport kan kjøres ut både med og uten merverdiavgift. - Kundeliste med faste opplysninger (fordelt pr. selskap) - Kontoutdrag som viser alle bevegelser pr. kunde | B |
- Omsetningsrapport pr. kunde (i år og sammenligning med fjorår). Denne rapport kan kjøres ut både med og uten merverdiavgift. - Aldersfordelt saldoliste for kunder og leverandører som skal kunne hentes ut på en gitt dato, både fremover og bakover i tid etter egne valgte intervaller (f.eks. etter inndelingen: Ikke forfalt, +/-: 0-30 dager, 31-60 dager osv.). - Åpen post liste for kunder og leverandører. Denne skal kunne hentes ut på en gitt dato både fremover og bakover i tid. - Rentejournal - Fakturajournal | ||||
4 | Det skal være mulig å søke i alle felter for alle transaksjoner. | M | ||
5 | Systemet bør ha funksjonalitet for effektiv spørring på alle felt som er definert, herunder foreta fritekstsøk i alle felter (at søk skal kunne utføres med bruk av Wildcards) | B | ||
6 | Systemet har enkle oppslagsmuligheter i registre etter behov (f.eks. fra bilag til register, o.l.) | B | ||
7 | Kobling i resultat og balanserapport skal være enkle å endre ved ønske om omklassifisering av konti | M | ||
8 | Kontoutdrag/registreringsjournal (som viser alle bevegelser pr Leverandør/kunde) med mulighet for å vise IB og UB. | M | ||
9 | Leverandør og kundereskontro skal kunne tas ut aldersfordelt og være avstembar mot HB tilbake i tid. | M | ||
10 | Systemet har online oppdatering og få prosesser som krever batch jobbing | M | ||
11 | Systemet har mulighet for å knytte dimensjoner opp mot egendefinerte grupper. F.eks. konto mot kontogruppe, anleggsmiddel mot avdeling, avdeling mot virksomhetsområde etc. Muligheter for å rapportere på tvers av alle felter i kontostrengen og egendefinerte grupper. | B | ||
12 | Systemet gir mulighet for å velge (merke av) elementer i masterregister for sammenstilling av relevante rapportdata. | B | ||
13 | Systemet har valgmulighet på periode (= til/fra måned og år) | M |
14 | Systemet presenterer valgt periode (se over) og akkumulert eller løpende 12 måneder | B | ||
15 | Systemet gir rapporter målt mot tilsvarende i fjor, opprinnelig budsjett, budsjett II (prognose), budsjett III | B | ||
16 | Systemet gjør det mulig å bruke følgende utvalgskriterier ved spørring hovedbok: fra/til periode, år, alle dimensjoner i kontostreng i ulike kombinasjoner. | B | ||
17 | Ved spørring kan man vise alle felter i kontostreng. Gjerne brukerstyrt med hvilke felter som skal vises og sortering av "kolonne" på viste data | B | ||
18 | Systemet skal ha muligheter til å generere standard regnskapsrapporter med budsjettall fra ulike budsjettversjoner med tilhørende avvikskolonner (regnskap mot budsjett). | M | ||
19 | Skal være mulig å hente ut regnskap på kontonivå for hver av dimensjonene. | M | ||
20 | Skal tilbys en rapporteringsløsning med enkel tilgang (f.eks. web-basert rapporteringsportal) for enkel og oversiktlig presentasjon av regnskapsdata. | M | ||
21 | Leverandøren bes beskrive rapporteringsløsningen hva angår brukervennlighet, intuitivitet, effektivitet og tilgjengelighet (f. eks. app). | B | ||
22 | Rapporteringsløsningen skal kun være med lesetilgang (uten mulighet for å endre regnskapsdata) | M | ||
23 | Det skal være mulig å kjøre ut standard regnskapsrapporter med valgfrie perioder; - Saldobalanse - balanse - Resultat - Dimensjoner (hver dimensjon skal kunne kjøres ut.) | M | ||
24 | Standard regnskapsrapportene skal kunne velges basert på: - mulighet for sammenligning med; fjorår og budsjett - Regnskapsår, alle tilgjengelige år i regnskapet. - Periode (måned og eventuelt periodegrupperinger). Rapporten skal vise den isolerte periode og akkumulert så langt i for det valgte året. | M |
25 | Systemet kan presentere data grafisk og i tabellform, i type dashboardfunksjon skreddersydd til hver bruker | B | ||
26 | Ved produksjon av obligatoriske rapporter skal det alltid være mulig å finne tilbake til enkelttransaksjonene som inngår i rapportene (drilldown). Eks. drilldown på kontonivå for å se bilagslinjer med eventuelle bilagsdokumenter (elektroniske) | M | ||
27 | Løsningen har en fleksibel rapportgenerator som på en enkel måte henter data på tvers av systemløsningen i tråd med økonomimodellen, f.eks. hovedbok, reskontri, anlegg, prosjekt, osv. | B | ||
28 | Brukeren kan selv definere rapporter og rapportlayout. Definerte rapportoppsett kan lagres for senere bruk. Eksempelvis på kontonivå og/eller dimensjonsnivå | B | ||
29 | Tilgang til rapporter styres av rollen/rettighet til brukeren. | B | ||
30 | Mulighet for å hente ut en datadump, i Excel- format, som inneholder hovedboksføringer for valgt regnskapsår og minimum ett år før valgt regnskapsår. Datadumpen må inneholde minimum: - periode - år - bokført saldo for hver periode på kontonivå og dimensjonsnivå - budsjettverdi for hver periode på konto- og dimensjonsnivå for alle aktuelle budsjettversjoner. - Se vedlagt eksempel | M |
Budsjett
5.10.1 Bakgrunn
Budsjett og budsjettoppfølging er en viktig del av Kundens økonomistyring. Det rapporteres hver måned, med sammenligning mot budsjett og eventuell prognose. Budsjettet på dimensjonsnivå brukes daglig for alle med økonomiansvar og er en viktig styreindikator.
5.10.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal ha mulighet til å lese inn budsjett på dimensjoner i samsvar med økonomimodellen til Kunden | M | ||
2 | Systemet skal ha funksjonalitet for å kunne lese inn budsjett fra Excel basert på faste maler. | M | ||
3 | Systemet skal ha funksjonalitet for å kunne gjøre endringer på budsjetterte verdier direkte i løsningen. | M | ||
4 | Systemet skal ha funksjonalitet for å kunne angi ulike budsjettversjoner | M | ||
5 | Systemet skal ha muligheter til å kunne kopiere et budsjett til en ny versjon for deretter å gjøre justeringer. | M | ||
6 | Systemet skal ha mulighet til at alle budsjetter skal kunne legges inn med periodisering minimum per måned. | M |
Timeregistrering og -oppfølging
5.11.1 Bakgrunn
• AtB har et eget reglement for fleksibel arbeidstidsordning (se vedlegg 6) og overenskomst (vedlegg 7).
• AtB har i dag et ansattskjema som benyttes for å oppdatere ansattinformasjon overfor Leverandør (se vedlegg 5).
• AtB er IA-bedrift og praktiserer seniorpolitikk.
• Leverandøren etablerer årlig en produksjonsplan i samarbeid med AtB som fastsetter frister for sine og AtBs oppgaver ifm. periodeavslutning og lønnskjøring.
• Styrehonorar utbetales i juni, men styremedlemmer har ingen bruker for timeregistrering.
• AtB har i dag single-sign on og en slik løsning bør leveres av Leverandøren.
• Rom for videreutvikling, skreddersøm av løsninger som passer Kunden.
• Det vil muligens bli behov for integrasjon med fremtidig HRM-system (Human resources management).
• Se vedlegg 3 for prosessbeskrivelse for timeregistrering, -oppfølging og lønn.
5.11.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal kunne understøtte informasjonsflyt, roller og oppgaver tilsvarende vedlagte prosessbeskrivelse for timeregistrering, -oppfølging og lønn (Vedlegg 3). | M | ||
2 | Timer, ferie og permisjoner skal også kunne føres/korrigeres og godkjennes av attesterende/leder/Administrator på vegne av ansatt. | M | ||
3 | Brukere av systemet skal kunne delegere roller som Administrator og Attesterende. | M | ||
4 | Leverandøren bes beskrive hvordan deres system kan tilby AtB forbedringer jf. ovennevnte prosessbeskrivelse. Forbedringer kan være bedre kontroll, bedre oversikt, mer effektiv håndtering, automatisering, m.fl. | B | ||
5 | Systemet skal monitorere og holde oppdatert timesaldo, xxxxx og fravær for valgt periode, slik at den enkelte ansatte og dennes nærmeste leder til enhver tid har oversikt. | M | ||
6 | Det skal være mulig å se akkumulert saldo (timer/ferie/fravær) for gjeldende periode. | M | ||
7 | Det skal være mulig å hente ut rapport hvor man kan se saldo (timer/ferie/fravær) per periode og akkumulert. | M | ||
8 | Det bør være mulig å hente ut rapport hvor man kan se saldo (timer/ferie/fravær) for tidligere perioder, også akkumulert pr disse. | B | ||
9 | Systemet bør varsle leder ved oppdagelse av mønster i sykefravær. | B | ||
10 | Leverandøren skal tilby en løsning for å innhente oppdaterte opplysninger om de ansatte i AtB. Opplysningene registrerer Leverandøren i sitt/sine system(er) for å tilby timeregistrering, -oppfølging og lønn. | M |
11 | Innhenting av oppdaterte opplysninger (ref. punkt over) bør gjøres ved integrerte og effektive løsninger som vil spare tid for ansatte hos AtB. Dette foretrekkes. | B | ||
12 | Systemet skal gjøre det mulig for ansatte i AtB å føre timer både i turnusordning og med normaltidsarbeid. | M | ||
13 | Det skal være mulig å velge timebasert lønn ved føring av timer i systemet. (Gjelder turnus.) | M | ||
14 | Det skal være mulig å føre ubekvemstillegg ved føring av timer i systemet. (Gjelder turnus.) | M | ||
15 | Føring av timer/fravær skal kunne gjøres i systemet 365 dager i året. (Gjelder turnus.) | M | ||
16 | Det skal være mulig å føre timer/minutter utover normal arbeidstid. Ordinær arbeidstid per dag skal være lagt inn i systemet. Gjelder både ved fulltid og for lavere stillingsbrøker. | M | ||
17 | Det skal være mulig å føre timer i systemet i form av antall timer/minutter per dag. | M | ||
18 | Det bør være mulig å føre timer mot prosjekt. Dette uavhengig av normal arbeidstid, fleksitid, overtid osv. (prosjektføringsmodul). Dette vil ha nytteverdi for AtB i tilfeller der timer skal viderefaktureres. | B | ||
19 | Det skal benyttes SSB-koder for stillingstyper. | M | ||
20 | Systemet skal understøtte AtBs reglement for fleksibel arbeidstidsordning og overenskomst, samt endringer i dette. | M | ||
21 | Systemet skal understøtte AtBs seniorpolitikk, også mht. korrekt håndtering av saldo. | M | ||
22 | Systemet skal understøtte håndtering av en femte ferieuke (og sjette, ref. punkt over). | M | ||
23 | Systemet skal ha en god rutine for overføring av xxxxx og plusstid til neste år. Dette skal gjøres iht. gjeldende lovverk og AtBs policy. | M | ||
24 | Systemet bør ha en dashboard-funksjon hvor attesterende leder kan sette opp sin egen oversikt over ansatte med tilhørende | B |
akkumulerte data på f.eks. ferie brukt, ferie til gode, fleksitid-saldo, overtid etc. f.eks. pr. siste godkjente lønnskjøring. | ||||
25 | Systemet bør understøtte timeføring og timeattestering/-godkjenning på flere plattformer. Web-løsning er et minimum, app- løsning i tillegg vektlegges positivt. | B | ||
26 | Det vektlegges helhetlig inntrykk av løsningen hva angår brukervennlighet, intuitivitet, effektivitet og tilgjengelighet. | B |
Reiseregninger og utgiftsrefusjon
5.12.1 Bakgrunn
Det er viktig for Kunden av systemet for reiseregning og utleggsrefusjon er brukervennlig og intuitivt. Mobile løsninger i form av app e.l. vektlegges. Leverandør må også kunne behandle manuelle reiseregninger på papir for eventuelle ansatte eller styremedlemmer som ikke ønsker å levere elektronisk. Dette kan gjerne være i henhold til gitte maler/skjema fra Leverandør. Se vedlegg 4 for prosessbeskrivelse som viser informasjonsflyt, roller og oppgaver som skal støttes.
5.12.2 Xxxxx og krav
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal etterleve de enhver tid gjeldende krav iht. lovverk og forskrifter (regnskap, bokføring, skatt m.fl.) på temaer som bl.a. oppbevaringsplikt, digital signering av reiseregninger/refusjonsoppstillinger, personvern | M | ||
2 | Systemet skal kunne basere seg på de enhver tid gjeldende satsene og reglene angitt i Statens Reiseregulativ | M | ||
3 | Systemet skal kunne ta hensyn til lokale tariffbestemmelser utover Statens reiseregulativ | M | ||
4 | Systemet skal ha funksjon for opplasting av vedlegg for digital lagring og arkiv (kvitteringer). | M |
5 | Systemet skal ha funksjonalitet for å håndtere ulike brukerroller og attestasjonsflyt, som f.eks. hver bruker har en overordnet attestant, noen brukere kan ha doble/triple roller (både ansatt og leder, ansatt, leder og administrator). | M | ||
6 | Ved registrering av reise skal systemet kunne utføre automatiske diettberegninger basert på informasjon gitt om reisen (fra dato og klokkeslett, til dato og klokkeslett, land gjeldende for reisen). | M | ||
7 | Systemet bør kunne håndtere å legge inn flere reiser på én og samme reiseregning | B | ||
8 | Systemet skal kunne håndtere ren utleggsrefusjon (hvis ansatte utfører kjøp/legger ut for bedriften uten at det er i sammenheng med en utført reise) | M | ||
9 | Systemet skal understøtte føring av reiseregninger og utleggsrefusjoner på web som et minimum. | M | ||
10 | Det bør tilbys en app for minimum Android og iOS for å enklere kunne føre reiseregning. Minimum mulighet til å registrere/laste opp kvitteringer via enhetens kamera slik at denne blir tilgjengelig når reiseregningen skal sluttføres. | B | ||
11 | Admin til systemoppsett for enkle oppgaver, som å definere attestantrekkefølger samt administrative oppgaver som å endre kontering, kostnadsfordeling på dimensjoner, m.m. | B | ||
12 | Det vektlegges helhetlig inntrykk av løsningen hva angår brukervennlighet, intuitivitet, effektivitet og tilgjengelighet. | B |
6. Teknologiske og ikke-funksjonelle krav
Dette kapittelet inneholder Kundens tekniske og ikke-funksjonelle krav, som Leverandøren skal besvare i Bilag 2.
Krav til opplæring
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Det skal tilbys opplæring av nøkkelpersonell/superbrukere og evt. vanlige brukere, i den grad det er nødvendig for å ta systemet i bruk på en fullgod måte. Det forventes at systemet i utgangspunktet er så enkelt og intuitivt å ta i bruk at opplæringsomfanget vil være begrenset. Leverandøren bes beskrive hva som vil leveres. | B | ||
2 | Det skal tilbys opplæring av testpersonale i forkant av testperioden slik at Kunden er i stand til å utføre tilstrekkelig med testing av det tilbudte systemet. | M | ||
3 | Leverandøren skal sikre tilstrekkelig med opplæringsmateriell som er tilpasset systemet som leveres Kunden. | M | ||
4 | Opplæring er en del av leveransen, og Leverandøren bes beskrive sin anbefalte metodikk for dette prosjektet og denne Kunden. | B |
Krav til sikkerhet
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet har funksjonalitet for logisk adgangskontroll, herunder autorisasjon og autentisering med bakgrunn i hver enkelt brukers behov for å utføre normale arbeidsoppgaver. | M | ||
2 | Styring av tilgangsrettigheter bør kobles mot AtBs Active Directory, slik at brukere kan aksessere lønns- og regnskapssystemet gjennom Single sign-on (SSO; dvs. uten å måtte taste brukernavn og passord på nytt for å aksessere systemet). Dette gjelder for alle typer brukerroller og evt. arbeidsflater som støttes av Leverandørens | B |
løsninger. Relevante flater er f.eks. Windows- PC, nettbrett, smarttelefon. Kunden opplever dette som en stor tidsbesparelse for brukeren, og vektlegger gode SSO-løsninger høyt. | ||||
3 | Leverandøren skal levere løsninger som fortrinnsvis ikke krever lokale klientinstallasjoner hos Kunden, og iallfall holder dette til et minimum. | M |
Krav til responstider
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Systemet skal ha god responstid på alle vanlige transaksjoner og handlinger. | M | ||
2 | Leverandøren bes beskrive Systemets responstider i normal drift. Angi eventuelle forutsetninger i Kundens installasjoner eller nettverk. | B |
Krav til konvertering
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Leverandøren skal gjennomføre konvertering av Kundens faste data og transaksjoner på hovedboksnivå. Dette gjøres for minimum 2017 og 2018. | M |
Krav til databehandleravtale
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Leverandøren skal ved avtaleinngåelse signere vedlagt databehandleravtale. (Vedlegg 9 til konkurransegrunnlaget) | M |
7. Krav til integrasjoner
Kundens eksisterende integrasjoner, fremtidige krav til disse og evt. nye integrasjoner er beskrevet i Bilag 3 Kundens tekniske plattform. Dette kapittelet inneholder Kundens krav til integrasjoner, som Leverandøren skal besvare i Bilag 2.
Det nye Systemet bør ha mulighet til å enkelt kunne knytte seg mot eksisterende og fremtidige systemer i Kundens løsningsportefølje ut ifra endrede behov hos Kunden, eller nye løsninger fra Leverandøren.
Kravnr. | Kravbeskrivelse | Krav- kode (M/B) | Krav dekkes i standard løsning? (Ja, Tilpasning/ utvikling, Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Leverandøren skal etablere integrasjonene til/fra Systemet som spesifisert i Bilag 3 Kundens tekniske plattform. | M | ||
2 | Leverandøren av Systemet vil ha et koordineringsansvar ved integrasjoner mot andre systemer. I dette ligger det at Leverandøren av lønns- og regnskapssystemet skal drive prosessen for å implementere lønns- og regnskapssystemet og etablere nødvendige grensesnitt/integrasjoner som beskrevet i Bilag 3 Kundens tekniske plattform. Dette koordineringsansvaret prises inn av Leverandøren. | M |
8. Krav til etableringsprosjektet
Krav til prosjekt- og fremdriftsplan
I tabellen nedenfor beskrives de krav Kunden stiller til prosjekt- og fremdriftsplan for etablering av Systemet. Følgende krav skal besvares i Bilag 4.
Krav nr. | Krav | Krav-kode (M/B) | Krav dekkes? (Ja/Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Leverandør utarbeider en realistisk prosjekt- og fremdriftsplan for prosjektet som etablerer Systemet. | B | ||
2 | Leverandøren beskriver gjennom prosjektplanen organisasjonen for etableringsprosjektet. | B | ||
3 | Leverandøren beskriver i sitt forslag til prosjekt- og fremdriftsplan hvordan samarbeidet med Xxxxxx er tenkt løst. | B |
Krav til testing og godkjenning
I tabellen nedenfor beskrives de krav Kunden stiller til testing og godkjenning ifm. etablering av Systemet. Følgende krav skal besvares i Bilag 5.
Krav nr. | Krav | Krav-kode (M/B) | Krav dekkes? (Ja/Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Forut for Kundens akseptansetest skal Leverandøren foreta test av løsningen. Disse tester skal omfatte enhetstest, integrasjonstest og ytelsestest. Leverandøren skal utarbeide rapport med testresultater som gjøres tilgjengelig for Kunden. | M |
Krav nr. | Krav | Krav-kode (M/B) | Krav dekkes? (Ja/Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
2 | Kunden har ansvar for planlegging og gjennomføring av Kundens akseptansetest. Leverandøren bør bistå Kunden i planlegging og gjennomføring av akseptansetest, herunder • Bidra med malverk og eksempler for utarbeidelse og beskrivelse av testplan med beskrivelse av testcase • Veilede Kunden for å sikre at akseptansetesten dekker alle relevante forhold, både mht. funksjonalitet, integrasjoner og ytelse • Opplæring av brukere som skal gjennomføre akseptansetesten • Bistå i gjennomføring av akseptansetesten mht. å besvare spørsmål fra testbrukere, rette feil • Mer konkret plan for akseptansetest skal utarbeides senest 30 dager før planlagt oppstart av akseptansetesten. • Kategorisering av feil gjøres iht. pkt. 2.4.5 i Avtalen. Leverandøren bes beskrive konkret hvordan | B | ||
3 | Leverandøren bør stille tilgjengelig egnet verktøy for testadministrasjon, med mulighet for kategorisering, oppfølging og rapportering. | B | ||
4 | Forberedelse og gjennomføring av idriftsettelse. Leverandøren skal utarbeide detaljert plan for forberedelse og gjennomføring av idriftsettelse. Kunden skal bidra med relevant informasjon til denne planen. | M |
Krav til organisering av etableringsprosjektet
Krav nr. | Krav | Krav- kode (M/B) | Krav dekkes? (Ja/Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
1 | Leverandøren angir hvilke roller/funksjoner som er nøkkelfunksjoner i prosjektorganisasjonen. | B |
I tabellen nedenfor beskrives de krav Kunden stiller til Leverandørens organisering av etableringsprosjektet. Følgende krav skal besvares i Bilag 6.
Krav nr. | Krav | Krav- kode (M/B) | Krav dekkes? (Ja/Nei) | Referanse til Leverandørens kommentar, beskrivelse eller evt. forbehold til kravet i vedlegg |
2 | For alle nøkkelfunksjonene i Leverandørens prosjektorganisering bør Leverandøren tilby navngitte ressurser (nøkkelressurser). For alle nøkkelressursene bør det dokumenteres relevant kompetanse og erfaring i form av kortfattet CV som vedlegges tilbudet | B | ||
3 | Leverandøren bør ha tilgang på nødvendig kapasitet til å kunne gjennomføre sine forpliktelser i etableringsprosjektet og beskrive hvordan dette vil sikres. | B | ||
4 | Leverandøren beskriver hvilken kompetanse og kapasitet Kunden må stille tilgjengelig ovenfor Leverandøren i prosjektgjennomføringen. Beskrivelsen inneholder beskrivelse av hvilke roller og ansvar som Kunden skal fylle samt angivelse av antall dagsverk som Kunden må stille tilgjengelig for å dekke det beskrevne behovet. | B |
9. Vedlegg
Vedlegg 1: Hovedbokutdrag
Vedlegg 2: Datadump fra regnskapssystemet i Excel på kontonivå, som benyttes som underlag for månedsrapportering
Vedlegg 3: Prosessbeskrivelse for timeregistrering, -oppfølging og lønn Vedlegg 4: Prosessbeskrivelse for reise- og utgiftsrefusjon, -oppfølging og lønn Vedlegg 5: Ansattskjema
Vedlegg 6: Reglement for fleksibel arbeidstid for ansatte i AtB Vedlegg 7: Overenskomst for ansatte i AtB