Version 0154

Uppdaterad av Leigh Hutchens

Från och med den 17 februari har stödet för ATS Terminals nått slutet av sin livslängd och terminalerna kommer att sluta fungera. Alla kunder som har använt terminalerna har blivit informerade och implementerat nya lösningar.
De planerade lönefilsändringarna har släppts den 23 februari 2023.

Utgivningsdatum 28 februari 2023

Sammanfattning av release

Har du ont om tid och är intresserad av en sammanfattning på hög nivå?

Webbapp

  • Godkännandeflöde av schema (tredje versionen): För den här versionen aktiverar vi stöd för två-nivågodkännande i arbetsflödet.
  • Tillgänglighet i smartlistan: Anställda som har lagt till tillgänglighet via mobilappen och angett önskade arbetstider visas i listan med en ny "Tillgänglighet"-ettikett.
  • Vi har uppdaterat logiken för frånvaroschemats alternativ för justering av "sysselsättningsgrad".
  • Variabler för optimalt antal anställda finns nu även på prognossidan.

SOAP API / Webservice-uppdateringar

  • Inga uppdateringar i den här releasen.

Buggfixar

  • Vi har justerat några saker för små att lägga märke till eller för svåra att förklara. Om du verkligen vill ha mer information, klicka här.

Ny funktionalitet

Godkännandeflöde av schemat (tredje versionen)

Med den här versionen fortsätter vi att bygga upp vårt godkännandeflöde för schemat. Det underliggande affärsbehovet som vi möjliggör i den här versionen är stöd för godkännande i två nivåer i arbetsflödet. Detta behov kommer från våra tyska kunder, främst de som har ett arbetarråd i sitt företag. I deras fall, efter chefernas godkännande, skulle arbetarrådet som andra nivå kontrollera att schemat är rättvist och att olika arbetsrättsliga regler följs. Därefter ger de det slutliga godkännandet av schemat.

Konfiguration

Aktiveringen av detta arbetsflöde sker i enhetens avancerade enhetsinställningar. Under underavsnittet "Misc." finns en rullgardinsmeny som heter Godkännande av schema. Om du vill aktivera arbetsflödet i två steg väljer du "Godkännande i två steg" och tilldelar roller som ansvarar för godkännandet.

I godkännandeprocessen inkluderar vi alla personer som har en roll (direkt eller nedärvd) på enheten och läsbehörighet för schemaläggning.

Denna ordning är hierarkisk vilket innebär att begäran om schemagodkännande kommer till den första nivån och sedan till den andra nivåns godkännare.
Planerare som begär godkännande och publicering

Ur en planerarens perspektiv förblir flödet detsamma som med ett godkännandeflöde på en nivå. Genom att klicka på Begär godkännande och publicera ett nytt fönster öppnas där planeraren kan välja vilken period som ska godkännas och publiceras. Genom att klicka på knappen Skicka begäran kommer den tilldelade godkännaren på första nivån att meddelas om den väntande begäran.

Ge feedback på det granskade schema - första nivån

Ur ett godkännandeperspektiv på första nivån är flödet detsamma som i den första versionen. Den enda skillnaden är att i det här fallet skickas ett meddelande till den andra nivåns godkännare efter att godkännaren på första nivån har godkänt schemat. Schemat publiceras inte förrän godkännaren på andra nivån ger sin feedback. Vi har lagt till ett meddelande under kommentarsfältet som förklarar flödet.

Ge feedback på det granskade schemat - andra nivån

Den andra nivåns godkännare använder samma avsnitt "Scheman att godkänna" i Notifikationspanelen. I det avsnittet kommer vi att visa väntande förfrågningar med information om vem som begärde godkännandet, för vilken tidsperiod och när förfrågan skickades. Vi kommer också att ge information om godkännande på första nivån.

Efter att ha granskat schemar och sett till att det är skapat i enlighet med arbetslagar och förordningar, kan godkännaren på andra nivån ge feedback till planeraren genom att godkänna eller avslå begäran. Om begäran godkänns kommer den åtgärden också att göra schemat publicerat för de anställda under den valda tidsperioden. Om begäran avslås måste godkännaren kommunicera med planeraren om nödvändiga ändringar för att schemat ska godkännas.

Kommunikation mellan planerare och godkännare stöds med automatiserade Qmails. Av transparensskäl skickas feedback från den andra nivån (godkännande eller avslag) till både planerare och godkännare på första nivån.

Tillgänglighet i smartlistan

Den här förbättringen är baserad på den feedback vi fick efter att vi lanserade tillgänglighetsfunktionen för några månader sedan. Med den här förbättringen hjälper vi chefer som arbetar med ett schema att tilldela skift på det mest effektiva sättet.

Anställda som har lagt till Tillgänglighet via mobilappen och angett önskade arbetstider kommer att visas i listan med en ny "Tillgänglighets"-ettikett. Dessa anställda kommer att synas högst upp i listan. Om flera anställda har lagt till Tillgänglighet för samma timmar kommer sorteringen mellan dem att baseras på de matchande/saknade färdigheter som anställda har för det specifika skiftet.

För att undvika förvirring har vi bytt namn på det befintliga märket "Tillgänglig" till "Tillgänglig för schemaläggning". Det här märket representerar alla anställda som kan schemaläggas på det skiftet men som inte har tillgänglighet eller en intresseanmälan.

Uppdateringar och prestandaförbättringar

Uppdaterad logik för frånvaroschemats alternativ för justering av "anställningsgrad".

Under de senaste åren har det varit många tillfällen då användare har kontaktat oss för att rapportera vad de tror är en bugg om att det inte finns något alternativ för justering av anställningsgrad i frånvaroschemat.

Problemet var att medan många av er förväntade er att systemet skulle tillämpa följande logik:

Frånvaroschema skiftlängd* x Den givna arbetstagarens anställningsgrad

så tillämpade systemet i praktiken följande logik:

Om frånvaroschemats skiftlängd är kortare än den givna anställdes nominella timmar, används skiftlängd * anställningsgrad. Men om frånvaroschemats skiftlängd är längre än de nominella timmarna, används istället nominella timmar * anställningsgrad.

I och med den här versionen släpper vi en förbättrad version av alternativet för justering av anställningssgraden, som ett sätt att komma till rätta med orsaken till dessa "troliga" felrapporter. Logiken för justeringsalternativet för anställningssgrad kommer framöver att vara följande:

Frånvaroschema skiftlängd x Den givna anställdes anställningssgrad

Exempel: Skiftlängden i frånvaroschemat är definierat som 09.00-17.00. Anställningsssgraden för din anställde Annas enda avtal är 50 %. Det frånvaroskift som skapas när du skapar en frånvaro med hjälp av det här frånvaroschemat för Anna är kl. 09.00-13.00, förutsatt att frånvaron du skapar överlappar frånvaroschemats skiftlängd enligt beskrivningen här.

Observera att eftersom det skulle innebära en risk för felaktig lönekörning att tvinga alla våra kunder att börja använda denna nya logik har vi antagit en avvecklingsstrategi. Detta innebär att för alla frånvaroscheman som skapats före 0154 och som använder alternativet anställningssgrad måste du aktivt byta från den gamla logiken ("anställningsgrad (gammal logik)") till den nya ("anställningsgrad").

Om du byter från alternativet anställningsgrad (gammal logik) till någon annan logik, informerar vi också tydligt om den förändring du genomför:

Som framgår av skärmdumparna ovan kommer vi inte längre att behålla den gamla logiken. Det betyder att du är fri att fortsätta använda den tills vidare, men vi kommer inte att fixa buggar som uppstår i det gamla alternativet för anställningsgrad framöver. Av den anledningen, om detta gäller dig, rekommenderar vi att du byter till det nya alternativet för justering av anställningsgraden förr snarare än senare.

* Med schema skiftlängd hänvisar vi till skiftlängden enligt definitionen i avsnittet Dag och tid:

Variabler för optimalt antal anställda finns nu även på prognossidan

Vi har nu lagt till möjligheten att visualisera Optimala antalet anställda även i prognosgrafen och tabellerna, och inte längre bara i schemastatistiken. Du kan aktivera visualisering av variabler för optimalt antal anställda genom att lägga till dem i rätt visningsgrupper och aktivera visualisering för Prognos.

Buggfixar

  • Löste ett problem med rapporten Stämplade timmar som gjorde att den totala sammanfattningen i schemastatistiken beräknades felaktigt.
  • Löste ett problem med lönearter som lades till i frånvaro som gjorde att alternativet "beroende av dagnummer" inte var markerat som standard.
  • Löste ett problem som gjorde att "Internal server error" meddelanden visades för vissa kunder när skift lades till.
  • Löste ett problem med SOAP-slutpunkten wsdlSendQmail som gjorde att avsändaren fick en kopia av det skickade Qmailet i sin inkorg.
  • Löste ett problem med att datum väljarna inte var helt synliga när du körde Autoschema eller Autotilldelning.

Nya HelpDocs-artiklar

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?