Versie 0183
Updated
by
Daniel Sjögren
- Release samenvatting
- Belangrijke informatie
- Quinyx web app Versie 0183
Releasedatum 3 april 2024
Release samenvatting
Weinig tijd en behoefte aan een beknopte samenvatting? Quinyx web app Versie 0183 Nieuwe functionaliteit
Updates en prestatieverbeteringen
Bug fixes
Belangrijke informatie
Frontline Portal Versie 0183 Nieuwe functionaliteit
Updates en prestatieverbeteringen
Bug fixes
SOAP API / Webservice updates
|
Belangrijke informatie
Laatste aankondiging! Roostervoorkeur (NOI) functionaliteit
In deze versie verwijderen we alle functionaliteit voor roostervoorkeuren (NOI) in de web app en mobiele app en dringen we er bij alle klanten en gebruikers op aan om over te schakelen naar het gebruik van de "Beschikbaarheid" functionaliteit. Beschikbaarheid is een gebruiksvriendelijkere functie die een breder scala aan gebruiksscenario's bedient in vergelijking met Roostervoorkeur. Enkele opmerkelijke mogelijkheden van de Beschikbaarheid functionaliteit zijn onder andere de mogelijkheid om een beschikbaarheidsitem om te zetten in een dienst in de Planning in de Quinyx web app. Daarnaast ondersteunt Quinyx secties met beschikbaarheid en multi-selectie van zowel units als secties bij het invoeren van beschikbaarheid als gebruiker. Gebruikers kunnen hun eigen beschikbaarheidsuren zien, maken, bewerken en verwijderen met behulp van onze mobiele app.
Als u vragen heeft of verdere assistentie nodig heeft, aarzel dan niet om contact op te nemen met ons ondersteuningsteam.
End of life van de Klassieke en mobiele SSO tegen 31 maart 2024
Quinyx heeft besloten dat de ondersteuning voor de oude SSO-configuratie (Klassiek en Mobiel) zal worden stopgezet in 2024.
Nieuwe configuraties zijn al beschikbaar in het Manager Portal, en u heeft nu slechts één configuratie nodig voor alle Quinyx-toepassingen. We raden klanten die nog steeds de oude configuratie gebruiken aan om te beginnen met het plannen van de installatie van de nieuwe configuratie.
De nieuwe configuratieprovider ondersteunt SAML 2 of OPEN ID-standaarden.
- Algemene informatie: SSO basis
- Azure: SAML enkele aanmelding en 'OPEN ID enkelvoudige aanmelding'
Quinyx web app Versie 0183
Releasedatum 3 april 2024
Nieuwe functionaliteit
Fulltime werkuren gelijkmatig verdelen over de werkdagen van de week
We brengen het tweede deel uit van onze initiatief dat tot doel heeft een nauwkeurigere weergave te garanderen van de nominale urenverdeling van werknemers, zoals vermeld in hun arbeidsovereenkomst. Dit biedt een betere ondersteuning voor de Quinyx overuren, extra tijd of minuren methoden en de duur van afwezigheden kan hierdoor aangepast worden met behulp van absentieplanningen. Dit zal met name de nominale urenverdeling verbeteren voor de overeenkomsten van werknemers die zijn gedefinieerd voor minder of meer dan 5 werkdagen per week.
Hoe configureer ik deze nieuwe setup?
Overeenkomstsjablonen/persoonlijke overeenkomsten krijgen een nieuwe optie in het vervolg keuzemenu in de sectie "Werkuren en periodes". In dit vervolgkeuzemenu kunt u fulltime werkuren gelijkmatig verdeeld over de werkdagen van de week definiëren door de optie "Fulltime werkuren gelijkmatig verdeeld over de werkdagen van de week" te selecteren.
Wanneer u deze optie selecteert, verschijnen er velden om fulltime werkuren en dagen te definiëren.
Wat is de optie "Fulltime werkuren gelijkmatig verdeeld over de werkdagen van de week (vóór Versie 0183)" in het vervolg keuzemenu?
Deze optie vertegenwoordigt de huidige overeenkomstconfiguratie die tot deze release bestond. We hebben besloten om deze configuratie actief te houden totdat alle klanten zijn ingeschakeld en gemigreerd naar de nieuwe configuratie die we uitbrengen met Versie 0183.
Hoe verschilt deze configuratie die wordt uitgebracht met release 183 van degene die we vandaag hebben (vóór 183)?
Het verschil zit hem in hoe de gedefinieerde uren in Quinyx worden weerspiegeld in werknemersstatistieken en bij het werken met absentieroosters met behulp van de nominale uren aanpassing.
Hoe beïnvloedt het parttime percentage de uren die ik heb toegevoegd op de werkdagen?
Het parttime percentage van de werknemer zal op dezelfde manier werken als vandaag. Het percentage wordt toegepast op de gedefinieerde uren op de werkdagen van de week.
Voorbeeld:
Als, in de afbeelding hierboven, de voltijdse werkuren zijn gedefinieerd als 24 uur, met een parttime percentage van 50%, zou de werknemer 12 verwachte nominale uren hebben voor die week.
Hoe worden mijn geconfigureerde uren weerspiegeld in de werknemersstatistieken in de roosterview?
Laten we aannemen dat onze voorbeeldwerknemer 24 werkuren per week heeft gedefinieerd in 3 werkdagen.
Omdat het contract van de werknemer niet aangeeft welke 3 dagen tijdens de week werkdagen zijn, introduceren we met onze nieuwe logica een meer flexibele benadering waarbij de 3 werkdagen tijdens de week kunnen verschuiven afhankelijk van het werkschema van de werknemer.
De logica werkt als volgt:
- Nominale uren per werkdag zijn 8 uur, wat de gelijke verdeling is van 24 uur over 3 werkdagen.
- Als de werkweek van de werknemer nog leeg is (de werknemer is nog niet ingeroosterd om te werken), worden er 8 dagelijkse nominale uren toegewezen op de eerste drie dagen van de week (maandag, dinsdag en woensdag). Andere weekdagen zullen 0 toegewezen dagelijkse nominale uren hebben.
- Tijdens het planningsproces, als de werknemer ingeroosterd staat om op een andere 3 dagen van de week te werken, worden de toegewezen 8 nominale uren per dag verplaatst naar die 3 werkdagen.
Voorbeeld:
Ik heb mijn werknemer ingeroosterd om 8 uur te werken op dinsdag, donderdag en zaterdag. De dagelijkse nominale uren worden verplaatst van de eerste toegewezen maandag, dinsdag en woensdag naar de ingeroosterde dinsdag, donderdag en zaterdag, waardoor deze dagen werkdagen worden voor de werknemer.
- Met deze logica stellen we managers in staat flexibiliteit te hebben in het planningsproces om diensten toe te wijzen op een willekeurige 3 dagen van de week voor de werknemers met deze overeenkomstconfiguratie die de werknemersstatistieken aanpast aan het planningsproces.
- Zodra alle 3 dagen gedefinieerd per de overeenkomst zijn ingeroosterd, zullen alle andere dagen in de week 0 nominale uren toegewezen krijgen.
Wat gebeurt er als mijn werknemer ingeroosterd staat om een dienst te werken die over middernacht heen gaat?
In dat geval worden de dagelijkse nominale uren toegewezen aan de dag waarop de dienst begint.
Wat gebeurt er als mijn werknemer geen ingeroosterde dienst heeft maar wel een klokactie heeft?
Als een werknemer alleen een klokactie heeft zonder een geplande dienst, zullen we deze dag ook beschouwen als een "geplande" dag, en dagelijkse nominale uren zullen worden toegewezen volgens de overeenkomst.
Kan mijn werknemer eigenlijk meer werken dan de afgesproken werkdagen van de week?
Ja, Quinyx zal het inplannen van werknemers op meer dagen dan gedefinieerd in hun overeenkomsten niet blokkeren. Afhankelijk van de geconfigureerde overwerk methode, zullen werknemers worden gecompenseerd voor die uren.
Voorbeeld:
Laten we zeggen dat een werknemer gecontracteerd is om 3 dagen te werken voor die week, maar eigenlijk 4 dagen werkt → als u dagelijkse overwerk berekening gebruikt, zal de 4e dag volledig worden beschouwd als overwerk. In dit voorbeeld wordt de 4e dag geteld vanaf het begin van de week, te beginnen op maandag.
Als u wekelijkse/maandelijkse overwerk berekening gebruikt, zal het systeem kijken naar wekelijkse/maandelijkse uren en zullen werknemers worden gecompenseerd afhankelijk van die uren.
Krijgen werknemers de vermindering van uren op feestdagen met deze nieuwe logica?
Ja, met onze nieuwe logica zullen we kijken naar het aantal werkdagen dat is toegevoegd in de overeenkomst en waar die uren zich bevinden in de planning voor die week, volgens dezelfde aanpak als hierboven gedefinieerd.
Voorbeeld:
De werknemer heeft 3 werkdagen en is ingeroosterd om alle 3 dagen te werken (maandag tot en met woensdag).
Als er een feestdag valt op dinsdag en deze feestdag is ingesteld om nominale uren te verminderen, zal die werknemer een feestdagvermindering krijgen omdat dinsdag wordt beschouwd als ingeroosterde dag voor die werknemer.
Als er een feestdag valt op zaterdag, zal die werknemer op zaterdag geen feestdagvermindering ontvangen omdat de gecontracteerde 3 werkdagen al zijn ingeroosterd tijdens die week.
Het is belangrijk om te vermelden dat we zullen kijken naar de configuratie van feestdagen die zijn gebaseerd op het % van nominale uren. Als de feestdagen zijn ingesteld om rekening te houden met de vaste uren, zal deze logica niet van toepassing zijn en zullen de uren altijd worden verminderd op die dag.
Hoe worden mijn geconfigureerde uren weerspiegeld wanneer ik afwezigheden toevoeg met een absentieplanning die de nominale uren aanpast?
Absentieplanningen die aanpassingen hebben op basis van nominale uren zullen altijd rekening houden met de waarden van de werkdagen en werkuren van de werknemer die geconfigureerd zijn in de overeenkomst van de werknemer onder de optie "Fulltime werktijden gelijkmatig verdeeld over de werkdagen van de week".
Wanneer een manager een afwezigheid toevoegt met behulp van een absentieplanning, zullen absentieplanningen worden toegevoegd aan hetzelfde aantal werkdagen zoals gedefinieerd in de overeenkomst van de werknemer. Met onze nieuwe en verbeterde logica zal Quinyx nu rekening houden met het feit of de werknemer al diensten heeft gewerkt tijdens die week en de absentieplanningen zullen worden toegevoegd op andere dagen die zijn gedefinieerd in de overeenkomst.
De dagen geconfigureerd in de configuratie van de absentieplanningen zullen het bereik van de dagen vertegenwoordigen waarop Quinyx absentieplanningen zal toevoegen wanneer de afwezigheid wordt gecreëerd. We raden aan dat absentieplanningen geconfigureerd zijn met alle dagen van de week geselecteerd (maandag-zondag) om maximale flexibiliteit toe te staan.
De logica van de absentieplanningen zal dezelfde aanpak volgen als de werknemersstatistieken, waarbij wordt aangenomen dat de eerste drie dagen van de week werkdagen zijn voor de werknemer.
Laten we hetzelfde voorbeeld van een werknemer gebruiken die 24 werkuren per week heeft gedefinieerd in 3 werkdagen met deze absentieplanning configuratie.
- Als wordt aangenomen dat de werknemer niet ingeroosterd staat om te werken en de afwezigheid met behulp van de absentieplanning voor de hele week is toegevoegd, worden absentieplanningen gegenereerd op de eerste 3 dagen van de week (maandag, dinsdag en woensdag). Elke dag heeft 8 dagelijkse nominale uren toegewezen, waardoor de nominale uren voor de week 24 uur bedragen.
- Als de werknemer op maandag een dienst heeft gewerkt maar daarna ziek werd nadat hij die dag thuis was gekomen van het werk, wordt als gevolg daarvan een afwezigheid met behulp van een absentieplanning toegevoegd voor de rest van de week. Afwezigheidsdiensten worden gegenereerd op dinsdag en woensdag met respectievelijke uren van 8. In dit voorbeeld heeft Quinyx overwogen dat de werknemer al 1 van de 3 werkdagen heeft gewerkt die zijn gedefinieerd in de overeenkomst van de werknemer.
Audit log oorsprong
Vanaf deze release introduceren we het concept van oorsprong in onze huidige auditlogs. Het doel van deze functie is om u extra inzicht te bieden in waar de beoordeelde actie heeft plaatsgevonden. Bijvoorbeeld, bij het beoordelen van een dienst die is aangemaakt, kunt u begrijpen of deze is aangemaakt in het managersportaal of eerder in de mobiele app.
De oorsprongsinformatie bevindt zich in kleinere tekst onder de hoofdwaarde in de kolom "Actie uitgevoerd door" van de weergave, zoals aangegeven in de afbeelding hieronder.
De tabel hieronder bevat een uitgebreide lijst van de verschillende oorsprongswaarden die u kunt tegenkomen tijdens het doorzoeken van uw logboek zoekresultaten, evenals de gevallen waarin deze waarden worden weergegeven. De logica in de oorsprongsbenaming is bedoeld om u te ondersteunen bij het oplossen van geschillen of problemen met betrekking tot de planning en aanwezigheid en is als volgt:
- In de meeste gevallen weerspiegelt het het Quinyx "platform" waar de actie is geactiveerd, zoals het Managersportaal, Mobiel, Webpunch of Integratie.
- Echter, als de actie is geactiveerd door een specifieke functie die een waterval effect heeft op andere delen van Quinyx, zoals het wijzigen van de basisunit van een werknemer of het beëindigen van hun dienstverband, dan wordt dit weergegeven als oorsprong.
Actie | Oorsprong | Zaak/zaken |
Creatie | Via Managersportaal | Wanneer een dienst wordt aangemaakt in de planning in het managersportaal. |
Creatie | Via basisrooster uitrol | Wanneer een dienst wordt aangemaakt in de planning als gevolg van een basisrooster uitrol. |
Creatie | Door absentie |
|
Creatie | Door absentie met behulp van absentieplanning | Wanneer een absentie wordt aangemaakt met behulp van een absentieplanning en als gevolg daarvan bestaande dienst(en) in de planning worden verwijderd en later dezelfde absentie wordt verwijderd, en de gebruiker kiest om de diensten te herstellen, worden de diensten die werden verwijderd toen de absentie werd aangemaakt opnieuw aangemaakt. |
Creatie | Via Mobiel |
|
Creatie | Via integratie | Wanneer een dienst wordt aangemaakt via een integratie, of het nu is via onze SOAP API's of - in de toekomst - REST API's. Wat betreft auto-assign en auto-scheduling: Raadpleeg de beschrijving boven deze tabel. |
Update | Via Managersportaal | Wanneer een dienst wordt bijgewerkt in de planning in het Managersportaal. |
Update | Via basisrooster uitrol | Wanneer een dienst wordt bijgewerkt in de planning door een basisrooster her-uitrol. |
Update | Vanwege absentie |
|
Bijwerken | Vanwege de functie "Diensten bijwerken" | Wanneer een dienst wordt bijgewerkt als gevolg van de functie Diensten bijwerken in Accountinstellingen of Groepsinstellingen. |
Bijwerken | Vanwege werknemersverwijdering | Wanneer een dienst niet is toegewezen omdat een werknemer is verwijderd. Let op dat in dit geval de eigenschap Staat van salaristyperingen die goedkeuring vereisen nul wordt als gevolg hiervan. |
Bijwerken | Via Mobiel |
|
Bijwerken | Vanwege logica voor overeenkomstselectie | Wanneer de overeenkomst van de dienst wordt bijgewerkt volgens een van de gevallen waarin Quinyx zijn overeenkomst selectie logica toepast (zoals beschreven hier). |
Bijwerken | Vanwege einde van dienstverband | Wanneer een dienst niet is toegewezen als gevolg van de wijziging van de einddatum van het dienstverband van de toegewezen persoon, vóór de startdatum van de dienst. |
Bijwerken | Vanwege wijziging van de basisunit | Wanneer de basisunit van een werknemer wordt gewijzigd, betekent dit dat de volgende veranderingen worden getriggerd als gevolg van het systeem:
|
Bijwerken | Vanwege verwijdering van overeenkomst | Wanneer de overeenkomst die wordt gebruikt voor een bepaalde dienst wordt verwijderd. |
Bijwerken | Vanwege goedkeuring van het ontkoppelen van een dienst / Via Managersportaal | Wanneer de eigenschap van een dienst van een werknemer wordt gewijzigd als gevolg van een verzoek tot goedkeuring van het ontkoppelen van een dienst. Let op dat specifiek voor logacties vóór 20 maart 2024 de tekst "Via Manager portaal" wordt gebruikt vanwege technische beperkingen. |
Bijwerken | Vanwege goedkeuring van het boeken van een dienst / Vanwege verzoek tot boeken van een dienst | Wanneer de eigenschap van een dienst van werknemer wordt gewijzigd als gevolg van het goedkeuren van het boeken van een dienst. Let op dat specifiek voor logacties vóór 20 maart 2024 de tekst "Vanwege verzoek tot boeken van een dienst" wordt gebruikt vanwege technische beperkingen. |
Bijwerken | Vanwege goedkeuring van de toewijzing van een dienst aan een andere unit / Vanwege boekingsverzoek | Wanneer de eigenschap van een dienst van een werknemer wordt gewijzigd als gevolg van een basisunit manager die het verzoek van een unitmanager van een andere unit goedkeurt om een werknemer toe te wijzen. Let op dat specifiek voor logacties vóór 20 maart 2024 de tekst "Vanwege boekingsverzoek" wordt gebruikt vanwege technische beperkingen. |
Bijwerken | Vanwege goedkeuring van dienstwissel / Vanwege verzoek tot dienstwissel | Wanneer de eigenschap dienst van de werknemer wordt gewijzigd vanwege goedkeuring van een dienstwissel door de manager. Let op dat specifiek voor logacties vóór 20 maart 2024 de tekst "Vanwege verzoek tot dienstwissel" wordt gebruikt vanwege technische beperkingen. |
Bijwerken | Vanwege herberekende salarisuitkomst | Wanneer een salarisberekening wordt geactiveerd door bepaalde acties in de planning, wat leidt tot de update van de "Status van salaristypen die goedkeuring vereisen" van een dienst naar "Niet goedgekeurd". Een voorbeeld van een actie in Planning die de salaris herberekening kan activeren, is het openen van de tijdskaart in Planning. Let op dat dit alleen de berekening activeert, de daadwerkelijke oorzaak van de wijziging zal eerder te wijten zijn aan een verandering in de instellingen geconfigureerd in Quinyx om de salarisoutput van de werknemer te beïnvloeden. |
Update | Via integratie | Wanneer een dienst wordt bijgewerkt via een integratie, of het nu via onze SOAP API's is of - in de toekomst - REST API's. Wat betreft auto-assign en auto-schedule: Raadpleeg de beschrijving boven deze tabel. |
Verwijdering | Via Managersportaal | Wanneer een manager een dienst verwijdert in de planning in het managersportaal. |
Verwijdering | Via basisrooster uitrol | Wanneer een dienst wordt verwijderd in de planning bij een basisrooster her-uitrol. |
Verwijdering | Via Mobiel | Wanneer een manager een dienst verwijdert in Mobiel. |
Verwijdering | Vanwege absentie | Wanneer een dienst wordt verwijderd als gevolg van het toevoegen van een absentie. Let op dat dit gebeurt in de volgende gevallen:
|
Verwijdering | Via integratie | Wanneer een dienst wordt verwijderd met behulp van een integratie, of het nu is via onze SOAP API's of - in de toekomst - REST API's. Wat betreft auto-assign en auto-schedule: Raadpleeg de beschrijving boven deze tabel. |
Momenteel wordt de oorsprong weergegeven voor de acties met betrekking tot het itemtype "dienst". U kunt verwachten dat oorsprongsinformatie voor de overige itemtypes in de komende maanden wordt vrijgegeven.
Updates en prestatieverbeteringen
Diensten bijwerken - nieuw en verbeterd!
Vanwege noodzakelijk onderhoud en technische beperkingen hebben we wat tot nu toe bekend stond als de functies Diensten bijwerken en Regels toepassen samengevoegd. Vanaf deze release zullen de functionaliteiten die verband houden met deze legacy-functies te vinden zijn door te navigeren naar Accountinstellingen > Diensttypes > Diensten bijwerken en Groepsinstellingen > Diensttypes > Diensten bijwerken respectievelijk.
In Quinyx, wanneer een diensttype wordt bewerkt in Accountinstellingen > Diensttypes En Groepsinstellingen > Diensttypes respectievelijk, de bewerkingen die zijn uitgevoerd zullen worden weerspiegeld in alle diensten (en taken, indien van toepassing) die vanaf dat moment in de tijd worden aangemaakt. Het doel van de Diensten bijwerken functie is om genoemde bewerkingen - of een deel van genoemde bewerkingen - door te voeren naar bestaande diensten in de Planning en/of Basisrooster. Het Diensten bijwerken paneel stelt u in staat om de exacte subset van bestaande diensten - verleden of toekomst - die u wilt bijwerken te specificeren.
De volgende criteria zijn beschikbaar om aan te geven welke diensten u wilt bijwerken.
Veld | Omschrijving |
Groepen | Deze boomstructuur stelt u in staat om te selecteren naar welke groepen u uw diensttypebewerkingen wilt doorvoeren. Gebruik de selectievakjes van de boomstructuur van groepen om dit te selecteren. U kunt het vrije tekstveld gebruiken om items in de boomstructuur gemakkelijker te vinden. De boomstructuur is standaard ingeklapt. Onder het vrije tekstveld worden respectievelijk het aantal districten, units en secties weergegeven die zijn geselecteerd.
Als u deze functie benadert vanuit accountinstellingen, kunt u elke groep of groepen in het account selecteren. Als u deze benadert vanuit groepsinstellingen, kunt u de momenteel geselecteerde groep in de groepselector van de navigatiebalk selecteren, evenals eventuele onderliggende groepen*.
De standaardwaarde voor dit veld is de groep die momenteel is geselecteerd in de groepselector van de navigatiebalk, evenals al zijn onderliggende groepen (indien van toepassing).
Het deselecteren van een oudergroep deselecteert ook al zijn onderliggende groepen. Het selecteren van een groep selecteert automatisch al zijn onderliggende groepen. Let op dat u op eigen initiatief alle genoemde onderliggende groepen kunt deselecteren. |
Diensttype | Selecteer de diensttypes waarvoor u de actie wilt uitvoeren. Door het selectievakje "Alle diensttypes selecteren" aan te vinken, selecteert u alle diensttypes in één keer. |
Van | Van toepassing op diensten in de planning: Selecteer - door te typen of door te klikken - de startdatum vanaf wanneer u wilt dat uw diensttype-aanpassingen worden doorgevoerd in de planning |
Tot | Van toepassing op diensten in de planning: Selecteer - door te typen of door te klikken - de einddatum tot wanneer u wilt dat uw diensttype-aanpassingen worden doorgevoerd in de planning |
Selecteer wat u wilt bijwerken | Selecteer welke specifieke diensteigenschappen u wilt bijwerken. De beschikbare diensteigenschappen om bij te werken zijn:
|
Update salaristyperingsregels alleen voor diensten waarop nog geen regels van toepassing zijn | Dit selectievakje wordt alleen weergegeven als u de optie "Salaristyperingsregels" selecteert in het veld "Selecteer wat u wilt bijwerken" hierboven.
Als u dit selectievakje aanvinkt en op Bijwerken klikt, zal Quinyx de diensten scannen die overeenkomen met uw selectiecriteria en identificeren welke diensten waarop nog geen salaristyperingsregels van toepassing zijn niet overeenkomen met het type dienst. Vervolgens worden eventuele ontbrekende salaristyperingsregels toegevoegd aan deze diensten.
Dit is een oudere functie, geïmplementeerd met de bedoeling om u zelfservice-mogelijkheden te bieden om een (nu opgelost) terugkerende bug in ons systeem met betrekking tot salaristyperingsregels op te lossen. Tot nader order kunt u deze functie naar eigen inzicht gebruiken. |
Selecteer waar u wilt bijwerken | Dit gedeelte van het formulier stelt u in staat te selecteren of u alleen diensten in de Planning wilt bijwerken, of ook in het Basisrooster; en zo ja, welke basisroosters. Door het selectievakje "ouder" van het Basisrooster aan te vinken, worden alle basisroosters geselecteerd. Let op dat de basisroosters die in de lijst worden weergegeven alleen die zijn die minstens één dienst bevatten die overeenkomt met de rest van uw selectiecriteria van het betreffende formulier. Let op dat basisroosters met onopgeloste waarschuwingen niet kunnen worden bijgewerkt en daarom verschijnen met grijs weergegeven tekst samen met de tekst "Kan niet worden bijgewerkt omdat basisroosterwaarschuwingen niet zijn opgelost." |
Zodra u klaar bent met het selecteren van uw bijwerkingscriteria, klikt u op "Bijwerken" onderaan het paneel. Zodra de update is voltooid, verschijnt er een meldingstoaster die het succes aangeeft:
Als uw selectie van diensten groot is, zal het laden waarschijnlijk enige tijd in beslag nemen en blijft het paneel Update diensten open terwijl een draaiend wiel wordt weergegeven boven op de knop Update . U kunt van dit scherm weg navigeren - of een andere tab openen in uw browser - en terugkomen bij de Update diensten. Let echter op dat als u dit doet, de eerder genoemde meldingstoaster niet wordt weergegeven bij voltooiing van de update, noch worden uw selecties per velden weergegeven. Dit is iets wat we in de loop van de tijd willen verbeteren.
Als er fouten optreden met betrekking tot de update, zal de tekst in de toaster lezen "Niet alle diensten zijn bijgewerkt. Probeer het opnieuw." De redenen voor een dergelijke fout kunnen bijvoorbeeld zijn dat een andere gebruiker in uw organisatie probeert een basisrooster uit te rollen dat deel uitmaakt van uw bijwerkingscriteria terwijl u de Update diensten invult Formulier. Let op dat in dergelijke gevallen, u zo vaak als u wilt kunt updaten.
Toestemmingen
In Quinyx hebben gebruikers schrijftoegang nodig tot de toestemming "Diensttypes" om van deze functie gebruik te kunnen maken. Sinds pre-Versie 0183, controleerde de toestemming "Regels toepassen" niet of gebruikers salaristyperingsregels konden bijwerken, maar specifiek of ze gebruik konden maken van de functie "Alleen salaristyperingsregels bijwerken voor diensten waarop nog geen regels zijn toegepast", we verzamelen momenteel feedback over hoe we deze toestemming het beste kunnen evolueren. Voel u vrij om ons feedback te sturen via de knop "Stuur ons feedback".
Samenvatting van wijzigingen in functionaliteit als gevolg van de update van Versie 0183
- Voorheen bood Quinyx één functie genaamd Update diensten en één genaamd Regels toepassen. Deze zijn nu samengevoegd tot één, waarbij nog steeds dezelfde gevallen worden ondersteund als voorheen - en meer.
- Met name: voorheen zouden Update diensten verzoeken soms time-out geven. Dit zou meestal - maar niet uitsluitend - gebeuren als u als gebruiker een te grote selectie van diensten had geselecteerd waar het systeem mee om moest gaan. Nu gebruikt Quinyx asynchrone polling om ervoor te zorgen dat uw verzoek wordt uitgevoerd. Let op dat dit niet betekent dat u geen fouten kunt krijgen, maar dit zal niet zijn omdat het systeem niet in staat is om de enorme hoeveelheid diensten die u heeft geselecteerd te verwerken.
- Voorheen, als u een basisrooster had geselecteerd met onopgeloste uitrolwaarschuwingen in "Selecteer waar bij te werken" en op bijwerken klikte, zou Quinyx u informeren dat er iets mis was gegaan, wat betekende dat u vast kon komen te zitten in een oneindige lus van pogingen om de Opdrachten bijwerken opdracht uit te voeren. Nu worden basisroosters met onopgeloste uitrolwaarschuwingen grijs weergegeven in het gedeelte "Selecteer wat bij te werken" van het formulier, en worden ze vergezeld door verklarende tekst.
- Als gevolg van uw feedback is de instelling voor het type dienst "Pauzes tonen in mobiele app" nu selecteerbaar in het veld "Selecteer wat bij te werken".
- Voorheen kon men "Alles selecteren" voor het selectievakje "Selecteer wat bij te werken". We hebben die optie nu verwijderd als gevolg van frequente meldingen van gebruikers die per ongeluk alle waarden selecteerden, wat leidde tot enorme overhead om deze fout te corrigeren, vooral voor de waarde "diensttijden".
- Voorheen kon men alleen verschillende diensttypes bijwerken als specifiek de salaristyperichtlijnen werden bijgewerkt (via de nu verouderde functie "Regels toepassen") - dit is nu ook mogelijk voor de overige diensteigenschappen.
- Voorheen was het niet mogelijk om bij het openen van Update shifts via Accountinstellingen alleen een subset van groepen te selecteren waarvoor diensten moesten worden bijgewerkt. Dit is nu mogelijk met behulp van de groepenboom.
- Voorheen werd in het gedeelte "Selecteer waar bij te werken" van het paneel het aantal diensten dat zou worden bijgewerkt op basis van uw huidige selectie weergegeven tussen haakjes onderaan het paneel voor Planning en voor Basisrooster respectievelijk. Helaas had dit een zeer negatief effect op de prestaties, waardoor we genoodzaakt waren om deze telling te verwijderen.
- Zie de kop Machtigingen boven het gedeelte dat u momenteel leest.
Compliance checker
Controle van naleving voor planning
Bij het controleren van de naleving van de planning heeft u nu de mogelijkheid om afwezigheidsdiensten in overweging te nemen. Dit is vooral handig wanneer u wilt zien of een gebruiker enige regels heeft overtreden voordat ze afwezig waren, bijvoorbeeld door ziekteverzuim.
Als voorbeeld: een gebruiker mag niet meer dan drie diensten achter elkaar ingepland worden. In eerste instantie was deze gebruiker ingepland voor vier diensten achter elkaar, wat een overtreding zou moeten opleveren. Maar bij de derde dienst meldde de gebruiker zich ziek. Met de nieuwe optie zal er een overtreding worden gemeld, terwijl dit voorheen niet het geval was. Let op dat deze optie standaard is uitgeschakeld en handmatig moet worden ingeschakeld.
Controleren van naleving van gewerkte uren
We hebben enkele verbeteringen aangebracht in het controleren van hoe een werknemer heeft gewerkt tijdens een dienst. Voor deze release controleerden we elke klokactie afzonderlijk, wat kon leiden tot onjuiste overtredingen in bepaalde situaties. Met de verbetering evalueren we nu alle klokacties die bij dezelfde dienst horen, wat de nauwkeurigheid van het controleren van overtredingen aanzienlijk zou moeten verhogen.
Ondersteuning van lokale diensttypes in Optimale Personeelsbezetting en Arbeidsnormen
Quinyx kan nu ook lokale diensttypes ondersteunen, en niet alleen globale diensttypes, in optimale personeelsbezetting en arbeidsnormen bij het selecteren van het diensttype waar de specifieke rol/personeelsbezetting betrekking op heeft. Dit zal klanten die zowel globale als lokale diensttypes gebruiken in staat stellen om hun personeel nauwkeurig in te plannen en hun arbeidsbehoeften te bepalen.
Bij het creëren van de optimale personeelsbezetting op basis van lokale diensttypes worden alleen de units en secties teruggegeven die betrekking hebben op het lokale dienstype in de groepstructuur bij het configureren van arbeidsnormen. Dit zorgt ervoor dat er geen units kunnen worden geselecteerd waar de lokale diensttypes niet bestaan, en het is duidelijker welke specifieke units bij het lokale dienstype horen.
Bug fixes
- Een probleem opgelost dat ervoor zorgde dat het sectieveld in het Bewerk diensttype modal niet werd bijgewerkt.
- Een probleem opgelost waarbij de informatieboodschap "afstandsverklaring ondertekend" niet verscheen en de premie niet werd verwijderd bij het uitklokken binnen specifieke uren waarin afstandsverklaringen actief waren, ondanks de instellingen voor maaltijdpauzes en eenmalige afstandsverklaringen die waren ingeschakeld.
- Een probleem opgelost dat een manager ervan weerhield om een klokactie op een dienst op een specifieke datum goed te keuren.
- Een probleem opgelost dat afrondingsverschillen veroorzaakte in het Gedetailleerde pauzes en taken rapport.
- Een probleem opgelost dat ervoor zorgde dat het Gedetailleerde pauzes en taken rapport mislukte als er klokacties waren zonder de dienst in de gefilterde periode.
Nieuwe Quinyx HelpDocs inhoud
HelpDocs artikelen
Interactieve tutorials
Frontline Portal Versie 0183
Releasedatum 3 april 2024
Nieuwe functionaliteit
Alles-in-één login voor gebruikers van alleen Frontline Portal
Voor gebruikers op het Quinyx All-in-one platform (AIO) die alleen de Frontline Portal gebruiken, dus NIET Workforce Management (WFM), hebben we een aantal verbeteringen aangebracht in het inlogproces.
- De gebruiker logt hier zoals gewoonlijk in bij Quinyx:
- De gebruiker wordt rechtstreeks naar de homepage van Frontline Portal geleid:
- Gebruikers met rechten voor Gebruikersbeheer kunnen naar Quinyx WFM navigeren via Instellingen > Gebruikersbeheer.
- De gebruiker wordt dan doorverwezen naar het tabblad Quinyx WFM People.
- Hier kunnen ze gebruikersgegevens bijwerken, d.w.z. de naam, het e-mailadres, het wachtwoord enz. van een gebruiker. Dit doen ze door de gebruiker te selecteren van wie ze de gegevens willen wijzigen, hun gegevens bij te werken en vervolgens Opslaan te selecteren.
- Om terug te gaan naar het Frontlineportaal moet de gebruiker Profiel > Overschakelen naar Frontline Portal selecteren.
Updates en prestatieverbeteringen
Geen op dit moment.
Bug fixes
- Een probleem opgelost dat ervoor zorgde dat bestanden niet correct werden weergegeven op het platform.
- Een probleem opgelost dat ervoor zorgde dat lege widgets niet verdwenen van de startpagina.
Nieuwe Frontline Portal HelpDocs inhoud
HelpDocs artikelen
- Geen op dit moment.
Interactieve tutorials
- Geen op dit moment.
SOAP API / Webservice updates
- Geen op dit moment.
- Er zijn momenteel geen eindpunten verouderd en gepland voor verwijdering.Klik hier om de nieuwe Quinyx WFM Web Service documentatie te bekijken. U kunt nog meer informatie over webdiensten vinden hier.We moedigen al onze klanten aan om gebruik te maken van onze API's om gegevens te onderhouden en ervoor te zorgen dat informatie up-to-date is. Om de schaalbaarheid van onze API's te waarborgen terwijl we onze klanten- en gebruikersbasis laten groeien, hebben we besloten beperkingen toe te voegen aan het gebruik van onze SOAP API's. Deze beperkingen zullen programmatisch worden afgedwongen, wat betekent dat we een limiet zullen opleggen aan gelijktijdige oproepen per klant tot 10 U moet een reactiecode 429 verwachten als u deze limiet overschrijdt, en het wordt aanbevolen om een backoff retry-mechanisme te implementeren om met de limiet om te gaan. Let op dat de limiet alleen van toepassing is op SOAP. Bij de overgang van SOAP naar Rest in de komende jaren zullen eventuele limieten in de API worden ingebouwd.
Zorg ervoor dat u deze informatie doorstuurt naar de partij binnen uw bedrijf die verantwoordelijk is voor integraties.
