avbryt
Viser resultater for 
Søk heller etter 
Mente du: 
Mine områder

Logg inn

Logg inn eller registrer en ny bruker for å automatisk få tildelt relevante områder i Mine områder.

Highlighted
CONTRIBUTOR ***

Retro-inkonsistens

Visma skriver og retro-funksjonaliteten:

 

"Men sannheten er at retro har betydelige fordeler for deg som bruker av Visma.net Payroll. Måten retro fungerer på er i tråd med gjeldende regelverk for innrapportering til a-melding. I hovedtrekk betyr det at kontantytelser skal følge kontantprinsippet og rapporteres i utbetalingsmåneden, mens naturalytelser, trekk og korreksjoner skal rapporteres i den måneden ytelsen gjelder.  Fordelen er at Payroll ordner dette selv, så lenge du er nøye med å angi korrekt dato for når en ytelse skal gjelde. Legger du f.eks. inn en firmabil i oktober som gjelder fra 1. september vil Payroll automatisk sende en retroaktiv a-melding for september i tillegg til den ordinære for oktober".

 

2 ansatte hadde dekket egne lisvforsikringer.  For den ene var det endret beløp i løpet av året (prisstigning), mens for den andre så hadde autogirobeløpet blir overskredet og stoppet opp. Gikk inn på ansattes faste transaksjonene for å endre grunnlaget for beskatning. Effekten av dette var at det ble generert korrigerte a-meldinger for tidligere perioder, uten at det ble laget nye samsvarende lønnskjøringer og dermed også regnskapsbunter. Dermed ble det inkonsistens mellom a-meldingene, lønnstransaksjoner og regnskapstransaksjoner selv om jeg egentlig oppnådde det som Visma beskriver ovenfor som korrekt innrapportering.

 

Det som Visma beskriver som fordelaktig, vil jeg beskrives som ukontrollerbar dysfunksjonalitet når man sitter der og skal forklare avvikene, korrigere/forklare avvikende betalinger til skattekontoret og få alt gjenspeilet i regnskapet.

 

Minimum så bør det genereres korrigerende lønnskjøringer, så det blir konsistens mellom a-meldingene og lønn (og dermed regnskapet).

 

Min egentlige løsning hvis jeg hadde forstått effekten, hadde vært å lage en variabel lønnsart hvor jeg ikke hadde brydd meg med det «politisk korrekte», men løst problemet på enkleste måte med en lønnskjøring i desember. For å bli sittende i timesvis for først å forstå problemet og så få kontroll på det, den situasjonen blir jeg ikke å komme opp i på ny. Glad dette var en lønnsklient med 4 ansatte og ikke de som vi ellers kjører lønn for i Visma Lønn. Skal bli lenge til de blir flyttet til Payroll om de blir det noen gang.

4 SVAR 4
Highlighted
VISMA

Re: Retro-inkonsistens

Hei Kaj,

Det er veldig beklagelig å høre at du har brukt mye tid på dette. 

Årsaken til at det er gjort på denne måten er fordi kontantprinsippet styrer hvilke perioder en korreksjon skal rapporteres på: https://www.skatteetaten.no/bedrift-og-organisasjon/arbeidsgiver/a-meldingen/veiledning/lonn-og-ytel...

Hensikten med korreksjonsprosessen i Payroll er at dette skal bli korrekt uten at du skal måtte ta stilling til hvilke perioder korreksjonene skal rapporteres på. Å korrigere på riktig periode vil bli mer og mer viktig etterhvert som flere aktører henter ut data fra a-meldingen. Blant annet brukes dette til beregning av sykepenger, lån og etterhvert pensjon hos pensjonstilbyderne. 

Grunnen til at det ikke blir generert lønnskjøringer for hver periode, er for å unngå at du skal måtte gå gjennom en hel lønnsprosess for hver periode som skal korrigeres. 

I noen tilfeller vil dette kunne skape utfordringer med avstemming av tall mot regnskapet. Det kan være at vi kan se på om vi for eksempel kan presentere regnskapstallene på en annen måte i Payroll for å gjøre det enklere å få en oversikt. Jeg skal ta det med videre som et innspill til fremtidig utvikling.

 

Mvh

Hanna

Highlighted
CONTRIBUTOR ***

Re: Retro-inkonsistens

Det er ikke holdbart at man ikke oppnår konsistens mellom a-meldinger, lønnskjøringer, regnskapskjøringer, bankkonter og skattekontoret. Når man endrer i a-meldinger, så endrer man hva som skulle ha vært betalt inn av arbeidsgiveravgift og eventuelt skattetrekk. F.eks økt eller redusert skattetrekk må endres i regnskapet og det må eventuelt betales inn med korrekt kidkode så det kommer inn på rett oppgave. Hvordan vet skattekontoret at det er korrekt at det skal betales tilbake?

 

Jeg hold på å sette overskriften til retro-galskap, men unnlot det, men siden dere sliter med å forstå de praktiske konsekvensene, så nevner jeg det allikevel. Jeg kommer ikke til å overføre flere lønnsklienter til dette systemet før det er blitt mer brukervennlig i den forstand at man forstår og ser hva som foregår og får konsistens i dataene og betalingene. Det er faktisk regelrett galskap slik det fungerer i dag.

 

Highlighted
VISMA

Re: Retro-inkonsistens

Hei! 

Takk for samtalen tidligere i dag. Jeg har notert meg de tilbakemeldingeen du kom med, og kommer til å ta det med videre for å se på hvordan vi presenterer dette med retroer i systemet.

 

Ha en fin dag videre!

 

Mvh

Hanna

Highlighted
CONTRIBUTOR ***

Re: Retro-inkonsistens

Individuell livsforsikring som ble trukket fra bankkonto til bedriften hadde blitt stoppet for en ansatt, mens det fortsatt lå inne som fast transaksjon for beregning av skatt og arbeidsgiveravgift. Ved å sette inn sluttdato tilbake til når trekket hadde stoppet opp, så ble det kjørt en omberegning av tidligere oppgaver til AltInn i Payroll uten å vise hva som ble endret eller mulighet til å stoppe det.

 

Det finnes ingen spor i utskrifter/rapporter i AltInn hva som er gjort av endringer og heller ikke produsert endringsbunt til regnskap.

 

Heldigvis har jeg tatt ut gamle og nye rapporter fra AltInn som jeg kan se endringen som er gjort. Ellers ville dette vært umulig å spore og forklare til de som fører regnskap og skal avstemme skattetrekk og arbeidsgiveravgift.

 

Antar at hele hendelsen har medført 2-3 dagers merarbeid til sammen for de som jobber med lønn, regnskap og skattemyndigheten inkl avvik i innbetaling av skatt og arbeidsgiveravgift.