Gå til innhold

Korrigere timer i låst periode

Når en periode er låst via Låsedato for timeregistrering, kan ansatte ikke endre eller registrere timer på datoer til og med låsedatoen. Hvis en glemt time, feilført wagetype eller annen korreksjon må gjøres på en låst dato, har administrator i praksis ett verktøy: flytte låsedatoen midlertidig tilbake (eller slå låsingen helt av), gjøre korreksjonen, og deretter sette låsedatoen tilbake.

Det finnes ingen egen «Lås opp periode»-knapp, ingen dialog for årsak/varighet, og ingen automatisk relåsing. Låsen er en enkel datoinnstilling som styrer hva som kan endres.

Tilgang

Timeregistrering med låst periode-melding

Hvem Hva trengs
Rolle Bruker med modul-tilgang til Portalinnstillinger (new === true på moduleID = 99)
Modul Portalinnstillinger — moduleId: 99 på /settings/portal-setting-ruten (setting-routing.module.ts:30)
Effekt Endring i låsedato gjelder hele tenanten — alle ansatte og ledere blir påvirket samtidig

Tilgangssjekken er todelt: ModuleGuard blokkerer hele ruten, og komponentens egen checkAdminAccess() skjuler UI når brukeren mangler tilgang (portal-setting.component.ts:197-208).

Det finnes ingen separat CanUnlockPeriod-rettighet eller egen ObjectType for låsing — den eneste sjekken er modul-tilgangen til Portalinnstillinger.

Hvordan låsen faktisk fungerer

Låsedatoen lagres i kolonnen LockDate i tabellen wv_PeriodStatus (klient-database) for inneværende år (PeriodStatusRepository.cs:183-240). Backend tilbyr endepunktet GET /api/PeriodStatus/IsDateLocked?date=<dato> som returnerer true hvis valgt dato er lik eller før LockDate.

Håndhevingen er eksplisitt per skjerm — det er ingen global middleware som blokkerer skrivinger:

  • Time-registrering (ansatt-skjerm) kaller TimeService.isDateLocked(date) hver gang datoen endres, deaktiverer alle input-felt og viser den gule alert-en «Perioden er låst for endringer til og med \<dato>. Du kan registrere timer fra dagen etter.» (time-registration.component.ts:652).
  • KAI-time-operasjoner sjekker IsDateLocked før AI-assisterte endringer (KAITimeOperationService.cs:68).
  • Admin-import via «Kontroll av timer» bruker fortsatt den eldre månedsbaserte legacy-mekanikken (PeriodStatus.Locked per måned), ikke den datobaserte låsen (CheckHoursController.cs:298-322).

Det betyr at hvis du midlertidig flytter låsedatoen tilbake for å korrigere én linje, blir alle datoer mellom ny og gammel låsedato åpne for alle ansatte i tenanten så lenge endringen står. Det er ikke mulig å åpne bare for en enkelt ansatt eller en enkelt dato.

Slik gjør du en korreksjon i låst periode

Forutsetninger:

  • Du har avtalt korreksjonen med berørt ansatt og leder
  • Du vet om lønnen for perioden er kjørt ut til mottaksystemet
  • Du har dokumentasjon på hva som skal endres og hvorfor

1. Noter dagens låsedato

Gå til Innstillinger → Portalinnstillinger og velg fanen Periode (URL: /settings/portal-setting?tab=period). Skriv ned datoen som står i feltet Låsedato — denne skal settes tilbake etterpå.

"Periode"-fanen med toggle "Aktiver låsing av tidsperiode" påslått og dato-feltet "Låsedato" fylt ut

2. Flytt låsedatoen tilbake (eller slå låsingen av)

Du har to alternativer:

  • Flytt låsedatoen til en dato før datoen du skal korrigere (anbefalt — alle datoer fra og med dagen etter ny låsedato blir åpne). Velg ny dato i Låsedato-feltet og klikk Lagre øverst. Toast «Låsedato oppdatert» bekrefter at backend har lagret.
  • Slå låsingen helt av ved å sette bryteren Aktiver låsing av tidsperiode til av. Komponenten kaller umiddelbart disableLockDate() som sender lockDate: null til backend — ingen ekstra Lagre-klikk er nødvendig (portal-setting.component.ts:1249-1284). Hele tenanten er da åpen for endringer på alle datoer.

Klient-side-sjekken avviser låsedato i fremtiden med toast «Låsedato kan ikke være i fremtiden» (portal-setting.component.ts:1206-1220). Backend gjentar samme sjekk og returnerer «Lock date cannot be in the future» ved direkte API-kall (PeriodStatusController.cs:130-152).

3. Gjør korreksjonen

Gå til Timeregistrering (URL: /time/time-registration) eller la berørt ansatt gjøre det selv. Velg riktig dato — den gule «Perioden er låst»-alert-en skal nå være borte, og alle felt er aktive. Korriger linjen som er feil (antall, wagetype, kommentar) og lagre.

For å redusere risiko: be ansatt logge inn umiddelbart etter at korreksjonen er gjort, og verifiser at linjen vises korrekt.

4. Sett låsedatoen tilbake

Gå tilbake til Innstillinger → Portalinnstillinger → Periode, sett Låsedato tilbake til verdien du noterte i steg 1, og klikk Lagre. Hvis du slo bryteren av i steg 2, må du nå slå den på igjen før du kan velge dato — Lagre-knappen er disabled så lenge bryteren er av eller dato er tom (portal-setting.component.html:882-886).

Det finnes ingen automatisk relåsing og ingen varsel om at perioden står åpen. Du må huske å låse manuelt.

5. Håndter lønnseksporten separat

Hvis lønnen for perioden allerede er kjørt mot mottaksystemet, må korreksjonen håndteres som en separat justering — det finnes ingen «Kun korreksjoner»-filter i lønnseksporten i ePortal. Avtal med lønnsansvarlig hvordan korreksjonen skal sendes (egen batch, manuell justering, eller med på neste vanlige eksport).

Alternativ: etterregistrere i åpen periode

Hvis lønnen er ferdig kjørt og det er upraktisk å flytte låsedatoen, er det vanlig praksis å etterregistrere korreksjonen i en åpen periode med tydelig kommentar (f.eks. «Etterregistrering for \<dato> — \<årsak>»). Da går linjen gjennom vanlig godkjenningsflyt og blir med på neste vanlige lønnseksport.

Dette er en organisatorisk konvensjon — det er ikke en egen funksjon i ePortal, og det krever ingen spesielle innstillinger.

Vanlige problemer

Lagre-knappen er disabled

Lagre-knappen aktiveres kun når toggle Aktiver låsing av tidsperiode er på og låsedato er satt (portal-setting.component.html:882-886). Slo du nettopp bryteren på, må du også velge en dato før du kan lagre.

«Låsedato kan ikke være i fremtiden»

Klient-validering avviser dato senere enn i dag. Velg en dato i fortiden eller dagens dato.

Jeg ser ikke fanen «Periode»

Du har ikke tilgang til Portalinnstillinger (moduleID = 99 med new = true på din userLevel). Be administrator om å legge til tilgangen.

Ansatt får fortsatt «Perioden er låst» etter at låsedatoen ble flyttet

Time-registreringsskjermen sjekker IsDateLocked per dato. Hvis ansatt allerede hadde skjermen åpen før låsedatoen ble endret, må de bytte dato (eller laste siden på nytt) for at ny status skal hentes. Tilstanden cachet i lockCheckInProgress/isDateLocked oppdateres først ved neste datovalg (time-registration.component.ts:652).

Jeg flyttet låsedatoen og glemte å sette den tilbake

Det finnes ingen automatisk relåsing. Gå inn igjen og sett Låsedato tilbake til ønsket verdi. Hvis du mistenker at ansatte rakk å endre noe i mellomtiden: sammenlign endringsdato på timeregistreringene mot tidspunktet hvor låsen var åpen.

Admin-import av timer blokkeres ikke selv om datobasert lås er satt

Datobasert lås håndheves bare i time-registrering og KAI-time-operasjoner. Admin-import via Kontroll av timer bruker fortsatt den eldre månedsbaserte mekanikken (CheckHoursController.cs:298-322). Vil du også sperre admin-import, må du sette tilsvarende måneder som inaktive i «Eldre periodestatus»-tabellen — se Låsing av perioder for timeregistrering.

Konsekvenser for andre

  • Hele tenanten blir påvirket — det er ikke mulig å åpne kun for én ansatt eller én dato.
  • Andre ansatte kan registrere fritt mens låsedatoen er flyttet tilbake. Vurder å gjøre korreksjonen utenfor arbeidstid eller varsle berørte ledere på forhånd.
  • Lønnsregnskapet kan komme i utakt hvis lønnen for perioden allerede er kjørt — koordiner alltid med lønnsansvarlig.
  • ISY Jobtech-integrasjon (hvis tenant har JWT-claimene CCNotifyLockedPeriod = True og CCLockedPeriodNotificationUrl satt) trigger en synkronisering for perioden 1. januar → ny låsedato hver gang UpdateLockDate kalles (PeriodStatusRepository.cs:233-238). For tenants uten denne integrasjonen skjer ingenting ekstra.

Relaterte sider