Version 0146

Uppdaterad av Leigh Hutchens

Utgivningsdatum 3 november 2022

Sammanfattning av release

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

Webbappen

  • Quinyx har nu speciell logik - kallad återutrullningslogik- för vad som händer när du rullar ut ett samma grundschema för samma period, anställda och grundschemavecka och veckodag.
  • Du kan nu ändra frånvarolängden på en frånvaroansökan i notifikationspanelen.
  • Vi har den första iterationen av kompensationsregler som nu kan basera utfallet på arbetade timmar eller lönearter för samma veckodag under den valda perioden före helgdag.
  • Vi har lagt till stöd för Webpunch-inställningar så att du kan konfigurera vilken funktionalitet som är tillgänglig i ditt Webpunch gränssnitt.
  • På Prognossidan har vi bytt ut pilarna som används för att sortera variablerna i justeringsvyn i visningsgrupper med samma drag-and-drop alternativ som finns för schemastatistiken.
  • wsdlPunch och wsdlUpdateTimePunches stöder nu uppdelning av stämplingar på uppgifter.

SOAP API / Webservice-uppdateringar

  • Validering av datumformat har lagts till:
    • wsdlUpdateEmployees
    • wsdlUpdateAgreementsV2

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

Grundschema återutrullning och frånvaro

Den här funktionen drogs tillbaka från release 0142 på grund av problem som uppstod under vår kvalitetssäkringsprocess. Dessa har nu lösts.

Quinyx har speciell logik - kallad återutrullningslogik - för vad som händer när du rullar ut ett samma grundschema för samma period, anställda och grundschemavecka och veckodag. Den allmänna regeln är att om det har gjorts en redigering av skiften i grundschemat men inte på motsvarande skift som härstammar från grundschemat i Schema så kommer återutrullningen att uppdatera förändringarna i Schema. Om det å andra sidan har gjorts någon form av ändring av skiften från grundschemat i Schema så kommer ingen uppdatering av det senare att ske som ett resultat av återutrullningen.

Fram till denna version har ovanstående logik gällt för alla fall förutom följande:

  1. Om skiftet i Schema har tagits bort.
  2. Om skiftet i Schema har omvandlats till ett frånvaroskift.
  3. Om skiftet i Schema har fått en godkänd stämpling.

På grund av efterfrågan har nummer 2 ovan nu åtgärdats. Återutrullningslogiken inklusive den ovannämnda förbättringen, beskrivs mer i detalj i den här artikeln.

Ändra frånvarolängd när du godkänner frånvaroansökningar

Vi har lagt till möjligheten att ändra frånvarolängden på en frånvaroansökan i notifikationspanelen.

En chef kan nu uppdatera frånvarolängden när den godkänner frånvaroansökningar. När frånvarolängden uppdateras och frånvaroansökan godkänns så kommer denna frånvarolängd att visas i fältet för frånvarolängd för samma frånvaro. Om istället en frånvarolängd uppdateras på en frånvaroansökan som nekas, kommer den ändringen inte att återspeglas någonstans. Standardvärdet för detta fält kommer att vara den frånvarolängd som valdes av anställd när frånvaroansökningen skapades. Vid uppdatering av frånvarolängden kommer Quinyx att kontrollera om den anställde i den valda perioden har skift och/eller överlappande frånvaro och det kommer att presenteras i notifikationspanelen.

Den här funktionen är användbar eftersom den gör att du som chef kan uppdatera frånvarolängden i de fall det har skett en felkommunikation med anställd och där frånvarotiden behöver uppdateras för att få rätt Time Tracker-saldo och lönebesked för den anställde.

Kompensationsregler baserade på arbetade timmar

Quinyx WFM har tidigare haft stöd för kompensationsregler för helgdagar för att skapa kompensation baserat på genomsnittlig produktion för lönearter under en period före den faktiska helgdagen.

I och med den här versionen släpper vi den första versionen av kompensationsregler som nu kan basera utfallet på arbetade timmar eller lönearter för samma veckodag under den valda perioden före en helgdag.

Detta alternativ kommer, tillsammans med regler för berättigande, att göra det möjligt för kunder inom detaljhandeln i Nederländerna att konfigurera "8/13-regeln för helgdagar".

Du kan läsa mer om reglerna för berättigande och om kompensationsreglerna. Båda artiklarna finns för närvarande endast på engelska, men så snart innehållet är färdigt kommer de att översättas till andra språk som stöds.
“8/13 regel för helgdagar”

"8/13-regeln för helgdagar" är avsedd att kunna kompensera anställda som inte arbetar på en helgdag som infaller på samma veckodag som de vanligtvis arbetar på.

I det här fallet betyder 8/13 att om helgdagen infaller på en fredag måste du ha arbetat minst 8 av de 13 föregående fredagarna för att ha rätt till ersättning för denna helgdag.

Om arbetstagaren arbetar på den aktuella helgdagen är det frivilligt att besluta om ersättningen ska minskas med de arbetade timmarna eller inte.

Läs mer om behörighetsregler här och mer om ersättningsregler här.

Webpunch-inställningar

Med den här versionen har vi lagt till stöd för Webpunch-inställningar som finns under Kontoinställningar > Webpunch > Webpunch- inställningar. Med dessa inställningar kan du konfigurera exakt vilken funktionalitet som ska finnas tillgänglig i ditt Webpunch-gränssnitt för att säkerställa att dina anställda kan stämpla in smidigt.

För detaljer om exakt hur Webpunch-inställningar fungerar och vad varje modul gör klicka här.

Uppdateringar och prestandaförbättringar

  • wsdlPunch och wsdlUpdateTimePunches stöder nu uppdelning av stämplingar på uppgifter.
  • På Prognossidan har vi bytt ut pilarna som används för att sortera variablerna i justeringsvyn i visningsgrupper med samma drag-and-drop alternativ som finns för schemastatistiken.
  • Händelser som läggs till under händelsehantering kan nu visualiseras i prognosgrafen och tabellen.

Buggfixar

  • Löste ett problem som gjorde att ett valt skift försvann bakom statistikvyn.
  • Löste ett problem som visade statistik för anställda med anställningsroller i det förflutna, medan rollfiltret för avdelningen visade anställda med roller i dag eller i framtiden på ett korrekt sätt.
  • Löste ett problem relaterat till sommartid (DST) där stämplingar genererade daglig övertid vid övergång av sommartid. Läs mer om sommartid här.
  • Löste ett problem med att visa schemalagd kostnad i Grundschemastatistik, Lönekostnad för grundschema.
  • Löste ett problem med att uppdatera reglerna för lönekompensation för helgdagar genom att ta bort fastställda procentsatser.
  • Löste ett problem med vilka övertidstyper som visades i rapporten Summering per anställd.
  • Löste ett problem där det inte var möjligt att ta tag i och flytta variabler i schemastatistikens visningsgrupper för att justera vyn när det krävdes skrollning.
  • Löste ett problem med prognosdata som inte laddades när månadsaggregationen hade valts på fliken Prognos.

Nya HelpDocs-artiklar

SOAP API / Webservice-uppdateringar

Följande slutpunkter kommer att uppdateras under de kommande sprintarna. Detta är nödvändigt för oss att göra för att lägga till ny funktionalitet för ersättningsregler (se ovan). Dessa är konfigurationsslutpunkter och vår data visar att inga aktiva integrationer körs mot dem.

Nya inmatningsparametrar kommer att läggas till samt nya svarsobjekt.

3.36 wsdlGetSalaryCompensations

3.37 wsdlUpdateSalaryCompensations

3.38 wsdlDeleteSalaryCompensations

Validering av datumformat har lagts till för:

  • wsdlUpdateEmployees
  • wsdlUpdateAgreementsV2
Det förväntade formatet för ledighetsdatumet är ÅÅÅÅ-MM-DD och ledighetsdatum med andra format kommer att orsaka fel från och med den här versionen.

Slutpunkter fasas ut och tas bort

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?