Version 0183

Uppdaterad av Daniel Sjögren

Releasedatum 3 april 2024

Sammanfattning av release

Har du ont om tid och vill ha en övergripande sammanfattning?

Quinyx web app Version 0183

Ny funktionalitet

  • Definiera heltidsarbetstimmar jämnt fördelat över arbetsdagarna i veckan: Vi släpper den andra delen av vårt större initiativ som syftar till att säkerställa en mer exakt återspegling av anställdas nominella timfördelning enligt deras anställningsavtal, bättre stöd för Quinyx övertid, mertidtid eller minustid metoder, och varaktighet av frånvaroskift skapade med frånvaroscheman.
  • Ursprung för granskningslogg: I denna version introducerar vi begreppet ursprung i våra nuvarande granskningsloggar. Det ger dig ytterligare insikter om var åtgärden som granskades ägde rum.

Uppdateringar och prestandaförbättringar

  • Uppdatera skift - nytt och förbättrat: På grund av nödvändigt underhåll och tekniska begränsningar har vi sammanfogat det som hittills har varit känt som Uppdatera skift och Tillämpa regler-funktionerna respektive.
  • Efterlevnadskontroll: När du kontrollerar schema-efterlevnad har du nu möjligheten att ta hänsyn till frånvaroskift.
  • Stöd för lokala skifttyper i Optimal bemanning och Arbetsstandarder: Quinyx stödjer nu lokala skifttyper och inte bara globala skifttyper i optimal bemanning och arbetsstandarder när du väljer skifttypen som den specifika rollen/bemanningen hänför sig till.

Buggfixar

  • Du kanske är intresserad av en av våra buggfixar i denna version. För mer information, klicka här.

Viktig information

  • Quinyx har beslutat att stödet för den gamla SSO-konfigurationen (Classic och Mobile) kommer att tas bort under 2024.

Frontline Portal Version 0183

Ny funktionalitet

  • Allt-i-ett-inloggning för användare som endast använder Frontline Portal: För de användare på Quinyx All-in-one-plattform (AIO) som endast använder Frontline Portal, dvs. INTE Workforce Management (WFM), har vi gjort några förbättringar av inloggningsprocessen.

Uppdateringar och prestandaförbättringar

  • Inga för närvarande.

Buggfixar

  • Du kanske är intresserad av en av våra buggfixar i denna version. För mer information, klicka här.

SOAP API / Webservice-uppdateringar

  • Inga för närvarande.

Viktig information

Sista meddelandet! Intresseanmälan-funktionalitet

I denna version tar vi bort all funktionalitet för intresseanmälan i webbappen och mobilappen och uppmanar alla kunder och användare att övergå till att använda funktionaliteten för Tillgänglighet. Tillgänglighet är en mer användarvänlig funktion som tillgodoser ett bredare spektrum av användningsfall jämfört med Intresseanmälan. Några anmärkningsvärda funktioner hos Tillgänglighetsfunktionaliteten inkluderar möjligheten att konvertera ett tillgänglighetsobjekt till ett skift i Schemavyn i Quinyx webbapp. essutom stöder Quinyx avdelningar med tillgänglighet och flerval av både enheter och avdelningar vid skapande av tillgänglighet som användare. Användare kan se, skapa, redigera och ta bort sina egna tillgänglighetstimmar med hjälp av våra mobilappar.

Om du har några frågor eller behöver ytterligare hjälp, tveka inte att kontakta vårt supportteam.

Livslängden av Classic och Mobile SSO upphör senast den 31 mars 2024

Quinyx har beslutat att stödet för den gamla SSO-konfigurationen (Classic och Mobile) kommer att tas bort under 2024.

Nya konfigurationer är redan tillgängliga i Chefsportalen och du kommer nu bara behöva en konfiguration för alla Quinyx-applikationer. Vi rekommenderar att kunder som fortfarande använder den gamla konfigurationen börjar planera för att sätta upp den nya konfigurationen.

Den nya konfigurationsleverantören stöder antingen SAML 2 eller OPEN ID-standarder.

Du kan hitta information om hur användare loggar in med mobilapparna med den nya SSO-konfigurationen här.

Quinyx webbapp Version 0183

Releasedatum 3 april, 2024

Ny funktionalitet

Definiera heltidsarbetstimmar jämnt fördelat över veckans arbetsdagar

I Version 0183 släpper vi den andra delen av vårt större initiativ som syftar till att säkerställa en mer exakt återspegling av anställdas nominella timfördelning enligt deras anställningsavtal, bättre stödja Quinyx övertid, mertid eller minustid-metoder, och varaktigheten av frånvaroskift skapade med frånvaroscheman. Denna förbättring kommer speciellt att förbättra den nominella timfördelningen för anställdas avtal som är definierade för färre eller fler än 5 arbetsdagar per vecka.

Hur konfigurerar jag denna nya inställning?

Avtalsmallar/personliga avtal kommer att få ett nytt alternativ i rullgardinsmenyn i avsnittet "Arbetstimmar och perioder". I denna rullgardinsmeny kan du definiera heltidsarbetstimmar jämnt fördelat över arbetsdagarna i veckan genom att välja alternativet "Arbetstid på heltid jämnt fördelat över veckans arbetsdagar"..

När du väljer detta alternativ kommer fält för att definiera heltidsarbete och dagar att arbeta att visas.

Vad är alternativet "Arbetstid på heltid jämnt fördelat över veckans arbetsdagar (före version 0183)" i rullgardinsmenyn?

Detta alternativ representerar den nuvarande avtalsinställningen som fanns fram till denna version. Vi har beslutat att behålla denna konfiguration aktiv tills alla kunder är aktiverade och migrerade till den nya konfigurationen som vi släpper med Version 0183.

Hur skiljer sig denna konfiguration som släpps med version 183 från den vi har idag (före 183)?

Ja, du har rätt om du har märkt att avtalskonfigurationsfälten är identiska. Skillnaden kommer med hur dessa definierade timmar återspeglas i Quinyx nyckeltal för anställda och när man arbetar med frånvaroscheman med hjälp av nominella timjusteringar.

Hur påverkar anställningsgraden de timmar jag lagt till på arbetsdagarna?

Anställdas anställningsgrad fungerar på samma sätt som det gör idag. Procenten tillämpas på de definierade timmarna under arbetsveckans arbetstimmar.

Exempel:

Om, i bilden ovan, där heltidstimmar definieras som 24 timmar, och med en anställningsgrad på 50%, skulle den anställde ha 12 förväntade nominella timmar för den veckan.

Hur återspeglas mina konfigurerade timmar i de anställdas nyckeltal i Schemavyn?

Låt oss anta att vår exempelanställd har definierat 24 arbetstimmar per vecka på 3 arbetsdagar.

Eftersom anställningsavtalet inte anger vilka 3 dagar under veckan som är arbetsdagar, inför vi med vår nya logik, en mer flexibel metod där de 3 arbetsdagarna kan flyttas under veckan beroende på den anställdes faktiska schema.

Logiken fungerar på följande sätt:

  • Nominella timmar per arbetsdag är 8 timmar vilket är en jämn fördelning av 24 timmar på 3 arbetsdagar.
  • Om den anställdas arbetsvecka fortfarande är tom (dvs. den anställde är ännu inte schemalagd att arbeta) kommer 8 dagliga nominella timmar att tilldelas de tre första dagarna i veckan (måndag, tisdag och onsdag). Övriga vardagar kommer att ha 0 tilldelade dagliga nominella timmar.
  • Om den anställde under schemaläggningsprocessen schemaläggs att arbeta 3 andra dagar i veckan, kommer de tilldelade 8 nominella timmarna per dag att flyttas till dessa 3 arbetsdagar.

Exempel:

Jag har schemalagt min anställd att arbeta 8 timmar på tisdag, torsdag och lördag. Dagliga nominella timmar kommer att flyttas från de första tilldelade måndag, tisdag och onsdag till de schemalagda tisdag, torsdag och lördag, vilket gör dessa dagar till arbetsdagar för den anställda.

  • Med denna logik tillåter vi chefer att ha flexibilitet i schemaläggningsprocessen för att tilldela skift på vilka 3 dagar som helst under veckan för de anställda med denna avtalskonfiguration och tar anpassar de anställdas nyckeltal till schemaläggningsprocessen.
  • När alla 3 dagar som definierats enligt avtalet har schemalagts, kommer alla andra dagar i veckan att ha 0 nominella timmar tilldelade.

Vad händer om min anställd är schemalagd att arbeta ett skift som sträcker sig över arbetsdagens början?

I detta fall kommer dagliga nominella timmar att tilldelas den dag då skiftet börjar.

Vad händer om min anställd inte har ett schemalagt skift men har en stämpling?

Om en anställd endast har stämplat utan ett schemalagt skift, kommer vi att betrakta denna dag som en "schemalagd" dag också, och dagliga nominella timmar kommer att tilldelas för denna dag enligt avtalet.

Kan min anställd faktiskt arbeta mer än de avtalade arbetsdagarna i veckan?

Ja, Quinyx kommer inte att blockera schemaläggningen av anställda på fler dagar än de som är definierade i deras avtal. Beroende på den konfigurerade övertidsmetoden kommer anställda att kompenseras för dessa timmar.

Exempel:

Låt oss säga att en anställd är kontrakterad att arbeta 3 dagar den veckan men faktiskt arbetar 4 dagar. Om du använder daglig övertidsberäkning, kommer den 4:e dagen att betraktas som övertid. I detta exempel räknas den 4:e dagen från veckans början, med start från måndag.

Om du använder vecko/månadsövertidsberäkning kommer systemet att titta på vecko/månadstimmar och anställda kommer att kompenseras beroende på dessa timmar.

Får anställda reducerade timmar på helgdagar med denna nya logik?

Ja, med vår nya logik kommer vi att undersöka antalet arbetsdagar som har lagts till i avtalet och var de timmarna finns i schemat för den veckan, genom att följa samma tillvägagångssätt som definierats ovan.

Exempel:

En anställd har 3 arbetsdagar och är schemalagd att arbeta alla 3 dagarna (måndag-onsdag).

Om en helgdag infaller på tisdag och den helgdagen är inställd för att minska nominella timmar, kommer den anställde att få reducerad helgdag eftersom tisdag anses vara en schemalagd dag för den anställde.

Om en helgdag infaller på lördag kommer den anställde inte att få reducerad helgdag på lördag eftersom de avtalade 3 arbetsdagarna redan är schemalagda under den veckan.

Det är viktigt att nämna att vi kommer att undersöka konfigurationen av helgdagar som är baserade på % av nominella timmar. Om helgdagarna är inställda för att ta hänsyn till de fasta timmarna kommer denna logik inte att gälla och timmarna kommer alltid att reduceras den dagen.

Hur återspeglas mina konfigurerade timmar när jag lägger till frånvaro med ett frånvaroschema som har justering av nominella timmar?

Frånvaroscheman som har justeringar baserade på nominella timmar kommer alltid att ta hänsyn till värdena för den anställdas arbetsdagar och timmar under veckan som är konfigurerade i den anställdas avtal under alternativet "Heltidsarbete med jämnt fördelade arbetstimmar över veckans arbetsdagar".

När en chef lägger till en frånvaro med hjälp av ett frånvaroschema kommer frånvaroskift att läggas till på samma antal arbetsdagar som definierats i den anställdas avtal. Med vår nya och förbättrade logik kommer Quinyx nu att ta hänsyn till om den anställda redan har arbetat skift under den veckan, och frånvaroskift kommer att läggas till på andra dagar som är definierade i avtalet.

Dagarna som är konfigurerade i frånvaroschemans konfiguration kommer att representera intervallet av dagar på vilka Quinyx kommer att lägga till frånvaroskift när frånvaron skapas. Vi rekommenderar att frånvaroscheman konfigureras med alla veckodagar valda (måndag-söndag) för att möjliggöra maximal flexibilitet.

Frånvaroschemans logik kommer att följa samma tillvägagångssätt som de anställdas nyckeltal, med antagandet att de tre första dagarna i veckan är arbetsdagar för den anställde.

Låt oss använda samma exempelanställd som har definierat 24 arbetstimmar per vecka på 3 arbetsdagar med denna frånvaroschemakonfiguration.

  • Antag att den anställde inte är schemalagd att arbeta och frånvaron med användning av frånvaroschemat läggs till för hela veckan, frånvaroskift genereras under de första 3 dagarna i veckan (måndag, tisdag och onsdag). Varje dag har tilldelade 8 dagliga nominella timmar, vilket justerar de nominella timmarna för veckan till 24 timmar.
  • Om den anställde arbetade ett skift på måndag men sedan efter att de kom hem från arbetet den dagen blev sjuka. Som ett resultat läggs frånvaro med användning av ett frånvaroschema till för resten av veckan. Frånvaroskift genereras på tisdag och onsdag med respektive timmar 8, 8. I det här exemplet ansåg Quinyx att den anställde redan hade arbetat 1 av de 3 arbetsdagarna som definierats i den anställdes avtal.
Granskningslogg-ursprung

Från och med denna version introducerar vi begreppet ursprung i våra nuvarande granskningssloggar. Syftet med denna funktion är att ge dig ytterligare insikt om var åtgärden som granskas ägde rum. Som exempel, när du granskar ett skift som har skapats, kommer du att kunna förstå om det skapades i Chefsportalen eller i mobilappen.

Ursprungsinformationen finns i mindre text under huvudvärdet i kolumnen "Åtgärd utförd av" i vyn, som framhävs i bilden nedan.

Tabellen nedan innehåller en utförlig lista över de olika ursprungsvärden du kan stöta på när du bläddrar i dina loggsökresultat, samt tillfällena där dessa värden kommer att visas. Logiken i ursprungsnamngivningen syftar till att stödja dig i att lösa tvister eller problem som rör arbetskraftsplanering och närvaro och är följande:

  • I de flesta fall återspeglar det den Quinyx "plattformen" där åtgärden utlöstes, såsom Chefsportalen, Mobil, Webpunch eller Integration.
  • Om åtgärden däremot har utlösts av en specifik funktion som har kaskadeffekter på andra delar av Quinyx, såsom att ändra en anställds hemmaenhet eller avsluta deras anställning, kommer detta att visas som ursprung istället.
På grund av tekniska begränsningar är inte auto-tilldelning och auto-schema för närvarande tillgängliga som ursprungsvärden. Relevanta Quinyx-team arbetar för närvarande med detta för att det ska kunna förbättras på medellång sikt.

Åtgärd

Ursprung

Fall

Skapande

Via Chefsportalen

När ett skift skapas i schemat i chefsportalen.

Skapande

Via grundschema-utrullning

När ett skift skapas i schemat som ett resultat av en grundschema-utrullning.

Skapande

På grund av frånvaro

  1. När ett skift omvandlas till ett frånvaroskift som ett resultat av att frånvaro skapas ovanpå ett skift. Observera: Detta gäller även när frånvaro läggs till ovanpå en del av ett skift.
  2. När en frånvaro tas bort och ett frånvaroskift återinsätts som ett resultat. Detta gäller oavsett vilken skiftåtgärd som valdes vid frånvaroskapandet, antingen radera/omtilldela/omtilldela.

Skapande

På grund av frånvaro med frånvaroschema

När en frånvaro skapas med hjälp av ett frånvaroschema och som ett resultat av detta befintliga skift i schemat tas bort och senare samma frånvaro tas bort och användaren väljer att återinföra skiften; kommer de skift som togs bort när frånvaron skapades skapas på nytt, därav detta ursprung.

Skapande

Via Mobil

  1. Anställd lägger till skift i Mobil
  2. Chef lägger till skift i Mobil

Skapande

Via integration

När ett skift skapas med hjälp av en integration, vare sig det är med hjälp av våra SOAP-API:er eller - i framtiden - REST-API:er.

Angående automatisk schemaläggning och automatisk tilldelning: Se beskrivningen ovanför denna tabell.

Uppdatering

Via Chefsportalen

När ett skift uppdateras i schemat i chefsportalen.

Uppdatering

Via grundschema-utrullning

När ett skift uppdateras i schemat vid en grundschema-omrullning.

Uppdatering

På grund av frånvaro

  1. När en frånvaro skapas och den valda skiftåtgärden är avtilldelad eller omtilldelad, avtilldelar/omtilldelar Quinyx det ursprungliga skiftet. (Under huven skapar Quinyx samtidigt ett nytt arbetspass för frånvaropasset).
  2. När en deltidsfrånvaro skapas för ett befintligt skift, och som ett resultat av detta, uppdateras antingen start- eller sluttiden för det skiftet.
  3. När en deltidsfrånvaro tas bort och den första delen av den befintliga frånvaron därmed förlängs för att återspegla tiden för det första skiftet. Exempel:
    1. Ursprungligt skift 08:00 -16:00
    2. Frånvaro läggs till 10:00 - 14:00
    3. Frånvaron tas bort
    4. Som ett resultat ändras sluttiden för 08:00 10:00 till 16:00
  4. När den anställde stämplar ut tidigt eller sent och väljer en frånvaroorsak, vilket i sin tur omvandlar motsvarande del av skiftet till en frånvaro och därmed ändrar skiftets start- eller sluttid i enlighet med detta.

Uppdatering

På grund av "Uppdatera skift" -funktionen

När ett skift uppdateras som ett resultat av uppdateringsfunktionen för skift i Kontoinställningar eller Gruppinställningar respektive

Uppdatering

På grund av radering av anställd

När ett skift inte är tilldelat eftersom en anställd har raderats. Observera att i detta fall blir egenskapen Status för löneartsregler som kräver godkännande noll som ett resultat.

Uppdatering

Via mobil

  1. När en anställd uppdaterar ett skift i mobilappen
  2. När en chef uppdaterar ett skift i mobilappen

Uppdatering

På grund av avtalsval-logik

När avtalet för skiftet uppdateras enligt något av fallen där Quinyx tillämpar sin avtalsval-logik (som beskrivet här).

Uppdatering

På grund av anställningens slut

När ett skift är otilldelat som ett resultat av att mottagarens slutdatum för anställningen ändras till före det angivna skiftets startdatum.

Uppdatering

På grund av ändring av hemmaenhet

När en anställds hemmaenhet ändras, vilket innebär att följande ändringar utlöses som ett resultat av systemet:

  1. Den anställdes framtida schemalagda skift blir otilldelade (men förblir på samma enhet)

Uppdatera

På grund av avtalsradering

När avtalet som används för ett visst skift raderas.

Uppdatera

På grund av skiftavbokningsgodkännande / Via Chefsportalen

När skiftegenskapen anställd ändras som ett resultat av att en skiftavbokningsförfrågan godkänns.

Observera att specifikt för loggåtgärder före den 20 mars 2024 används texten "Via Chefsportalen" på grund av tekniska begränsningar.

Uppdatera

På grund av skiftbokningsgodkännande / På grund av skiftbokningsbegäran

När skiftegenskapen anställd ändras som ett resultat av att en skiftbokning godkänns.

Observera att specifikt för loggåtgärder före den 20 mars 2024 används texten "På grund av skiftbokningsbegäran" på grund av tekniska begränsningar.

Uppdatera

På grund av godkännande av skifttilldelning på bortaenhet / På grund av skiftbokningsbegäran

När skiftegenskapen anställd ändras som ett resultat av en chef på hemmaenheten godkänner en begäran från en chef på en bortaenhet att tilldela en anställd.

Observera att specifikt för loggåtgärder före den 20 mars 2024 används kopieringen "På grund av bokningsbegäran" på grund av tekniska begränsningar.

Uppdatering

På grund av godkännande av skiftbyte / På grund av begäran om skiftbyte

När skiftegenskapen anställd ändras på grund av att ett skiftbyte godkänns av chefen.

Observera att specifikt för loggåtgärder före den 20 mars 2024 används kopieringen "På grund av begäran om skiftbyte" på grund av tekniska begränsningar.

Uppdatering

På grund av omberäknat löneutfall

När en löneberäkning utlöses av vissa åtgärder i schemat, vilket leder till att ett skifts "Status för löneartsregler som kräver godkännande" uppdateras till Ej godkänd.

Ett exempel på en åtgärd i schemat som kan utlösa löneomberäkningen är att öppna tidkortet i Schemavyn. Observera att detta endast utlöser att beräkningen körs, den verkliga orsaken till förändringen kommer snarare att vara på grund av en förändring i de faktorer som är konfigurerade i Quinyx för att påverka den anställdas löneutfall.

Uppdatering

Via integration

När ett skift uppdateras med hjälp av en integration, vare sig det är med hjälp av våra SOAP API:er eller - i framtiden - REST API:er.

Angående automatisk schemaläggning och automatisk tilldelning: Se beskrivningen ovanför denna tabell.

Radering

Via Chefsportalen

När chefen raderar ett skift i schemat i chefsportalen.

Radering

Via grundschema-utrullning

När ett skift raderas i schemat vid en grundschema-omutrullning.

Radering

Via Mobil

När en chef raderar ett skift i Mobilappen.

Radering

På grund av frånvaro

När ett skift raderas på grund av att en frånvaro har lagts till. Observera att detta sker i följande fall:

  1. När en frånvaro skapas och skiftåtgärden raderas.
  2. När en frånvaro skapas med hjälp av ett frånvaroschema där frånvaroschemat är konfigurerat för att ersätta "schemalagda dagar" eller "alla dagar", vilket innebär att vissa av de befintliga skiften i schemat raderas som ett resultat av den skapade frånvaron.
  3. När en deltidsfrånvaro raderas och frånvaroskiftet (som skapades av Quinyx i bakgrunden specifikt för att säkerställa att den aktuella deltidsfrånvaron innehöll ett frånvaroskift) tas bort från systemet som ett resultat.

Borttagning

Via integration

När ett skift tas bort med hjälp av en integration, vare sig det är med hjälp av våra SOAP-API:er eller - i framtiden - REST-API:er.

Angående automatisk schemaläggning och automatisk tilldelning: Se beskrivningen ovanför denna tabell.

 

För närvarande kommer ursprungsinformation att visas för åtgärder som rör objekttypen "skift". Du kan förvänta dig att ursprungsinformation släpps för de återstående objekttyperna under de kommande månaderna.

Observera att vi för närvarande arbetar med att lägga till "Via Webpunch" för uppdateringar av skift som sker som ett resultat av att en anställd lägger till en oplanerad uppgift med hjälp av Webpunch.

Uppdateringar och prestandaförbättringar

Uppdatera skift - nytt och förbättrat!

På grund av nödvändigt underhåll och tekniska begränsningar har vi sammanfogat det som hittills har varit känt som funktionerna Uppdatera skift och Tillämpa regler. Från och med denna version kommer funktionaliteten relaterad till dessa äldre funktioner att hittas genom att navigera till Kontoinställningar > Skifttyper > Uppdatera skift och Gruppinställningar > Skifttyper > Uppdatera skift respektive.

I Quinyx, när en skifttyp redigeras i Kontoinställningar > Skifttyper och Gruppinställningar > Skifttyper respektive, kommer de redigeringar som görs att återspeglas i alla skift (och uppgifter, om tillämpligt) som skapas från och med den tidpunkten framåt i tiden. Syftet med funktionen Uppdatera skift är att sprida dessa redigeringar - eller delar av dessa redigeringar - till befintliga skift i schemat och/eller grundschema. Panelen Uppdatera skift låter dig specificera den exakta delmängden av befintliga skift - förflutna eller framtida - som du vill uppdatera.

Följande kriterier finns tillgängliga för dig att specificera vilka skift du vill uppdatera.

Fält

Beskrivning

Grupper

Detta träd låter dig välja vilka grupper du vill sprida dina skifttypsredigeringar till. Använd checkrutorna i trädstrukturen för grupper för att välja detta. Du kan använda det fritextfältet för att enklare lokalisera objekt i trädstrukturen. Trädstrukturen är hopfälld som standard.

Under det fritextfältet visas antalet regioner, enheter och avdelningar som valts respektive.

 

Om du har åtkomst till denna funktion från kontoinställningar kan du välja vilken grupp eller grupper som helst över kontot. Om du har åtkomst till den från gruppinställningar kan du välja den grupp som för närvarande är vald i gruppväljaren i navigeringsfältet, samt någon av dess undergrupper*.

 

Standardvärdet för detta fält är gruppen som för närvarande är vald i navigeringsfältets gruppväljare, samt alla dess undergrupper (om tillämpligt).

 

Att avmarkera en föräldergrupp avmarkerar också alla dess undergrupper. Att välja en grupp markerar automatiskt alla dess undergrupper. Observera att du har möjlighet att avmarkera alla dessa undergrupper efter eget gottfinnande.

Skifttyp

Välj de skifttyper du vill utföra åtgärden för. Genom att markera rutan "Välj alla skifttyper" väljer du alla skifttyper på en gång.

Från

Gäller för skift i schemat: Välj - genom att skriva eller klicka - startdatumet från vilket du vill att dina skifttypsredigeringar ska spridas i schemat

Till

Gäller för skift i schemat: Välj - genom att skriva eller klicka - slutdatumet fram till vilket du vill att dina skifttyspredigeringar ska spridas i schemat

Välj vad som ska uppdateras

Välj vilka specifika skiftegenskaper du vill uppdatera. De skiftsegenskaper som är tillgängliga att uppdatera är:

  1. Räkna som schemalagda timmar
  2. Räkna som arbetade timmar
  3. Kostnadsställe
  4. Kommentar
  5. Fridag
  6. Produktiv tid
  7. Projekt
  8. Skifttider
  9. Avdelning
  10. Löneartsregler
  11. Uppgift
  12. Visa raster i mobilappen

Uppdatera löneartsregler endast på skift som inte har några aktuella regler applicerade på dem

Denna checkruta visas endast om du väljer alternativet "Löneartsregler" i fältet "Välj vad som ska uppdateras" ovan.

 

Om du markerar denna checkruta och klickar på Uppdatera, kommer Quinyx att skanna skiften som matchar dina urvalskriterier och identifiera de skift vars nuvarande löneartsregler inte matchar dess skifttyp. Den kommer sedan lägga till eventuella saknade löneartsregler till dessa skift.

 

Detta är en äldre funktion, implementerad med avsikten att ge dig självbetjäningsmöjligheter att lösa (en nu löst) återkommande bugg i vårt system relaterat till löneartsregler. Tills vidare kan du använda denna funktion efter eget gottfinnande.

Välj var du vill uppdatera

Denna del av formuläret låter dig välja om du vill uppdatera endast skift i Schemat, eller även i Grundschema; och i så fall, vilka grundscheman. Om du markerar checkrutan "förälder" för Grundschema kommer alla grundscheman att väljas. Observera att de grundscheman som visas i listan är endast de som innehåller minst ett skift som matchar resten av dina urvalskriterier i formuläret ifråga.

Observera att grundscheman med olösta varningar inte kan uppdateras och kommer därför att visas med gråtonad text tillsammans med texten "Kan inte uppdateras eftersom grundschemavarningar är olösta."

När du har valt dina uppdateringskriterier klickar du på "Uppdatera" längst ner i panelen. När uppdateringen är klar kommer en toaster som indikerar dess framgång att visas:

Om ditt urval av skift är stort är det troligt att laddningen tar lite tid och panelen Uppdatera skift kommer att förbli öppen medan ett snurrande hjul visas ovanpå Uppdatera-knappen. Du kan navigera bort från denna skärm - eller öppna en annan flik i din webbläsare - och komma tillbaka till Uppdatera skift. Observera dock att om du gör det kommer ovan nämnda toaster-meddelande inte att visas vid uppdateringsslutet, och inte heller kommer ditt urval per fält att visas. Detta är något vi strävar efter att förbättra över tiden.

Om det finns några fel relaterade till uppdateringen kommer texten i toastern att läsa "Inte alla skift uppdaterades. Försök igen". Orsakerna till ett sådant fel kan vara att en annan användare i din organisation försöker rulla ut ett grundschema som är en del av dina uppdateringskriterier medan du fyller i Uppdatera skift-formuläret. Observera att i sådana fall kan du uppdatera igen så många gånger du vill

Observera att detta för närvarande endast gäller enheter och avdelningar.

Behörigheter

I Quinyx behöver användare skrivrättigheter till behörigheten "Skifttyper" för att kunna använda den här funktionen. Före version 0183 styrde inte "Tillämpa regler" om användare kunde uppdatera löneartsregelvärden utan snarare specifikt om de kunde använda funktionen "Uppdatera löneartsregler endast på skift som inte har några aktuella regler tillämpade på dem". Vi samlar för närvarande in feedback om hur vi bäst kan utveckla denna behörighet. Tveka inte att skicka oss feedback genom att använda knappen "Skicka oss feedback".

Sammanfattning av förändringar i funktionalitet som ett resultat av uppdateringen till version 0183

  • Tidigare erbjöd Quinyx en funktion som kallades Uppdatera skift och en som kallades Tillämpa regler. Dessa har nu sammanslagits till en, som fortfarande stöder samma fall som tidigare - och mer.
  • Framför allt: tidigare kunde Uppdatera skift-förfrågningar ibland ta för lång tid. Detta skulle vanligtvis - men inte enbart - hända om du som användare hade valt för många skift för systemet att hanteraNu använder Quinyx asynkron polling för att se till att din begäran utförs. Observera att detta inte betyder att du inte kan få fel, men det beror inte på att systemet inte kan hantera den enorma mängden skift du har valt.
  • Tidigare, om du hade valt ett grundschema som hade olösta utrullningsvarningar i "Välj vad som ska uppdateras" och klickade på uppdatera, skulle Quinyx informera dig om att något gick fel, vilket innebar att du kunde fastna i en oändlig loop av försök att köra kommandot Uppdatera skift. Nu är grundscheman med olösta utrullningsvarningar gråmarkerade i "Välj vad som ska uppdateras"-delen av formuläret och åtföljs av en förklarande text.
  • Som ett resultat av din feedback är skifttypinställningen "Visa raster i mobilappen" nu valbar i fältet "Välj vad du vill uppdatera".
  • Tidigare kunde man "Välja alla" för checkrutan "Välj vad du vill uppdatera". Vi har nu tagit bort den möjligheten på grund av frekventa rapporter om att användare av misstag valde alla värden oavsiktligt, vilket ledde till massiva överkostnader för att korrigera detta misstag, särskilt för värdet "skifttider".
  • Tidigare kunde man endast uppdatera olika skifttyper om man uppdaterade löneartsregler specifikt (genom den nu föråldrade funktionen "Tillämpa regler") - detta är nu möjligt även för återstående skiftegenskaper.
  • Innan, om du hade tillgång till Uppdatera skift genom Kontoinställningar, fanns det ingen möjlighet att välja endast en delgrupp för vilken skiften skulle uppdateras. Det är nu möjligt att göra det med hjälp av gruppstrukturen.
  • Tidigare, i "Välj var du vill uppdatera" -delen av panelen, skulle antalet skift som skulle uppdateras enligt ditt nuvarande val visas inom parentes längst ner på panelen för Schema och för Grundschema respektive. Tyvärr hade detta en mycket negativ effekt på prestandan, vilket är varför vi var tvungna att ta bort nämnda räkning.
  • Se behörigheterna rubriken ovanför avsnittet du läser just nu.
Efterlevnadskontroll

Kontroll av efterlevnad för schema

När du kontrollerar efterlevnaden för schemat har du nu möjligheten att ta hänsyn till frånvaroskift. Detta är särskilt användbart när du vill se om en användare bröt mot några regler innan de var frånvarande, dvs. ringde in sjuka.

Som ett exempel: en användare ska inte schemaläggas för mer än tre skift i rad. Inledningsvis var denna användare schemalagd för fyra skift i rad, vilket borde utgöra ett brott. Men på det tredje skiftet ringde användaren in sjuk. Med den nya inställningen kommer ett brott att rapporteras, medan det tidigare inte skulle göras. Observera att denna inställning är inaktiverad som standard och måste aktiveras manuellt.

Denna funktion behöver konfigureras av Quinyx-experter, vänligen kontakta oss för mer information.

Kontroll av efterlevnad för arbetade timmar

Vi har gjort några förbättringar i att kontrollera hur en anställd har arbetat under ett skift. Innan denna version skulle vi kontrollera varje stämpling individuellt, vilket kunde leda till falska överträdelser i vissa situationer. Med förbättringen utvärderar vi nu alla stämplingar som tillhör samma skift, vilket bör öka noggrannheten av kontrollen av överträdelser avsevärt.

Observera att vi för närvarande exkluderar stämplingar som inte tillhör något skift på grund av tekniska begränsningar.
Stöd för lokala skifttyper i Optimal Bemanning och Arbetsstandarder

Quinyx kan nu även stödja lokala skifttyper, och inte bara globala skifttyper i optimal bemanning och arbetsstandarder när man väljer skifttypen som den specifika rollen/bemanningen hör till. Detta kommer att låsa upp möjligheten för kunder som använder både globala och lokala skifttyper att schemalägga sin personal för att kunna bestämma sina arbetsbehov på ett korrekt sätt.

Vid skapande av optimal bemanning baserat på lokala skifttyper returneras endast enheter och avdelningar som är relaterade till den lokala skifttypen i gruppstrukturen när arbetsstandarder konfigureras. Detta säkerställer att inga enheter kan väljas där de lokala skifttyperna inte existerar, och det blir tydligare vilka specifika enheter den lokala skifttypen tillhör.

Buggfixar

  • Löste ett problem som orsakade att avdelningsfältet i Redigera skifttyp-panelen inte uppdaterades.
  • Löste ett problem där informationsmeddelandet "avstående undertecknat" inte visades och premielönen inte togs bort när man stämplade ut inom specifika avståendeaktiva timmar, trots att inställningar för måltidsrast och engångsavstående var aktiverade.
  • Löste ett problem som hindrade en chef från att attestera en stämpling på ett skift för ett specifikt datum.
  • Löste ett problem som orsakade avrundningsfel i den Detaljerade raster och uppgifter-rapporten.
  • Löste ett problem som orsakade att Detaljerade raster och uppgifter-rapporten misslyckades om det fanns några stämplingar utan skiftet i den filtrerade perioden.

Ny Quinyx HelpDocs-innehåll

HelpDocs-artiklar
Interaktiva handledningar

Frontline Portal Version 0183

Releasedatum 3 april 2024

Ny funktionalitet

Allt-i-ett-inloggning för användare som endast använder Frontline Portal

För de användare på Quinyx All-in-one-plattform (AIO) som endast använder Frontline Portal, dvs. inte Workforce Management (WFM), har vi gjort några förbättringar av inloggningsprocessen.

  1. Användaren loggar in i Quinyx som vanligt:

  1. Användaren kommer att skickas direkt till Frontline Portal hemsidan:
  1. De användare som har behörighet för användarhantering kan navigera till Quinyx WFM via Inställningar > Användarhantering.
  1. Användaren kommer sedan till Quinyx WFM fliken Personer.
  1. Här kan de uppdatera användaruppgifter, dvs. en användares namn, e-postadress, lösenord osv. Detta görs genom att välja den användare vars uppgifter de vill ändra, uppdatera informationen och sedan välja Spara.
  1. För att navigera tillbaka till Frontline Portal måste användaren välja Profil > Växla till Frontline Portal.
  1. Klart!

Uppdateringar och prestandaförbättringar

Inga för närvarande.

Buggfixar

  • Löste ett problem som förhindrade att filer visades korrekt över plattformen.
  • Löste ett problem som förhindrade att tomma widgets försvann från startsidan.

Nytt Frontline Portal HelpDocs-innehåll

HelpDocs-artiklar
  • Inga för närvarande.
Interaktiva handledningar
  • Inga för närvarande.

SOAP API / Webservice-uppdateringar

  • Inga för närvarande.
  • Inga slutpunkter är för närvarande föråldrade och planerade för borttagning.
    Klicka här för att se den nya Quinyx WFM Web Service-dokumentationen. Du kan hitta ännu mer information om webbtjänster här.
    Vi uppmanar alla våra kunder att använda våra API:er för att underhålla data och se till att informationen är aktuell. För att säkerställa skalbarheten av våra API:er samtidigt som vi växer 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 verkställas programmatiskt, vilket innebär att vi kommer att införa en begränsning på samtidiga anrop per kund till 10. Du bör förvänta dig svarskod 429 om du råkar överskrida denna gräns, och det rekommenderas att du implementerar en backoff-omförsökningsmekanism för att hantera gränsen. Observera att gränsen endast gäller för SOAP. När vi övergår från SOAP till Rest under de kommande åren kommer eventuella begränsningar 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?