Version 0184
Uppdaterad
av
Leigh Hutchens
- Sammanfattning av release
- Quinyx webbapp Version 0184
Releasesdatum 17 april, 2024
Sammanfattning av release
Har du ont om tid och vill ha en övergripande sammanfattning? Quinyx web app Version 0184 Ny funktionalitet
Uppdateringar och prestandaförbättringar
Buggfixar
Frontline Portal Version 0184 Ny funktionalitet
Uppdateringar och prestandaförbättringar
Buggfixar
SOAP API / Webservice uppdateringar
|
Quinyx webbapp Version 0184
Releasedatum 17 april, 2024
Ny funktionalitet
Granskningsloggar för godkännandeflöde av schema
Med denna version lägger vi till ett nytt objekt i vårt ramverk för granskningsloggar. Förutom granskningsloggar för schemaobjekt kommer du nu att kunna söka efter granskningsloggar kopplade till godkännandeflödet för schemat (du kan hitta mer detaljer om arbetsflödet här).
Med detta tillägg tillhandahåller vi mer information och en större bild för chefer att bättre förstå alla förändringar som sker i deras enheter.
I framtida versioner planerar vi att komplettera bilden genom att lägga till granskningsloggar för andra schemahändelser med uppgifter om när schemat publicerades eller låstes.
Sökning och navigering i schemagodkännande-granskningsloggarna inuti justeringsvypanelen och tabellen följer samma logik som beskrivs i denna artikel med följande justeringar:
- "Schemagodkännande" är ett nytt objekt som kommer att ha sin egen separat rad i granskningsloggstabellen.
- Inuti kolumnen "Tidsstämpel" visar vi datum och tid när en given åtgärd i Quinyx utfördes.
- Inuti kolumnen "Påverkade grupper" visar vi enheterna som påverkades av den aktuella åtgärden.
- Inuti kolumnen "Objekttyp" visar vi en ny objekttyp med namnet "Schemagodkännande".
- Inuti kolumnen "Objekt" visar vi tidsperioden för vilken godkännandet skickades av planeraren.
- Inuti kolumnen "Åtgärd" visar vi åtgärder som vidtagits på detta objekt, vilka faller in i följande typer: skapa, godkänna, neka och ta bort.
- Inuti kolumnen "Åtgärd utförd av" visar vi vem som har utfört den aktuella åtgärden.
- Inuti kolumnen "Åtgärd utförd för" kommer vi att visa värdet N/A eftersom vi i detta fall inte har några berörda parter.
I dina sökresultat i granskningsloggen för schemagodkännandeflödet kan du se mer detaljer om de egenskaper som gäller för det angivna objektet genom att klicka på pilen i den vänstra kolumnen i tabellen med sökresultat. Genom att klicka där kommer du att kunna se en underordnad tabell med egenskaper som är kopplade till åtgärderna skapa, godkänna och neka. Inuti underordnad tabell kommer skiftbyten att ha två egenskaper kallade:
- Schemaperiod - denna egenskap beskriver för vilken period förfrågan skickades av planeraren.
- Kommentar - denna egenskap kommer att innehålla värdet av kommentarer som läggs till av godkännare när schemagodkännandeförfrågningar har godkänts eller nekats.
Nedan illustrerar bilden hur den nämnda underordnade tabellen för ett schemagodkännande kan se ut:
Enligt samma logik som för alla andra objekt kommer borttagna förfrågningar inte att ha en undertabell.
Vi presenterar QClock, vår nya produkt för in- och utstämplingsfunktionalitet!
I denna version introducerar vi QClock! Vår nya moderna produkt för in- och utstämplingsfunktionalitet.
Vi utvecklar QClock för att kunna fortsätta förbättra våra funktioner kring tidsregistrering för dina anställda. QClock-utvecklingen kommer att fortsätta under de kommande månaderna, och vi kommer att släppa nya funktioner så snart de är klara. I denna första version inkluderar vi möjligheten att konfigurera QClock på dina enheter och stöd för in- och stämpling.
Om du är intresserad av att prova QClock, vänligen kontakta vårt supportteam, så kommer de att hjälpa dig att aktivera det för din organisation.
Uppdateringar och prestandaförbättringar
Korrigeringar till justeringsalternativ av frånvaroscheman för mini-jobbers
Som ett resultat av feedback från vissa kunder som använder detta frånvaroschema-alternativ har vi gjort några mindre korrigeringar för att säkerställa en mer korrekt generering av frånvaroskift för det specifika fallet med tyska mini-jobbers:
- Tidigare, om den anställdes genomsnittliga arbetstimmar var 0, skulle Quinyx lägga till ett frånvaroskift vars varaktighet matchade start- och sluttiderna i Dag och Tidsmodalen i frånvaroschemainställningarna. Detta var äldre logik som inte längre tjänade något syfte för våra kunder, och av den anledningen har vi nu tagit bort den logiken. Istället, om den anställdes genomsnittliga arbetstimmar är 0, kommer inget frånvaroskift att genereras.
- Hittills har frånvaroschemajusteringsalternativet beaktat helgdagsreduktion (beroende på kontokonfiguration). På grund av den tyska avtalstypen för minijobbare, ger det en mer korrekt frånvarolön att inte beakta reducering av helgdagar - av den anledningen beaktar denna alternativtyp för justering av frånvaroschemat inte längre reducering av helgdagar, vare sig för helgdagar eller för dagen före helgdagar
Vänligen notera att som nämnts här (Arbeta med frånvaroscheman), så planerar vi att se över justeringslogiken för mini-jobbers.
Nytt UI för att välja alla skifttyper i funktionen Uppdatera skift
När du väljer att uppdatera alla tillgängliga skifttyper i Kontoinställningar > Uppdatera skift respektive Gruppinställningar > Uppdatera skift har vi av konsekvensskäl ersatt den gamla checkrutan Välj alla med samma designmönster som finns i filtren Schema och Grundchema:
Buggfixar
- Löste ett problem som orsakade att frånvaro som lades till på inaktiverade användare via wsdlUpdateAbsence blev aktiva igen i Schemavyn.
- Löste ett problem som orsakade att API-anropet wsdlUpdateAbsence fick timeout när frånvaroorsaken Egenmelding användes.
- Löste ett problem som orsakade att varningar att visades i Grundschema när anställda överskred veckans schemalagda timmar även om de inte hade det.
- Löste ett problem som orsakade att Schemaperiod-rapporten genererade felaktiga diff. värden för stämplingstimmar och nominella timmar.
- Löste ett problem som orsakade att en minskning av nominella timmar dagen före en helgdag inte fungerade.
Nytt Quinyx HelpDocs-innehåll
HelpDocs-artiklar
- Inga för närvarande.
Interaktiva handledningar
- Inga för närvarande.
Frontline Portal Version 0184
Releasedatum 17 april, 2024
Ny funktionalitet
Ingen för närvarande.
Uppdateringar och prestandaförbättringar
Designuppdateringar - Förhandsgranskningsnummer och dynamisk etikett för sparad publik
Baserat på era återkopplingar har vi gjort några uppdateringar av mottagarantalet för sparad publik.
Mottagarantal för icke-dynamisk sparad publik
Innan denna version visade mottagarantalet endast ett nummer, och många av er informerade oss om att det skulle vara mer användbart för användare att veta om detta nummer avser grupper eller individer.
Det nya beteendet är att mottagarantalet för sparad publik nu visas som "X grupper" ELLER "Y personer".
Antal mottagare i listan | Visa som |
0 | 0 |
1 grupp | 1 grupp |
1 person | 1 person |
Mer än en grupp | X grupper |
Mer än en person | Y personer |
Mottagarantal för dynamisk sparad publik
Innan denna version visades mottagarantalet för dynamiska sparade publik som 'N/A*' med '*Dynamisk publik' angivet nedan. Detta kunde vara förvirrande för användare, eftersom det vid första anblicken kunde verka som om listan inte var tillgänglig för val.
Det nya beteendet är att mottagarantalet för dynamiska sparade målgrupper visas som "Dynamisk".
Buggfixar
- Löste ett problem som orsakade att uppgifter skickades till samma person två gånger.
Nytt Frontline Portal HelpDocs-innehåll
HelpDocs-artiklar
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 upprätthå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 samtal per kund till 10. Du bör förvänta dig svarsstatus 429 om du råkar överskrida denna gräns, och du rekommenderas att implementera en backoff-omförsök-mekanism för att hantera gränsen. Observera att begränsningen 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.
Var vänlig och se till att vidarebefordra denna information till den part inom ert företag som ansvarar för integrationer.
