Versie 0154

Updated by Leigh Hutchens

Vanaf 17 februari is de ondersteuning voor ATS-terminals beëindigd en zullen de terminals stoppen met werken. Alle klanten die de terminals hebben gebruikt, zijn geïnformeerd en hebben nieuwe oplossingen geïmplementeerd.
De geplande wijzigingen in het loonbestand zijn vrijgegeven op 23 februari 2023.

Releasedatum 28 februari 2023

Samenvatting vrijgeven

Weinig tijd en een samenvatting op hoog niveau?

Web applicatie

  • Goedkeuringsstroom plannen (derde release): voor deze release schakelen we ondersteuning in voor goedkeuring op twee niveaus in de workflow.
  • Beschikbaarheid in de slimme lijst: Werknemers die Beschikbaarheid hebben toegevoegd via de mobiele app en gewenste werktijden hebben opgegeven, verschijnen in de lijst met een nieuwe “Beschikbaarheid”-badge.
  • We hebben de logica voor de aanpassingsoptie "Werkgelegenheidsgraad" van het afwezigheidsschema bijgewerkt.
  • Optimale personeelsvariabelen bestaan nu ook op de prognosepagina.

SOAP API / Webservice-updates

  • Geen updates in deze release

Bugfixes

  • We hebben enkele dingen aangepast die te klein zijn om op te merken of te moeilijk om uit te leggen. Als je echt meer details wilt, klik dan hier .

Nieuwe functionaliteit

Goedkeuringsstroom plannen (derde release)

Met deze release gaan we door met het bouwen van onze planningsgoedkeuringsstroom. De onderliggende zakelijke behoefte die we vanaf deze release mogelijk maken, is ondersteuning voor goedkeuring op twee niveaus in de workflow. Deze behoefte komt van onze Duitse klanten, voornamelijk degenen die een ondernemingsraad in hun bedrijf hebben. In hun geval zou de ondernemingsraad, na goedkeuring door de manager, als tweede niveau de eerlijkheid van de werkroosters en andere arbeidsrechtelijke regels controleren. Daarna zouden ze het schema definitief goedkeuren.

Opgericht

Activering van deze workflow wordt geplaatst in de geavanceerde eenheidsinstellingen van de eenheid. Onder "Overig." subsectie is er een vervolgkeuzelijst met de naam Planningsgoedkeuring. Als u de workflow op twee niveaus wilt activeren, selecteert u "Goedkeuring in twee stappen" en wijst u rollen toe die verantwoordelijk zijn voor de goedkeuring.

In het goedkeuringsproces nemen we alle mensen op die een rol hebben (direct of geërfd) op die eenheid en leestoegang op planningsrechten.

Deze volgorde is hiërarchisch , wat betekent dat het verzoek om goedkeuring van het schema naar het eerste niveau gaat en vervolgens naar de fiatteur van het tweede niveau.
Planner vraagt goedkeuring en publicatie

Vanuit het perspectief van een planner blijft de stroom hetzelfde als bij de goedkeuringsstroom op één niveau. Door te klikken op Goedkeuring aanvragen en publiceren wordt een nieuw venster geopend waarin de planner de periode kan selecteren die moet worden goedgekeurd en gepubliceerd. Door op de knop Verzoek verzenden te klikken, wordt de toegewezen eerstelijns goedkeurder op de hoogte gebracht van het lopende verzoek.

Feedback geven op het herziene schema - eerste niveau

Vanuit het perspectief van een fiatteur op het eerste niveau blijft de stroom hetzelfde als in de eerste release. Het enige verschil is dat in dit geval, nadat de fiatteur op het eerste niveau de planning heeft goedgekeurd, er een melding wordt verzonden naar de fiatteur op het tweede niveau. Het schema wordt pas gepubliceerd als de goedkeurder op het tweede niveau feedback geeft. We hebben een bericht toegevoegd onder het commentaarveld waarin de stroom wordt uitgelegd.

Feedback geven op het herziene rooster - tweede niveau

De goedkeurder op het tweede niveau gebruikt dezelfde sectie 'Te goedkeuren schema's' in het meldingenvenster. In dat gedeelte zullen we lopende verzoeken weergeven met de informatie - wie de goedkeuring heeft aangevraagd, voor welke periode en wanneer dat verzoek is verzonden. We zullen ook informatie verstrekken over goedkeuring op het eerste niveau.

Na het bekijken van het rooster en ervoor te zorgen dat het is gemaakt in overeenstemming met arbeidswetten en -regelgeving, kan de goedkeurder op het tweede niveau feedback geven aan de planner door het verzoek goed te keuren of te weigeren. Als het verzoek wordt goedgekeurd, zorgt die actie er ook voor dat het rooster voor die geselecteerde periode wordt gepubliceerd aan de werknemers. Als het verzoek wordt afgewezen, moet de goedkeurder de noodzakelijke wijzigingen doorgeven aan de planner om de planning goed te keuren.

Communicatie tussen planners en goedkeurders wordt ondersteund met geautomatiseerde Qmail s. Omwille van de transparantie wordt feedback van het tweede niveau (goedkeuring of weigering) naar zowel de planner als de goedkeurder van het eerste niveau gestuurd.

Beschikbaarheid in de slimme lijst

We brengen deze verbetering uit op basis van de feedback die we hebben ontvangen na het vrijgeven van de beschikbaarheidsfunctionaliteit een paar maanden geleden. Met deze verbetering helpen we managers die volgens een rooster werken om diensten op de meest efficiënte manier toe te wijzen.

Medewerkers die Beschikbaarheid hebben toegevoegd via de mobiele app en de gewenste werkuren hebben opgegeven, verschijnen in de lijst met een nieuwe "Beschikbaarheid"-badge. Deze medewerkers verschijnen bovenaan de lijst. Als meerdere werknemers Beschikbaarheid voor dezelfde uren hebben toegevoegd, wordt er tussen hen gesorteerd op basis van de overeenkomende/ontbrekende vaardigheden die werknemers hebben voor die specifieke dienst.

Om verwarring te voorkomen, hebben we de bestaande badge 'Beschikbaar' hernoemd naar 'Beschikbaar voor planning'. Deze badge vertegenwoordigt alle werknemers die in die dienst kunnen worden ingepland, maar die geen Beschikbaarheid of een Kennisgeving van interesse hebben.

Updates en prestatieverbeteringen

Bijgewerkte logica voor de aanpassingsoptie "Werkgelegenheidspercentage" van het afwezigheidsschema

In de afgelopen paar jaar zijn er talloze keren geweest dat gebruikers contact met ons opnamen om te melden wat volgens hen een bug was met betrekking tot de aanpassingsoptie "Werkgelegenheidspercentage" van het afwezigheidsschema.

Het probleem was dat hoewel velen van jullie verwachtten dat het systeem de volgende logica zou toepassen:

Afwezigheidsschema dienstduur* x De opgegeven arbeidsparticipatie van de werknemer

Het systeem paste de facto de volgende logica toe:

Als de ploeglengte van het verzuimschema korter is dan de nominale uren van de gegeven werknemer, gebruik dan ploeglengte * toegepaste arbeidsparticipatie. Als de dienstduur van het verzuimschema echter meer is dan de nominale uren, gebruik dan de nominale uren * arbeidsparticipatie.

Vanaf deze release brengen we een verbeterde versie uit van de optie voor het aanpassen van het werkgelegenheidspercentage, als een manier om de hoofdoorzaak van deze vermoedelijke bugrapporten onder ogen te zien. Als zodanig zal de logica voor de aanpassingsoptie voor arbeidsparticipatie in de toekomst zijn:

A afwezigheid rooster dienstduur x De gegeven arbeidsparticipatie van de werknemer

Voorbeeld: De duur van de dienst voor het afwezigheidsschema is gedefinieerd als 9.00 - 17.00 uur. De arbeidsparticipatie van uw werknemer Anna is slechts 50%. De afwezigheidsdienst die wordt gemaakt wanneer u een afwezigheid aanmaakt met behulp van dit afwezigheidsschema voor Anna is 9.00 - 13.00 uur, ervan uitgaande dat de afwezigheid die u maakt de duur van de afwezigheidsplanningsdienst overlapt zoals hier beschreven.

Houd er rekening mee dat, aangezien al onze klanten zouden worden gedwongen om gebruik te gaan maken van deze nieuwe logica, het risico van een foutieve salarisadministratie met zich mee zou brengen, hebben we een afschrijvingsstrategie aangenomen. Dit betekent dat voor elk afwezigheidsschema dat vóór 0154 is gemaakt en dat gebruikmaakt van de optie arbeidsparticipatie, u actief moet overschakelen van de oude logica ("werkgelegenheidsgraad (oude logica)") naar de nieuwe ("werkgelegenheidsgraad").

Als u overstapt van de optie arbeidsparticipatie (oude logica) naar een andere logica, informeren we u ook duidelijk over de wijziging die u doorvoert:

Zoals vermeld in de bovenstaande schermafbeeldingen, zullen we niet langer de oude logica behouden. Dit betekent dat u het tot nader order kunt blijven gebruiken, maar dat we in de toekomst geen bugs zullen oplossen die zich voordoen in de oude arbeidsparticipatieoptie . Daarom raden we u aan om, als dit op u van toepassing is, zo snel mogelijk over te stappen op de nieuwe logica voor aanpassing van de werkgelegenheidsgraad.

* Met afwezigheidsschema ploeglengte verwijzen we naar de ploeglengte zoals gedefinieerd in de modaliteit Dag en tijd:

Optimale bezettingsvariabelen op prognosepagina

We hebben nu de mogelijkheid toegevoegd om Optimaal personeelsbestand ook te visualiseren in de prognosegrafiek en tabellen, en niet langer alleen in Schemastatistieken. U kunt visualisatie van variabelen voor optimale personeelsbezetting inschakelen door ze toe te voegen aan de juiste weergavegroepen en visualisatie voor Forecast in te schakelen.

Bugfixes

  • Een probleem opgelost met het rapport Geslagen uren waardoor het totaaloverzicht in planningsstatistieken onjuist werd berekend.
  • Een probleem opgelost met salarissoorten die werden toegevoegd aan afwezigheden waardoor het "afhankelijk van dagnummer" standaard werd uitgevinkt.
  • Een probleem opgelost dat ervoor zorgde dat "Interne serverfout"-berichten voor sommige klanten verschenen bij het toevoegen van diensten.
  • Een probleem opgelost met het SOAP-eindpunt wsdlSend Qmail waardoor de afzender een kopie van de verzonden Qmail in zijn inbox ontving.
  • Een probleem opgelost waarbij de datumkiezers niet volledig zichtbaar waren bij het uitvoeren van Automatisch plannen of Automatisch toewijzen.

Nieuwe HelpDocs-artikelen

SOAP API / Webservice-updates

  • Geen updates in deze release

Er zijn momenteel geen eindpunten verouderd of gepland voor verwijdering.

Klik hier om de nieuwe Quinyx WFM Web Service-documentatie te bekijken. U kunt hier nog meer informatie over webservices vinden.
We moedigen al onze klanten aan om onze API's te gebruiken om gegevens te onderhouden en ervoor te zorgen dat informatie up-to-date is. Om de schaalbaarheid van onze API's te garanderen en tegelijkertijd ons klanten- en gebruikersbestand te laten groeien, hebben we besloten om beperkingen toe te voegen aan het gebruik van onze SOAP API's. Deze beperkingen worden programmatisch afgedwongen, wat betekent dat we een limiet voor gelijktijdige gesprekken per klant opleggen tot 10 . U kunt responscode 429 verwachten als u deze limiet overschrijdt en u wordt aangeraden een backoff-mechanisme voor opnieuw proberen te implementeren om de limiet te verwerken. Merk op dat de limiet alleen van toepassing is op SOAP. Bij de overstap van SOAP naar Rest in de komende jaren worden eventuele limieten in de API ingebouwd.

Zorg ervoor dat u deze informatie doorstuurt naar de partij binnen uw bedrijf die verantwoordelijk is voor de integraties .

How did we do?