Varför ändras ett Time Tracker-saldo utan transaktioner?

Uppdaterad av Daniel Sjögren

Om ett Time Tracker-saldo plötsligt ändras så beror det vanligtvis på schemakomponenter som existerar under tidigare tidsperioder och som ännu inte har överförts till lön.

En Time Tracker kommer att räkna den senast uppdaterade perioden och 60 dagar bakåt i tiden, räknat från dagens datum. Detta betyder att om du har några föremål under de senaste 60 dagarna från den aktuella dagen (eller den dag som för närvarande visas på tidskortet) som inte har överförts till lön kommer din Time Tracker att visa inkorrekt antal timmar.

För att lösa detta, se till att göra en definitiv överföring till lön för att uppdatera. Efteråt bör dina Time Trackers visa korrekt antal timmar.

För att vara tydlig, en definitiv överföring till lön, ibland även kallad en hård låsning av schemat, är inte samma sak som att låsa ditt schema från Schemavyn. Att helt enkelt låsa ditt schema kommer bara att förhindra att ändringar kan görs på skift och stämplingar, men kommer fortfarande att påverka ditt Time Tracker-saldo.
Varför 60 dagar?

Intervallet på 60 dagar är utformat för att säkerställa optimal systemprestanda och beräkningsnoggrannhet. Vår beräkningsmotor (LABM) stöder både Time Trackers och lönekörning. När lön (TTP) inte körs ofta måste LABM bearbeta större datamängder för beräkningar på begäran, vilket ökar systembelastningen och potentiellt påverkar prestandan. Därför har vi en gräns i backend som bara kan hänvisa till information upp till 60 dagar tillbaka i tiden.

Genom att utföra lönekörningar minst en gång var 60:e dag skapas en ”snapshot” av beräkningsresultaten i vår databas. Denna ögonblicksbild gör det möjligt för LABM att hänvisa till förberäknade data och endast fokusera på de senaste uppdateringarna.

Exempel

Semesterdagar räknar alla dagar från den faktiska dagen och tillbaka i tiden om tid är hårdlåst (annars upp till 60 dagar) och tar även hänsyn upp till 30 dagar framåt.

Fick du hjälp?