Versie 0110

Updated 23/6/21 by Leigh Hutchens

Releasedatum 16 juni 2021

Quinyx werkt onvermoeibaar aan het versterken van de informatiebeveiliging en het continu verbeteren van maatregelen om gegevens te beschermen. Als onderdeel van dit werk hebben we ons Informatiebeveiligingsoverzicht bijgewerkt om het beleid, de mechanismen, de stuurprocessen en de organisatiestructuur weer te geven die onze toewijding vormen om uw gegevens te beschermen. De bijgewerkte versie is naast de huidige versie te vinden in het gedeelte Informatiebeveiliging op onze website en is geldig via overeenkomsten 2 maanden vanaf vandaag.
Met betrekking tot het bovenstaande bericht zal Quinyx het huidige wachtwoordbeleid wijzigen in de release van versie 0111, gepland voor 30/6. Het huidige beleid kan worden gevonden hier . Het huidige standaard wachtwoordbeleid wordt verwijderd en de nieuwe standaard wordt vervangen door een gewijzigde hoge versie.

Nieuw wachtwoordbeleidsniveau 30/6 vereist dat alle wachtwoorden:

  • Minimaal 12 tekens lang bevatten (maximaal 128)
  • Minimaal 2 numerieke tekens bevatten
  • Minimaal 2 letters bevatten

Als een manager het wachtwoord van een medewerker reset of als de medewerker ervoor kiest om het wachtwoord opnieuw in te stellen, vereist het systeem dat je een nieuw wachtwoord kiest bij het inloggen.

Het gebruikersaccount wordt na 6 mislukte inlogpogingen geblokkeerd. Een beheerder moet het account dan opnieuw activeren.

Het wachtwoord moet worden bijgewerkt de volgende keer dat de gebruiker het wachtwoord opnieuw instelt of de beheerder een wachtwoord voor de gebruiker instelt.
Huidige wachtwoorden worden niet beïnvloed. Het bovenstaande is alleen van toepassing op wachtwoorden die worden gewijzigd of opnieuw worden ingesteld.

Nieuwe functionaliteit

Schema

Afwezigheid toevoegen/bewerken

In deze release hebben we enkele verbeteringen aangebracht zodat het niet mogelijk is om een afwezigheid te creëren met een duur langer dan 12 maanden.

Wanneer u een afwezigheid toevoegt of bewerkt, ziet u nu dat de datums na 12 maanden grijs worden weergegeven en dat het niet mogelijk is om ze te selecteren. Er wordt een tekst weergegeven waarin wordt uitgelegd waarom u die datums niet kunt selecteren wanneer u de muisaanwijzer erop plaatst:

Optimalisatie

In deze release hebben we alle informatie uit de artikelen met variabele instellingen, invoergegevens en prognoseconfiguratie gecombineerd in één artikel met de naam "Variabele instellingen en prognoseconfiguraties". Daar kun je hier meer over lezen.

Updates en prestatieverbeteringen

Wettelijke / Buitenwettelijke saldi per vastgestelde data

We hebben de mogelijkheid toegevoegd om wettelijke en bovenwettelijke vakantie-uren te bekijken op de dag voordat ze verlopen. Deze functionaliteit is gekoppeld aan Time Trackers die zijn ingesteld op "eerst verlopen" EN het zichtsaldo hebben per "maand / dag" .

Wanneer aan deze voorwaarden is voldaan, worden de statutaire en bovenwettelijke saldi weergegeven op de volgende data:

Statutory hours current year (2021) - Show as per 2022-06-30 (current year+1 : June 30)

Non - Statutory hours (2021) - Show as per 2026-12-31 (current year +5 years : December 31)

Statutory hours year - 1 (2020) - Show as per 2021-06-30 (year -1 +1 year : June 30)

Non - Statutory hours (2020) - Show as per 2025-12-31 (year -1 +5 year : December 31)

Non - Statutory hours (2019) - Show as per 2024-12-31 (year -2 +5 year : December 31)

Non - Statutory hours (2018) - Show as per 2023-12-31 (year -3 +5 year : December 31)

Non - Statutory hours (2017) - Show as per 2022-12-31 (year -4 +5 year : December 31)

Non - Statutory hours (2016) - Show as per 2021-12-31 (year -5 +5 year : December 31)

Vanuit gebruikersperspectief betekent dit dat er helemaal geen rekening wordt gehouden met de volgende keer dat de gekozen datums voorkomen. Dus alle geperiodiseerde Time Trackers die als eerste verlopen EN het saldo per maand/dag weergeven, hebben dezelfde hardgecodeerde datums. Lees meer over de "Nederlandse vakanties" hier .

Overeenkomst wijzigingen in ploegendienst

Wanneer een overeenkomst tijdens een ploeg wordt gewijzigd, wordt de geselecteerde overeenkomst nu ook overgenomen naar de aangesloten punch.

Bugfixes

  • Probleem opgelost met extra afwezigheden op dezelfde dag in combinatie met langdurige afwezigheid van hetzelfde type creëerde een extra "karensdag".
  • Er is een probleem opgelost dat ervoor zorgde dat de toegangscontrole bij de updatewachtwoordfunctionaliteit ontbrak.
  • Een probleem opgelost waardoor een eenheid niet kon worden opgeslagen als een manager die aan die eenheid was toegewezen en later de managerrol had verwijderd.
  • Er is een probleem opgelost waarbij managers hun eigen stoten konden goedkeuren, zelfs als 'Toestaan van eigen stoten toestaan' was uitgeschakeld.
  • Een probleem opgelost waarbij een afwezigheid langer dan drie maanden in het schema werd weergegeven, maar niet op de tijdkaart.
  • Een 400-fout opgelost toen een managerrol werd verwijderd van een medewerker nadat deze was toegewezen aan een eenheid.
  • Er is een probleem opgelost waarbij Unit-integratiesleutels niet konden worden ingevoerd.
  • Een probleem opgelost met ploegen tijdens het aanbreken van de dag waardoor werknemers die het basisschema als overuren gebruikten, ten onrechte overuren ontvingen voor alle ploegen wanneer ploegen die na middernacht waren uitgerold op de laatste dag van de uitrolperiode waren uitgerold.
  • Een probleem met de planningsweergave opgelost waardoor afwezigheid/ploegen niet werden weergegeven als onbeschikbaarheid op sectieniveau wanneer Maandweergave was geselecteerd.
  • Probleem opgelost met groepsbeheer waardoor een integratiesleutel voor een unit niet kon worden opgeslagen.
  • Een probleem opgelost waardoor een afwezigheidsploeg niet opnieuw kon worden toegewezen als de afwezigheid gedurende een lange periode plaatsvond.
  • Er is een probleem opgelost waarbij de statistiek 'Gewerkte/nominale werknemer' ten onrechte rekening hield met de instelling 'Tellen als geplande uren' van verzuimdiensten, wat problemen veroorzaakte bij het analyseren waarom werknemers overwerkvergoedingen ontvangen. Nu kijkt diezelfde statistiek in plaats daarvan naar de instelling 'Tellen als gewerkte uren' van afwezigheden.
  • Een probleem opgelost met dubbele vaardigheidscategorieën geretourneerd door wsdlGetSkillCategories
  • Een probleem opgelost met tijdzones in Webpunch met ongeplande stoten.

Nieuwe HelpDocs-artikelen

Houd er rekening mee dat we de komende weken HelpDocs zullen herschikken om beter af te stemmen op de manier waarop onze web-app is gestructureerd. Ons doel is om het u gemakkelijker te maken om de documentatie te vinden die u nodig heeft. Blijf kijken!

REST API/webservice-updates

SOAP API / webservice-updates

WsdlUpdateEmployee : nieuwe optionele vlag toegevoegd throwExceptionOnHomeUnitEndDate

Dit is een Booleaanse vlag waarvan sterk wordt aangeraden deze in te stellen op True. Dan ontvangt u een uitzondering als u rollen bijwerkt en de rol die u bijwerkt de enige bestaande rol is op de thuiseenheid van de werknemer.

Eindpunten worden verouderd en verwijderd

De volgende SOAP API-eindpunten worden stopgezet en verwijderd uit Quinyx WFM augustus 2021 . Ze zijn nu al vervangen door REST API-eindpunten voor Quinyx Forecast of verouderd. Lees meer over Quinyx Voorspelling en de verbeterde functionaliteit hier en over de nieuwe REST API's hier .

6.2 wsdlGetForecasts

6.3 wsdlUpdatePrognoses

6.5 wsdlGetMonthlyView

6.6 wsdlUpdateForecastV2

6.8 wsdlUpdatePrognosesV3

6.4 wsdlGetSalesData

6.9 wsdlGetSalesDataV2

6.7 wsdlGetOptimalPersoneel

4.6 wsdlUpdateAdminGroupRelationships <- niet van toepassing op Quinyx WFM

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 gebruik te maken van onze API's om gegevens bij te houden en ervoor te zorgen dat de informatie up-to-date is. Om de schaalbaarheid van onze API's te garanderen en tegelijkertijd ons klanten- en gebruikersbestand uit te breiden, hebben we besloten beperkingen toe te voegen aan het gebruik van onze SOAP API's. Deze beperkingen worden programmatisch afgedwongen en dat betekent dat we een limiet voor gelijktijdige oproepen per klant tot 10 zullen afdwingen. U kunt antwoordcode 429 verwachten als u deze limiet overschrijdt en het wordt aanbevolen om een backoff-retry-mechanisme te implementeren om de limiet af te handelen. Houd er rekening mee dat de limiet alleen van toepassing is op SOAP. Wanneer u de komende jaren van SOAP naar Rest gaat, worden eventuele limieten in de API ingebouwd. Zorg ervoor dat u deze informatie doorstuurt naar de partij binnen uw bedrijf die verantwoordelijk is voor integraties.


How did we do?