Retroaktiv löneberäkning - Löneberäkning - Körningar innevarande löneperiod

I detta avsnitt kan du läsa om de förutsättningar som finns samt vilka begränsningar i retrofunktionaliteten som finns.

Du kan även läsa om hur du upptäcker begräsningen samt eventuell work around. 

Genom att visa på vilka begränsningar som finns så klargörs detta, annars är det lätt att tro att det är ett fel som uppstått när det istället faktiskt är en begränsning i funktionaliteten.

Definitioner

Retroperiod – Perioden som ska räknas retro på. Om du t.ex. ska betala ut retro i september som ska gälla från april så är retroperioden april-augusti. 

Modertrans – Den statistik-transaktion (i tabell p_lstat) som ligger till grund för uträkningen huruvida det ska bli en retrotrans eller inte.

Lönedata – I HR-plus 8 så används lönedata som ett begrepp. I detta fallet så är det en summering av de komponenter som används för att skapa en lön. Uppgifterna finns i tabellerna Grundlöneuppgifter samt Lönepåverkande uppgifter.

Förutsättningar för att det ska bli retroaktiva transar

1. ’R’ måste vara satt på raden (i Lönedata/Grundlön) som ska retroberäknas

2. Lönearten ska finnas med i tabell 31.

3. För att det ska bli en retrotrans så måste det beloppet som räknas ut av retrofunktionaliteten få ett annat belopp än vad som återfinns i modertransen. Om det blir samma belopp så skapas ingen retrotrans.

Notera! Om det inte finns någon modertrans så kommer beräkningen inte att fungera.

4. Om beloppet är registrerat av användaren och ej uträknat av systemet samt om det inte finns några timmar satta i modertransen så läses retrofunktionaliteten förbi. Då blir det alltså ingen retrotransaktion.
Undantag: Det som är genererat från lönedata blir retroberäknat.

5. Normalt sett så bör det fungera att köra retro både på korrigeringstransar från statistikregistret samt även totalavdragstransar.

Ackar: 

Vi rekommenderar att du inte använder ackar vid retro då dessa är levande och ständigt förändras (såvida det inte är någon noteringsack som är statisk).

Begränsningar i retrofunktionalitet

  • Retrot tar inte hänsyn till transar med ursprung ’k’ som har genererats från lönedata, exempelvis månadslön (Lösning – vänd aldrig månadslönetransen utan använd en korrigeringslöneart istället). Du kan bara ha en förändringstidpunkt (datum) per månad om retrot ska fungera. På detta datumet så kan du dock ha flera ändringar - t.ex. månadslöneförändring samt sysselsättningsgradsförändring. 
  • Du kan inte ha två förändringstidpunkter per månad (ex 20180401 och 20180415) – Då kommer retrot inte att fungera. Du kan ha två förändringstidpunkter under retroperioden och retrot ska kunna hantera detta.
    Exempel: Ny månadslön från 20180401 och sysselsättningsgradsförändring från 20180501. Eller för den delen två månadslöneförändringar. En per 20180401 och en per 20180501. Förutsättningen är dock att förändringarna ligger i månadsbrytet ÅÅMM01. Det fungerar inte att datumen t.ex. är: 20180415 samt 20180515. Om du skulle få dubbla retrotransar vid löneberäkningen så kan det tyda på att det har funnits 2 st förändringar under samma månad.
  • Det går inte att beräkna retro om den aktuella lönarten (eller dess formel) innehåller en hämtning av m- alt b-ack. Då kommer löneberäkningsprogrammet att returnera samma belopp som modertransen i statistiken har fast med omvänt tecken. 
  • Om beloppet från början är rapporterat manuellt på modertransen i statistikregistret så kommer inte retrofunktionaliteten att fungera. Då kommer retrot enbart att lägga ut samma belopp som modertransen med omvänt tecken. 

Felsökningstips för när retrot blir fel

Titta i formeln som hänvisas till i modertransen. Byt ut hämtningen i formeln en efter en till det värdet (som hämtningen borde bli) och se om det blir korrekt. På detta sätt så kan du se vilket av hämtbegreppen som fallerar. 

Proportioneringar

Titta i första hand i proportioneringsformelhämtningen i Tabell 30, Lönedata (t.ex. på månadslönetransen). Om det inte skulle finnas någon hämtning i T30 så får du titta i Tabell 07, Avtalstabellen istället. Retrot börjar alltid i T30 och kollar sedan i T07.

Om det inte finns någon propformelhämtning ifylld på något av ställena, så blir det ingen retrotrans alls. 

Avvaktivera retrofunktionalitet

Om du inte har tid att felsöka på vad det är som har blivit fel i retrot, så kan du beroende på omfattningen av felet, använda dig av någon av nedanstående punkter för att avaktivera retrofunktionaliteten och istället rapportera in retrot manuellt; 

  1. Om det enbart är en transaktion som strular för en person och övriga retrotransaktioner blir korrekta, så kan du sätta en 1:a i fältet Undantag vid retro (fältid: p_sxxxs0) på varje berörd enskild modertransaktion i statistikregistret. På detta sätt så skapas inga retrotransaktioner som grundar sig på den berörda modertransaktionen. 
  2. Om all retro på en speciell person strular, så kan du ta bort ’R’ från p_ldata på den aktuella personen/arbetstagaren. 
  3. Om all retro på en speciell löneart strular, så kan du ta bort den specifika lönearten från Tabell 31. 
  4. Om du inte vill ha någon uträkning av retro alls gällande en speciell rad i Lönedata - tabell 30, så kan du ta bort hänvisningen till den specifika retrotranstabellen. Detta görs i tabell 30, Lönedata. 

Relaterad hjälp