Versie 0159

Updated by Daniel Sjögren

Releasedatum 3 mei 2023

Samenvatting vrijgeven

Weinig tijd en een samenvatting op hoog niveau?

Aankondiging

Wijzigingen in aggregatieberekening van berekende variabelen

  • We zijn momenteel van plan om dit uit te brengen in versie 0160.

Web applicatie

Nieuwe functionaliteit

  • Mobiele apps bieden meldingsondersteuning voor beschikbaarheid die is gekoppeld aan nieuwe niet-toegewezen ploegen.
    • Herinnering om Beschikbaarheid te gebruiken in plaats van Kennisgeving van interesses.

Updates en prestatieverbeteringen

  • Afwezigheid All-Day checkbox logica wijziging.
  • Betere planningservaring met verbeterde waarschuwingsberichten.
  • Verhoging van de looptijd van het algoritme vóór status Onbekend resultaat .

SOAP API / Webservice-updates

  • Geen updates in deze release.

Bugfixes

  • Mogelijk bent u geïnteresseerd in een van onze bugfixes in deze release.

Aankondiging

Wijzigingen in aggregatieberekening van berekende variabelen - release gepland in versie 0160

We werken momenteel aan het verwijderen van inconsistenties in de manier waarop we gegevens verzamelen (elk uur, dagelijks, wekelijks, maandelijks) voor berekende variabelen in Schemastatistieken en prognose . Tot nu toe was de aggregatie in berekende variabelen afhankelijk van het feit of de berekende variabele naast hun primaire invoer één of meerdere operanden heeft. Met een enkele operand worden de granulaire waarden eerst opgeteld en daarna gebruikt in de berekening om een dagtotaal te krijgen. Bij meerdere operanden wordt de berekening uitgevoerd op het laagste granulaire niveau en pas daarna opgeteld.

Waarom is dit een probleem?

Afgezien van het probleem van inconsistenties in de berekeningsmethoden, resulteert het ook in berekende variabelen die bijvoorbeeld procentuele waarden vertegenwoordigen die afhankelijk zijn van meerdere operanden, en uiteindelijk bijvoorbeeld dagelijkse totalen laten zien op basis van optelling en niet op gemiddelde.

Hoe gaat het in de toekomst werken?

We werken aan een wijziging om deze inconsistentie op te lossen door ervoor te zorgen dat de berekening in alle gevallen wordt uitgevoerd op elk detailniveau.

Voorbeeld 1

  • Variabele A (aggregatietype som)
  • Variabele B (aggregatietype gemiddelde)
  • Berekende variabele C: A/B
  • Dagelijks C = dagelijks (som) A / dagelijks (gemiddeld) B

De dagelijkse C-berekening wordt uitgevoerd op basis van de dagelijkse waarden van de onderliggende variabelen.

Voorbeeld 2

  • Variabele A (aggregatietype som)Variabele B (aggregatietype som)
  • Variabele C (aggregatietype som)Berekende variabele D: A+BC
  • Dagelijks D = dagelijks (som) A + dagelijks (som) B - dagelijks (som) C

De dagelijkse D-berekening wordt uitgevoerd op basis van de dagelijkse waarden van de onderliggende variabelen.

Voorbeeld 3

  • Variabele A (aggregatietype som)Berekende variabele B: A+100 (aangepaste invoer)
  • Dagelijks B = dagelijks (som) A + 100

De dagelijkse B-berekening voegt de aangepaste invoer toe zoals gedefinieerd in de berekende variabelen, niet als een som van de optelling van de aangepaste invoer met de laagste granulariteit.

Waarom is dit belangrijk voor u om te weten?

In sommige gevallen zijn tijdelijke oplossingen, bijvoorbeeld aanvullende berekende variabelen, ingevoerd om de juiste dagelijkse berekende variabelewaarden te krijgen. Zodra de wijziging is aangebracht, zijn de tijdelijke oplossingen niet langer nodig en zijn de waarden van de onjuist berekende variabelen consistent.

Nieuwe functionaliteit

Mobiele app - Meldingsondersteuning voor Beschikbaarheid gekoppeld aan nieuwe niet-toegewezen ploegen die zijn gemaakt

We hebben ondersteuning geïmplementeerd voor het ontvangen van een melding wanneer een niet-toegewezen ploeg wordt gemaakt die overeenkomt met een van uw beschikbaarheidsentiteiten. U kunt deze logica inschakelen op de pagina Instellingen van de app en deze volgt dezelfde instelling als de meldingen voor niet-toegewezen diensten die zijn gemaakt die overeenkomen met uw interessemeldingen.

Herinnering - Gebruik Beschikbaarheid in plaats van Kennisgeving van Interesses

We dringen er bij al onze klanten op aan om onze Beschikbaarheidsfunctionaliteit te gaan gebruiken in plaats van Kennisgeving van Interesses. De beschikbaarheidsfunctionaliteit is gebruiksvriendelijker en ondersteunt meer use cases dan onze huidige functie Notice of Interest.

Een functie die beschikbaarheid ondersteunt, is het omzetten van een beschikbaarheidsitem in een dienst als manager in de weergave Planning van de webapp. We ondersteunen ook secties met beschikbaarheid en meervoudige selectie van zowel eenheden als secties bij het creëren van beschikbaarheid als gebruiker. We hebben de mogelijkheid geïmplementeerd voor onze gebruikers om hun eigen beschikbaarheidsuren in onze mobiele apps te zien, aan te maken, te bewerken en te verwijderen. Voor de mobiele apps is de toestemming voor beschikbaarheid standaard uitgeschakeld en moet deze worden ingeschakeld onder Mobile en Staff portal-machtigingen in web.quinyx.com. Informatie over de beschikbaarheidsfunctionaliteit in mobiel vind je hier en voor beheerders hier .

Updates en prestatieverbeteringen

Afwezigheid All-Day checkbox logica wijziging

Als resultaat van feedback die we van velen van jullie hebben ontvangen met betrekking tot de UX-wijzigingen die we hebben aangebracht in het maken van afwezigheid in release 0151 , hebben velen van jullie ons feedback gegeven dat hoewel de wijziging van de standaarddatums op prijs werd gesteld, de standaardstatus van de hele dag checkbox heeft ertoe geleid dat veel afwezigheden onbedoeld voor een enkel uur zijn aangemaakt in plaats van voor een volledige dag zoals bedoeld. Dankzij uw feedback over dit onderwerp hebben we een aanvullende wijziging kunnen doorvoeren waarmee we dit bruikbaarheidsprobleem willen aanpakken.

In de toekomst ziet het selectievakje Hele dag er als volgt uit:

  1. Aangevinkt wanneer u het paneel Afwezigheid toevoegen opent door op een cel in het rooster te klikken.
  2. Aangevinkt wanneer u het paneel Afwezigheid toevoegen opent door op de + in de rechterbovenhoek van het rooster te klikken.
  3. Niet aangevinkt wanneer u het deelvenster Afwezigheid toevoegen opent via de knop onderaan het deelvenster Ploeg bewerken .

Als in gevallen 1 en 2 hierboven dezelfde datum is geselecteerd als start- en einddatum, bijvoorbeeld 25-04-2022, blijven de start- en einddatum hetzelfde wanneer u het selectievakje uitschakelt, terwijl de start- en eindtijden van de afwezigheid zal een interval van een uur zijn. Dit interval van een uur vindt plaats 12 uur na het aanbreken van uw werkdag, dus als de ingestelde werkdag in de instellingen van uw unit 02.00 uur is, dan zijn de standaard afwezigheidstijden 14.00-15.00 uur.

Als in gevallen 1 en 2 hierboven meerdere datums zijn geselecteerd als begin- en einddatum, bijvoorbeeld 25-04-2022 - 30-04-2022, blijven diezelfde datums hetzelfde wanneer u het selectievakje uitschakelt, terwijl de begin- en eindtijden van het verzuim zijn van de werkdag tot de werkdag. Bijvoorbeeld, als de ingestelde werkdag in de instellingen van uw unit 2 uur is, dan zijn de standaard afwezigheidstijden 2 uur - 2 uur.

In geval 3 hierboven is er niets veranderd ten opzichte van voorheen; de standaard datums en tijden weerspiegelen de ploeg waarvoor u de afwezigheid invoert.

Als u verschillende datums selecteert voordat u het betreffende selectievakje uitschakelt, is het bovenstaande gedrag vanwege technische beperkingen helaas niet van toepassing. Dit is iets dat we te zijner tijd willen aanpakken.

Betere planningservaring met verbeterde waarschuwingsberichten

We geven het eerste deel van het initiatief vrij, met als doel het verbeteren van waarschuwingsberichten die aan managers worden gepresenteerd bij het plannen van diensten. We hopen dat managers dankzij deze verbeteringen minder tijd besteden aan het werken in de planningsweergave omdat ze meer informatie hebben over ontbrekende vaardigheden, overschrijding van uren en andere soorten waarschuwingen.

De eerste waarschuwing die we met deze release hebben verbeterd, is er een over ontbrekende werknemersvaardigheden.

Vanaf deze release zal Quinyx in het waarschuwingsbericht informatie geven over welke vaardigheid een medewerker mist voor die dienst. Zo weet de leidinggevende direct welke vaardigheid er gecontroleerd of gecorrigeerd moet worden in de medewerkergegevens voordat de dienst ingepland wordt.

Er is één uitzondering op dit nieuwe waarschuwingsbericht en het is van toepassing op alle gevallen waarin managers waarschuwingen niet hebben opgelost bij het uitrollen van een basisschema. Als waarschuwingen over de uitrol vóór deze release niet zijn opgelost, toont Quinyx het oude waarschuwingsbericht "Employee missing skill(s)" bij het openen van dat basisschema.

Als onderdeel van dit initiatief hebben we ook visueel verbeterd hoe we alle overschrijfbare en niet-overschrijfbare waarschuwingen aan de manager weergeven. We hebben deze verbetering aangebracht omdat we Quinyx gebruiksvriendelijker wilden maken en ook om uit te leggen welke stappen er genomen moeten worden voordat de dienst ingepland wordt. Momenteel is deze nieuwe waarschuwingsmodaliteit alleen van toepassing in de planningsweergave; we hebben plannen om het ook te verbeteren in de basisplanningweergave.

Verhoging van de looptijd van het algoritme vóór de status "Onbekend resultaat"

Binnen Automatisch plannen en Automatisch toewijzen hebben we momenteel een technische limiet voor hoe lang de algoritme-uitvoeringstabellen de status van algoritme-uitvoeringen opvragen om ervoor te zorgen dat de uitvoeringstabellen up-to-date blijven. Deze technische limiet is vereist om prestatieredenen. Algoritme loopt langer dan 30 minuten tot nu "Onbekende resultaten" als status wordt weergegeven, hoewel de algoritme-run is voltooid. We hebben de limiet nu verhoogd naar 90 minuten, zodat elke algoritmerun die binnen 90 minuten is voltooid, de juiste status en looptijd weergeeft.

Updates over maaltijdpauzes

Premiebetalingen

Met deze release introduceren we automatische compensatiebetalingen (dwz boetebetaling/premiebetalingen) in de maaltijdpauzefunctionaliteit. Wat we mogelijk willen maken, is een sneller en minder foutgevoelig beheer van compensatie wanneer een maaltijdpauze niet is voorzien of genomen volgens de regels voor maaltijdpauzes.

Hier leest u alles over het toevoegen van premiebetalingen aan uw regels voor maaltijdpauzes: (link naar subpagina)

UX-wijzigingen voor regels voor maaltijdpauzes

Na wat feedback hebben we de configuratieflow in Quinyx bijgewerkt bij het toepassen van regels voor maaltijdpauzes op bepaalde overeenkomsten. De belangrijkste verandering is dat u in plaats van afspraken toe te passen op de regels in het maaltijdpauzepaneel, u nu de regels in Overeenkomstsjablonen > (nieuw paneel) Maaltijdpauzepremies in de overeenkomstige vervolgkeuzelijst moet toepassen.

Bugfixes

  • Een probleem opgelost waardoor kosten anders werden weergegeven tussen wekelijkse en maandelijkse weergaveselectie. Als gevolg van deze bugfix geven statistieken agenda-items en werknemers weer, ongeacht of een bepaalde werknemer al dan niet een actieve rol heeft.
  • Een probleem opgelost dat ervoor zorgde dat het opnieuw uitrollen van een bewerkt basisschema niet overeenkwam met de bewerkingen in het uitgerold schema.
  • Een probleem opgelost dat een 500-fout veroorzaakte bij het uitvoeren van een API-aanroep voor get-shifts tussen 00.00 - 06.00.
  • Een probleem opgelost met betrekking tot de zomertijd waarbij de tijd inconsistent werd weergegeven in schemastatistieken tussen de tabel en de pop-up telkens wanneer een specifiek gegevenspunt werd geselecteerd. Dit was alleen een probleem op de dag van DST en tijdens het aanbreken van de dag.

Nieuwe HelpDocs-artikelen

Quinyx-artikelen

Herinnering! Als u tweewekelijkse e-mailmeldingen wilt ontvangen over nieuwe releases van de Quinyx-app, kunt u zich hier aanmelden.

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 opleggen voor gelijktijdige oproepen per klant 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 overgang 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?