Version 0157

Uppdaterad av Daniel Sjögren

Utgivningsdatum 5 april 2023

Sammanfattning av release

Har du ont om tid och vill du ha en sammanfattning på hög nivå?

Webbapp

Ny funktionalitet

  • Det är nu möjligt att dra tillbaka en pågående begäran om schemagodkännande. Om planeraren bestämmer sig för att dra tillbaka begäran kommer alla tilldelade godkännare att meddelas om detta så att de kan sluta granska schemat för den perioden.
  • Två nya värdejusterare som gör att periodiseringsbaserade Time Trackers kan definieras på frånvarotyp och inte bara för semester.

Uppdateringar och prestandaförbättringar

  • Möjlighet att konfigurera öppettider på 15 minuters granularitet.
  • UI-förbättringar för konfiguration av frånvaroschema.

SOAP API / Webservice-uppdateringar

  • Inga uppdateringar i den här versionen.

Buggfixar

  • Du kanske är intresserad av en av våra buggfixar i den här utgåvan. Om du vill ha mer information, klicka här.

Ny funktionalitet

Möjlighet att dra tillbaka väntande begäran om schemagodkännande

Med den här versionen har vi lagt till möjligheten för planerare att dra tillbaka väntande förfrågningar om schemagodkännande.

Om planeraren bestämmer sig för att dra tillbaka begäran kommer alla tilldelade godkännare att meddelas om den åtgärden så att de kan sluta granska schemat för den perioden. För konfigurationen med två godkännandenivåer kommer godkännare på andra nivån att få detta meddelande endast om begäran väntade på att de ska granskas (godkännande på första nivån har gjorts). Möjligheten att dra tillbaka begäran kommer att vara tillgänglig för alla chefer som har tillgång till schemavyn.

När du öppnar schemat för godkännande och publicering, kommer chefen att presenteras med dessa alternativ:

Genom att klicka på Återkalla begäran öppnas en ny ruta där åtgärden måste bekräftas:

Efter att ha klickat på Ja dras begäran tillbaka och ett automatiskt Qmail skickas till godkännare om denna åtgärd:

Nya Time Tracker värdejusterare

Två nya värdejusterare läggs till Time Tracker-associeringarna.

Varje "frånvaro anledning" ledighetsdag

Värdet på Time Trackern beräknas med antalet dagar då en specifik frånvarorsak används. Detta möjliggör en mer detaljerad konfiguration av värdejusteringen jämfört med den befintliga varje semesterdag.

Det är nu möjligt att konfigurera värdejusteringsbaserade Time Trackers att dra av 0,5 dagar från en frånvarotyp och 1 dag från en annan frånvarotyp, även om båda är av typen semester.

Varje 'frånvaro orsak' ledighetstimmar

Värdet på Time Trackern beräknas med antalet timmar när en specifik frånvarorsak används. Detta möjliggör en mer detaljerad konfiguration av värdejusteraren jämfört med de befintliga semestertimmar för varje semester.

Du kan läsa mer om hur och var du konfigurerar Time Tracker på avtalsmallar här.

Uppdateringar och prestandaförbättringar

Möjlighet att konfigurera öppettider på 15 minuters granularitet

Medan det tidigare bara var möjligt att konfigurera öppettider (standard och speciella timmar) på timnivå, är det nu möjligt att ställa in öppettider med en granularitet på 15 minuter. Du kan ange önskade värden antingen genom att skriva direkt i fältet, eller genom att välja klockan och välja rätt timmar i rullgardinsmenyn.

UI-förbättringar för konfiguration av frånvaroscheman

Information om denna förbättring lades till den 2023-04-03. Vi ber om ursäkt för den olägenhet som det sena meddelandet kan ha orsakat dig.

Under årens lopp har funktionalitet som rör frånvaroscheman rapporterats till oss som buggar, trots att det egentligen var en funktionalitet som var avsedd för ändamålet. Vi har nu tagit lite tid på oss att förbättra både vår dokumentation och användargränssnittet för konfigurationen av frånvaroscheman för att öka förståelsen för det förväntade beteendet hos våra frånvaroscheman.

Som du kan se i skärmbilden ovan, när du går till Kontoinställningar > Frånvaroscheman > [kalenderikonen i kolumnen Åtgärder för ett frånvaroschema], har modalrutan Dag och tid nu några nya element i användargränssnittet:

  1. Tidsfälten har nu fått namnen "Starttid" och "Sluttid". Detta för att de ska kunna refereras korrekt i den förbättrade dokumentationen om detta ämne.
  2. Under fälten "Starttid" och "Sluttid" finns en förklarande text. Den lyder: "Det här frånvaroschemat använder sig av [namnet på anpassningsalternativet för det aktuella frånvaroschemat] anpassningsalternativet. Det kommer att interagera med de dagar och tider som du konfigurerar ovan."
  3. Under den förklarande texten har vi inkluderat en länk till artikeln i användardokumentationen som beskriver hur dag- och tidsfälten i den här modalen interagerar med affärslogiken för respektive justeringsalternativ. Observera att om artikeln i fråga inte finns på ditt lokala språk, kommer du genom att klicka på länken "Mer information här" att komma till artikeln i den engelska versionen.

Buggfixar

  • Löste ett problem som gjorde att en anställd inte var synlig i den månatliga schemarapporten.
  • Löste ett problem som gjorde det möjligt att lägga till Egenmelding för anställda när de hade använt alla tillfällen om chefen använde en annan frånvarotyp och sedan konverterade den till Egenmelding.
  • Löste ett problem med data som ibland var oläslig och inte laddade på fliken Prognos.
  • Löste ett problem med att optimala timmar inte beräknades korrekt när du hade både statiska och dynamiska regler.
  • Löste ett problem med Time Trackers och kombinationen av minskning av lördagar och lördagar som definieras som en helgdag.
  • Löste ett problem där en Time Tracker-transaktion togs bort efter överföring till löneposter.

Nya HelpDocs-artiklar

Påminnelse! Om du vill få e-postmeddelanden varannan vecka om nya releaser kan du registrera dig här.

SOAP API / Webservice-uppdateringar

  • Inga uppdateringar i den här versionen

Inga slutpunkter är för närvarande utfasade och planerade för borttagning.

Klicka här för att se den nya dokumentationen för Quinyx WFM Web Service. Du kan hitta ännu mer information om webbtjänster här.
Vi uppmuntrar alla våra kunder att använda våra API:er för att underhålla data och för att se till att informationen är uppdaterad. För att säkerställa skalbarheten hos våra API:er samtidigt som vi utökar vår kund- och användarbas, har vi beslutat att lägga till begränsningar för användningen av våra SOAP API:er. Dessa begränsningar kommer att tillämpas programmatiskt, vilket innebär att vi kommer att tillämpa en gräns för samtidiga anrop per kund till 10. Du bör förvänta dig svarskod 429 om du råkar överskrida denna gräns, och du rekommenderas att implementera en backoff-försöksmekanism för att hantera gränsen. Observera att gränsen endast gäller SOAP. Vid övergång från SOAP till Rest under de kommande åren kommer eventuella gränser att byggas in i API:et.

Se till att vidarebefordra denna information till den part inom ditt företag som ansvarar för integrationer.

Fick du hjälp?