Oppsett refusjonsmodul

Transkript

1 Oppsett refusjonsmodul Brukerveiledning Oppsett refusjonsmodul 19. mai 2017 Selv om alt er gjort for at informasjonen skal være nøyaktig og fullstendig, kan opplysningene i dette dokumentet endres uten varsel. Unit4 AS er ikke ansvarlig for eventuelle feil i dokumentasjonen. Kontakt nærmeste Unit4 AS Support hvis du har spørsmål. Microsoft Excel, Windows og Microsoft SQL Server er enten registrerte varemerker eller varemerker for Microsoft Corporation i USA og/eller andre land. Oracle er registrert varemerke for Oracle Corporation og/eller andre land. Alle andre merkenavn, produktnavn og logoer er varemerker eller registrerte varemerker for de respektive eierne. Dette dokumentet inneholder informasjon som er rettighetsbeskyttet av Unit4 AS, og som selskapet betrakter som en forretningshemmelighet. Det er uttrykkelig avtalt at det ikke skal kopieres helt eller delvis, offentliggjøres, bekjentgjøres eller på andre måter gjøres tilgjengelig for noen tredjeparter verken direkte eller indirekte. Kopiering av denne dokumentasjonen for noe som helst formål er forbudt uten at det på forhånd er innhentet skriftlig samtykke fra Unit4 AS, Oslo, Norge. Med enerett. Unit4 AS Unit4 AS, Gjerdrums vei 4, 0401 Oslo, Norge Tenk på miljøet. Vær vennlig å ikke skriv ut dette dokumentet så fremt det ikke er nødvendig!

2 Innhold Oppsett refusjonsmodul 1 Innhold 2 Endringslogg 3 Innledning 6 Nyheter/endringer 7 Oversikt refusjon 9 Oppsett i UBW 11 Refusjonsgrupper 12 Refusjonstyper 14 Relasjoner 16 Fraværskoder 20 Varsel om max-dato i fraværsregistrering (PS32) 24 Handlingstype 26 Lønnarter i rapportkolonner 29 Verdireferanser 32 Lønnart for kontering 33 Bilagsarter/serier/posteringsrunder 34 NAV-kontor 36 Saksbehandler 43 Dokumenttyper 45 Datakontroll 48 Systemparametere 51 Kontering 65 Informasjon 67 Side 2 av mai 2017

3 Endringslogg Historikk Her er en punktvis beskrivelse av hva som har endret seg i dokumentet siden sist utgivelse: Dato Endring Navn Nye systemparametere REIMB_PRN06_REMOVEZERO og REIMB_PSN16_OVERLAP_VAC og endring i systemparameter REIMB_PRN06_WARNDA Det er ingen endring i oppsett til versjon Nytt oppsett for begrepsverdiene for begrep NAVFORVALTNING Ny systemparameter REIMB_PRN06_WARNDA. Nytt kundenummer for de som benytter PSN19 Innlesing av fil fra NAV Ny (valgfri) systemparameter for bruk i PSN20 Automatisk utligning. Det er gjort endringer i program PSN20 Automatisk utligning som innebærer at systemparameterne REIMB_PSN20_COMP_REG_NO og REIMB_PSN20_DIFF_MATCH må være skrudd på Det kreves ingen endringer i oppsett av refusjonsmodulen for versjon BW On! Lagt til en presisering rundt bruk av adresse for begrepet NAVFORVALTNING, se side Lagt til presisering rundt systemparameter REIMB_MATCH_AMOUNT_LIMIT, REIMB_MAX_DATE_COL_SICK og REIMB_MAX_DATE_COL_MAT samt fjernet begrensning ved bruk av REIMB_TPRN020_ACCOUNT. Oppdatert informasjon rundt lønnarter i rapportkolonner Lagt til informasjon rundt begrepsverdier for begrep NAVFORVALTNING SOM SOM SOM SOM SOM SOM SOM SOM SOM Lagt til flere nye systemparametere. SOM 19. mai 2017 Side 3 av 67

4 Utvidet informasjon rundt handlingstype for brukere som benytter annet språk enn norsk (kapittel Handlingstype). Forslag til nytt oppsett for svangerskapspenger (kapittel Refusjonstyper). Nytt begrep NAVKODEREF En ny systemparameter. Nytt begrep for å hente adresse til IOskjemaer Nytt begrep beskrevet vedrørende fordeling Nye systemparametere REIMB_USE_SATS5_KONTERING REIMB_KONTERING_DIM Ny systemparameter REIMB_PRN06_VAL_DAYS Ny systemparameter REIMB_HS01_BLANK_SCHEMA Forbedret dokumentasjon for systemparameterne som har med maksdato å gjøre Nye systemparametere REIMB_MAX_DATE_NAV og REIMB_MAX_DATE_VIEW Endring i Lønnarter i rapportkolonner. SOM SOM SOM SOM SOM SOM HKH SOM Oppdatert til Agresso Milestone 3 SOM Spesifisering av oppsettet for fraværskode for svangerskapspenger. SOM Oppgradert til Route 66 SOM Forbedret dokumentasjonen i forhold til ekskludering av ansettelsestyper (begrep EKSKL) Fjernet begrepsverdi 41 for begrepet REFTYPE Ny fraværskode og refusjonsgruppe for ferieavvikling i løpet av en sykmelding. I tillegg er det lagt til dokumentasjon for oppsett av datakontroll i refusjonsmodulen. SOM SOM SOM Ingen nyheter, kun forbedringer av SOM Side 4 av mai 2017

5 dokumentasjonen Ny UNIT4-profil. Oppdatert dokumentasjon i forhold til nye Inntekts- og trekkopplysningsskjemaer innført fra SOM 19. mai 2017 Side 5 av 67

6 Innledning Generelt Dette dokumentet beskriver nødvendig oppsett for refusjonsmodulen. Formål Dokumentet skal gjøre det mulig å utføre det oppsettet som må være på plass før oppgradering av modulen kan foretas eller tas i bruk: Fraværskoder Refusjonsgrupper (begrep REFUSJON med DM-kode MNBE) Fraværsgrupper for permisjon og ferie Refusjonstyper (begrep REFTYPE med DM-kode MNBF) Bilagsarter, bilagsserier og posteringsrunder Lønnart for refusjonslistene Lønnarter i rapportkolonner NAV-kontor Handlingstype for Refusjon Verdireferanser for antall dager i året, 6G, skatte % og deltids % Dokumenttyper for Inntektsopplysningsskjema (IO-skjema) og Trekkopplysningsskjema (TO-skjema) dersom disse skal lagres i dokumentarkivet Systemparametere Relasjon på ansatt, stilling eller ansettelse for å finne bedriftsnummer Versjoner De til enhver tid supporterte versjoner av Unit4 Business World (UBW). Side 6 av mai 2017

7 Nyheter/endringer Generelt Dette kapittelet inneholder informasjon om siste endringer i programmet. REIMB_PSN16_OVERLAP_VAC Det er lagt til rette for å opprette en ny systemparameter (det er ikke et krav å opprette denne). Det finnes i dag en kontroll i programmet som sjekker at det er benyttet lik fraværskode for ferie i løpet av arbeidsgiverperioden dersom en ressurs har mer enn én stilling. Dersom det er benyttet ulike feriekoder på de to stillingene, vil rapporten i dag stoppe og det gis en melding i rapportloggen om hvilke(n) ressurs(er) det gjelder. Dersom man ikke ønsker en slik kontroll, kan man opprette systemparameter REIMB_PSN16_OVERLAP_VAC. Da vil programmet ikke utføre denne kontrollen, men kjøre videre som normalt. REIMB_PRN06_REMOVEZERO Ved behov kan det opprettes en ny systemparameter REIMB_PRN06_REMOVEZERO. Dersom denne systemparameteren er opprettet og skrudd på, vil alle rader i Ajourhold refusjonskrav (PRN01) vise tilhørende konteringsdimensjoner. Dersom systemparameteren ikke er skrudd på, vil rader som kun inneholder helgedager (m.a.o. antall refusjonsdager = 0) ikke inneholde konteringsinformasjon. Eksempel dersom systemparameteren er skrudd på: 19. mai 2017 Side 7 av 67

8 Eksempel dersom systemparameteren ikke er skrudd på: Bakgrunnen for denne endrede funksjonaliteten er kun med tanke på oppslag i skjermbildet Ajourhold refusjonskrav (PRN01). Enkelte kunder benytter konteringsdimensjonene som søkekriterier for oppslag i skjermbildet, og det er da viktig at alle rader inneholder konteringsverdier. Utover dette har ikke den endrede funksjonaliteten noen innvirkning på andre rapporter som f.eks. bokføring. Side 8 av mai 2017

9 Oversikt refusjon Beregning av krav Rutinen for å beregne et refusjonskrav er som følger: Beregne refusjonskrav (PRN06) i 6 varianter. Kjøre rapporter for å produsere IO- og TO-skjema. Bokføring av refusjonskrav. Oversikten under viser prosessen for å beregne krav og hvilke menypunkt i UBW som benyttes. Utligning av refusjon Rutinen for utligning av refusjonskrav består av: Utligning av refusjonskrav Bokføring av utlignede refusjonskrav Differanseføring I tillegg er funksjonalitet fra kundereskontroen hentet inn i modulen slik at all oppfølging av refusjonskrav kan foregå i refusjonsmodulen. Oversikten under viser prosessen for å utligne refusjonskrav og hvilke menypunkt i UBW som benyttes. 19. mai 2017 Side 9 av 67

10 Side 10 av mai 2017

11 Oppsett i UBW Generelt Nødvendig oppsett beskrives som eksempler. Oppsettet viser UBW-standard og kan variere fra ulike installasjoner. Alle skjermbilder er fra UBW versjon 5.5. Det gjøres oppmerksom på at det kan være ulikheter mellom versjon 5.5 og høyere versjoner, men disse skal være beskrevet spesifikt. 19. mai 2017 Side 11 av 67

12 Refusjonsgrupper Generelt Begrep og begrepsverdier for de ulike refusjonsgruppene som benyttes i PRN06 Beregne refusjonskrav må opprettes. I tillegg må det opprettes begrepsverdier for ferie og andre permisjoner med lønn. Begrep REFUSJON Begrepet skal ha DM-kode MNBE og lengde 12. Merk! Dersom begrep REFUSJON finnes fra før med annen DM-kode må gammelt begrep døpes om før du oppretter nytt. Begrepsverdier REFUSJON Følgende refusjonsgrupper må opprettes: Begrepsverdi REFMARB REFUARB REFUARB100 Beskrivelse Sykepenger sykdom, refusjon med arbeidsgiverperiode Sykepenger kronisk sykdom, refusjon uten arbeidsgiverperiode Omfatter kronisk sykdom og svangerskapsrelatert sykdom Foreldrepenger 100 % dekning (benyttes også for svangerskapspenger) Side 12 av mai 2017

13 Begrepsverdi Beskrivelse REFUARB80 Foreldrepenger 80 % dekning REFMARBOMS Omsorgspermisjon, refusjon etter 10 dager REFUARBOMS Omsorgspermisjon, refusjon fra dag 1 FRI Ferie FERIESYK Ferieavvikling i løpet av periode med sykmelding PERMM Annen permisjon med lønn REFMARBPLEI Refusjon pleiepenger fra dag 8 REFUARBPLEI Refusjon pleiepenger fra dag 1/Opplæringspenger REFSVANG Refusjon svangerskapspenger REFBEHA Refusjon enkeltstående behandlingsdager Refusjonsgruppe FRI og FERIESYK benyttes for ferie og brukes av PRN06 for å finne ut om det skal beregnes ny arbeidsgiverperiode i forbindelse med ferie i en fraværsperiode. Refusjonsgruppe PERMM benyttes for å sette kryss i felt 1.16, 1.17 og 1.19 på IOskjema. Merk! Refusjonsmodulen håndterer ikke kombinasjonen av enkeltstående behandlingsdager i forbindelse med kronisk sykdom. 19. mai 2017 Side 13 av 67

14 Generelt Refusjonstyper Det må opprettes begrep og begrepsverdier for refusjonstyper. Refusjonstypene benyttes til følgende: Sette kryss i ett av feltene (Opplysningene gjelder) på IO- og TOskjema. Sette kryss for langvarig eller kronisk sykdom eller svangerskapsrelatert sykdom samt i felt 1.6 Foreligger det sykmelding fra lege på skjema NAV (for refusjon av sykepenger i arbeidsgiverperioden pga langvarig, kronisk eller svangerskapsrelatert sykdom). Begrep REFTYPE Begrepet skal ha DM-kode MNBF og feltet Len skal ha verdi 2. Merk! Dersom begrep REFTYPE finnes fra før med annen DM-kode må gammelt begrep døpes om før du oppretter nytt. Begrepsverdier REFTYPE Følgende refusjonstyper skal opprettes: Begrepsverdi Beskrivelse Felt på IO-skjema 1 Sykepenger til arbeidstaker Sykepenger til sjømann i utenriksfart Annet Svangerskapspenger Foreldrepenger ved fødsel og adopsjon 1.6 (med feriepenger) 6 Omsorgspenger Pleie-/opplæringspenger Kronisk syk egenmelding Kronisk syk legemelding Svangerskapsrelatert sykdom, egenmelding 14 Svangerskapsrelatert sykdom, legemelding Foreldrepenger/Fedrekvote, uten feriepenger 1.6 Side 14 av mai 2017

15 Begrep NAVKODEREF I forbindelse med automatisk utligning (PSN19 Innlesing av fil fra NAV) må det opprettes et nytt begrep med DM-kode MNBN: Begrepet skal ha følgende begrepsverdier: Disse begrepsverdiene benyttes i automatisk utligning for å koble sammen refusjonstypene i UBW med refusjonskoden fra NAV. 19. mai 2017 Side 15 av 67

16 Relasjoner Innledning Beregne refusjonskrav (PRN06) benytter relasjoner for å hente ut enkelte data rapporten benytter. Relasjoner på fraværskode - REFUSJON - REFTYPE Relasjoner på ressurs - GRUPPE Relasjoner på ressurs/stilling/ansettelse - BEDRNR Relasjoner på stilling - EKSKL Relasjoner på KUNDENR - POSTNR (beskrives under kapittel NAV-kontor) Relasjoner på fraværskode Begrepet FRAVKODE kobles til begrep REFUSJON og begrep REFTYPE. Dette gjøres under menypunkt Agresso Lønn og Personal > Personalsystem > Fravær > Relasjoner på fraværskode. Merk! For relasjonen REFUSJON skal felt Dup. være krysset av. Navn REFUSJON REFTYPE Beskrivelse Benyttes for å hente ut alt fravær som hører til aktuell refusjonsgruppe. Benyttes for å sette korrekt kryss i IO-, TO- og KRskjema. Side 16 av mai 2017

17 Relasjoner på ressurs Relasjonen GRUPPE benyttes for å krysse av på IO-skjema for om sykepenger utbetales i arbeidsgiverperioden. Se nærmere beskrivelse av denne funksjonaliteten i brukerveiledningen for den enkelte rapport for Beregne refusjonskrav. Merk! Dersom dette begrepet ikke benyttes, må det eksistere et begrep som forteller hvilke ansatte som det betales sykelønn for. Parameter Relasjon 2 og Relasjonsverdi2 må da endres i alle varianter av Beregne refusjonskrav (PRN06). Relasjoner på ressurs eller stilling/ansettelse Refusjonskrav vil genereres per bedriftsnummer. Det må derfor eksistere en relasjon for å hente dette fra enten ressurs eller stilling/ansettelse. Det må eksistere en relasjon på enten ressurs eller stilling/ansettelse som igjen er koblet til bedriftsnummer. 19. mai 2017 Side 17 av 67

18 I eksempelet som her er vist er det KOSTSTED som er knyttet til BEDRNR. Relasjon er knyttet både mot ressursen og stillingen den ansatte har. Siden flagget Rapport er avkrysset på ansettelsen er det begrepsverdien derfra som blir benyttet for å hente bedriftsnummer. Relasjoner på stilling Beregne refusjonskrav (PRN06) gir mulighet for å ekskludere enkelte stillinger fra refusjonsbehandling ved hjelp av begrepet EKSKL. Merk! Begrepet opprettes kun dersom det er behov for å ekskludere stillinger. Begrepet skal ha DM-kode MNAE. Opprett begrepsverdi PRN06 for bruk i Beregne refusjonskrav (PRN06). Opprett en relasjon mellom begrep ANS.TYPE og begrep EKSKL. Side 18 av mai 2017

19 Koble aktuelle ansettelsestyper som skal ekskluderes mot begrepsverdi PRN06. Ved å fylle ut rapportparameterne for ekskludering i PRN06 Beregne refusjonskrav vil dermed ansettelsestypene koblet til begrepsverdi PRN06 ikke bli tatt med i refusjonsberegningen. Fordeling av lønnskostnader Dersom det foreligger en lønnfordeling basert på lønnart, vil beregning av refusjonskrav følge den samme fordelingen. Programmet klarer her ikke å skille mellom lønnarter som har med lønnsutbetaling å gjøre og andre lønnarter. Som eksempel kan det ofte foreligge en fordeling på lønnarten for et kantinetrekk. Dersom det finnes slike fordelinger som man ikke ønsker at skal tas hensyn til i beregning av refusjonskrav, kan man opprette et begrep med DM-kode MNBM: I begrepsverdiene for dette begrepet må man oppgi alle lønnarter man ønsker at programmet skal ta hensyn til ved bokføring av refusjonskrav. Man utelater da å oppgi lønnarten for kantinetrekk som var nevnt i avsnittet over. 19. mai 2017 Side 19 av 67

20 Innledning Forutsetning Fraværskoder Fravær det skal kunne søkes refusjon for må være koblet til korrekt refusjonsgruppe og refusjonstype. Fravær som gjelder kronisk sykdom, svangerskapsrelatert sykdom og omsorgspenger for kronisk syke eller funksjonshemmede barn må føres på egne fraværskoder. Dersom fravær føres med stilling må også lønn ligge per stilling. Dersom fravær føres uten stilling må også lønn ligge uten stilling. Merk! Enkelte kunder fører fravær uten stilling men har allikevel lønn med stilling. I disse tilfellene kan man allikevel kjøre refusjon. Det må da opprettes en egen generert lønnart uten stillingsopplysninger for bruk i refusjonsmodulen. Se nærmere beskrivelse under Lønnarter. Fraværskoder Dersom stillingsmappekortet benyttes må flagg Stilling avkrysses. Relasjon på fraværskode Fraværskoden må kobles til aktuell refusjonsgruppe (REFUSJON) samt korrekt refusjonstype (REFTYPE). Side 20 av mai 2017

21 Relasjon på fraværskoder for foreldrepenger Fraværskoder for foreldrepenger må kobles til to refusjonsgrupper: Navn REFUARB100 eller REFUARB80 PERMM Beskrivelse Benyttes i Beregne refusjonskrav (PRN06) for å få hentet ut aktuelle fraværskoder og få korrekt beregning. For å få satt kryss i korrekte felt på IO- og TO-skjema Relasjon på fraværskoder for svangerskapspenger Merk! Det er anbefalt å opprette en egen refusjonsgruppe for svangerskapspenger. Dette er nødvendig for å sikre at det blir laget inntektsopplysningsskjema også dersom den ansatte går direkte over fra svangerskapspenger til foreldrepenger 100 % uten noe opphold i mellom. Det må da opprettes en egen rapportvariant av PRN06 Beregne refusjonskrav der rapportparameter REFUSJON settes lik REFSVANG. Dersom man i stedet benytter refusjonsgruppen REFUARB100 (som anbefalt tidligere) vil det ikke bli laget et eget inntektsopplysningsskjema dersom den ansatte går direkte fra svangerskapspenger til foreldrepenger 100 %. 19. mai 2017 Side 21 av 67

22 Spesielle fraværskoder Fraværskoder for kronisk sykdom og svangerskapsrelatert sykdom må splittes i koder for egenmelding og sykemelding. Dette for å kunne sette korrekt kryss på IO- og TO-skjema. Merk! Egne fraværskoder for sykdom kronisk syke/funksjonshemmede barn må opprettes for å kunne kjøre refusjon omsorgspenger med refusjon fra første dag. Det må opprettes forskjellige fraværskoder for ferie: én kode for ferieavvikling i en periode der den ansatte har sykmelding og én kode for ferie der den ansatte ikke har sykmelding under ferieavviklingen. Årsaken til dette er at regelverket tolkes forskjellig i disse to tilfellene dersom ferien starter før arbeidsgiverperioden er utløpt. Kode 500 er her knyttet til refusjonsgruppe FRI og benyttes i de tilfeller der den ansatte ikke har sykmelding som dekker den perioden ferien avvikles. Side 22 av mai 2017

23 Kode 505 er knyttet til refusjonsgruppe FERIESYK og benyttes i de tilfeller der den ansatte har sykmelding som varer i den perioden ferien avvikles. 19. mai 2017 Side 23 av 67

24 Innledning Varsel om max-dato i fraværsregistrering (PS32) Det er mulig å få varsel om den ansattes max-dato ved registrering av sykefravær eller fødselspermisjon. Dette er kun en opplysning, og vil ikke hindre brukeren i å registrere fravær utover max-dato. Max-dato Ved registrering av fravær i fraværsregistreringsbildet (PS32), vil det komme informasjon om den ansattes max-dato, dersom denne er lagret i ressursbildet (HS01). Det er i utgangspunktet fire forskjellige max-datoer som kan vises: - Systemgenerert (fra PRN06 Beregne refusjonskrav) max-dato for sykefravær. - Systemgenerert (fra PRN06 Beregne refusjonskrav) max-dato for fødselspermisjon. - Max-dato fra NAV for sykefravær - Max-dato fra NAV for fødselspenger. Hvilke max-datoer som fremkommer i fraværsregistreringsbildet, bestemmes av systemparameterne REIMB_MAX_DATE_NAV og REIMB_MAX_DATE_VIEW. Hvilke felter i ressursbildet (HS01) som benyttes til de forskjellige max-datoene settes opp i systemparameterne REIMB_MAX_DATE_COL_MAT, REIMB_MAX_DATE_COL_SICK, REIMB_MAX_DATE_COL_MAT_C og REIMB_MAX_DATE_COL_SICK_C. Informasjon om alle disse systemparameterne finner du i kapittelet Systemparametere. Etter at ressursnummer er lagt inn, vil de forskjellige max-datoene fremkomme i skjermbildet (PS32): Dette betinger at datoene ligger i ressursbildet (HS01): Side 24 av mai 2017

25 19. mai 2017 Side 25 av 67

26 Innledning Handlingstype Refusjon Handlingstype For å merke fraværsrader som refusjonsbehandlet må det opprettes en egen handlingstype. Denne må defineres som beskrevet i dette dokumentet og må angis i angitt rapportparameter i Beregne refusjonskrav (PRN06). Begrepet Handlingstype må være opprettet før handlingstyper kan opprettes. Begrepet skal ha DM-kode A15. Handlingstypen opprettes under menypunkt Felles > Handlingsoversikt og e-post maler > Handlingstyperegister Handlingstypen skal hete REFUSJON og defineres som bildet viser. Elementtypen skal være Fravær (ikke godkjent). Behandlingsregel Refusjon Det må opprettes begrepsverdi REFUSJON for begrepet BEH.REG (DM-kode CY). Side 26 av mai 2017

27 Handlingstype/behandlingsregel for brukere med annet språk enn norsk Dersom det finnes brukere av refusjonsmodulen som benytter et annet språk enn norsk, må begrepsverdien REFUSJON for handlingstype og behandlingsregel også defineres på det aktuelle språket. Åpne menypunktet Agresso Felles > Begreper og relasjoner > Begrepsverdier og søk opp begrep BEH.REG med begrepsverdi REFUSJON. Markér den aktuelle raden og velg Verktøy > Tekst. Det samme må gjøre for begrepet HANDLINGSTYPE. Dersom begrepsverdien REFUSJON ikke finnes, må den først opprettes før man også her legger inn teks på det aktuelle språket: 19. mai 2017 Side 27 av 67

28 Side 28 av mai 2017

29 Innledning Lønnarter i rapportkolonner Ved kjøring av PRN06 Beregne refusjonskrav vil det dannes 5 refusjonskrav. Refusjonskrav 1, grunnlag fra måneden før fraværet starter Refusjonskrav 2, grunnlag fra måneden før fraværet starter Refusjonskrav 3, grunnlag fra de 3 siste månedene før fraværet starter Refusjonskrav 4, grunnlag fra de 6 månedene før fraværet starter Refusjonskrav 5, verdireferanse I400 Systemparameter REIMB_ADD_FIXED_LEVEL bestemmer hvilke kolonner (SATS1 og eller SATS2) som benyttes for å danne refusjonskrav. Beskrivelsen under tar utgangspunkt i at REIMB_ADD_FIXED_LEVEL er slått av: Refusjonskrav 1, lønnarter for fast lønn. Det vil si at refusjonskrav en benyttes for ansatte som kun har fast månedslønn. Refusjonskrav 2, lønnarter for fast + variabel lønn Refusjonskrav 3, lønnarter for fast lønn for 1 måned + gjennomsnitt variable lønnarter for 3 måneder Refusjonskrav 4, lønnarter for fast lønn for 1 måned + gjennomsnitt variable lønnarter for 6 måneder Normalt benyttes da refusjonskrav 1 som utgangspunkt for ansatte med fast månedslønn. Refusjonskrav 2 kan benyttes for ansatte som har en kombinasjon av fast månedslønn og f.eks. provisjonslønn, eller for de som kun har timelønn. Ønskes det å ta utgangspunkt i en mer gjennomsnittlig lønn f.eks. 3 eller 6 måneder tilbake for timelønnede benyttes refusjonskrav 3 eller 4. Refusjonskrav 5 benyttes f.eks. i de tilfeller der en ansatt ikke har mottatt lønn før sykefraværet starter. I disse tilfellene vil det komme beløp 0 i refusjonskravene 1 til 4. Det må da være registrert en sats tilsvarende månedslønn for verdireferansen I400 på den ansatte før beregning av refusjonskravet gjøres. Ellers anbefales det at det registreres en generell sats på kr 1 på verdireferansen I400. Det gjør at man senere kan overskrive grunnlaget for refusjonskrav 5 underveis i refusjonsløpet. Nærmere beskrivelse av dette finnes i brukerveiledningen for PRN01 Ajourhold refusjonskrav Brukerveiledning. SATS1 Alle faste lønnarter (lønnarter for faste lønnsutbetalinger, som f.eks. månedslønn) som skal være med i grunnlag for å beregne refusjonskrav må defineres i SATS1. SATS1 framkommer i følgende rutiner og danner grunnlag for å beregne refusjonskrav: PRN06 Beregne refusjonskrav o felt Sats1 Ajourhold refusjonskrav o Felt F1mnd 19. mai 2017 Side 29 av 67

30 Dersom veldig mange lønnarter er med i sykepengegrunnlaget bør det vurderes om disse heller skal inngå i en generert lønnart som så benyttes i SATS1. SATS2 Alle variable lønnarter (lønnarter for variabel lønn, som f.eks. lønnarter for timelønn og provisjonslønn) som skal være med i grunnlag for å beregne refusjonskrav må defineres i SATS2. SATS2 framkommer i følgende rutiner og danner grunnlag for å beregne refusjonskrav: PRN06 Beregne refusjonskrav o felt Sats2 Ajourhold refusjonskrav o Felt F+V1mnd Dersom veldig mange lønnarter er med i SATS2, bør det vurderes om disse heller skal inngå i en generert lønnart som så benyttes i SATS2. Lønnarter i rapportkolonner, trekk Kolonnene PÅLEGG, og FAGFOR benyttes for å hente ut informasjon om eventuelle trekk den ansatte har. Informasjon skrives i følgende felt på TO-skjema: Kolonne FAGFORENING PÅLEGG Felt i skjema 3.5 Oppgi hvilken fagforening/særforbund 4.1 Trekk til skatteetaten, 4.2 Restbeløp, 4.4 Trekk er foretatt 4.4 Trekk til skatteetaten, 4.5 Restbeløp, 4.6 Trekk er foretatt 4.7 Trekk til skatteetaten, 4.8 Restbeløp, 4.9 Trekk er foretatt Dersom lønnartene ikke har angitt leverandør, eller samme trekk har flere leverandører vil det ved bestilling av TO-skjema skrives en feilliste. Skjemaene må i disse tilfellene vedlikeholdes med navn på den som skal motta trekket før de bekreftes. Stilling benyttes i lønn, benyttes ikke i fravær Regelen i refusjonsmodulen er at dersom fravær er registrert med stilling må lønn også være registrert med stilling, og er fravær ikke registrert med stilling må heller ikke lønn være med stilling. Side 30 av mai 2017

31 Dersom det er kunder som benytter stilling kun i lønn kan refusjonsmodulen allikevel benyttes. Forutsetningen er da at alle lønnarter som skal være med i sykepengegrunnlaget går videre til en generert lønnart som ikke har felt Stilling avkrysset. Det er denne genererte lønnarten som da må opprettes i Lønnarter i rapportkolonner. 19. mai 2017 Side 31 av 67

32 Innledning Verdireferanser Det er til sammen 5 verdireferanser som må være opprettet før rapporten PRN06 Beregne refusjonskrav kan benyttes. Rapportparameter Verdireferanse Beskrivelse Sats5 I400 Benyttes for ansatte som ikke har lønn forut for fraværet eller hvor lønnsgrunnlaget ikke er korrekt. Satsen må være gyldig på den dato fraværet starter. Dersom stillingsmappekortet er i bruk må satsen opprettes med stilling. Verdiref dager i året G012 Verdireferanse for antall refusjonsdager i året. Satsen skal være 260 dager og blir benyttet ved utregning av refusjonsbeløp og satser. Verdireferanse skatte % I002 Verdireferanse skatte %. Skrives ut på Beregne refusjonskrav. Verdiref deltid % I001 Verdireferanse for deltids %. Skrives ut på Beregne refusjonskrav samt på IO-skjema. Verdiref årlig beløp 6G G010 Verdireferanse med sats for årlig beløp for 6G. Side 32 av mai 2017

33 Innledning Lønnart for kontering Konto refusjonskravet bokføres mot hentes fra den lønnarten som er angitt i rapportparameter Lønnart lønn i Beregne refusjonskrav (PRN06). Konteringsregelen på angitt konto vil bestemme hvilke dimensjoner som benyttes ved bokføring av refusjonskravet. Konteringsverdiene vil hentes fra lønnstransaksjonene eller fra relasjoner på ressurs, stilling eller ansettelse dersom den ansatte ikke har lønnstransaksjoner før fraværet. Viktig at kontering på lønnarten samsvarer med det behov man har for å følge opp refusjonen, for eksempel per KOSTSTED, PROSJEKT. Merk! Det er lønnarten som benyttes i PRN06 som vil bestemme kontering gjennom hele refusjonsmodulen. Det er derfor viktig at man hensyntar det nivå man ønsker å følge opp refusjonskravene og innbetalinger fra NAV. 19. mai 2017 Side 33 av 67

34 Innledning Bilagsarter/serier/posteringsrunder Det er to rutiner i refusjonsmodulen som gjør postering mot hovedbok og reskontro. Det må derfor opprettes bilagsarter og forsystem for dette. I tillegg kreves det en egen intern bilagsart for tildeling av kravnummer. Følgende bilagsarter foreslås opprettet: RA Bokføring refusjonskrav (PRN11 Bokfør refusjoner) RB Bokføring mottatt refusjon (PSN15 Bokføring utlignede refusjonskrav) RK Kravnummer (PRN06 Beregne refusjonskrav) Selv om samme bilagsart kan angis i PRN11 og PSN15 anbefales det å opprette to arter, dette av hensyn til sporbarhet og avstemming av transaksjoner. Merk! Dersom man oppretter andre bilagsarter enn disse for bruk i refusjonsmodulen må det opprettes rapportvarianter for rapportene PRN06 (RK), PRN11 (RA) og PSN18 (RB). Dette fordi det er disse tre artene som ligger som verdiforslag. Bilagsarter/serier/posteringsrunder Dersom refusjonsmodulen skal ha en eller to egne bilagsserier må disse opprettes før bilagsarter opprettes. Bilagsart RK benyttes internt i refusjonsmodulen og skal derfor ha egen bilagsserie. Opprett nødvendige bilagsserier under menypunkt Agresso Felles > Faste registre > Bilagsserier. Opprett deretter nødvendige posteringsrunder under menypunkt Agresso Felles > Faste registre > Posteringsrunder. Side 34 av mai 2017

35 Opprett deretter bilagsartene under menypunkt Agresso Felles > Faste registre > Bilagsarter og koble de til ønsket bilagsserie. Forsystem Forsystem RA og RB må også opprettes for å kunne overføre transaksjoner fra refusjonsmodulen til hovedbok og reskontro. Dette gjøres under menypunkt Agresso Økonomi > Import fra forsystemer > Faste registre > Forsystem Merk! Forsystem må ha samme navn som bilagsarten. 19. mai 2017 Side 35 av 67

36 NAV-kontor Innledning Det beregnede refusjonskravet blir bokført i kundereskontroen. Alle NAV-kontor må derfor opprettes som kunder og de ansatte må kobles til korrekt NAV-kontor. Det er viktig at kundenummeret inneholder NAV-kontornummeret. Det er to måter å koble den ansatte til et NAV-kontor, enten via postnummer eller via relasjon på den ansatte. Merk! Siden det ikke er en entydig kobling mellom postnummer og NAV-kontor i de store byene anbefaler vi løsningen med å koble NAV-kontor som en relasjon på ansatt. Dersom man legger opp til kobling via postnummer må allikevel relasjonen mellom ansatt og NAV-kontor opprettes og benyttes i de tilfeller hvor samme postnummer kan gå til ulike NAV-kontor. Oppsett KUNDENR Det må først opprettes en egen kundegruppe for NAV-kontor. Det er i dette skjermbildet man også legger inn kundereskontrokonto for refusjonskrav: Side 36 av mai 2017

37 Alle NAV-kontor må opprettes med eget kundenummer: Alle kundenummer for NAV-kontor må knyttes til kundegruppen NAV-kontorer. I feltet Ekstern ref må det oppgis hvilket kommunenummer NAV-kontoret tilhører. Som generell adresse i fane 2 angis adressen til det lokale trygdekontoret. Kundenummeret må inneholde NAV-kontornummeret. Som vist i eksempelet over, er kundenummeret , mens NAV-kontornummeret er 1101 (de fire siste sifferne i kundenummeret). Kundenummer i forbindelse med K27 Fra 26. november 2016, vil alle refusjonsutbetalinger komme fra NAV-kontor Det må derfor opprettes et kundenummer for dette NAV-kontoret for de kundene som benytter PSN19 Innlesing av fil fra NAV. Det er viktig at de fire siste sifferne i kundenummeret består av NAV-kontornummeret mai 2017 Side 37 av 67

38 NAV Forvaltning Det må opprettes et begrep NAVFORVALTNING slik at korrekt adresse skal fremkomme på inntektsopplysningsskjemaer for sykepenger. Det må opprettes et begrep med DM-kode MNBO. Tidligere fantes det ett forvaltningskontor for hvert fylke (gjaldt frem til ). I begrepsregisteret må forvaltningskontorene (verdi 13 er ikke i bruk) opprettes med generell adresse. Gjeldende fra benyttes ikke lenger betegnelsen «forvaltningskontor», men i stedet skal skjemaene sendes til «NAV Arbeid og ytelse». Samtidig er antallet kontorer som behandler inntektsopplysningsskjemaer endret til 13. For å kunne ivareta denne endringen, må man imidlertid benytte alle de 19 begrepsverdiene som tidligere er opprettet. Det er viktig at begrepsverdiene settes opp akkurat slik det er vist i figuren under (selv om det innebærer like navn og adresser på noen av begrepsverdiene): Side 38 av mai 2017

39 Når det gjelder oppsettet for NAV arbeid og ytelser Karmøy (gjelder kun begrepsverdi 11 som tidligere gjaldt NAV Forvaltning Rogaland, og ikke begrepsverdi 12) er det viktig at det opprettholdes to adressetyper, selv om disse er like: 19. mai 2017 Side 39 av 67

40 Merk! I Rogaland fantes det tidligere to fylkeskontor for NAV Forvaltning. Her må det derfor fortsatt registreres to adresser; en Generell adresse (address_type = 1) og en Leveringsadresse (address_type = 2). Dersom Leveringsadresse ikke er adressetype 2, så skal man velge den adressen som er benyttet som adressetype 2. Adressen som fylles ut skal imidlertid være den samme på begge to. Relasjon POSTNR - KUNDENR For å kunne finne NAV-kontor på grunnlag av den ansattes postnummer må det opprettes en relasjon mellom begrep POSTNR og KUNDENR. Begrepet POSTNR skal ha DM-kode MNBG. Merk! Opprettes kun dersom man ønsker å hente ut NAV-kontor på grunnlag av postnummer. Dersom man velger å ikke opprette begrepet må det opprettes rapportvarianter av Beregne refusjonskrav (PRN06) hvor felt begrep postnummer er blank. Opprett en relasjon mellom begrepet POSTNR og KUNDENR. Side 40 av mai 2017

41 Koble deretter aktuelle postnummer til riktig NAV-kontor. Merk! Dersom en ressurs ikke er tilknyttet noe NAV-kontor, eller er tilknyttet et NAV-kontor som er sperret, vil det ikke bli generert noe refusjonskrav. 19. mai 2017 Side 41 av 67

42 Relasjon RESSNR KUNDENR Koble KUNDENR som en relasjon på ressurs. Hver enkelt ansatt må deretter kobles til aktuelt NAV-kontor. Dersom PRN06 Beregne refusjonskrav ikke finner noen kobling mellom ansatt og NAV-kontor vil kunde angitt i systemparameter ERROR_CUST bli benyttet. Side 42 av mai 2017

43 Innledning Saksbehandler Ved generering av inntekts- og trekkopplysningsskjemaer, er det i utgangspunktet slik at telefonnummer i felt 3.2 Inntektsskjemaet hentes fra firmaregisteret. I tillegg legges brukernavn ut i felt 3.5. Dersom man i stedet ønsker telefonnummer og navn på saksbehandler av refusjonssaken skal fremkomme, kan man opprette et begrep for saksbehandler (f.eks. REFSAKSB). Det må opprettes en relasjon mellom saksbehandler og hvilken organisasjonstilhørighet denne har tilgang til (eventuelt ansvar for): Det må også opprettes en relasjon mellom bruker og saksbehandler: 19. mai 2017 Side 43 av 67

44 Brukerens telefonnummer må registreres i feltet Telefon i Generell adresse: Side 44 av mai 2017

45 Innledning Dokumenttyper Dokumenttyper Ved kjøring av rapporten PSN17 - Bekreftelse Inntekts- og trekkopplysningsskjema er det mulig å lagre skjemaene i dokumentarkivet på den ansatte. Begrepet for dokumenttype må være opprettet før handlingstyper kan opprettes. Begrepet skal ha DM-kode A12. Merk! Begrep og dokumenttyper opprettes kun dersom du ønsker å lagre Inntektsog trekkopplysningsskjemaene i dokumentarkivet på den ansatte. Opprett dokumenttyper for IO- og TO-skjema og KR-skjema under menypunkt Agresso Felles > Dokumentarkiv > Faste registre > Dokumenttype Dokumenttypen for Inntekts- og trekkopplysningsskjema må hete ITSKJEMA og ha oppsett som vist over. Dersom TO-skjema skal lages, legger dette seg i samme dokumentet som IO-skjema. 19. mai 2017 Side 45 av 67

46 Dokumenttypen for skjema for kronisk sykdom og svangerskapsrelatert sykdom skal hete KRSKJEMA og ha oppsett som vist over. Merk! Det er teksten til dokumenttypen (markert med gult i bildet over) som skal angis i rapportparameterne ved bestilling av PSN17 Bekreftelse inntekts- og trekkopplysningsskjemaer. PSN17- Bekreftelse Inntekts- og trekkopplysningsskjema Det må lages en rapportvariant av rapporten hvor dokumenttypene angis. Side 46 av mai 2017

47 Rapportparametere: ParameterID Parameter Verdi Doc_type Dokumenttype IO- og TOskjema ITSKJEMA Doc_type2 Dokumenttype KR-skjema KRSKJEMA 19. mai 2017 Side 47 av 67

48 Innledning Datakontroll Det er mulig å sette opp datakontroll i refusjonsmodulen. Hensikten med løsningen er å sikre at brukere bare kan se og redigere data i henhold til regler bestemt av datakontroll. Datakontroll i Refusjon skiller seg noe fra datakontroll i andre UBW-moduler. Det skyldes refusjonsmodulens natur, der det på grunn av lover og regler er helt nødvendig å se og/eller behandle ressurser under ett, uavhengig av stilling, arbeidssted etc. Forutsetninger Datakontroll er orientert rundt et begrep som er en relasjon til ressursen eller ansettelsen. Dette kan f.eks. være KOSTSTED. Det er da KOSTSTED som bestemmer hvilke data en bruker har lov til å behandle eller se. I skjermbilder vises relevante data som brukeren har lov til å redigere, samt data som brukeren bare har lov til å se, men ikke redigere. Data brukeren ikke har lov til å redigere vises skyggelagt og er sperret for redigering. Data brukeren har lov til å endre, kan implisitt påvirke data brukeren ikke har lov til å endre. Det er tillatt. Det er eksplisitt endring av sperrede data som ikke er tillatt. Når det gjelder inntekts- og trekkopplysningsskjemaer, så bestemmer begrepet BEDRNR (bedriftsnummer) sammen med KOSTSTED (KOSTSTED er her valgt som eksempel) hvilke data en bruker har lov til å se. Årsaken til dette er at det dannes ett IO-skjema pr. bedriftsnummer pr. ansatt. En bruker må derfor ha mulighet til å se IO-skjemaet selv om en ansatt tilhører flere kostnadssteder, så lenge alle kostnadsstedene tilhører samme bedriftsnummer. Det samme vil gjelde for innbetalinger fra NAV (som kun er merket med bedriftsnummer). Brukeren må ha lov til å behandle krav fra samme bedriftsnummer for å ha lov til å behandle innbetalingen. Oppsett Det må opprettes en relasjon mellom begrepet datakontroll sjekkes mot og begrepet ROLEID. Dersom datakontroll sjekkes mot begrepet KOSTSTED, må følgende relasjon opprettes: Det må også opprettes en relasjon mellom ROLEID og begrepet for bedriftsnummer: Side 48 av mai 2017

49 Hvordan tilgangen til informasjon er begrenset, må defineres i skjermbildet Oppsett > Systemadministrasjon > Brukere og tilgang > Tilgang til distribuert informasjon > Tilgang til distribuert informasjon. Definering av tilgang må gjøres for alle menyelementene det gjelder i refusjonsmodulen: 19. mai 2017 Side 49 av 67

50 Det er i tillegg fire systemparametere som må opprettes i forbindelse med datakontroll. Disse fire systemparameterne er PRN01_DIA_CONTROL, TPRN016_DIA_CONTROL, PSN16_DIA_CONTROL, og TPRN002_DIA_CONTROL. Beskrivelse av systemparameterne finner du i kapittelet Systemparametere. Merk! Det er viktig at alle de fire systemparameterne som er nevnt ovenfor, er slått på dersom datakontroll tas i bruk. Side 50 av mai 2017

51 Innledning Systemparametere Det er i 553 innført en del nye systemparametere for refusjonsmodulen. Disse må opprettes og settes til ønsket verdi. REIMB_ADD_FIXED_LEVEL Parameteren kan ha følgende oppsett: Av På På med Verdi 2. Krav 1 F1mnd Krav 2 F+V1mnd Krav 3 F+V3mnd Krav 4 F+V6mnd AV SATS1 SATS2 SATS2 SATS2 PÅ SATS1 SATS2 SATS1 siste mnd + SATS2 gj.snitt 3 mnd PÅ med verdi 2 SATS1 SATS1+SATS2 SATS1 siste mnd + SATS2 gj.snitt 3 mnd SATS1 siste mnd + SATS2 gj.snitt 6 mnd SATS1 siste mnd + SATS2 gj.snitt 6 mnd Parameteren bestemmer hvordan sats 2, sats3 og sats4 i Beregne refusjonskrav (PRN06) og Ajourhold refusjonskrav blir beregnet. Merk! Dersom systemparameteren er skrudd på uten verdi og det benyttes Sats 2, vil det uansett krysses av for Nei i felt 2.6 (Utbetaler arbeidsgiver full lønn i stønadsperioden) på Inntektsopplysningsskjema. REIMB_ADD_FIXED_CORR Parameteren sier at arbeidsgiver utbetaler full lønn i stønadsperioden/etter utløpet av arbeidsgiverperioden. Dersom systemparameter REIMB_ADD_FIXED_CORR skrus på (uten verdi), er det rapportbestillingen av PRN06 som bestemmer avkryssingene i feltene 2.6 og 2.8 på IO-skjemaet uavhengig av systemparameter REIMB_ADD_FIXED_LEVEL 19. mai 2017 Side 51 av 67

52 REIMB_LINK_ABS_MAX_DAYS_F Parameteren bestemmer hvor mange dager man kan jobbe i foreldrepermisjonen før det blir sett på som et nytt fravær og uthenting av ny sats. REIMB_MATCH_AMOUNT_LIMIT Parameteren er i bruk i skjermbildene TPRN002 Utligning refusjonskrav og TPRN020 Ajourhold forslag utligning. Parameteren bestemmer hvor stor differansen mellom krav og mottatt beløp kan være for at programmet automatisk skal sette kryss i kolonne Alt. i TPRN002 Utligning refusjonskrav (og overføre restbeløpet til kolonnen Tapsført). I skjermbildet TPRN020 Ajourhold forslag utligning gjelder tilsvarende. Parameteren bestemmer hvor stor differanse det kan være mellom krav og utlignet beløp for at programmet automatisk skal sette kryss i kolonne Alt (og overføre restbeløp til kolonnen Differanseføres). Merk! Parameteren må være skrudd på for å kunne benytte skjermbildet TPRN002 Utligning refusjonskrav. REIMB_MAX_DATE_COL_MAT Parameteren forteller hvilket datofelt i ansattbildet som benyttes for maksdato foreldrepenger fra NAV. Feltet vil først bli fylt ut dersom man gjør en endring i vinduet TPRN002 (Utligning refusjonskrav). For å kunne benytte Utligning refusjonskrav, er det en betingelse at systemparemeteren er skrudd på med verdi date_col1, date_col2 eller date_col3. REIMB_MAX_DATE_COL_SICK Side 52 av mai 2017

53 Parameteren forteller hvilket datofelt i ansattbildet som benyttes for maksdato sykdom fra NAV. Feltet vil først bli fylt ut dersom man gjør en endring i vinduet TPRN002 (Utligning refusjonskrav). For å kunne benytte Utligning refusjonskrav, er det en betingelse at systemparemeteren er skrudd på med verdi date_col1, date_col2 eller date_col3. REIMB_MAX_DATE_COL_MAT_C Parameteren forteller hvilket felt i ansattbildet (HS01) som benyttes når PRN06 Beregne refusjonskrav beregner maksdato for foreldrepenger. De eneste lovlige verdiene er code1-code8. Det er frivillig å benytte denne systemparameteren. REIMB_MAX_DATE_COL_SICK_C Parameteren forteller hvilket felt i ansattbildet (HS01) som benyttes når PRN06 Beregne refusjonskrav beregner maksdato for sykepenger. De eneste lovlige verdiene er code1-code8. Det er frivillig å benytte denne systemparameteren. REIMB_MAX_DATE_NAV Systemparameter for å styre hvilken maksdato som skal fremkomme i skjermbildet Fraværsregistrering (PS32). Parameteren, om den er skrudd på, forteller at maksdatoen fra NAV skal brukes. Det vil ikke bli foreslått en generert maksdato av systemet. REIMB_MAX_DATE_VIEW Systemparameter for å styre hvilken maksdato som skal fremkomme i skjermbildet Fraværsregistrering (PS32). Parameteren kan ha følgende oppsett 19. mai 2017 Side 53 av 67

54 Av På med verdi 1 På med verdi 2 På med verdi 3 På med verdi 4 Systemparameter AV PÅ med verdi 1 PÅ med verdi 2 PÅ med verdi 3 PÅ med verdi 4 Visning Ingen endring fra dagens funksjonalitet Viser alltid systemgenerert maksdato Viser alltid maksdato fra NAV Viser både systemgenerert maksdato og maksdato fra NAV Viser den maksdatoen som inntreffer først Merk! Maksdato vil i dette tilfelle først fremkomme etter at fraværskoden er lagt inn. Om REIMB_MAX_DATE_NAV er skrudd på vil ikke systemet foreslå en systemgenerert maksdato, og det anbefales da å bruke PÅ med verdi 2. REIMB_NOK_CHILD Parameteren forteller hvilken verdi i pårørenderegisteret som skal sjekkes ved foreldrepermisjon. Fødselsdato vil sjekkes og dersom denne er tidligere enn 3 uker etter dato fra i permisjonen vil fødselsdato benyttes for å beregne maksdato. REIMB_REQ_TREAT_BEF_POST Dersom parameteren er satt må feltet Dokumentasjon være avkrysset i Ajourhold refusjonskrav før refusjonsraden kan behandles videre. REIMB_VAL_REF_6G Parameteren skal inneholde verdireferansen for 6G. Benyttes ved beregning av refusjonskrav. Side 54 av mai 2017

55 REIMB_CLAIM_USECONSULTANT For at det er saksbehandler som skal fremkomme på IO-skjema, må systemparameter REIMB_CLAIM_USECONSULTANT opprettes: Verdien må settes ulik 0. Telefonnummer til den enkelte bruker må legges inn på generell adresse på den enkelte bruker i feltet for Telefon (ikke Mobil): Bruker og brukerens telefonnummer vil da fremkomme på IO-skjemaet: REIMB_HS01_BLANK_SCHEMA Det er nå lagt til rette for å opprette en ny systemparameter ved generering av IO-, KR- og TO-skjemaer fra HS01 Ressursinformasjon. Systemparameteren heter REIMB_HS01_BLANK_SCHEMA og har følgende funksjon: Verdi Av På Funksjon Som tidligere Det er kun navn, personnummer og NAV-kontor som fylles ut når skjema hentes fra HS01. Det vil si at arbeidsgivers navn og adresse ikke kommer med. Årsaken til innføringer av systemparameteren er at det ikke ble hentet ønsket navn og adresse for arbeidsgiver dersom man benytter oppsett for enklient. REIMB_COSTC_NAME 19. mai 2017 Side 55 av 67

56 Denne parameteren benyttes for å angi hvilket begrep som benyttes for DM-kode C1. Standard er KOSTSTED. Dersom dette benyttes, trenger man ikke opprette denne systemparameteren. Benyttes det et annet navn enn KOSTSTED, må dette angis i verdien for systemparameteren. Dersom man for eksempel benytter navnet ANSVAR, vil begrepet og systemparameteren være som følger: REIMB_COMP_NO Det er opprettet en ny systemparameter hvor man kan definere hva slags begrep som brukes for å angi bedriftsnummer. Dersom det benyttes navnet BEDRNR på begrepet for bedriftsnummer, trenger man ikke opprette denne systemparameteren. Dersom man benytter et annet navn, må dette navnet legges inn som verdi på systemparameteren REIMB_COMP_NO. REIMB_PRN06_VAL_DAYS Systemparameteren angir hvor mange dager i forkant av rapportbestillingen programmet skal varsle om dobbeltregistrert fravær. Dersom systemparameteren ikke er opprettet eller ikke er skrudd på, vil programmet benytte 183 dager. Dersom systemparameteren er skrudd, vil programme benytte det antall dager som er angitt som verdi (ingen verdi oppfattes som 0). REIMB_PRN06_WARNDA Systemparameter REIMB_PRN06_WARNDA kan opprettes og skrus på for å unngå at rapport PRN06 Beregne refusjonskrav gir stopp for ressurser som har gamle duplikater. Systemparameteren må da opprettes uten å angi noen verdi, og varsellisten PRN06WARNDA vil ikke bli generert. Side 56 av mai 2017

57 Ved å opprette systemparameteren, skru den på og angi en verdi (i antall måneder) kan man begrense søket bakover i tid. REIMB_PRN06_REMOVEZERO Ved behov kan det opprettes en ny systemparameter REIMB_PRN06_REMOVEZERO. Dersom denne systemparameteren er opprettet og skrudd på, vil alle rader i Ajourhold refusjonskrav (PRN01) vise tilhørende konteringsdimensjoner. Dersom systemparameteren ikke er skrudd på, vil rader som kun inneholder helgedager (m.a.o. antall refusjonsdager = 0) ikke inneholde konteringsinformasjon. REIMB_USE_SATS5_KONTERING Systemparameter som kan benyttes for at konteringen av refusjonskrav alltid skal følge den konteringen som er gyldig for ansettelsen/ressursen på fraværstidspunktet (slik som for sats 5) uansett valg av sats. I tillegg til at systemparameteren må være skrudd på, må den også ha verdi 1. Systemparameteren opprettes ved behov. REIMB_KONTERING_DIM Systemparameter for å angi hvilke konteringsdimensjoner man ikke skal få lov til å gjøre endringer på i TPRN003 Ajourhold kontering. Systemparameteren opprettes ved behov. 19. mai 2017 Side 57 av 67

58 REIMB_PSN15_VOUCHER_TEXT Systemparameter REIMB_PSN15_VOUCHER_TEXT kan benyttes dersom man ønsker at datoene «Mottatt dato fra» og «Mottatt dato til» i utligningsbildet skal benyttes som en del av bilagsteksten i stedet for kravets «Dato fra» og «Dato til». REIMB_PSN16_NAV_ADDRESS Systemparameter REIMB_PSN16_NAV_ADDRESS benyttes for å hente adresse fra riktig NAV Forvaltning på IO-skjemaene. Hvilket forvaltningskontor programmet henter ut styres ut i fra kundenummeret til NAV-kontoret. Det er en forutsetning at kundenummeret i UBW inneholder NAVkontornummeret. Verdien i systemparamteren sier hvilket siffer fra venstre den skal starte uthentingen. Det er de to første sifferne i NAV-kontornummeret som hentes ut. REIMB_PSN16_OVERLAP_VAC Systemparameter REIMB_PSN16_OVERLAP_VAC kan opprettes ved behov. Det finnes en kontroll i programmet som sjekker at det er benyttet lik fraværskode for ferie i løpet av arbeidsgiverperioden dersom en ressurs har mer enn én stilling. Dersom det er benyttet ulike feriekoder på de to stillingene, vil rapporten stoppe og det gis en melding i rapportloggen om hvilke(n) ressurs(er) det gjelder. Dersom man ikke ønsker en slik kontroll, kan man opprette systemparameteren. Da vil programmet ikke utføre denne kontrollen, men kjøre videre som normalt. REIMB_PSN19_NAV Ved innlesing av K27-filen skal det være en kontroll av at hvert NAV-kontor har et gyldig kundenummer i UBW. Dette betinger at kundenummeret i UBW inneholder nummeret til NAV-kontoret. Vanlig oppsett i UBW er at de fire siste sifferne i kundenummeret består av NAV-kontorets nummer (f.eks. kundenummer tilsvarer NAV-kontor 0326). Ved å opprette en ny systemparameter kan man få hentet ut NAV-kontorets nummer ut fra det enkelte kundenummeret. Eks: Side 58 av mai 2017

59 Verdiene i systemparameteren viser til at for alle kundenummer som tilhører kundegruppe 10, skal det hentes ut fire siffer og starte på siffer nummer tre i kundenummeret. REIMB_PSN19_REL Hvis man i stedet benytter et oppsett der det er en relasjon mellom kundenummer og NAV-kontor benyttes følgende systemparamter for å identifisere tilhørende kundenummer ut i fra NAV-kontor i K27-filen: Verdien som fylles ut er begrepet som er opprettet som en relasjon til kundenummer. REIMB_PSN19_MAX_DATE Dersom man ønsker en begrensning på hvilke maxdatoer som skal oppdateres i ressursregisteret ved innlesing av fil fra NAV, kan man opprette systemparameteren REIMB_PSN19_MAX_DATE. I kolonnen Verdi angis antall dager. Systemparameteren fungerer slikt at maksdatoen i ressursregisteret ikke oppdateres dersom maksdatoen i K27-filen er mer enn 30 dager eldre enn maksdatoen som allerede er registrert i ressursregisteret. Dette for å unngå fil oppdatering av maksdatoer dersom NAV refunderer gamle refusjonskrav. Max-datoer som ikke oppdateres i ressursregisteret kommer på en egen varselliste (PSN19E). REIMB_AUTOMATIC_MATCH Systemparameter REIMB_AUTOMATIC_MATCH må opprettes for å ta i bruk automatisk matching. Dersom systemparameteren ikke er skrudd på, vil rapporten PSN20 Automatisk utligning stoppe. 19. mai 2017 Side 59 av 67

60 Det skal ikke angis noen verdi, men systemparameteren må være skrudd på dersom man skal benytte automatisk utligning. Systemparameteren benyttes i programmene PSN20 Automatisk utligning og PSN15 Bokføring utlignede refusjonskrav. REIMB_PSN20_DIFF_MATCH Systemparameter REIMB_PSN20_DIFF_MATCH må opprettes og skrus på. REIMB_PSN20_COMP_REG_NO Systemparameter REIMB_PSN20_COMP_REG_NO må opprettes og skrus på. REIMB_PSN20_CHECK_DUPL Systemparameter REIMB_PSN20_CHECK_DUPL kan opprettes for de som tidligere har opplevd feil med at det har blitt bokført duplikater i PRN11 Bokføring (denne feilen ble rettet til versjon ). Det er valgfritt å opprette denne systemparameteren. Den nye systemparameteren gjør at programmet PSN20 Automatisk utligning ikke vil foreta noen utligning for krav som tidligere har gitt duplikater i PRN11 Bokføring. Merk! Systemparameteren bør skrus av når alle duplikater har blitt ryddet bort eller er utlignet. Side 60 av mai 2017

61 REIMB_TPRN020_ACCOUNT Systemparameter REIMB_TPRN020_ACCOUNT kan opprettes for å vise korrekte overskrifter for søkefeltene dim1 dim7 i fane 2 i TPRN020 Ajourhold forslag utligning og i THN4001 Ikke mottatte refusjonskrav. Som verdi må konto for refusjon av sykepenger angis. Merk! Dersom det benyttes ulike konti for sykepenger og foreldrepenger, forutsettes det at det benyttes samme konteringsregel for begge konti. Dersom det benyttes ulike konteringsregler, vil overskriftene i skjermbildet kun henvise til konteringsregel for konto angitt i systemparamteren. Det er i dag en feil i programvaren (versjon og 1.7.1). For å kunne benytte denne systemparameteren krever det at man benytter alle 7 konteringsdimensjonene i konteringsregelen for kontoen som angitt i systemparameteren. Dersom ikke alle 7 konteringsdimensjonene er fylt ut i konteringsregelen, vil man ikke få åpnet skjermbildene TPRN020 Ajourhold forslag utligning eller THN4001 Ikke mottatte refusjonskrav. I slike tilfeller anbefales det at man skrur av systemparameteren og skjuler søkefeltene for konteringsdimensjonene i de to skjermbildene. REIMB_TPRN020_SECTIONS Systemparameter REIMB_TPRN020_SECTIONS kan opprettes dersom man ønsker å endre visning av seksjonen «Mottatt beløp» i skjermbildet. Verdi Forklaring Ikke skrudd på (eller ikke opprettet) Seksjonen «Mottatt beløp» vises 1 Seksjonen «Parkerte rader» vises 2 Seksjonen er skjult 3 Seksjonen «Mottatt beløp og parkerte rader» vises PRN01_DIA_CONTROL (Datakontroll) Systemparameter PRN01_DIA_CONTROL må opprettes. I feltet Verdi må det angis hvilket begrep datakontrollen i skjermbildet skal sjekkes mot. 19. mai 2017 Side 61 av 67

62 TPRN016_DIA_CONTROL (Datakontroll) Systemparameter TPRN016_DIA_CONTROL må opprettes for. I feltet Verdi må det angis hvilket begrep datakontrollen i skjermbildet TPRN016 Ajourhold forslag Inntekts- og trekkopplysningsskjemaer skal sjekkes mot. PSN16_DIA_CONTROL (Datakontroll) For at PSN16 Forslag Inntekts- og trekkopplysningsskjemaer skal generere egne buntnummere ut i fra hvert bedriftsnummer, må systemparameter PSN16_DIA_CONTROL skrus på. I verdien angis hvilket begrep det skal genereres buntnummer for. Deretter angis hvor mange siffer det kan være i buntnummeret når PSN16 bestilles. Til slutt angis det hvor mange siffer det skal legges til når PSN16 genererer nye buntnummer. Merk! Dersom parameteren PSN16_DIA_CONTROL er slått på, kan samme buntnummer ikke angis ved bestilling av PSN16. Dersom parameteren er slått av, kan samme buntnummer angis ved bestilling av PSN16 før bunten er bekreftet i PSN17 Bekreftelse Inntekts- og trekkopplysningsskjemaer. TPRN002_DIA_CONTROL (Datakontroll) Systemparameter TPRN002_DIA_CONTROL må opprettes. I feltet Verdi må det angis hvilket begrep datakontrollen i skjermbildet TPRN002 Utligning refusjonskrav skal sjekkes mot. TPRN019_DIA_CONTROL (Datakontroll) Side 62 av mai 2017

63 Systemparameter TPRN019_DIA_CONTROL må opprettes dersom man ønsker en begrensning på hvilke brukere som skal ha tilgang til skjermbildet. I kolonnen verdi må man angi hvilket begrep som skal styre tilgangen. I eksempelet under er det benyttet rolle (ROLEID), der rollen er satt opp med en relasjon til bedriftsnummer. Her er det altså den påloggede brukerens rolle som definerer hvilke bedriftsnummere brukeren skal få lov til å se i skjermbildet. TPRN020_DIA_CONTROL (Datakontroll) Slik som i TPRN019 Ajourhold innlesing, er det mulig å sette opp en tilgangsstyring i skjermbildet. Det må først opprettes en systemparameter TPRN020_DIA_CONTROL. I kolonnen verdi må man angi hvilket begrep som skal styre tilgangen. I eksempelet under er det benyttet rolle (ROLEID), der rollen er satt opp med en relasjon til bedriftsnummer. Eksempel: Her er det altså den påloggede brukerens rolle som definerer hvilke bedriftsnummere brukeren skal få lov til å se i skjermbildet. 19. mai 2017 Side 63 av 67